システム 5 init ストーリーのごく一部のみを説明します。
Linux の世界に影響を与える一種の近視眼があります。人々は、「システム 5 init」というものを使用していると考えています。 」、そしてそれは伝統的なものであり、始めるのに最適な場所でもあります.実際にはどちらも当てはまりません.
そもそも伝統とは、そういう人が言うようなものではありません。システム 5 init およびシステム 5 rc AT&T UNIX システム 5 にさかのぼります。これは、Linux-Mandrake の最初のバージョンの後の現在 (たとえば) とほぼ同じくらい、最初の UNIX の後でした。
第 1 版 UNIX には init しかありませんでした . rc がありませんでした .第 1 版アセンブリ言語 init (そのコードは Warren Toomey らによって復元され、利用可能になっています。) 直接生成および再生成された 12 getty 組み込みテーブルから 3 つのハードワイヤード ファイルシステムをマウントし、mel という名前のユーザーのホーム ディレクトリから直接プログラムを実行しました。 . getty テーブルもプログラム イメージに直接含まれていました。
いわゆる「従来の」Linux init システムが登場したのは、UNIX System 5 からさらに 10 年後のことです。 1992 年、Miquel van Smoorenburg は Linux init を (再) 書きました。 +rc 、およびそれらに関連するツールは、現在「System 5 init」と呼ばれています。 "、実際には UNIX システム 5 のソフトウェアではありませんが (そして init だけではありません) ）。
システム 5 init /rc 始めるのに最適な場所ではありません.systemdの知識を追加したとしても、知っておくべきことの半分をカバーしていません.過去 20 年間だけでも、init システム設計 (Linux および BSD 用) の分野で多くの作業が行われてきました。あらゆる種類のエンジニアリング上の決定が議論され、行われ、設計され、実装され、実践されてきました。商用 Unice も多くのことを行いました。
研究および学習する既存のシステム
以外の主要な init システムの一部の不完全なリストを次に示します。 それらの 2 つと、それらの (いくつかの) 顕著な点の 1 つまたは 2 つ:
- Joachim Nilsson の finit は、より人間が読める構成ファイルを使用する方向に進みました。
- Felix von Leitner のミニットは、ファイルシステムがデータベースである構成システム、小さなメモリ フットプリント、
init間の依存関係の開始/停止を目指しました。 開始します。 - Gerrit Pape の runit は、4 つのシェル スクリプトを生成すると以前に説明したものに行きました。
- InitNG は、依存関係、名前付きターゲット、複数の構成ファイル、および子プロセスの設定全体をロードするより柔軟な構成構文を持つことを目的としています。
- upstart は完全な再設計を行い、システムをサービスや相互依存性としてではなく、それらによってトリガーされるイベントやジョブとしてモデル化しました。
- nosh の設計には、すべてのサービス管理 (
gettyを含む) を押し出すことが含まれます。 スポーンとゾンビのリープ) を別のサービス マネージャーに統合し、ただ オペレーティング システム固有の「API」デバイス/シンボリック リンク/ディレクトリおよびシステム イベントの処理 - sinit は非常に単純な init です。
/bin/rc.initを実行します プログラムの起動、ファイルシステムのマウントなどを担当します。このためには、minirc などを使用できます。
また、10 年ほど前に、daemontools ユーザーなどの間で svscan の使用について議論がありました。 プロセス #1 として、プロセス 1 として Paul Jarc の svscan、プロセス 1 として Gerrit Pape のアイデア、Laurent Bercot の svscan などのプロジェクトにつながりました。
これにより、第 1 のプログラムが実行するプロセスにたどり着きます。
プロセス 1 のプログラムが行うこと
プロセス #1 が実行する「想定」の概念は、その性質上主観的なものです。意味のある目標 設計基準は、プロセス #1 が最低限しなければならないものです 行う。カーネルにはいくつかの要件があります。そして、それがしなければならないさまざまな種類のオペレーティングシステム固有のことが常にいくつかあります。プロセス #1 が伝統的に持っているプロセスについて言えば、 完了した場合、私たちはその最低レベルに達しておらず、実際にそうであったことはありません.
さまざまなオペレーティング システム カーネルやその他のプログラムがプロセス #1 に要求する、単純に逃れられないものがいくつかあります。
人々はあなたに fork() と言うでしょう 物事を処理し、孤立したプロセスの親として機能することは、プロセス #1 の主要な機能です。皮肉なことに、これは真実ではありません。孤立したプロセスを処理することは (https://unix.stackexchange.com/a/177361/5132 で説明されているように、最近の Linux カーネルでは) プロセス #1 を他のプロセスに大きく分解できるシステムの一部です。専任のサービス マネージャー .これらはすべてサービス マネージャーであり、プロセス #1 で実行されます:
- IBM AIX
srcmstrプログラム、システム リソース コントローラー - Gerrit Pape の
runsvdirrunit から - ダニエル J. バーンスタインの
svscandaemontools から、Adam Sampson のsvscanfreedt より、Bruce Guenter のsvscandaemontools-encore および Laurent Bercot のs6-svscanから S6から - ウェイン・マーシャルの
perpdから - Solaris 10 のサービス管理機能
service-managerから
同様に、https://superuser.com/a/888936/38062 で説明されているように、全体の /dev/initctl アイデアはプロセス 1 の近くにある必要はありません。皮肉なことに、プロセス #1 の外に移動できることを示しているのは、高度に集中化された systemd です。
逆に init の必須事項 SIGINT の処理などは、頭のおかしいデザインで人々が忘れがちなことです。 、 SIGPWR 、 SIGWINCH などをカーネルから送信し、プロセス #1 への特定の信号が特定のことを意味することを「認識」しているプログラムから送信されるさまざまなシステム状態変更要求を実行します。 (例:https://unix.stackexchange.com/a/196471/5132 で説明されているように、BSD ツールセットは SIGUSR1 を「知っている」 には特定の意味があります。)
「API」ファイルシステムのマウントやファイルシステムキャッシュのフラッシュなど、逃れることができない、または実行しないと非常に苦しむ1回限りの初期化およびファイナライズタスクもあります。
「API」ファイルシステムを扱う基本は、init の操作とほとんど変わりません。 rom 1st Edition UNIX:1 つはプログラムに組み込まれた情報のリストを持ち、もう 1 つは単に mount() です。 s リスト内のすべてのエントリ。このメカニズムは、BSD (sic!) init と同じくらい多様なシステムで見られます。 、鼻から system-manager 、systemdへ。
「単純なシェル用にシステムをセットアップする」
ご覧のとおり、init=/bin/sh 「API」ファイルシステムがマウントされず、exit と入力すると、キャッシュ フラッシュなしで不格好にクラッシュします
プロセス 1 のプログラムで実際に何をするしかないかを確認し、指定された設計目標に向けて適切な方向性を設定するには、Gerrit Pape の runit である Felix von の操作におけるオーバーラップを調べるのが最善の方法です。ライトナーのミニット、および system-manager nosh パッケージのプログラム。前の 2 つは、ミニマリストになるための 2 つの試みを示していますが、避けられないものを処理しています。
後者は system-manager どの「API」ファイルシステムがマウントされているか、どの初期化タスクが実行されているか、どのシグナルが処理されているかを正確に詳述するプログラム。 仕様のシステムで システム マネージャーは、他の 3 つのもの (サービス マネージャー、付随するロガー、状態変更を実行するプログラム) を生成し、プロセス #1 で避けられないことだけを行います。
Debian の System V init (他のバリアントやバリエーションがあります) は、次のことを行います:
- ランレベルに入ると、
/etc/rcX.d/S*でスクリプトを呼び出しますXの英数字順 ランレベルです。これらのスクリプトは、ランレベルをセットアップする必要があります。通常のセットアップでは、デーモンを開始し、その実行レベルのセットアップ タスクを実行します。これは、ランレベルに入るときに 1 回だけ行うことです。 - 実行レベルでは、
/etc/inittabにリストされているデーモンを開始します。 その実行レベル中にアクティブである必要があるため。これらのデーモンが実行を停止すると、再起動します。initで管理したい任意のデーモンを使用できますが、 、少なくともいくつかのgettyが必要です ですので、ログインできます。gettyログインが完了すると終了し、init再起動して、新しいログイン プロンプトを表示します。
- デーモンがあまりにも短い時間に何度も再起動すると、デーモンはしばらく再起動を試みなくなります。
- 実行レベルに入ったときにキックオフ スクリプトによって何かが開始されたからといって、
initにはなりません。 自動的に実行し続けようとします。/etc/inittabで別途指定する必要があります .
- ランレベルを終了するとき、
/etc/rcX.d/K*でスクリプトを呼び出します 英数字順、Xランレベルです。シャットダウンまたは再起動を実装する方法は、これらのイベントのランレベルを定義し、最後に実行されたタスクをhaltにすることです またはrebootコマンド - 電源イベントや Ctrl-Alt-Del などの特定のイベントに応答して、実行可能ファイルを呼び出します。
- ソケットをリッスンし、特定のメッセージを受信するとランレベルを変更します。
したがって、 init を使用できます 必要に応じて初歩的なサービス マネージャーとしても使用できますが、最近の主なタスクは getty を維持することです が利用できるので、ユーザーはログインしてランレベルの移行を開始できます。
単純なシェル用にシステムをセットアップするために、init はどのようなタスクを実行するのだろうか?
あなたが望むものなら、なんでも。 Debian では、各 /etc/rcX.d で ディレクトリは /etc/init.d のスクリプトへのシンボリックリンクです これらのスクリプトを完全にカスタマイズまたは削除できます。順序は、各スクリプトの前に 00 を付けることで確立されます 、 01 など
-b を指定することもできます init へのオプション (つまり、カーネルコマンドライン経由) init だけが必要な場合 シェルを生成します。シェルを終了すると、init 死亡し、init 死ぬと、カーネルはパニックになります。
init がしなければならない最低限のことは、少なくとも 1 つの他のプログラムを実行し、決して終了しないことです。 init が終了すると、システムがクラッシュします。別のプログラムを 1 つ実行することさえ厳密には必要ではないと思いますが、それを実行しないと、システムが実行することが期待されるすべてのことを init が担当する必要があり、さもないとあまり役に立ちません。