Linuxブートプロセスの仕組みとsystemdターゲット・プロセス管理の使い方【LinuC101】



Linuxサーバーが電源投入からログインプロンプトを表示するまでには、ファームウェアからブートローダ、カーネル、初期化プロセスへと処理を引き継ぐ厳密なシーケンスが存在します。現行の主要ディストリビューションでは、この起動処理および起動後のプロセス管理の中核をsystemdが担っています。本稿では、LinuC 101試験の最重要トピックであるLinuxブートプロセスの全5段階、systemdターゲットによる実行レベル管理、そして日常の運用保守に直結するプロセス監視とシグナル制御の手法を、実機検証ログとともに論理的に解説します。

目次

1. 1. Linuxブートプロセスの全5フェーズ
   1. 1.1 フェーズ1：ファームウェア（BIOS/UEFI）によるハードウェア初期化
   2. 1.2 フェーズ2：ブートローダ（GRUB2）の読み込みとカーネル選択
   3. 1.3 フェーズ3：カーネル展開と初期RAMディスク（initramfs）の役割
   4. 1.4 フェーズ4：初期化プロセス（systemd: PID 1）の起動
   5. 1.5 フェーズ5：ターゲットに基づくサービス・環境の並列起動
   6. 1.6 カーネル起動ログの確認（dmesgコマンドとjournalctl -k）
2. 2. systemdターゲットとランレベル管理
   1. 2.1 systemdユニットとターゲット（.target）の基本概念
   2. 2.2 主要ターゲット一覧と旧ランレベル（0〜6）との完全対応
   3. 2.3 デフォルトターゲットの確認と恒久変更（get-default, set-default）
   4. 2.4 稼働ターゲットの一時的切り替え（systemctl isolate）
   5. 2.5 障害復旧モード（rescue.target と emergency.target）
3. 3. プロセスの生成とジョブ管理（フォアグラウンド・バックグラウンド）
   1. 3.1 プロセスの親子関係とPID・PPID
   2. 3.2 バックグラウンド実行（&）とジョブ制御（jobs, fg, bg, Ctrl+Z）
   3. 3.3 ログアウト後のプロセス実行継続（nohup, tmux, screen）
4. 4. プロセス監視コマンド（ps, top, pstree, uptime）
   1. 4.1 psコマンドによるスナップショット監視（ps aux vs ps -ef）
   2. 4.2 プロセスステータス（STAT）の読み解き方（R, S, D, Z, T）
   3. 4.3 topコマンドによるリアルタイムリソース監視と内部コマンド
   4. 4.4 プロセスのツリー表示（pstree）とロードアベレージ（uptime）
5. 5. シグナルによるプロセス制御と終了（kill, pkill, killall）
   1. 5.1 Linuxシグナルの仕組みと主要シグナル一覧（1, 2, 9, 15, 18, 19）
   2. 5.2 SIGTERM（15: 正常終了要求）とSIGKILL（9: 強制終了）の絶対原則
   3. 5.3 kill, pkill, killall コマンドの使い分けと書式
   4. 5.4 プロセス検索（pgrep）との連携
6. 6. 実機ハンズオン演習：AlmaLinux 9でターゲット変更とプロセス制御を体験
   1. 6.1 実機検証環境の確認
   2. 6.2 演習1：systemdターゲットの確認と切り替え
   3. 6.3 演習2：バックグラウンドジョブ制御とnohupの実行継続検証
   4. 6.4 演習3：シグナル送信によるプロセスの安全な終了と強制終了
7. 7. LinuC 101試験対策まとめとコマ問頻出チェック
   1. 7.1 コマ問（記述式）頻出キーワード一覧表
   2. 7.2 Ping-t演習へのブリッジ（対象分野と推奨学習順）
8. 8. まとめと次回予告

1. Linuxブートプロセスの全5フェーズ#

