☰

Systemdは何の理由もなくドッカーデーモンを停止しました。

tag-icon • tag-icon systemd docker
Systemdは何の理由もなくドッカーデーモンを停止しました。

systemdがdockerdに終了シグナルを送信する理由を調べたいと思います。これはこれに関連していますスタックオーバーフローポスト。

$ journalctl -r

Dec 01 06:25:05 ip-10-38-4-210 dockerd[2218]: time="2020-12-01T06:25:05.867748396Z" level=info msg="Processing signal 'terminated'"
Dec 01 06:25:05 ip-10-38-4-210 systemd[1]: Stopping Docker Application Container Engine...
Dec 01 06:25:03 ip-10-38-4-210 CRON[23453]: pam_unix(cron:session): session closed for user root
Dec 01 06:25:01 ip-10-38-4-210 systemd[1]: Starting Daily apt upgrade and clean activities...
Dec 01 06:25:01 ip-10-38-4-210 CRON[23454]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Dec 01 06:25:01 ip-10-38-4-210 CRON[23453]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 01 06:17:01 ip-10-38-4-210 CRON[23441]: pam_unix(cron:session): session closed for user root
Dec 01 06:17:01 ip-10-38-4-210 CRON[23442]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec 01 06:17:01 ip-10-38-4-210 CRON[23441]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 01 06:06:54 ip-10-38-4-210 CRON[23406]: pam_unix(cron:session): session closed for user root

dockerが停止する前の最後のログエントリはですCRON[23453]: pam_unix(cron:session): session closed for user root。このアイテムは関連性があると思いますか？

これはx86-64のUbuntu 16.04.6 LTSにあります。

答え1

この特別な場合、systemdにdockerサービスを停止するように指示するのは、Ubuntu無人アップデートサービスが更新されたUbuntuバージョンのコンテナ化パッケージを適用することです。今日、多くの人が同じ問題の影響を受けていることを示唆する一般的な質問があります。

https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1870514

このリンクのジャーナルは次のとおりです。

Apr 03 06:09:31 server systemd[1]: Starting Daily apt upgrade and clean activities...
...
Apr 03 06:09:43 server systemd[1]: Stopping Docker Application Container Engine...

私が提案する解決策は、アップストリームDockerリポジトリにDockerをインストールすることですが、この問題はないようです。

https://docs.docker.com/engine/install/ubuntu/

答え2

すでに承認された答えがあることを知っていますが...

dockerが停止する前の最後のログエントリは、CRON [23453]：pam_unix（cron：session）：ユーザールートに対して返されたセッションです。これは関連性があると思いますか？

はい、関連性があるようですが、この場合はそうではありません。この問題に直面した根のないドッカーを実行している将来の人々が解決策を得ることができるように、ここに答えます。

-drootlessモードでドッカーを設定し、ubuntuMy User（AW​​S Lightsailインスタンス）の下で分離モード（フラグ）で長期実行ドッカーコンテナをホストしようとしています。これにより、dockerデーモンとコンテナが正常に終了します。

解決策

宿泊可能

sudo loginctl enable-linger $USER

確実にするために、/etc/systemd/logind.conf次の行を編集して最後に追加してください。

UserStopDelaySec=infinity
KillUserProcesses=no

新しい設定を適用するには、コンピュータを再起動します。

sudo reboot

犯罪者

問題は、systemdログインセッション（SSHターミナルセッション）で開始されたプロセスを処理する方法です。デフォルトでは、ユーザーがログアウトした後にプロセスにsystemd送信されます。SIGTERM10s文書によると。

UserStopDelaySec=

ユーザー履歴とユーザー固有のサービスを保持する期間を指定してください。[Eメール保護]ユーザーが完全にログアウトした後。 0に設定すると、ユーザーの最後のセッションが終了するとすぐにユーザー固有のサービスが終了します。このオプションをゼロ以外の値に設定すると、ユーザーのサービス管理者は継続的に再起動しないため、高速ログオフ/ログインサイクルが加速されます。 「無制限」に設定すると、ユーザーのユーザー固有のサービスは最初のログイン後に終了しなくなり、システムが終了するまで実行され続けます。デフォルトは10秒です。

KillUserProcesses=

ブールパラメータを使用します。ユーザーがログオフするときにユーザーのプロセスを終了するかどうかを設定します。 true の場合、セッションに対応する範囲単位とその範囲内のすべてのプロセスが終了します。 falseの場合、範囲は「破棄」されます（systemd.scope（5）を参照）。プロセスは終了しません。デフォルトは「いいえ」です。ただし、下記の KillOnlyUsers= および KillExcludeUsers= オプションをご覧ください。

もちろん、リンガーモードが有効になっていない限り、ここに録音してください

enable-linger [USER...], disable-linger [USER...]

1人以上のユーザーのユーザー遅延を有効/無効にします。特定のユーザーに対して有効になっている場合、起動時にそのユーザーのユーザー管理者が作成され、ログアウト後も保持されます。これにより、ログインしていないユーザーが長期実行サービスを実行できるようになります。 1 つ以上のユーザー名または数値 UID を引数として使用します。引数が指定されていない場合は、呼び出し側セッションユーザーの遅延を有効/無効にします。

私それについてブログを書いた詳しくは確認したい場合はご覧いただけます。

関連情報