initシステムの系譜（SysV init・Upstart・systemd）

PID1とは何者か

カーネルがブートを終えて最初に exec するユーザー空間プロセスが PID 1、すなわち init です。ブート段でどうやって PID 1 にたどり着くかは ブートチェーンの内部 で扱いました。本稿はその先、PID 1 が起動後に担う サービス管理の設計 が、SysV init から Upstart を経て systemd へどう進化したかを系統でたどります。

PID 1 は通常のプロセスと違い、カーネルから特別扱いされます。要点は3つです。

• 全プロセスの祖先：以後生成されるプロセスはすべて PID 1 の子孫になります。
• 孤児の引き取り手（reaper）：親が先に死んだ子は PID 1 に再ペアレントされ、PID 1 が wait() してゾンビを刈り取ります（ゾンビプロセスと孤児プロセス参照）。
• 終了が許されない：PID 1 が exit するとカーネルは Kernel panic - Attempted to kill init! を出して停止します。

SysV init：ランレベルと逐次起動

最初の系統は、System V 由来の SysV init です。中核概念は ランレベル（runlevel） で、システムの動作状態を 0〜6 の番号で表します。

init は /etc/inittab を読み、initdefault で指定された既定ランレベルへ遷移します。各ランレベルには /etc/rc.d/rcN.d/ というディレクトリが対応し、その中に起動スクリプトへの シンボリックリンク が並びます。リンク名の規則が起動の本質を決めます。

/etc/rc3.d/ の中身（例）
  S10network -> ../init.d/network    # S=start、10=順序番号
  S12syslog  -> ../init.d/syslog
  S80httpd   -> ../init.d/httpd
  K30httpd   -> ../init.d/httpd      # K=kill（停止時に使う）

rc スクリプトの動作（擬似コード）:
  for link in sort(Sxx*):            # 番号の昇順に
      run  link  start               # 1本ずつ直列に実行
      wait_until_exit()              # 終わるまで次に進まない

ここに SysV init の本質的な限界が2つあります。第一に 逐次（シリアル）実行 です。S10 が完了するまで S12 は始まらないため、起動時間は各スクリプトの所要時間の 総和 になります。第二に 依存関係が番号で暗黙表現される ことです。「network の後に httpd」を S10 と S80 の番号差で表すしかなく、依存は人間が番号付けで管理する暗黙の約束に過ぎません。番号が衝突したり順序を読み違えたりすれば、起動順序のバグになります。

Upstart：イベント駆動への転換

逐次起動の遅さと、ホットプラグ（USB 接続やネットワーク到達）のような 非同期な出来事に対応できない 問題を解こうとしたのが、Ubuntu が開発した Upstart（2006年〜）です。発想を イベント駆動 に変えました。

SysV init が「ランレベルという固定の状態へ順に進む」モデルだったのに対し、Upstart は 「イベントが発生したら、それを待っているジョブを起動する」 モデルです。ジョブ定義（/etc/init/foo.conf）に、どのイベントで起動・停止するかを宣言します。

# /etc/init/foo.conf（概念例）
start on  (started networking)      # networking が起動したら開始
stop  on  runlevel [016]            # ランレベル 0/1/6 で停止
respawn                             # 落ちたら自動再起動
exec /usr/sbin/foo --no-daemon      # フォアグラウンドで実行

イベント（startup、started X、デバイス接続など）が発火すると、それを start on で待つジョブが起動します。あるジョブの起動完了が次のイベントになり、連鎖的にシステムが立ち上がります。依存を番号ではなく 「何の後に」を名前で宣言 できる点が前進で、独立なジョブは並列に起動できます。respawn による自動再起動も、SysV では自前実装だった機能を宣言一行に畳み込みました。このイベント／非同期トリガという発想は、I/O 多重化の世界の流れ（イベント駆動I/Oモデルの系譜）とも通じます。

systemd：依存グラフと並列起動

現在の主流である systemd（2010年〜）は、設計の軸を イベントの連鎖 から 依存グラフの解決 へ再び移しました。すべてを unit という統一概念で表します。

