依存性ベースの初期化システムは、サービスの初期化順序がサービス内またはサービスに付属する依存関係情報に基づくシステムです。これは、順序が静的に決定されるinitシステムとは対照的です（質問に含まれる図に示すように、しばしば辞書順に依存します）。

一部のシステムでは、2つのアプローチを組み合わせることができます。たとえば、使用されるDebianシステムでは、依存関係ベースのsysvinit階層は初期化sysvinitスクリプトのLSBヘッダーを使用して初期化順序を計算し、適切に名前付き/etc/rc?.d/シンボリックリンクを介して保存します。

多くの人がこれを誤解しています。ここにある回答の一部は間違っています。

まず、いくつかの間違った名前をまとめましょう。

• initプロセス＃1で実行されるプログラムと他のプロセスで実行されるプログラムの違いは、rcUnixの最初のバージョンにさかのぼります。あなたが議論した多くのことプロセス＃1では実行されませんほとんどのサービス/システム管理ソフトウェアでは、Upstartとsystemd例外ルールよりも。
• init「sysvinit」はAT&T Unix System 5+ではありませんrc。これは元々Miquel van SmoorenburgがMinix用に作成したクローン利子initシステムですrc。皮肉なことに、AT&T Unix System 5が登場してから数年後です。ほとんど廃止システムをサービスアクセス施設と置き換えます。

あなたが尋ねたサービス管理、上記のサービスアクセス機能（SAF）、AIXシステムリソースコントローラ（SRC）、Solarisサービス管理機能（SMF）、systemd、Upstart、daemontools、daemontools-encore、runit、noshツールセットAT&T Unixのサービス管理タスク、s6と他の様々なツールセット。 SAFとSRCが登場する前の元のAT&T Unix System 5は、rcサービスプロセスを直接分岐していましたが、実際にはこれを実行していませんでした。管理するその後彼ら。

Linuxのvan Smoorenburg（Minix出身）はrcまだこれを行います。また、最初は手動ではなく一時サービスの開始/終了順序に依存していました。元の巨大なモノグリフは、rc1970年代と1980年代初頭に数回の突然変異を経験し、まだあちこちで化石を見つけることができ（例えば、rc.localvan Smulenbergが1990年代にそれを複製したときにセットになりましrcた）。入れる/etc/サブディレクトリといくつかのシンボリックリンクフィールド（の他のサブディレクトリ）にあるスクリプトは、/etc/これらのスクリプトが完全な操作を実行する順序を表しますrc。シンボリックリンクファームは、さまざまなrcスクリプトに0から99までの優先順位が割り当てられる優先順位スキームに基づいています。 （1990年代後半にシンボリックリンクファームの代替メカニズムであるfile-rcがありましたが、これも優先順位システムを使用しました。）これは優先順位の選択に関する普遍的な慣例がなく、「両方のソフトウェアが1位になる」という問題です。 。化石の方法で仕事をしている人は、このWWWサイトで関連する質問の1つを尋ねます。まさに昨日.)

依存性ベースのサービス管理もっとうまくやろう。サービス定義は、どのような形でも各サービスが実行するアクションをリストします。に従ってそしてに相対的でなければならない開始して終了するとき。 「最初」と「最後」はありませんが、今後そして後ろに、また必要そして衝突する。

これは、21世紀のほとんどの間、rcLinuxとBSDのレガシーシステムに存在してきました。

• MewburnrcとOpenRC（両方とも21世紀の発明）は以前のシステムで学習し、rc最初から異なるスクリプト間の相互依存関係を表現する方法を採用しました。 Mewburnは、rcさまざまなスクリプト（たとえば、、、、および）の注釈システムがサービス間の相互依存性を表現し、それに基づいて実行可能ファイルと呼ばれるプログラムが各起動/終了の開始時にジョブを実行する順序を計算します。rcREQUIREPROVIDEBEFORErcorder
• rcvan SmoorenburgはDebianの人々から。insservサービス間の相互依存性は、さまざまなスクリプトにコメントとして含まれている既存の「LSBヘッダー」システムによって表され、ソフトウェアのインストール/削除時に依存関係を反映するために優先順位がrcシンボリックリンクで書き直されます。insservDebianとその派生物の一部は、2000年代後半にこれをたくさん採用しました。バラよりDebian Wikiもっと学ぶ。