Linuxサーバーの起動は、単一のプログラムが一括して行うのではなく、段階ごとに役割の異なるプログラムが順次処理を引き継ぐシーケンスで進行します。この流れを把握することは、起動障害時の原因特定やLinuC試験対策において不可欠な基礎知識となります。

1.1 フェーズ1：ファームウェア（BIOS/UEFI）によるハードウェア初期化#

サーバーの電源が投入されると、マザーボード上のROM（不揮発性メモリ）に記録されたファームウェアが最初に稼働します。ファームウェアには従来型のBIOS（Basic Input/Output System）と、現在の標準であるUEFI（Unified Extensible Firmware Interface）の2種類が存在します。

ファームウェアはまずPOST（Power-On Self-Test）と呼ばれる自己診断テストを実行し、CPU、メモリ、ストレージコントローラなどの物理ハードウェアが正常に認識されているかを検査します。診断完了後、NVRAMに保存された起動順序設定（Boot Order）に従って起動可能なデバイスを探索します。

• BIOS環境: 起動デバイスの先頭セクタ（セクタ0）に書き込まれた512バイトのMBR（Master Boot Record）を読み込み、そこに格納された第1段階ブートローダに制御を渡します。
• UEFI環境: GPT（GUID Partition Table）で初期化されたストレージ上のESP（EFI System Partition: FAT32ファイルシステム）を参照し、/EFI/almalinux/grubx64.efiなどの実行ファイル形式ブートローダを直接メモリ上に読み込みます。

1.2 フェーズ2：ブートローダ（GRUB2）の読み込みとカーネル選択#

現代のエンタープライズLinuxディストリビューションにおいて標準採用されているブートローダはGRUB2（GRand Unified Bootloader version 2）です。GRUB2の主な役目は、ストレージ上にあるLinuxカーネルバイナリと初期RAMディスクイメージをメモリ上にロードし、カーネルに実行権を移管することです。

GRUB2は起動時に設定ファイル（/boot/grub2/grub.cfg、UEFI環境ではディストリビューションに応じて/boot/efi/EFI/redhat/grub.cfg等）を読み込み、起動メニュー画面を表示します。管理者はこの画面で利用するカーネルバージョンを選択したり、起動時引数（カーネルパラメータ）を編集してレスキューモードで起動したりすることができます。

1.3 フェーズ3：カーネル展開と初期RAMディスク（initramfs）の役割#

GRUB2によってメモリ上にロードされたカーネル本体ファイルは、通常/boot/vmlinuz-<kernel-version>という名称で保存された圧縮バイナリです。カーネルは自己解凍を行ってメモリ上に展開された後、CPUの仮想記憶制御を初期化し、各種デバイスドライバの組み込みを開始します。

ここで重要な技術的課題が生じます。実際のルートファイルシステム（/）は、RAIDコントローラ、LVM論理ボリューム、あるいはNVMeストレージなどの上に構築されていることが多く、それらを読み書きするためのカーネルモジュール（ドライバ）は本来ルートファイルシステム内の/lib/modules/に配置されています。つまり、「ドライバを読むためにディスクをマウントする必要があるが、ディスクをマウントするためのドライバがディスクの中にある」という循環参照の依存関係が発生します。

この矛盾を解決する仕組みが初期RAMディスク（initramfs: Initial RAM File System）です。GRUB2はカーネル本体とともに、あらかじめ必要最小限のドライバや初期化スクリプトを格納した一時的なルートイメージ（/boot/initramfs-<kernel-version>.img）をメモリ上に展開します。カーネルは一時的にこのinitramfsをルートとしてマウントし、その中のドライバを用いて物理ストレージやLVMを初期化します。正規のルートファイルシステムが読み込み可能となった段階で、真のルートファイルシステムへの切り替え（pivot_root）を実行します。

1.4 フェーズ4：初期化プロセス（systemd: PID 1）の起動#

ルートファイルシステムのマウントが完了すると、カーネルはユーザー空間における最初のプロセスを起動します。このプロセスのPID（プロセスID）は必ず「1」となります。

