Linuxシステムの初期化プロセス

投稿者: | 2018年1月19日

先日、「Fedoraでtmpディレクトリの中身が再起動すると削除される」で”systemd”の仕組みが分かっていないことを痛感したので、まとめてみました。

ブートプロセスのおさらい

0.ブートローダをロード
PCの電源を入れると、PCのROMに書き込まれたファームウェアが起動します。
このファームウェアがブートローダで、OSをロードして起動するために二次ブートローダをロードします。

1.二次ブートローダをロード

  • BIOSベース : “MBR”から第1ステージブートローダを実行すると、次に別のブートローダGRUBをロードして実行
  • UEFIベースの場合 : “EFIシステムパーティション”をマウントし、”EFIブートマネージャ”がGRUBをロードして実行
    ※GRUBには、大きく分けてバージョン0.9x系の”GRUB Legacy”と1.9x系の”GRUB 2″の2種類があります

2.二次ブートローダがカーネルをメモリーにロードした後、必要なモジュールをロードして読取専用の”rootパーティション”をマウント

3.カーネルはブートプロセスの制御を”システムの初期化プロセス”に渡す

4.”システムの初期化プロセス”は全てのサービスをロードし、必要なパーティションをマウント

5.起動完了

ここで言う”システムの初期化プロセス”とは「システム起動時に最初に立ち上がるプロセス」を指します。
簡単に言うと「Linuxの起動処理やシステム管理を行う仕組み」です。
以降、”起動プロセス”と記載します。

Linuxでは(私の知っている限り)2つに大別されます。
※Upstartは主流から外れた気がするので除外しました

起動プロセス

init(Sysvinit)

古くからある起動プロセスで、シェルスクリプトによって書かれています。

メリット

  • シェルスクリプトなので構造が単純
  • シェルスクリプトなので”sh”があれば動く
  • 渡せる引数が{start, stop, restart, reload}に限定されない

デメリット

  • サービスについての動作が一つのシェルスクリプトの中に書かれているため、細分化することができず複雑になりがち
  • initが他プロセスを順次起動する仕組みのため性能上ボトルネックになる
    • 並列実行ができない

systemd

サービスをUnitという単位で管理し、設定ファイルとして持つことで処理を細分化でき個別に実行することが可能です。
2010年にリリースされた比較的新しいシステム管理デーモンです。

メリット

  • 処理の依存関係を明確できる
  • 並列での実行が可能(性能上有利)

デメリット

  • 対応している引数しか渡せないという制約がある
    特殊な起動状態を持つデーモンの場合は、/etc/init.dスクリプトで何とかするしかない

そのため、現在systemdがデファクトスタンダードとなっていますが、Sysvinitも残っています。
(Sysvinitも使えます)。

systemdを採用する主なディストリビューション

  • Arch Linux
  • CoreOS
  • Debian, Ubuntu
  • openSUSE, SLES(SUSE Linux Enterprise Server)
  • Oracle Linux
  • RHEL, CentOS, Fedora