web-dev-qa-db-ja.com

systemdユーザーはユーザーグループの機能を取得できません

Dockerグループに非rootユーザーを追加し、この非rootユーザーがdockerデーモンに接続するときに他のサービスを実行しました。しかし、サービスは機能しません。私はこれのテスト例を行います：

root@# systemctl start docker.service 
root@# gpasswd -a tiger docker

tigerでsystemdサービスを作成します。

[Service]
ExecStart=/home/tiger/connectdocker
Restart=always
StartLimitInterval=0
Delegate=true
KillMode=process
[Install]
WantedBy=default.target

このような/home/tiger/connectdocker：

docker run -itd busybox 2> connectdocker.log

このサービスを開始します。

tiger@# systemctl --user enable connectdocker.service
tiger@# systemctl --user start connectdocker.service

そして結果：

Thu Jul 21 00:59:15 CST 2016
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

しかし、私はtigerでdocker.sockに接続できます：

tiger@# docker run -itd busybox
997e99f959cfd5500319935ec17677775da9d367d203a11efef8b42161c3ee64

証明のために、/var/run/docker.sockグループをdockerからtigerに変更すると、connectdockerサービスがdockerデーモンに接続できるようになります。

変更/var/run/docker.sock：

ls -l /run/docker.sock
srw-rw---- 1 root docker 0 Jul 21 00:33 /run/docker.sock

に：

ls -l /run/docker.sock
srw-rw---- 1 root tiger 0 Jul 21 00:33 /run/docker.sock
systemdusersgroupdocker
8
yongsu zhang

systemdサービスではUser=ディレクティブを使用する必要があります。

ユーザー=、グループ=

プロセスが実行されるUNIXユーザーまたはグループをそれぞれ設定します。単一のユーザー名またはグループ名、または数値IDを引数として取ります。システムサービス（システムサービスマネージャーによって実行されるサービス、つまりPID 1によって管理されるサービス）およびrootユーザーのユーザーサービス（systemd --userのrootのインスタンスによって管理されるサービス）の場合、デフォルトは「root」ですが、User =は別のユーザーを指定するために使用されます。他のユーザーのユーザーサービスの場合、ユーザーIDの切り替えは許可されていないため、有効な設定は、ユーザーのサービスマネージャーが実行されているのと同じユーザーのみです。グループが設定されていない場合は、ユーザーのデフォルトグループが使用されます。この設定は、コマンドラインの前に「+」が付いているコマンドには影響しません。

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#User=

また、スクリプトをホームディレクトリから/usr/local/binなどの標準パスに移動することをお勧めします。

また、connectdocker.serviceとAfter=docker.serviceを指定して、Requires=docker.serviceの順序を確認する必要があります。書かれているように、connectdocker.serviceはおそらくdocker.serviceとほぼ同時に開始しようとしているので、接続する前にdocker.serviceが起動するのを待つ必要があります。

必要=

他のユニットへの要件の依存関係を構成します。このユニットがアクティブになると、ここにリストされているユニットもアクティブになります。他のユニットの1つが非アクティブ化されるか、そのアクティブ化が失敗した場合、このユニットは非アクティブ化されます。このオプションは複数回指定することも、1つのオプションで複数のスペース区切りの単位を指定することもできます。その場合、リストされているすべての名前の要件の依存関係が作成されます。要件の依存関係は、サービスが開始または停止される順序に影響を与えないことに注意してください。これは、After =またはBefore =オプションを使用して個別に構成する必要があります。ユニットfoo.serviceがRequires =で構成されたユニットbar.serviceを必要とし、After =またはBefore =で順序付けが構成されていない場合、foo.serviceがアクティブ化されると、両方のユニットが同時に開始され、それらの間で遅延は発生しません。多くの場合、障害のあるサービスを処理するときに、より堅牢なシステムを実現するために、Requires =の代わりにWants =を使用することをお勧めします。

この依存関係タイプは、このユニットの実行中に他のユニットが常にアクティブ状態である必要があることを意味するものではないことに注意してください。具体的には、条件チェック（ConditionPathExists =、ConditionPathExists =、…—以下を参照）に失敗しても、Requires =依存関係を持つユニットの開始ジョブは失敗しません。また、一部のユニットタイプは、それ自体で非アクティブ化される場合があり（たとえば、サービスプロセスが正常に終了することを決定したり、ユーザーがデバイスのプラグを抜いたりする場合があります）、これはRequires =依存関係を持つユニットに伝達されません。 BindsTo =依存関係タイプをAfter =と一緒に使用して、特定の他のユニットがアクティブ状態になっていない限り、ユニットがアクティブ状態にならないようにします（以下を参照）。

このタイプの依存関係は、ユニットファイルに付随する.requires /ディレクトリにシンボリックリンクを追加することにより、ユニット構成ファイルの外部で構成することもできることに注意してください。詳細については、上記を参照してください。

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=

1
Centimane