☰

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

tag-icon • tag-icon systemd users group docker
systemdユーザーはユーザーグループの能力を取得できません

root以外のユーザーをdockerグループに追加し、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

ベストアンサー1

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

ユーザー=、グループ=

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

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

また、スクリプトをホームディレクトリから/usr/local/bin。

connectdocker.serviceAfter=docker.serviceまた、およびを提供して注文を確認する必要がありますRequires=docker.service。書かれているように、connectdocker.service起動とほぼ同時に起動を試みることができ、接続する前に起動になるまでdocker.service待つ必要があります。docker.service

必要=

他のユニットの要件依存関係を構成します。このデバイスがアクティブになると、ここにリストされているデバイスもアクティブになります。他のデバイスのいずれかが無効または有効になっていない場合、このデバイスは無効になります。このオプションは複数回指定することも、1つのオプションでスペースで区切った複数の単位で指定することもできます。この場合、リストされているすべての名前に対して要件の依存関係が生成されます。需要依存性は、サービスの開始または停止の順序には影響しません。これはAfter =またはBefore =オプションを使用して独立して設定する必要があります。 foo.service デバイスに Requires= で構成される bar.service デバイスが必要で、After= または Before= で構成された順序がない場合、foo.service が有効になると、2 つのデバイス間で遅延なく同時に起動されます。通常、失敗したサービスに対してシステムをより強力にするには、Requires =の代わりにWants =を使用することをお勧めします。

この依存関係タイプは、このデバイスが実行されているときに他のデバイスを常にアクティブにする必要があるわけではありません。具体的には、失敗した条件チェック（ConditionPathExists =、ConditionPathExists =、... - 以下を参照）は、Requires =依存関係を持つデバイスの起動操作に失敗することはありません。さらに、一部のデバイスタイプはそれ自体で無効にすることができます（たとえば、サービスプロセスが完全に終了することを決定したり、ユーザーがデバイスのプラグを抜くことがあります）。これはRequires =依存関係を持つデバイスには伝播されません。 After= と共に BindsTo= 依存関係タイプを使用すると、他の特定のユニットもアクティブでない限り、そのユニットがアクティブにならないようにすることができます (下記参照)。

このタイプの依存関係は、デバイスファイルに付属の.requires /ディレクトリにシンボリックリンクを追加することによってデバイス設定ファイルの外部で設定することもできます。詳しくは上記をご覧ください。

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

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

おすすめ記事