この Arch wiki ページは無視してください。

Question 1

サービスはforkシステムコールを呼び出すことができます。Systemd はこれを阻止しませんし、阻止されても通知しません。この文は、デーモンを親プロセスから分離するためにデーモンの開始時にフォークする手法に特に言及しています。「プロセスはフォークしてはなりません [子プロセスでサービスを実行している間に親を終了してはなりません]」。

のマニュアルページこれをより詳細に、そしてこの特定の混乱を引き起こさない言葉で説明します。

デーモンとして使用される多くのプログラムには、起動時に親から分離するモード（多くの場合、デフォルトモード）があります。デーモンが起動し、を呼び出しfork()、親が終了します。子プロセスはを呼び出してsetsid()、独自のプロセスグループとセッションで実行し、サービスを実行します。その目的は、デーモンがシェルコマンドラインから呼び出された場合、端末が閉じるなど端末に何かが起こっても（この場合、シェルは認識しているすべてのプロセスグループに SIGHUP を送信します）、デーモンはカーネルまたはシェルからシグナルを受信しないようにすることです。これにより、サービスプロセスが init に採用され、終了時に init がそれを取得するため、ゾンビデーモンが、デーモンwait()にとって不適切な何かによって起動された場合 (デーモンがシェルによって起動された場合は、このようなことは起こりません)。

デーモンが systemd などの監視プロセスによって起動される場合、フォークは逆効果になります。監視プロセスは、サービスがクラッシュした場合にサービスを再起動することになっているため、サービスが終了したかどうかを知る必要がありますが、サービスが監視プロセスの直接の子でない場合は困難です。監視プロセスは終了することがなく、制御端末もないため、不要なシグナルやリーピングに関する懸念はありません。したがって、サービスプロセスがモニターの子にならない理由はなく、そうする十分な理由があります。

Answer

サービスはforkシステムコールを呼び出すことができます。Systemd はこれを阻止しませんし、阻止されても通知しません。この文は、デーモンを親プロセスから分離するためにデーモンの開始時にフォークする手法に特に言及しています。「プロセスはフォークしてはなりません [子プロセスでサービスを実行している間に親を終了してはなりません]」。

のマニュアルページこれをより詳細に、そしてこの特定の混乱を引き起こさない言葉で説明します。

デーモンとして使用される多くのプログラムには、起動時に親から分離するモード（多くの場合、デフォルトモード）があります。デーモンが起動し、を呼び出しfork()、親が終了します。子プロセスはを呼び出してsetsid()、独自のプロセスグループとセッションで実行し、サービスを実行します。その目的は、デーモンがシェルコマンドラインから呼び出された場合、端末が閉じるなど端末に何かが起こっても（この場合、シェルは認識しているすべてのプロセスグループに SIGHUP を送信します）、デーモンはカーネルまたはシェルからシグナルを受信しないようにすることです。これにより、サービスプロセスが init に採用され、終了時に init がそれを取得するため、ゾンビデーモンが、デーモンwait()にとって不適切な何かによって起動された場合 (デーモンがシェルによって起動された場合は、このようなことは起こりません)。

デーモンが systemd などの監視プロセスによって起動される場合、フォークは逆効果になります。監視プロセスは、サービスがクラッシュした場合にサービスを再起動することになっているため、サービスが終了したかどうかを知る必要がありますが、サービスが監視プロセスの直接の子でない場合は困難です。監視プロセスは終了することがなく、制御端末もないため、不要なシグナルやリーピングに関する懸念はありません。したがって、サービスプロセスがモニターの子にならない理由はなく、そうする十分な理由があります。

Question 2

この Arch wiki ページは無視してください。

設定に関してはかなり間違っていますType。さらに、これはの記述に限ったことではありませんsimple。についての記述forkingも間違っています。

この種の正しい推奨事項は、systemd自体が存在するよりも数十年も前から存在しており、少なくとも1990年代初頭にまで遡ります。https://unix.stackexchange.com/a/476608/5132systemd のドキュメントには、デーモンに関する推奨事項の最近のバージョンがあり、daemontools ユーザー、IBM、を使用している人々inittab、そして…まあ…私が何十年も言ってきたことをほぼ繰り返しています。(2001 年に私がそのように書いたとき、それはすでに頻繁に返答されていました。)

