必ずしも必要ではありません。

Cサービスがソケット接続を開く準備ができるまで待つ必要がある場合は、Sこれをまったく実行する必要はありません。代わりに、次のものを使用できます。早期リスニングソケットを開くサービス管理者別。

以下を含む複数のシステムローラン・ベルコテのS6、私のスナックツールセットsystemdにはいくつかの方法がありますリスニングソケットサービスを設定するときに最初にすべきことだけできるだけ早くオープンすることが可能です。これらはすべて、リスニングソケットを開くサービスプログラムと、呼び出し時に開かれたファイル記述子でリスニングソケットを受け取るサービスプログラム以外のものを含みます。

特にsystemdを使用してソケットユニットリスニングソケットを定義します。 systemdは、ソケットデバイスを開き、カーネルネットワーキングサブシステムが接続を受信するように設定し、ソケット接続を処理するプロセスを作成すると、それを開いたファイル記述子として実際のサービスに渡します。 （これは2つの方法で行うことができますが、inetdサービスとサービスの詳細についての議論はこの回答の範囲外です。）Accept=trueAccept=false

重要なことは、人々が必ずしもこれ以上注文する必要はないということです。カーネルは、サービスプログラムが初期化され、クライアント接続を受け入れ、クライアントと通信する準備ができるまでクライアント接続をキューにバッチします。

これを行うには、プロトコルを準備することが重要です。

systemdには次のセットがあります。契約の準備Type=サービスはサービスユニットの設定で指定されていることを理解しています。ここで関心のある特定の準備プロトコルはnotify準備プロトコルです。これにより、systemd はサービスのメッセージを待つように指示され、サービスが準備されたら準備完了というメッセージが送信されます。 systemdは、準備が完了するまで他のサービスのアクティブ化を遅らせます。

これを悪用するには、次の2つが必要です。

• SPierre-Yves Ritschardnotify_systemd()関数や Cameron T Norman 関数notify_socket()などの関数を呼び出すようにコードを変更します。
• Type=notifyサービスのサービスユニットを有効にして設定しますNotifyAccess=main。

このNotifyAccess=main制限（デフォルト）は、システム内のすべてのプロセスがsystemdの通知ソケットにメッセージを送信できるため、systemdがいたずらな（または単純なバグのある）プログラムからのメッセージを無視する必要があることに注意する必要があるためです。

人々はPierre-Yves RitchardまたはCameron T Normanのコードを好む。これは、UbuntuBSD、Debian FreeBSD、実際のFreeBSD、TrueOS、OpenBSDなどでこのメカニズムを使用する可能性を排除しないからです。 systemd作成者が提供したコードはこれを除外します。

避けるべきトラップの1つはsystemd-notifyプログラミングです。これにはいくつかの主な問題があり、その中で最も重要なのは、一緒に送信されたメッセージがsystemdで処理されずに破棄されることです。この場合のS最大の問題は、サービスの「メイン」プロセスとして実行されないため、それを使用する必要があることですNotifyAccess=all。

避けるべきもう一つのトラップは、合意がforkingより簡単であると考えることです。そうではありません。行為正しくプログラムのすべてのワーカースレッドが実行されるまで、親スレッドを分岐または終了しないことに関連しています。これは、ほとんどのフォークデーモンが実際にフォークする方法と一致しません。

追加読書

• ジョナサンデボインポラード（2015）。Unixデーモンの準備プロトコルの問題。よく与えられる答えです。
• レナルト・ペトリング（2010）。sd_notify()。システムのマニュアルページ。 freedesktop.org.
• レナルト・ペトリング（2010）。systemd-notify。システムのマニュアルページ。 freedesktop.org.
• 特定のインターフェイスが起動する前に起動するのを待つようにシステムサービスユニットファイルを作成するにはどうすればよいですか？
• systemdのステータス出力にステータス情報を追加する