各 service unit は依存関係を 明示的なディレクティブ で宣言します。中心は2軸です。Requires=／Wants= が 「何を一緒に必要とするか」（依存の有無）を、After=／Before= が 「どの順で起動するか」（順序）を表します。この2軸が独立している点が重要で、Requires=（必要だが順序は問わない）と After=（順序だけ規定）を分けることで、systemd は依存と順序を別々に最適化できます。

# foo.service（概念例）
[Unit]
Requires=network-online.target      # これが起動できないと foo も失敗
After=network-online.target         # 起動順序：network の後

[Service]
ExecStart=/usr/sbin/foo --foreground
Restart=on-failure

[Install]
WantedBy=multi-user.target          # この target に組み込まれる

systemd はこれらの宣言から 有向グラフ を構築し、トポロジカルに解決します。順序辺（After）で前後が定まっていない unit 同士は 同時に起動 されます。結果、起動時間は SysV のような所要時間の総和ではなく、依存チェーン上の最長経路（クリティカルパス） に近づきます。これが「systemd は速い」の正体です。

依存解決と並列起動（擬似コード）:
  graph = build_dependency_graph(all_units)   # After/Before を辺に
  ready = units_with_no_pending_predecessor(graph)
  while ready not empty:
      for u in ready (in parallel):           # 順序制約のないものは同時に
          start(u)
      ready = newly_unblocked_units(graph)     # 完了で次段が解放

cgroup統合：プロセス群を確実に追跡する

systemd のもう一つの本質的な前進が cgroup との統合 です。SysV init が PID ファイル頼みでプロセスを見失っていた問題を、systemd は構造的に解決しました。

systemd は各 service を起動するとき、その service 専用の cgroup を作り、ExecStart で起動したプロセスをその中に入れます。子が二重 fork してデーモン化しようとも、fork() で生まれた子孫は 同じ cgroup に属したまま です。cgroup はプロセスの集合をカーネルが追跡する仕組みなので、init はもはや PID を当てずっぽうで追う必要がありません。

/sys/fs/cgroup/.../foo.service/
  cgroup.procs:  1234 1240 1305 ...   # foo の全プロセスをカーネルが列挙

systemctl stop foo:
  → foo.service の cgroup 内の全 PID に SIGTERM
  → 猶予後に残存プロセスへ SIGKILL  # 取り逃しゼロ

この「サービス＝cgroup」という対応により、systemctl stop は 取り残しなくプロセス群全体を止められ、MemoryMax= や CPUQuota= といった リソース制限をサービス単位で課せます。cgroup そのものの仕組みは 名前空間と cgroups、v2 での階層モデルは cgroup v2の階層モデルとコントローラ を参照してください。

三世代を一枚で比較する

init システムの系譜（年代と分岐）:

  1983  SysV init        ── ランレベル＋rcN.d、逐次・直列起動
    │                       依存は番号(Sxx/Kxx)で暗黙表現
    │
  2006  Upstart (Ubuntu) ── イベント駆動、start on / stop on
    │                       非同期トリガに対応、並列起動へ
    │
  2010  systemd          ── unit＋依存グラフ、並列起動
                            cgroup統合・socket活性化・target

まとめ

• PID 1 はカーネルが最初に起動する特別なプロセスで、全プロセスの祖先・孤児の刈り取り手であり、終了するとカーネルパニックになる。
• SysV init はランレベルと rcN.d で 逐次・直列 に起動し、依存を番号で暗黙表現するため遅く壊れやすかった。
• Upstart は イベント駆動 へ転換し、非同期トリガと宣言的な依存・自動再起動を導入して部分並列化を実現した。
• systemd は 依存グラフ を解いて並列起動し、起動時間をクリティカルパスまで縮めた。
• systemd は service を cgroup で束ねてプロセス群を確実に追跡・制御し、socket活性化 で起動順序問題そのものを解消した。

PID 1 に至るまでの前段は ブートチェーンの内部、孤児プロセスの引き取りは ゾンビプロセスと孤児プロセス も合わせてどうぞ。