システム5 initでは、ストーリーのごく一部しか表示されません。
Linuxの世界に影響を与える一種の近視があります。人々は「System 5 init」と呼ばれるものを使用していると考えています。それは伝統的なものであり、始めるのに最適な場所です。どちらも事実ではありません。
実際のところ、伝統は、そのような人々が言うように、初心者にとってはそうではありません。System 5 initとSystem 5はrc、AT＆T UNIX System 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および関連するツールを（再）書きました。initこれは、実際にはUNIX System 5のソフトウェアではありませんが（「System 5 」）init）。
System 5 init/ rcは開始するのに最適な場所ではありませんし、知っていることの半分をカバーしていないsystemdの知識を追加したとしてもです。initシステム設計（LinuxおよびBSD用）の分野では、過去20年間だけで多くの作業が行われています。あらゆる種類のエンジニアリングの決定が議論され、作られ、設計され、実装され、実践されてきました。商用Unicesも大活躍しました。
調査および学習する既存のシステム
以下に、これら2つ以外の主要な初期化システムの一部の不完全なリストと、それらの（いくつかの）顕著な点の1つまたは2つを示します。
- Joachim Nilssonのfinitは、より人間が読みやすい構成ファイルを使用するルートを取りました。
- Felix von Leitnerのミニットは、ファイルシステムであるデータベース構成システム、小さなメモリフットプリント、および開始するものの間の開始/停止依存関係を求めました
init。
- Gerrit Papeのrunitは、私が以前に記述した、4つのシェルスクリプトアプローチを生成するためのものです。
- InitNGは、依存関係、名前付きターゲット、複数の構成ファイル、およびより柔軟な構成構文を持つことを目的としており、全体が子プロセスの設定をロードします。
- upstartは完全な再設計に取り組み、システムをサービスや相互依存関係としてではなく、それらによってトリガーされるイベントやジョブとしてモデル化しました。
- 設計間食は（さえ含む外サービス管理のすべてをプッシュ含む、
getty個別のサービスマネージャに産卵し、ゾンビ刈り取りを）、そしてちょうどオペレーティング・システム固有の「API」デバイス/シンボリックリンク/ディレクトリやシステムイベントを処理します。
- sinitは非常に単純なinitです。
/bin/rc.initプログラムの起動、ファイルシステムのマウントなどのジョブを実行します。これには、minircなどを使用できます。
また、約10年前、daemontoolsのユーザーと使用のとりわけ議論があったsvscanようなプロジェクトにつながったプロセス＃1、とポールJARCのsvscanプロセス1研究として、ゲリット・パプのアイデア、そしてローランBercotのsvscanプロセス1とは。
これにより、プログラム＃1が行うプロセスがわかります。
プロセス＃1プログラムが行うこと
プロセス＃1が実行する「想定」の概念は、その性質上主観的です。意味のある客観的な設計基準は、最低でもプロセス＃1がしなければならないことです。カーネルにはいくつかの要件があります。そして、それがしなければならない様々な種類のいくつかのオペレーティングシステム固有のものが常にあります。プロセス＃1が伝統的に行っていることになると、私たちはその最小値ではなく、実際に実行されたことはありません。
さまざまなオペレーティングシステムカーネルや他のプログラムがプロセス＃1に要求するいくつかのことがあります。
人々は、fork()物事を行い、孤立したプロセスの親として行動することが、プロセス＃1の主要な機能であると言うでしょう。皮肉なことに、これは真実ではありません。孤立したプロセスに対処することは（https://unix.stackexchange.com/a/177361/5132で説明されているように、最近のLinuxカーネルでは）、プロセス＃1から他のプロセスに大きく組み込むことができるシステムの一部です。専用のサービスマネージャー。これらはすべてサービスマネージャーであり、プロセス＃1で実行されます。
同様に、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」ファイルシステムを扱う基本は、initROM 1st Edition UNIXの操作とほとんど変わりません。1つはプログラムに組み込まれた情報のリストを持ち、もう1つはリスト内mount()のすべてのエントリを単純に持ちます。このメカニズムは、BSD（sic！）initからnoshをsystem-manager経てsystemdまでの多様なシステムで見つかります。
「システムを単純なシェル用にセットアップする」
あなたが観察してきたように、init=/bin/sh1種類なしキャッシュフラッシュと不格好な形でクラッシュし、「API」fileystemsがマウントされませんexit（https://unix.stackexchange.com/a/195978/5132）、および一般的な葉のそれ（スーパー）ユーザーに、システムを最小限に使用できるようにするアクションを手動で実行します。
実際にプロセス＃1プログラムで行う以外に何も選択肢がないことを確認し、指定された設計目標に向けて良いコースを設定するには、Gerrit Papeのrunit、Felix vonの操作の重複を見ることが最良の選択肢ですライトナーのミニット、およびsystem-managernoshパッケージのプログラム。前者の2つは、ミニマリストにしようとする2つの試みを示していますが、それでも避けることのできないものを処理します。
後者は、system-managerプログラムへの広範な手動入力のために役立ちます。これは、どの「API」ファイルシステムがマウントされ、どの初期化タスクが実行され、どの信号が処理されるかを正確に詳述します。システムの設計により、システム管理者にだけ産卵3つの他のもの（サービスマネージャ、付随するロガー、および状態変化を実行するためのプログラムを）持っているだけで、プロセス＃1にやむを得ないを行います。