詳細
systemd次の関連ディレクティブを含むサービスファイルがあります。Type=forking
User=me
Restart=always
WantedByこのディレクティブはまだ設定されていません。
実行するcronジョブがありますsu –l me –c '<some command>'。
前提条件
私たちは以下を見つけました：
- サービスが開始されました
- ユーザー
meはいいえログインシステム
観察結果
cronジョブの実行が完了するたびに、System V IPCキューが消え、サービスが再起動されます。これは、キュー内で読み取り/休止中のプロセスが起きてキューが消えて失敗状態になったことを発見するためです。
cron操作が完了した後、システムログで次の内容を確認しました。
… systemd[1]: Stopped User Manager for UID XXX
考えられる解決策
私たちのinstalledファイルは次のとおりです。
$ cat /etc/systemd/logind.conf.d/my-service.conf
[Login]
KillUserProcesses=no
RemoveIPC=no
質問
読んだ後システム変更ログ 230、上記の可能な解決策が十分かどうかはまだ混乱しています。
私たちが特に混乱しているのはadditional steps are necessary to allow intentionally long-running processes to survive logout.
報告されたサービスの親は、サービスを開始するために規定されたステップがここに適用されないと私たちを信じさせますsystemd-cgls。これは本当ですか？現在サービスをリリースしていますsystem.slicesystemd-runsystemctl start my-service.service
それでもlingeringユーザーのためにそれを有効にする必要がありますかme？
助けてくれてありがとう。
ベストアンサー1
その必要もありませんKillUserProcesses=no。 RemoveIPC=noそれだけで十分です。
ユーザーの遅延を有効にするのが代替me手段です。違いは、systemd --userインスタンスが常に実行されていることです。
この動作はlogind.confのKillUserProcesses =設定によって制御されます。以前のデフォルト値「no」は「yes」に変更されました。これは、ユーザーセッションが後で適切にクリーンアップされますが、長期実行プロセスを意図的にログアウトしたままにするために追加の手順が必要であることを意味します。
この引用符は、KillUserProcesses = yesの場合にのみログアウト後もGNU Screenが引き続き実行されるようにするには、「追加ステップ」が必要であることを意味します。追加のステップはデフォルトでsystemd-run --user --scope COMMANDAND遅延を有効にすることです。
それはあなたの希望とは何の関係もありません。これは、サービスプロセスがログインセッション内で実行されていないためです。
systemd-cglsを見て得た結論は絶対に正確です。
別のアプローチは、ユーザーとしてログインしないことですme。 su一度のログインとみなされます。ユーザーのcrontabはログインしていると見なすことができます（/etc/pam.d/cronがpam_systemdへの直接または間接呼び出しを防止しない限り）。たとえば、su使用を置き換えるsetprivか、cronの代わりにsystemdタイマーデバイスを使用しますUser=me。