端末からプロセスを分離する手順は何ですか？そのためにマンページを見つけました。daemon()説明では、彼らは言及しています。
nochdirが0の場合、daemon（）はプロセスの現在の作業ディレクトリをルートディレクトリ（ "/"）に変更します。それ以外の場合、現在の作業ディレクトリは変更されません。
nocloseが0の場合、daemon（）は標準入力、標準出力、および標準エラーを/ dev / nullにリダイレクトします。それ以外の場合、これらのファイル記述子は変更されません。
実際、私はPythonコードをデーモンとして実行しようとしています。tcollectorコードが見つかりました。ここ。このコードは説明と同じ手順に従いますdaemon()。だから私の質問は、私たちがこのステップを実行する理由は何ですか（wrtdaemonize()からtcollector）のように
なぜ、dirに変更してから電話などに変更しますか？/umask022os.setsid()
ベストアンサー1
実際に引用したものよりも多くの内容がありますが、マニュアルページがより明確になると思います。
nochdirが0の場合、
daemon()プロセスの現在の作業ディレクトリをルートディレクトリ（/）に変更します。
ここでは、プログラムが管理者のコマンドラインから始まると仮定し、その時点で管理者が実行するタスクからデーモンプロセスを分離することがアイデアです。/デーモンがマウントポイントを引き続き使用しないように、作業ディレクトリを変更します。たとえば、作業ディレクトリがあり、/home/adminしばらくしてからマウントを解除したい場合、/homeデーモンはこれを防ぎます。
nocloseが0の場合、
daemon()標準入力、標準出力、および標準エラーがリダイレクトされます/dev/null。
これは、デーモンが端末などにエラーメッセージを記録してユーザーを混乱させないようにするためです。デーモンがしなければならないことは、おそらく（設定された）ログファイルを開き、外部の世界と通信するために必要なものをすべて書き込むことです。
（この関数は分岐し、fork（2）が成功すると、親は_exit（2）を呼び出して子だけが追加のエラーを見ることができます。）
繰り返しますが、管理者シェルセッションから切断するためにデフォルトプログラムがすぐに返され、残りはバックグラウンドに残るため、プログラムがバックグラウンドで起動するように明示的に要求する必要はありません（例./daemon &：）
これで、マニュアルページではこれを明示的に言及していませんが、ここにヒントがあります（エラーの下）。
この関数のGNU Cライブラリ実装はBSDから取得され、生成されたデーモンを保証するために必要なデュアルフォーク技術（つまり、fork（2）、setid（2）、fork（2））を使用しません。セッションリーダーではありません。代わりに、生成されたデーモンはセッションリーダーです。
daemon()電話でもsetsid()セッションから抜け出す制御端子したがって、端末から信号が送信されます。ただし、引用文が示すように、端末装置を開くと、誤って制御端末として使用される可能性があります。これを防ぐために、一部のプログラムは子プロセスから呼び出され、再フォークして両方の親プロセスをfork()終了setsid()し、結果のプロセスはセッションリーダーではなく（中間のプロセス）、制御端末を取得できません。あなたが言及したPythonプログラムはまさにこれを行います。
変更はumaskデーモンと関係がないようです。たぶん、プログラムにはこれに対する特別な要求があるかもしれません。