繰り返す：

プログラムに「デーモン化」メカニズムがあり、特に子プロセスをフォークして親プロセスを終了する場合、消してそして使用しないでくださいdaemontoolsなどのおかげで、長い間これが必須となっていた多くのプログラムが、持っていないこのようなメカニズムは過去 20 年以上にわたって開発されてきましたが、他のメカニズムは最初から「デーモン化」をデフォルトとしていないため、デフォルトの動作モードで使用できます。

サービス管理サブシステムはサービスプロセスを起動するデーモンの文脈ではすでにこれらのプロセスは「デーモン化」する必要はありません。（実際、多くの現代のオペレーティングシステムでは、プログラムがデーモン化されると考えるのは誤りです。できるログインセッションコンテキストから「デーモン化」する。これが「デーモン化」の実際の目的である。) デーモンコンテキストに適した環境値とオープンファイル記述子が既に存在し、実際に「デーモン化」によって実行されるいくつかの処理が行われている。妨害するサービスマネージャーによってデーモンで定期的に実行される従来の処理の一部 (標準出力/エラーをログにキャプチャするなど)。

Type=simple早期ソケットオープン（サービス管理がサーバーソケットを開き、それらを既に開いているファイル記述子としてサービスプログラムに渡す）を使用するまたはを優先しますType=notify。

Type=simpleサービスプロセスが開始するとすぐに、サービスが準備完了として扱われます (そのため、そのサービスに基づいて注文されたサービスを開始/停止できます)。早期ソケットオープンでは、ソケット接続セマンティクスを使用して、サービスクライアントがサービスのためにサーバーに接続しようとする時点で、サーバーが実際に準備完了になるまでサービスクライアントを遅延させます。
Type=notifysystemdとLinuxに特有であるという欠点がある（シェル生成などの短命なプロセスからは機能しないという問題と、systemd-notify人間が読める形式を機械が読める形式に解析する特権プロセスではパーサーの問題が発生するという問題に加えて）。すでに起こった以前はそうではありませんでしたが、サービスが実際に準備完了と見なされるタイミングをより細かく制御できる (サービスプログラムの観点から) という利点があります。また、ステータス出力をある程度カスタマイズすることもできます。

どちらのタイプのサービスプログラムもフォークすることができます。フォークとはそして元のプロセスを終了するそれが問題だ。

（これは、シェルからプログラムを実行する場合も、サービスマネージャからプログラムを実行する場合も、同様に問題となることに注意してください。ユーザーは、プログラムが終了し、すぐに別のシェルプロンプトが表示されるのを目にします。実際、ちょうど今日、誰かが、親をフォークして終了するシェルからプログラムを実行することについて、再び質問していました。ターミナルでプログラムを実行すると、ターミナルで実行されないことがあるのはなぜですか?。

Type=oneshotおそらく、この特定のケースでは、サービスプログラム全体が完了するまでサービスの準備が整っていないとみなされるため、この方法は望ましくないと思われます。この方法には用途がありますが、どうやらあなたには当てはまらないようです。

決して使用しないType=forkingでください。ほとんどのプログラムでは実際にプロトコルを話す。彼らがやっていますその他、これは実際にはないこのプロトコルは、このプロトコルと正しく相互運用できず、実際に準備ができていることを示す信号ではありません。

参考文献

ジョナサン・デ・ボイン・ポラード（2001年）。 Unixデーモンプログラムを設計する際に避けるべき間違いよくある質問。
ジョナサン・デ・ボイン・ポラード（2015年）。本当に悪魔化する必要はありません。本当に。. システム化された恐怖の家。
ジョナサン・デ・ボイン・ポラード（2015年）。Unixデーモンの準備プロトコルの問題よくある質問。
https://unix.stackexchange.com/a/401611/5132

Answer

この Arch wiki ページは無視してください。

設定に関してはかなり間違っていますType。さらに、これはの記述に限ったことではありませんsimple。についての記述forkingも間違っています。

