systemd私は非常に長い間実行されるコマンド1（時間単位で測定）を管理するために独自のユニットファイルを作成したいと思います。検索中systemdに関するArchWiki記事、開始タイプの選択について、次のように説明します。
Type=simple（デフォルト）：systemdはサービスがすぐに開始されると見なします。プロセスは分岐してはいけません。。このサービスに対して別のサービスを注文する必要がある場合は、ソケットがアクティブでない限り、このタイプを使用しないでください。
なぜフォークをまったく処理できないのですか？デーモンがプロセスを呼び出す方法（親フォーク後に終了）でフォークを意味しますか、それともどのようなフォークを意味しますか？
1 tmux/screenに依存せずに状態を確認し、サービスを再起動するよりエレガントな方法が必要なので、tmux/screenは不要ですtmux send-keys。
ベストアンサー1
サービスがforkシステムコールを実行できるようにします。 Systemdはこれをブロックせず、ブロックしてもそれを認識しません。この文は、特にデーモンプロセスを親プロセスから分離するためにデーモンプロセスの先頭から分岐する慣行を表します。 「プロセスは、[サブプロセスでサービスが実行されている間に親プロセスを終了して]分岐しないでください。」
これマニュアルページこれについては、より詳細に説明し、これらの特別な混乱を引き起こさない表現として説明します。
デーモンとして使用される多くのプログラムには、起動時に親プロセスから自分自身を分離するモード（通常はデフォルトモード）があります。デーモンが起動し、呼び出された後に親fork()プロセスが終了します。子プロセスはそれを呼び出してsetsid()独自のプロセスグループとセッションで実行し、サービスを実行します。その目的は、シェルコマンドラインからデーモンを呼び出すと、端末に何が起こっても（たとえば、端末を閉じる）、デーモンがカーネルやシェルから信号を受け取らないことです（この場合、シェルはすべてのプロセスグループを知っています）ターミナルにSIGHUPを送信します。これにより、サービスプロセスがinitによって採用され、終了時にそれを収集して次のことを防ぎます。ゾンビデーモンが不適切なものによって開始された場合wait()（デーモンがシェルによって開始された場合、これは起こりません）。
systemdのような監視プロセスによってデーモンが起動されると、フォークは非生産的です。サービスがクラッシュした場合、監視プロセスはサービスを再起動する必要があるため、サービスが終了したかどうかを知る必要があります。サービスが監視プロセスの直接的なサブアイテムではない場合、これは困難です。監視プロセスは永遠に消えてはいけません。制御する端末がないため、不要な信号やハーベストを心配する必要はありません。したがって、サービスプロセスがモニターの子プロセスにならない理由はなく、そうするのに十分な理由があります。