Systemdとプロセスの生成

通常はここに投稿しないでくださいが、私はこの髪の毛を切り取っています。起動時に分岐し、他のプロセスの束を開始するPythonスクリプトがあります。このスクリプトは、起動時にsysvinitを介して起動されていましたが、最近Debian Jessieにアップグレードしたため、systemdを介して起動するように適合させました。

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

systemdを介して起動した場合、親プロセスが終了すると、子もすべて終了します（まあ、画面はダイで起動し、死んでいるように見えますか？）

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

ありがとう！

[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スクリプトは、本質的にその子プロセスの「コントローラー」であると指摘することはおそらく関連があります。中央サーバーからの要求に応じて、GNU画面でサーバーを起動および停止します。通常は常に実行されており、サービスを生成して終了しません。ただし、プロセスがpid 1に孤立していることを意味する場合でも、子プロセスを強制終了せずにスクリプトをリロードできるようにしたい場合があります。実際、Pythonスクリプトが可能であれば、親プロセス。

仕組みのより良い説明：

• Systemdは/Server.pyを生成します
• Server.pyはSystemdのpidファイルを分岐して書き込みます
• Server.pyは、その指示に基づいてgnu画面にサーバープロセスを生成します
• Server.pyは、サーバーから要求された再起動を実行するために実行を続けます

Systemdを使用せずに起動すると、Server.pyを再起動でき、起動するgnu画面は影響を受けません。Systemdで起動すると、Server.pyがシャットダウンすると、それらのスクリーンプロセスがpid 1に孤立する代わりに、それらは強制終了されます。

KillModeをcontrol-group（デフォルト）の代わりにprocessに設定するだけで、これを修正できました。皆さんありがとう

起動時に分岐し、他のプロセスの束を開始するPythonスクリプトがあります。

これは、あなたが間違っていることを示しています。これについては後ほど説明します。

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

これは正しいデーモンの振る舞いではありません。「メイン」プロセス（この場合は指定したためにフォークした子）がType=forking終了すると、systemdはサービスが非アクティブになったと見なし、整頓するために他のまだ実行中のプロセス（制御グループ内）を終了します。

rcsystemdの下で物事を行う正しい方法はまったく異なるため、System 5 スクリプトからsystemd への変換は簡単ではない場合があります。systemdで（たとえば）OpenVPN、OpenStack、またはOSSEC HIDSを実行する正しい方法は、rcスクリプトを使用して行う方法とは異なります。分岐しているスクリプトがあり、孫プロセスの負荷をすべて生成し、それらの孫が実行し続けることを期待して終了しているという事実は、分岐のossec-controlレベルが2つ少ないにもかかわらず、同じ種類の恐怖を犯していることを示しています。「有効」フラグをチェックし、システムの「有効」な部分の子プロセスを実行する「マスター」スクリプトを作成していることに気付いossec-controlた場合、恐ろしいと同じ間違いを犯しています。

systemdでは、こうした独自のメカニズムは必要ありません。これは、すでにあるサービスマネージャ。パー/unix//a/200365/5132、systemdにこのについて移動する正しい方法は、「サブサービス」を持っているスポーンいくつかの奇抜な混乱の試みというつのサービスを持っているではありません。それは、それぞれの子プロセスがそれ自体で完全なsystemdサービスとして持つことです。次に、通常のsystemdコントロールを使用して、システムのさまざまな部分を有効または無効にし、起動および停止します。OSSEC HIDSのケースでわかるように、シンプルなテンプレートサービスユニットはほとんどすべてのサービス（1つの例外は/ubuntu//a/624871/43344にあります）をカバーし systemctl enable ossec@agentlessd.service、オプションを有効にするなどのことを可能にしますagentlessdサービス、System 5で必要だった恐ろしい「マスタースクリプト」メカニズムはまったく必要ありませんrc。

OSSEC HIDSほど極端ではないかもしれませんが、そのような再考が必要なケースはたくさんあります。eximやsendmailのようなMTSはそのようなものです。rcキューランナー、SMTP送信デーモン、およびSMTPリレーデーモンを生成する単一のスクリプトがあり、実行するものを正確に制御するために、構成ファイルに多数のアドホックシェル変数が含まれている場合があります。しかし、systemdでこれを行う正しい方法は、3つの適切なサービスユニット（そのうち2つはソケットユニットに関連付けられています）を使用し、アドホックなものはまったくなく、サービスマネージャーの通常のメカニズムだけです。

親をスリープさせ、停止時にsystemdがそれを殺すのを待つことができます。