rcまた、最初からSolaris SMFからsystemdに至るまで、多くの非サービスマネージャーで一流のメカニズムとして存在してきました。注目すべき例外には、Upstart、daemontools（およびdaemontools-encore、perp、およびrunit）、および（数年前）s6があります。

daemontools、runitなど、これらのすべては最初に問題を解決するために「巨大な雷の群れ」アプローチをとり、すべてが機能するまでサービスを開始して再開しました。一部の人々は、サービスを一時停止し、他のことが発生するまで基本サービスプログラムを呼び出さないなどのトリックを使用してこれを少し調整しますが、基本的なアイデアはまだディレクトリ全体のすべての項目を「スキャン」します。一度に始まりました。

私は基本的なサービス管理の上にいくつかの階層を追加すると、より良いことができると長い間信じてきました、そして最終的に次のように証明しました。これを行うための特定のツールセット、実際のサービスマネージャから開始"スキャン"ロジックを取得し、別のプログラムに移動し、基本的なdaemontoolsサービス/監督ディレクトリ構造を中心にサービスバンドル相互依存システムを構築します。 Laurent Bercotもs6の追加機能で同じ効果を示しました。s6-rc。 OpenRCでさえ、rcスクリプトは相互依存関係を表現し、外部サービスマネージャ（s6など）を使用できるため、これを実証します。

皮肉なことに、Upstartは実際に（2005年に）2010年代の一部の人々のアイデアとして考案されました。新しいサービスの管理方法、変える依存性ベースのサービス管理イベントベースサービス管理、サービス開始発生したイベント結果としてではなく順序付き依存関係セットの計算。この概念が最終的に拒否された理由を議論することは、この回答の範囲外です。帰るしかし、2010年代初頭には依存関係ベースのサービス管理ノーマル。新開発者はそれが昔ながらだと思います。 van SmoorenburgはrcDebianの仕事を通してこれを得ましたが、FedoraとSUSEは実際にDebianからそれを継承しませんでした。 MewburnrcとOpenRCは最初からこれを持っていました。 systemdはまもなく発明されます。ソラリス、イルモスなどSMFと組み合わせて使用​​されます。など。

runitとUpstartを除いて、これは目立つ機能ではありません。これは標準で、現在です。これは、GNU Shepherdの初期にも他の人がやっていたりやっていることです。現在、GNU Shepherdと呼ばれるGNU dmdは2003年に開発されました。 Debianは2002年にスイッチを起動しましたinsserv。 Richard Goochはneed2002年にこれについて書きました。 Mewburnはrc2000年に発明され、そのトピックに関するLuke Mewburnの元の論文では、ファイル名でエンコードされたものよりも優先順位を使用する方法について説明しています。レベルシステムは依存関係を表現するのに適しています。デザインの特徴として。

追加読書

• ジョナサンデボインポラード（2018）。 /etc/rc.localそれは過去の仕事です。。一般的な答え。
• ジョナサンデボインポラード（2015）。システム5の既知の問題rc。一般的な答え。
• ジョナサンデボインポラード（2018）。 Unix サービスアクセスツール。一般的な答え。
• 仮想現実（2015-09-05）。現代初期化システムの歴史（1992-2015）。 darknedgy.net。

これは、広く使用されているSysVまたはSysmted initシステムと区別される機能ですか？

まあ、いいえからシステム「よく設計されたトランザクションを実装します。依存性ベースサービス制御ロジック」（強調）。

レナルトポータリングの言葉を引用します。systemdの基本原理ここで：

