デーモンを作成するときにダブルフォークを実行する理由は何ですか？

私はpythonでデーモンを作成しようとしています。私が現在フォローしているいくつかの良いリソースを持っている次の質問を見つけましたが、なぜダブルフォークが必要なのか知りたいです。私はグーグルをひっくり返しました、そしてそれが必要であると宣言する多くのリソースを見つけました、しかし理由はではありません。

デーモンが制御端末を取得できないようにするためだと言う人もいます。2番目のフォークなしでこれをどのように実行しますか？反響とは何ですか？

質問で参照されているコードを見ると、正当化は次のとおりです。

2人目の子供をフォークし、ゾンビを防ぐためにすぐに終了します。これにより、2番目の子プロセスが孤立し、initプロセスがそのクリーンアップを担当します。また、最初の子は制御端末を持たないセッションリーダーであるため、将来端末を開くことで取得できます（System Vベースのシステム）。この2番目のフォークは、子がセッションリーダーではないことを保証し、デーモンが制御端末を取得するのを防ぎます。

したがって、デーモンがinitに親を再設定し（デーモンを開始するプロセスが長命である場合に備えて）、確実にデーモンが制御ttyを再取得する可能性を排除します。したがって、これらのどちらのケースにも当てはまらない場合は、1つのフォークで十分です。「Unixネットワークプログラミング-Stevens」には、これに関する優れたセクションがあります。

私はダブルフォークを理解しようとしていて、この質問をここで偶然見つけました。多くの研究の後、これは私が考え出したものです。うまくいけば、それは同じ質問を持つ誰にとっても物事をより明確にするのに役立つでしょう。

Unixでは、すべてのプロセスがグループに属し、グループはセッションに属しています。これが階層です…

セッション（SID）→プロセスグループ（PGID）→プロセス（PID）

プロセスグループの最初のプロセスがプロセスグループリーダーになり、セッションの最初のプロセスがセッションリーダーになります。すべてのセッションに1つのTTYを関連付けることができます。セッションリーダーだけがTTYを制御できます。プロセスが本当にデーモン化される（バックグラウンドで実行される）には、セッションリーダーが強制終了され、セッションがTTYを制御する可能性がないようにする必要があります。

私は、UbuntuでこのサイトからSander MarechalのPythonサンプルデーモンプログラムを実行しました。これが私のコメント付きの結果です。

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046
2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046
3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085
4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

プロセスがなDecouple#1ので、後にセッションリーダーになることに注意してくださいPID = SID。それでもTTYを制御できます。

Fork#2はセッションリーダーではなくなりましたPID != SID。このプロセスがTTYを制御することはありません。本当にデーモン化。

個人的に、2倍の用語で混乱していると思います。より良いイディオムはfork-decouple-forkかもしれません。

興味のある追加リンク：

• Unixプロセス-http://www.win.tue.nl/~aeb/linux/lk/lk-10.html

厳密に言えば、ダブルフォークはデーモンをの子として再ペアレント化することとは何の関係もありませんinit。子を再親化するために必要なことは、親が終了する必要があることだけです。これは、単一のフォークだけで実行できます。また、それだけでダブルフォークを実行しても、デーモンプロセスの親はに変更されませんinit。デーモンの親は終了する必要があります。つまり、適切なデーモンをフォークすると、親は常に終了し、デーモンプロセスの親がに変更されinitます。

では、なぜダブルフォークなのでしょうか。POSIX.1-2008セクション11.1.3「Controlling Terminal」には答えがあります（強調を追加）：

セッションの制御端末は、実装で定義された方法でセッションリーダーによって割り当てられます。セッションリーダーに制御端末がなく、O_NOCTTYオプションを使用せずにセッションに関連付けられていない端末デバイスファイルを開く場合（を参照open()）、端末がセッションリーダーの制御端末になるかどうかは実装定義です。セッションリーダーではないプロセスが端末ファイルを開いたO_NOCTTY場合、またはオプションがで使用されたopen()場合、その端末は呼び出しプロセスの制御端末にはなりません。

これは、デーモンプロセスがこのようなことをする場合...

int fd = open("/dev/console", O_RDWR);

...次に、デーモンプロセスが/dev/consoleセッションリーダーであるかどうか、およびシステムの実装に応じて、デーモンプロセスが制御端末として取得する場合があります。プログラムは、プログラムが最初にセッションリーダーでないことを確認すると、上記の呼び出しが制御端末を取得しないことを保証できます。

通常、デーモンを起動すると、setsidが呼び出され（を呼び出した後の子プロセスからfork）、デーモンをその制御端末から切り離します。ただし、呼び出しsetsidは、呼び出しプロセスが新しいセッションのセッションリーダーになることも意味します。これにより、デーモンが制御端末を再取得できる可能性が残ります。ダブルフォーク技術は、デーモンプロセスがセッションリーダーではないことを保証します。これopenにより、上記の例のようにへの呼び出しが、デーモンプロセスが制御端末を再取得することはありません。

ダブルフォークのテクニックは少し偏執的です。デーモンが端末デバイスファイルを開かないことがわかっている場合は、必要ない場合があります。また、一部のシステムでは、動作が実装定義であるため、デーモンが端末デバイスファイルを開いたとしても、その必要がない場合があります。ただし、実装で定義されていないことの1つは、セッションリーダーだけが制御端末を割り当てることができることです。プロセスがセッションリーダーでない場合は、制御端末を割り当てることができません。したがって、偏執的になり、実装定義の詳細に関係なく、デーモンプロセスが制御端末を誤って取得できないようにしたい場合は、ダブルフォークテクニックが不可欠です。

Bad CTKから取得：

「Unixの種類によっては、デーモンモードに移行するために、起動時にダブルフォークを実行する必要があります。これは、シングルフォークが制御端末から切り離されることが保証されていないためです。」

StephensとRagoによる「Unix環境での高度なプログラミング」によると、2番目のフォークはより推奨されており、デーモンがSystem Vベースのシステムで制御端末を取得しないことを保証するために行われます。

1つの理由は、親プロセスがすぐに子のwait_pid（）を実行し、その後それを忘れることがあるためです。その後、孫が死ぬと、その親はinitであり、それを待機（）し、ゾンビ状態からそれを取り出します。

その結果、親プロセスはforkされた子を認識する必要がなくなり、libなどから長時間実行されているプロセスをforkすることも可能になります。

daemon（）呼び出しは、成功すると親呼び出し_exit（）を持ちます。元々の動機は、子供がデーモン化している間、親が追加の作業を行えるようにすることでした。

これは、デーモンに親プロセスがなく、initに親が変更されていることを確認するために必要であるという誤った考えに基づいている可能性もあります。ただし、これは、親がシングルフォークの場合に終了すると発生します。

つまり、結局のところ、すべてが伝統に帰着するものだと思います。親がいずれにせよ短期間で死ぬ限り、1つのフォークで十分です。

それについての適切な議論はhttp://www.developerweb.net/forum/showthread.php?t=3025にあるようです

そこからmlampkinを引用：

... setsid（）呼び出しを「端末」からの関連付けを解除する「新しい」方法として考え、その後の[second] fork（）呼び出しは、SVr4を処理する冗長性として...

この方法で理解する方が簡単かもしれません：

• 最初のforkとsetsidは新しいセッションを作成します（ただし、プロセスID ==セッションID）。
• 2番目のフォークは、プロセスID！=セッションIDを確認します。