かつてのSysVinit環境では/sbin/initというシェルスクリプト群を直列実行するプロセスが起動していましたが、現代のLinuxでは/usr/lib/systemd/systemdがPID 1として実行されます。実機linuc-node01でも、PID 1がsystemdであることが確認できます。

[user01@linuc-node01 ~]$ ps -fp 1
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 01:40 ?        00:00:00 /usr/lib/systemd/systemd --switched-root --system --deserialize 31

1.5 フェーズ5：ターゲットに基づくサービス・環境の並列起動#

PID 1として起動したsystemdは、システム設定に基づき必要なバックグラウンドサービス（デーモン）、ネットワーク機能、ストレージマウント、ログインプロンプトなどを並列依存関係解決のもとで高速に立ち上げます。これらをグループ化して制御する仕組みがsystemdターゲットです。

1.6 カーネル起動ログの確認（dmesgコマンドとjournalctl -k）#

カーネルがブート時に出力したハードウェア認識ログや初期化メッセージは、カーネル内部のリングバッファ（メモリ領域）に保持されます。これを確認する基本コマンドがdmesgです。伝統的なLinux環境では起動時にリングバッファの内容がテキストファイル /var/log/dmesg に保存される構成もありましたが、AlmaLinux 9をはじめとする現代のsystemd標準環境では、dmesg コマンドの直接実行および systemd-journald による統合管理が主流となっています。