この種の正しい推奨事項は、systemd自体が存在するよりも数十年も前から存在しており、少なくとも1990年代初頭にまで遡ります。https://unix.stackexchange.com/a/476608/5132systemd のドキュメントには、デーモンに関する推奨事項の最近のバージョンがあり、daemontools ユーザー、IBM、を使用している人々inittab、そして…まあ…私が何十年も言ってきたことをほぼ繰り返しています。(2001 年に私がそのように書いたとき、それはすでに頻繁に返答されていました。)

繰り返す：

プログラムに「デーモン化」メカニズムがあり、特に子プロセスをフォークして親プロセスを終了する場合、消してそして使用しないでくださいdaemontoolsなどのおかげで、長い間これが必須となっていた多くのプログラムが、持っていないこのようなメカニズムは過去 20 年以上にわたって開発されてきましたが、他のメカニズムは最初から「デーモン化」をデフォルトとしていないため、デフォルトの動作モードで使用できます。

サービス管理サブシステムはサービスプロセスを起動するデーモンの文脈ではすでにこれらのプロセスは「デーモン化」する必要はありません。（実際、多くの現代のオペレーティングシステムでは、プログラムがデーモン化されると考えるのは誤りです。できるログインセッションコンテキストから「デーモン化」する。これが「デーモン化」の実際の目的である。) デーモンコンテキストに適した環境値とオープンファイル記述子が既に存在し、実際に「デーモン化」によって実行されるいくつかの処理が行われている。妨害するサービスマネージャーによってデーモンで定期的に実行される従来の処理の一部 (標準出力/エラーをログにキャプチャするなど)。

Type=simple早期ソケットオープン（サービス管理がサーバーソケットを開き、それらを既に開いているファイル記述子としてサービスプログラムに渡す）を使用するまたはを優先しますType=notify。

Type=simpleサービスプロセスが開始するとすぐに、サービスが準備完了として扱われます (そのため、そのサービスに基づいて注文されたサービスを開始/停止できます)。早期ソケットオープンでは、ソケット接続セマンティクスを使用して、サービスクライアントがサービスのためにサーバーに接続しようとする時点で、サーバーが実際に準備完了になるまでサービスクライアントを遅延させます。
Type=notifysystemdとLinuxに特有であるという欠点がある（シェル生成などの短命なプロセスからは機能しないという問題と、systemd-notify人間が読める形式を機械が読める形式に解析する特権プロセスではパーサーの問題が発生するという問題に加えて）。すでに起こった以前はそうではありませんでしたが、サービスが実際に準備完了と見なされるタイミングをより細かく制御できる (サービスプログラムの観点から) という利点があります。また、ステータス出力をある程度カスタマイズすることもできます。

どちらのタイプのサービスプログラムもフォークすることができます。フォークとはそして元のプロセスを終了するそれが問題だ。

（これは、シェルからプログラムを実行する場合も、サービスマネージャからプログラムを実行する場合も、同様に問題となることに注意してください。ユーザーは、プログラムが終了し、すぐに別のシェルプロンプトが表示されるのを目にします。実際、ちょうど今日、誰かが、親をフォークして終了するシェルからプログラムを実行することについて、再び質問していました。ターミナルでプログラムを実行すると、ターミナルで実行されないことがあるのはなぜですか?。

Type=oneshotおそらく、この特定のケースでは、サービスプログラム全体が完了するまでサービスの準備が整っていないとみなされるため、この方法は望ましくないと思われます。この方法には用途がありますが、どうやらあなたには当てはまらないようです。

決して使用しないType=forkingでください。ほとんどのプログラムでは実際にプロトコルを話す。彼らがやっていますその他、これは実際にはないこのプロトコルは、このプロトコルと正しく相互運用できず、実際に準備ができていることを示す信号ではありません。

参考文献

ジョナサン・デ・ボイン・ポラード（2001年）。 Unixデーモンプログラムを設計する際に避けるべき間違いよくある質問。
ジョナサン・デ・ボイン・ポラード（2015年）。本当に悪魔化する必要はありません。本当に。. システム化された恐怖の家。
ジョナサン・デ・ボイン・ポラード（2015年）。Unixデーモンの準備プロトコルの問題よくある質問。
https://unix.stackexchange.com/a/401611/5132

この Arch wiki ページは無視してください。

答え1

答え2

この Arch wiki ページは無視してください。

参考文献

関連情報