☰

システムとプロセスの作成：基本プロセスが終了すると、子プロセスは終了します。

tag-icon • tag-icon systemd process-management sysvinit
システムとプロセスの作成：基本プロセスが終了すると、子プロセスは終了します。

普段はここに投稿しませんが、今回の投稿のために投稿します。起動時に分岐し、他のさまざまなプロセスの起動を担当するPythonスクリプトがあります。このスクリプトは起動時に実行されましたが、sysvinit最近Debian Jessieにアップグレードしてくださいsystemd。

残念ながら解決できない問題に封着しました。ユーザーシェルから直接スクリプトを起動すると、その子プロセスが正しく起動され、スクリプトが終了すると子プロセスが孤立して実行され続けます。

systemdを介して起動したときに親プロセスが終了すると、子プロセスも終了しますscreen。

理想的には、すべての子プロセスを終了せずに親スクリプトを再起動できる必要があります。欠けているものはありますか？

ありがとうございます！

[Unit]
Description=Server commander
After=network.target

[Service]
User=serveruser
Type=forking
PIDFile=/var/Server/Server.pid

ExecStart=/var/Server/Server.py
ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

編集する：

Pythonスクリプトは本質的に子プロセスの「コントローラ」であることを指摘するのが適切かもしれません。screen中央サーバーからの要求に応じて、GNUでサーバーを起動および停止します。通常は常に実行され、サービスを作成せずに終了します。

しかし、場合によっては、プロセスがpid 1で孤児になったとしても、子プロセスを終了せずにスクリプトを再ロードできるようにしたいです。実際、Pythonスクリプトがプロセスを親プロセス（可能な場合）で開始するかどうかは重要ではありません。

仕組みのより良い説明：

  • systemd生産するServer.py
  • Server.pyフォークしてpidファイルに書き込みます。systemd
  • Server.py次に、指示に従ってGNU画面でサーバープロセスを作成します。
  • Server.pyサーバーから要求された再起動を実行するには、引き続き実行してください。

始めにいいえ systemd、Server.py再起動でき、起動するGNUはscreens影響を受けません。起動を使用すると、終了するsystemdとServer.pypid 1に孤立するのではなく、これらの画面プロセスが終了します。

答え1

KillModeprocess（デフォルト）の代わりに設定してcontrol-groupこの問題を解決しました。みんなありがとうございます！

答え2

起動時に分岐し、他のさまざまなプロセスの起動を担当するPythonスクリプトがあります。

これは、何かが間違っていることを示します。これについては後で詳しく説明します。

スクリプトが終了すると、子プロセスは孤立して継続的に実行されます。

これは正しいデーモン動作ではありません。 「デフォルト」プロセス（この場合は指定したサブプロセスType=forking）が終了すると、systemdはサービスがダウンしていると見なし、まだ実行中の他のプロセス（制御グループ内）を終了してクリーンアップします。

時々、System 5スクリプトをsystemdに変換することは、rcsystemdで作業を実行する正しい方法が非常に異なるため、単純ではありません。たとえば、systemdでOpenVPN、OpenStack、またはOSSEC HIDSを実行する正しい方法は、スクリプトを使用してこれを実行するのとは異なりますrc。フォークするスクリプトがあり、完全な孫プロセスを作成して終了し、その孫プロセスが実行され続けることを期待しているという事実は、個々のossec-controlフォークレベルが2段階低いにもかかわらず同じ恐ろしい行為を犯していることを示唆しています。 「アクティブ化」フラグを確認し、システムの「アクティブ化」部分のサブプロセスを実行する「メイン」スクリプトを作成している場合は、ひどいことをしていますossec-control。

systemdにはそのような基本的なメカニズムは必要ありません。それすでにサービスマネージャ。すべてhttps://unix.stackexchange.com/a/200365/5132、systemdでこの問題を解決する正しい方法は、1つのサービスが奇妙で混乱した「サブサービス」試行を生成しないようにすることです。これは、各サブプロセスをそれ自体で完全なシステムサービスとして扱います。次に、通常のシステムコントロールを使用して、システムのさまざまな部分を有効および無効にし、起動および停止します。 OSSEC HIDSのケースに見られるように、単純なテンプレートサービスユニットはほぼすべてをカバーします（例外は https://askubuntu.com/a/624871/43344）サービスを使用すると、System 5が要求する恐ろしい「マスタースクリプト」メカニズムなしでオプションのサービスを有効にするなどのタスクを実行できます。systemctl enable [email protected]agentlessdrc

多くの場合、これらの在庫が必要ですが、おそらくOSSEC HIDSほど極端ではありません。 eximやsendmailなどのMTSはその2つです。rcキュー・ランチャー、SMTP送信デーモン、SMTPリレー・デーモンを生成するスクリプトがあり、構成ファイル内の一時シェル変数を使用して実行される項目を正確に制御できます。しかし、systemdを使用してこれを行う正しい方法は次のとおりです。3つの適切なサービスユニット（二つがつながっています。ソケットユニット）一時的な作業はまったくなく、サービスマネージャの一般的なメカニズムしかありません。

答え3

親プロセスをスリープ状態にし、systemdが停止時にそのプロセスを終了するのを待つことができます。

関連情報