[user01@linuc-node01 ~]$ dmesg | head -n 4
[    0.000000] Linux version 5.14.0-687.42.1.el9_8.x86_64 (mockbuild@x64-builder01.almalinux.org)
[    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-687.42.1.el9_8.x86_64 root=/dev/mapper/almalinux-root ro resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable

2. systemdターゲットとランレベル管理#

systemdでは、システムの動作状態や実行モードを「ユニット（Unit）」の集合体であるターゲット（Target）として定義します。これは従来のSysVinitにおける「ランレベル（Runlevel）」に相当する概念ですが、複数の状態を直感的な名称で柔軟に構成できる点が異なります。

2.1 systemdユニットとターゲット（.target）の基本概念#

systemdが管理するすべての構成要素は「ユニット」と呼ばれ、拡張子によって分類されます。サービスを定義する.service、マウントポイントを定義する.mount、ソケットを管理する.socketなどがあり、これらを特定の到達目標（マイルストーン）として束ねるユニットが.targetです。

2.2 主要ターゲット一覧と旧ランレベル（0〜6）との完全対応#

LinuC試験では、旧SysVinitの数値ランレベルとsystemdターゲットユニット名の完全な対応関係が記述式問題（コマ問）を含めて頻出します。以下の表は確実に暗記する必要があります。

2.3 デフォルトターゲットの確認と恒久変更（get-default, set-default）#

システム起動時にどのターゲットを既定として立ち上げるかは、systemctlコマンドで管理します。この設定の実体は、/etc/systemd/system/default.targetから該当するターゲットユニットファイルへのシンボリックリンクです。

2.4 稼働ターゲットの一時的切り替え（systemctl isolate）#

システムを再起動することなく、現在稼働しているシステム状態を別のターゲットへ即座に移行させるには、isolateサブコマンドを使用します。

[user01@linuc-node01 ~]$ sudo systemctl isolate graphical.target

このコマンドを実行すると、graphical.targetおよびその依存ユニットが起動されると同時に、新ターゲットの依存ツリーに含まれない不要なサービスが自動的に停止されます。

2.5 障害復旧モード（rescue.target と emergency.target）#

設定不備やファイルシステム破損などによりOSが通常起動できない場合に使用する2つの復旧モードがあります。

• rescue.target: 必要最小限のローカルファイルシステムを読み書き可能（rw）でマウントし、基本デーモンを起動した上でrootシェルを提供します。旧ランレベル1に相当します。
• emergency.target: 追加ファイルシステムのマウントやサービス起動を一切行わず、リードオンリー（ro）のルートファイルシステムのみでrootシェルを立ち上げる最もプリミティブな復旧環境です。

3. プロセスの生成とジョブ管理（フォアグラウンド・バックグラウンド）#

Linuxにおけるすべての処理単位は「プロセス」としてカーネルによって管理されます。シェル上でコマンドを実行する際の実行制御と親子関係の仕組みを理解します。

3.1 プロセスの親子関係とPID・PPID#

Linux上のプロセスは、必ず既存の親プロセスからフォーク（forkシステムコール）され、新しいプログラムイメージを実行（execveシステムコール）することで生成されます。すべてのプロセスは一意のPID（Process ID）を持ち、その親プロセスの識別子をPPID（Parent Process ID）と呼びます。

親プロセスが子プロセスの終了通知（waitシステムコールによる終了ステータスの回収）を行わないまま放置されると、子プロセスは処理を終えているにもかかわらずプロセステーブルに残留するゾンビプロセス（Zombie: 状態コード Z）となります。

3.2 バックグラウンド実行（&）とジョブ制御（jobs, fg, bg, Ctrl+Z）#

シェル上で長時間かかるコマンドを実行する際、末尾に&を付与することでプロセスをバックグラウンド（非同期）で実行できます。

3.3 ログアウト後のプロセス実行継続（nohup, tmux, screen）#

通常、SSHなどの端末セッションからログアウトすると、シェルは傘下の全プロセスに対してハングアップシグナル（SIGHUP: シグナル番号1）を送信し、配下のプロセスはすべて強制終了します。

ログアウト後も処理を継続させたい場合には以下の方法を採用します。

• nohupコマンド: SIGHUPシグナルを無視（ignore）するラッパーとしてコマンドを起動します。標準出力・標準エラー出力は自動的にnohup.outファイルへリダイレクトされます。

  [user01@linuc-node01 ~]$ nohup python3 backup_script.py &

• 端末マルチプレクサ（tmux / screen）: 仮想的な端末セッションをサーバー常駐プロセスとして保持します。セッション内でスクリプトを実行した後にデタッチ（セッション離脱）することで、SSH接続を切断しても安全にバックグラウンド実行を継続できます。

4. プロセス監視コマンド（ps, top, pstree, uptime）#

システムエンジニアの実務およびLinuC試験において、現在稼働しているプロセスの状態やリソース消費量を正しく把握するコマンド群は必須の出題領域です。

4.1 psコマンドによるスナップショット監視（ps aux vs ps -ef）#

psは現時点のプロセスの静的スナップショットを出力するコマンドです。Linuxにおけるオプション体系には、ハイフンなしの「BSD形式」と、ハイフン付きの「UNIX/POSIX形式」の2大潮流があります。

[user01@linuc-node01 ~]$ ps aux | head -n 6
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.5 110968 19096 ?        Ss   01:40   0:00 /usr/lib/systemd/systemd --switched-root --system --deserialize 31
root           2  0.0  0.0      0     0 ?        S    01:40   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        S    01:40   0:00 [pool_workqueue_]
root           4  0.0  0.0      0     0 ?        I<   01:40   0:00 [kworker/R-rcu_gp]
root           6  0.0  0.0      0     0 ?        I<   01:40   0:00 [kworker/R-slub_flush]

4.2 プロセスステータス（STAT）の読み解き方（R, S, D, Z, T）#

ps auxの出力に含まれる「STAT」列は、プロセスが現在どのような状態にあるかを示します。主要なステータスコードは試験で確実に問われます。

4.3 topコマンドによるリアルタイムリソース監視と内部コマンド#

topコマンドは、CPU使用率、メモリ消費量、稼働プロセス一覧を一定間隔（デフォルト3秒）でリアルタイムに更新・表示する対話型監視ツールです。

起動中に利用できる代表的な対話キー操作：

• h または ?: ヘルプ画面の表示
• k: プロセスを指定して終了シグナル（kill）を送信
• r: プロセスの優先度（ナイス値）を変更（renice）
• M: プロセス一覧をメモリ消費率（%MEM）順にソート
• P: プロセス一覧をCPU使用率（%CPU）順にソート（デフォルト）
• q: topコマンドを終了

4.4 プロセスのツリー表示（pstree）とロードアベレージ（uptime）#

プロセスの親子関係を視覚的に把握するにはpstreeコマンドを用います。引数にPIDを指定すると特定プロセスの配下ツリーのみを出力できます。

また、システムの稼働時間と負荷の推移を確認するにはuptimeコマンドを使用します。

[user01@linuc-node01 ~]$ uptime
 07:11:04 up  5:30,  0 users,  load average: 0.05, 0.08, 0.02

末尾の3つの数値はロードアベレージ（Load Average）であり、左から順に「過去1分間」「過去5分間」「過去15分間」においてCPUの割り当て待ちおよびディスクI/O待ち（D状態）となっていた平均プロセス数を示しています。

5. シグナルによるプロセス制御と終了（kill, pkill, killall）#

プロセスに対して終了や設定の再読み込みなどを非同期に通知する通信機構をシグナル（Signal）と呼びます。シグナルの名称と番号、それぞれの動作の違いを明確に区別することが運用・試験対策双方の鍵となります。

5.1 Linuxシグナルの仕組みと主要シグナル一覧（1, 2, 9, 15, 18, 19）#

シグナルは番号（整数）またはシンボル名（プレフィックスSIGで始まる文字列）で指定できます。LinuCで問われる主要シグナルは下表の通りです。

5.2 SIGTERM（15: 正常終了要求）とSIGKILL（9: 強制終了）の絶対原則#

システム管理における極めて重要な鉄則は、「まずSIGTERM（15）を送信し、それでも応答しない場合に限り最後の手段としてSIGKILL（9）を使用する」という点です。

SIGTERMを受信したプロセスは、開いているファイルの書き出し、データベース接続の切断、一時ファイルの削除といった終了処理（クリーンアップハンドラ）を自律的に完了させてから安全に終了します。一方、SIGKILLはプロセスを経由せずカーネルが強制的にプロセステーブルから抹消するため、データ破損や不整合が生じるリスクがあります。さらに、SIGKILLとSIGSTOPの2つはプロセス側でシグナルを捕獲（キャッチ）したり無視したりすることが仕様上絶対に不可能です。

5.3 kill, pkill, killall コマンドの使い分けと書式#

プロセスにシグナルを送信するコマンドは、対象の指定方法によって使い分けます。

5.4 プロセス検索（pgrep）との連携#

pkillと対をなすコマンドとして、プロセス名や所有ユーザーから該当するPIDのみを高速に抽出するpgrepがあります。

[user01@linuc-node01 ~]$ pgrep systemd
1
603
617
749
8496

[user01@linuc-node01 ~]$ pgrep -l -u user01 sshd
8497 sshd

-lオプションを付加することで、PIDと同時にプロセス名を出力して誤爆を防ぐことができます。

6. 実機ハンズオン演習：AlmaLinux 9でターゲット変更とプロセス制御を体験#

実機環境linuc-node01を利用して、systemdターゲットの操作とプロセスのジョブ制御・終了シグナル送信を体系的に演習します。

6.1 実機検証環境の確認#

現在のシステムのターゲット状況と、実行中の初期化プロセスを確認します。

[user01@linuc-node01 ~]$ systemctl get-default
multi-user.target

[user01@linuc-node01 ~]$ systemctl list-units --type=target --state=active
  UNIT                   LOAD   ACTIVE SUB    DESCRIPTION
  basic.target           loaded active active Basic System
  cryptsetup.target      loaded active active Local Encrypted Volumes
  local-fs.target        loaded active active Local File Systems
  multi-user.target      loaded active active Multi-User System
  network.target         loaded active active Network
  paths.target           loaded active active Path Units
  slices.target          loaded active active Slice Units
  sockets.target         loaded active active Socket Units
  sysinit.target         loaded active active System Initialization
  timers.target          loaded active active Timer Units

6.2 演習1：systemdターゲットの確認と切り替え#

デフォルトターゲットをグラフィカルターゲットへ変更し、設定のシンボリックリンクがどのように書き換わるかを確認した上で元のCUIターゲットへ戻します。

# デフォルトターゲットの変更（要sudo）
[user01@linuc-node01 ~]$ sudo systemctl set-default graphical.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.

# 確認
[user01@linuc-node01 ~]$ systemctl get-default
graphical.target

# 元のCUIマルチユーザーターゲットへ戻す
[user01@linuc-node01 ~]$ sudo systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

6.3 演習2：バックグラウンドジョブ制御とnohupの実行継続検証#

バックグラウンドで処理を開始し、ジョブ一覧で状態を確認した後にフォアグラウンドへ引き戻して中断する流れを追体験します。

# 1. バックグラウンドで実行
[user01@linuc-node01 ~]$ sleep 300 &
[1] 8598

# 2. ジョブ一覧とPIDを確認
[user01@linuc-node01 ~]$ jobs -l
[1]+  8598 実行中               sleep 300 &

# 3. フォアグラウンドへ復帰
[user01@linuc-node01 ~]$ fg %1
sleep 300
^C
# Ctrl+CでSIGINTを送信して停止

6.4 演習3：シグナル送信によるプロセスの安全な終了と強制終了#

nohupを用いてバックグラウンド実行したプロセスに対し、まずSIGTERM (15)を送信して正常終了を確認します。

# 1. nohupで起動
[user01@linuc-node01 ~]$ nohup sleep 600 > /tmp/nohup_test.log 2>&1 &
[1] 8610

# 2. プロセスの生存確認
[user01@linuc-node01 ~]$ ps -o pid,ppid,stat,command -p 8610
    PID    PPID STAT COMMAND
   8610    8575 S    sleep 600

# 3. SIGTERM (15) で終了要求を送信
[user01@linuc-node01 ~]$ kill -15 8610

# 4. プロセスが消滅したことを確認
[user01@linuc-node01 ~]$ ps -p 8610
    PID TTY          TIME CMD
（該当なし：終了完了）
[user01@linuc-node01 ~]$ rm -f /tmp/nohup_test.log

7. LinuC 101試験対策まとめとコマ問頻出チェック#

本章の学習内容から、LinuC 101試験で記述式（コマ問）や複数選択問題として頻出する重要ポイントを総整理します。

7.1 コマ問（記述式）頻出キーワード一覧表#

7.2 Ping-t演習へのブリッジ（対象分野と推奨学習順）#

LinuC 101試験の一発合格を目指すにあたり、Web学習プラットフォーム「Ping-t」の最強WEB問題集を活用した反復演習を強く推奨します。

• 主題1.01：システムアーキテクチャ
  • 「ブートプロセスとsystemd」分野（重要度4）：ターゲット名とランレベル対応、systemctl set-default、dmesg、initramfsの仕組みを集中的に解きます。コンボ（正解連続）を維持できるまで周回してください。
  • 「プロセスの生成、監視、終了」分野（重要度3）：シグナル番号（1, 2, 9, 15, 18, 19）の識別、ps auxのSTAT記号（R, S, D, Z, T）、nohup、kill、pkillの書式記述問題を完璧に定着させます。

8. まとめと次回予告#

次回は主題1.04「GNUおよびUnixのコマンド」より、Linuxディストリビューションの根幹をなすパッケージ管理システム（RPM / yum / dnf および Debian / dpkg / apt）の仕組みとコマンド体系を詳細に比較・解説します。