これらのすべてのユニットは相互依存性（肯定的および否定的、つまり「必要」および「衝突」）を持つことができます。デバイスはサービスへの依存関係を持つことができます。これは、デバイスが利用可能になるとすぐに特定のサービスが開始されることを意味します。マウントには、マウントされたデバイスへの暗黙的な依存関係があります。さらに、マウントは前に付けられたマウントに対する暗黙的な依存関係を取得します（つまり、/home/lennartをマウントすると、暗黙的に/homeマウントに依存関係が追加されます）。

以前のsysv時代には、システムサービス間の依存関係を表現するための最良の方法はありませんでした。スクリプトの順序の使用、ヘッダーの送信などの点でハードワイヤードですが、これらのシステムは本質的に脆弱です。このため、正しく注文することは特に困難です。たとえば、このサービスでは、このネットワークインターフェイスとこのマウントポイントが機能する必要がありますが、そのマウントポイントには他のデバイスが動作する必要があります。/etc/rcX.D/スクリプトで数値手動注文プレフィックスを使用することを検討してください。 。

適切なシステムを使用してユニット間の依存関係を表現することで、init システムは、サービスがお互いとどのようにシステムに関連しているかに関するすべての情報を持っているため、正しい順序を把握できます。

---

対照のために依存関係を使用するのではなく、イベントに直接依存するUpstartを検討してください。

Upstart は、次のイベントを介してサービス直列化を実行します。 syslog-started イベントがトリガされると、Syslog を使用できるようになり、D-Bus の起動を指示するために使用されます。その後、dbus-startedがトリガされると、D-Busなどが利用可能になり、NetworkManagerが起動します。

このように、管理者または開発者が理解する実際の論理依存関係ツリーは、イベントおよび作業ルールに変換およびエンコードされていると言えます。管理者/開発者が理解する各論理「aはbが必要です」ルールは「開始」になります。 b が起動すると a を停止します。" + "b が停止すると a を停止します。"

この文脈において、「依存性に基づく」とは、サービスが提供される順序を決定するために他の要因に依存するのではなく、通常、実行時に他のサービスによって提供される機能が実際に必要なサービスを特定し、一般にユーザーの介入が全くないことを意味するします。 start9（たとえば、語彙順）ファイル名）。

init.dこれは、systemdが出現する前にほとんどのLinuxディストリビューションが使用していた元のSVR4初期化アレイおよびいくつかの以前のBSDメソッドとは対照的ですrc.d。この方法では、すべてのユーザー/管理者がサービスが開始された順序を手動で提供する必要がありました。ファイル名または変数を手動で設定するか、ツールを実行してスクリプトに含まれているメタデータを検索します。

現在活発に使用されている依存関係およびサービス監督ベースのシステムの他の例initは次のとおりです。

• OpenRC：AlpineとGentooで使用されます。依存関係情報を取得するには、initスクリプト自体で特別な関数定義とマクロを使用します（lvmetadLVM構成で有効になっている場合にのみLVMを実行する必要があるように、サービス間の条件付き依存関係を表すことができるため、これは非常に強力です）。一般的な依存関係（つまり、実行中のsyslogデーモンが必要ですが、どのデーモンが実行されているかは考慮されません）。
• Monit：サービス監督者、init場合によっては置き換えます。ランタイム依存関係の計算は、監視するエンティティ（この場合はサービスではなく「エンティティ」）に対して定義された依存関係に基づいています。これは、ネットワークの他の場所で外部サービスまたはシステムコンテンツのファイルとディレクトリを監視および依存できるためです。サービス）。
• initUpstart：Ubuntuのレガシー代替品です。依存関係追跡を直接実行する代わりに、Upstartを使用すると、サービスはイベントに基づいて状態の変更をトリガーできます。これは、効率的な依存関係に基づくサービス開始シーケンスを提供するために使用されます。
• Systemd：依存性ベースの順序付けの現在の例です（しばしばinitファンはこれらのシステムが最初であると誤って主張しています）。依存関係の計算は実行時に実行され、場合によっては厳密な依存関係追跡の必要性を実際に軽減する機能を提供します。