起動プロセスを理解していないと、どこから調査すればよいか途方に暮れます。
RHEL 7以降のLinuxはsystemdが起動管理を担っており、
旧来のinitやランレベルとは仕組みが根本的に変わっています。
この記事では、BIOS→GRUB2→カーネル→systemd→targetという起動順序の全体像、
journalctl -b / systemctl list-units による起動状態の確認方法、
そして起動エラーが発生したときの調査手順を体系的に解説します。
RHEL 9 / Rocky Linux 9 / Ubuntu 24.04 LTS で動作確認済みです。
この記事のポイント
・BIOS→GRUB2→kernel→systemd→targetの起動順序を理解できる
・journalctl -b で起動時のログを確認し、エラーを特定できる
・systemctl list-units でサービス起動状態を一覧確認できる
・起動に失敗したサービスの原因をsystemctl statusで調査できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxのsystemdとはなにかーinitとの違い
旧来のLinux（RHEL 6以前、SysVinit）では、起動スクリプト（/etc/rc.d/init.d/配下）が1つずつ順番に実行されていました。
処理が直列であるため、起動に時間がかかるのが欠点でした。
systemd はこれを根本から変えました。主な特徴は以下のとおりです：
・並列起動：依存関係を解析し、独立したサービスを同時に起動する
・依存管理：.service / .target ファイルで明示的に依存を定義できる
・ログ統合：journald によりサービスのログを一元管理する
・socket activation：サービスを遅延起動しリソースを節約する
「ランレベル」は systemd では「target」に置き換わっています。
| SysVinit ランレベル | systemd target | 説明 |
|---|---|---|
| 0 | poweroff.target | シャットダウン |
| 1 | rescue.target | シングルユーザーモード |
| 3 | multi-user.target | テキスト（CUI）モード |
| 5 | graphical.target | グラフィカル（GUI）モード |
| 6 | reboot.target | 再起動 |
Linuxの起動シーケンスをステップで理解する
起動の流れをBIOSからログインプロンプトまで順番に追っていきましょう。1. BIOS / UEFI
電源を入れると最初にBIOS（またはUEFI）が動作します。ハードウェアの初期化（POST: Power-On Self Test）を行い、
起動デバイスを決定してブートローダを読み込みます。
UEFI環境ではEFIシステムパーティション（ESP）から直接ブートローダを呼び出します。
2. GRUB2（ブートローダ）
GRUB2（GRand Unified Bootloader version 2）はLinuxの標準ブートローダです。・設定ファイル：/boot/grub2/grub.cfg（自動生成）
・カーネルオプションのカスタマイズ：/etc/default/grub
・ブートメニューでどのカーネルを起動するか選択できる
GRUB2 はカーネルイメージ（vmlinuz）と初期RAMディスク（initramfs）をメモリに展開し、カーネルに制御を渡します。
3. カーネル（Linux Kernel）
カーネルが起動すると以下の初期化処理を行います：・メモリ管理の初期化
・CPUの初期化
・ハードウェアデバイスの検出（dmesgに記録される）
・ルートファイルシステムのマウント
・/sbin/systemd（PID=1）の起動
「PID 1」として起動するのが systemd です。
これ以降の全サービス・プロセスは systemd の子プロセスとして管理されます。
4. systemd の初期化処理
systemd は /etc/systemd/system/ および /usr/lib/systemd/system/ の設定を読み込み、デフォルトtarget（通常は multi-user.target または graphical.target）に向けて起動を進めます。
# デフォルトtargetを確認する systemctl get-default # 実行例 multi-user.target # デフォルトtargetを変更する（次回起動から有効） sudo systemctl set-default graphical.target
5. targetとサービスの起動
systemd は target の依存関係を解析し、必要なサービスを並列起動します。例：multi-user.target は sshd.service、crond.service、NetworkManager.service などを起動します。
# multi-user.target の依存関係を確認 systemctl list-dependencies multi-user.target # 現在のtargetを確認（ランレベルの現在地） systemctl list-units --type=target --state=active
journalctl -b で起動時ログを確認する
起動に問題があったとき、journalctl -b は最も強力な調査ツールです。1. 基本的な使い方
# 今回の起動時のログを全表示 journalctl -b # エラー・警告のみ表示（起動トラブルの調査に最適） journalctl -b -p err # 前回の起動時のログ（再起動直前のエラーを調べるのに使う） journalctl -b -1 # さらに前の起動ログを確認 journalctl -b -2 # 過去の起動一覧を表示（何回分の記録があるか確認） journalctl --list-boots
-3 8f9a1234abc0 Thu 2026-04-04 10:00:00 JST—Thu 2026-04-04 11:30:00 JST -2 1b2c3d4e5f60 Fri 2026-04-05 09:00:00 JST—Fri 2026-04-05 18:00:00 JST -1 a1b2c3d4e5f0 Mon 2026-04-06 08:00:00 JST—Mon 2026-04-06 22:00:00 JST 0 9z8y7x6w5v40 Tue 2026-04-07 08:00:00 JST—Tue 2026-04-07 08:15:00 JST
2. 起動時間の分析
# 起動にかかった時間を分析（どのサービスが遅いか） systemd-analyze # 実行例 Startup finished in 1.532s (kernel) + 3.241s (initrd) + 12.453s (userspace) = 17.226s graphical.target reached after 12.312s in userspace # 各サービスの起動時間を表示（遅い順） systemd-analyze blame # 起動の依存グラフをSVGで出力（視覚化） systemd-analyze plot > /tmp/boot.svg
systemctl list-units でサービス起動状態を確認する
1. 全サービスの状態確認
# アクティブなunitを全て表示 systemctl list-units # 特定タイプ（service）のみ表示 systemctl list-units --type=service # 失敗したサービスのみ表示（起動トラブル調査の第一歩） systemctl list-units --state=failed # 全unitの状態を表示（無効なものも含む） systemctl list-units --all
UNIT LOAD ACTIVE SUB DESCRIPTION * httpd.service loaded failed failed The Apache HTTP Server LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state. SUB = The low-level unit activation state. 1 loaded units listed.
2. 特定サービスの詳細確認
# サービスの状態と直近のログを表示 systemctl status httpd # 自動起動の有効・無効を確認 systemctl is-enabled httpd # 特定サービスのログのみ journalctl で表示 journalctl -u httpd -n 50
3. サービスの自動起動を制御する
# 自動起動を有効にする sudo systemctl enable httpd # 自動起動を無効にする sudo systemctl disable httpd # 有効化してすぐ起動する（最も使う操作） sudo systemctl enable --now httpd # 再起動 sudo systemctl restart httpd # 設定ファイルの再読み込み（サービスを止めずに） sudo systemctl reload httpd
systemdのユニットファイルを理解する
systemd は .service / .target / .socket などの「ユニットファイル」でサービスを管理します。トラブルシュートには、ユニットファイルの内容を読めることが必要です。
1. ユニットファイルの場所
・/usr/lib/systemd/system/：パッケージが提供するデフォルトのユニットファイル（書き換え禁止）・/etc/systemd/system/：管理者がカスタマイズするためのユニットファイル（こちらが優先される）
・/run/systemd/system/：実行時に動的に生成されるユニットファイル
2. ユニットファイルの内容を確認する
# sshd のユニットファイルを表示 systemctl cat sshd # 実行例（一部抜粋） # /usr/lib/systemd/system/sshd.service [Unit] Description=OpenSSH server daemon Documentation=man:sshd(8) man:sshd_config(5) After=network.target sshd-keygen.target Wants=sshd-keygen.target [Service] Type=notify ExecStart=/usr/sbin/sshd -D $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target
3. ユニットファイルの主要セクション
・[Unit]：ユニットの説明と依存関係（After=, Before=, Requires=, Wants=）・[Service]：実行するコマンド（ExecStart=）、再起動ポリシー（Restart=）
・[Install]：自動起動時のtarget（WantedBy=）
After=network.target は「ネットワークの初期化後に起動する」という意味で、起動順序のトラブル（ネットワークが使えない状態でDBへ接続しようとするなど）の原因になることがあります。
4. カスタムサービスを作成する
自作スクリプトをsystemdサービスとして管理することもできます。# /etc/systemd/system/myapp.service を作成 [Unit] Description=My Application After=network.target [Service] Type=simple User=myuser ExecStart=/usr/local/bin/myapp Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
# ユニットファイルを配置したら daemon-reload が必要 sudo systemctl daemon-reload # サービスを有効化して起動 sudo systemctl enable --now myapp # 動作確認 systemctl status myapp journalctl -u myapp -f
起動エラーの調査・対処法
1. サービスが起動しない場合の調査手順
# ステップ1: 失敗しているサービスを特定する systemctl list-units --state=failed # ステップ2: 詳細なエラー内容を確認する systemctl status サービス名 # ステップ3: journalctl でさらに詳しいログを取得 journalctl -u サービス名 -n 100 --no-pager # ステップ4: 起動時全体のエラーを確認 journalctl -b -p err --no-pager
2. GRUB2のレスキューモードで起動する
カーネルパニックやrootファイルシステムのマウント失敗など、systemdが起動すらできない場合はGRUB2のメニューから救出できます。
起動時にGRUB2メニューで
e を押し、linuxの行に systemd.unit=rescue.target を追加して起動します。rescue.targetでは最低限のサービスのみ起動し、root パスワードを入力してシングルユーザーモードになります。
3. systemd-journal の永続化（記録が消える問題の対処）
デフォルト設定では journald のログは再起動で消えます。前回の起動エラーを調べるために、ログを永続化しておくことをお勧めします。
# /var/log/journal を作成してログを永続化 sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald # 確認 journalctl --disk-usage
4. 「Failed to start」エラーの典型的な原因と対処
・設定ファイルの構文エラー：nginx -t、httpd -t などで事前チェック・ポートの競合：
ss -tlnp | grep :80 で使用中のポートを確認・SELinux によるブロック：
ausearch -m avc -ts today で確認・依存サービスが未起動：journalctl -u で依存先のサービスログを確認
・ExecStart パスが間違っている：
systemctl cat サービス名 でユニットファイルを確認5. 緊急時のレスキューシェルに入る方法
ルートパーティションのマウント失敗など、systemd が起動できない深刻なケースにはGRUB2 のメニューから救出モードに入ります。
# GRUB2 メニューで 'e' キーを押して編集モードへ # linux の行の末尾に以下を追加して Ctrl+X で起動 # レスキューモード（rootパスワード要求あり） systemd.unit=rescue.target # 緊急モード（最小限のマウントのみ・rootパスワード不要） systemd.unit=emergency.target
# レスキューシェル内でルートファイルシステムを読み書き可能に再マウント mount -o remount,rw / # /etc/fstab の問題を調査 cat /etc/fstab # ファイルシステムの整合性チェック（マウントを解除してから） umount /data fsck -y /dev/sdb1
systemd環境での実務Tips
1. cronとsystemd timerの使い分け
定期実行タスクには伝統的な cron と、systemd の timer ユニットの2つが使えます。・cron：シンプルな定期実行に向く。設定が直感的で学習コストが低い
・systemd timer：サービスとの依存関係管理、実行ログのjournald統合、
BootTimer（起動○分後に実行）などの柔軟な指定が可能
既存のシステムでは cron が多いですが、
新規構築の場合は systemd timer の採用も検討する価値があります。
2. systemdで管理されるプロセスのリソース制限
systemd のユニットファイルでは、CPUやメモリの使用制限を設定できます。# /etc/systemd/system/myapp.service に追記 [Service] # CPUを最大50%に制限 CPUQuota=50% # メモリを最大512MBに制限 MemoryLimit=512M # ファイルシステムをread-onlyでマウント（セキュリティ強化） ProtectSystem=full
3. systemctl show でユニットの全設定を確認する
# sshd の全設定パラメータを表示 systemctl show sshd # 特定パラメータのみ表示 systemctl show sshd -p MainPID,ActiveState,SubState,Restart # 実行例 MainPID=1234 ActiveState=active SubState=running Restart=on-failure
4. サービスの依存関係を可視化する
起動が遅い原因や、サービスが起動しない理由を依存関係から調べることができます。# sshd が依存しているユニットを確認 systemctl list-dependencies sshd # sshd に依存しているユニットを確認（逆引き） systemctl list-dependencies sshd --reverse # 全体の依存ツリーを深く掘り下げる systemctl list-dependencies multi-user.target --all
本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| 起動時のエラーを確認 | journalctl -b -p err |
| 前回起動時のログを確認 | journalctl -b -1 |
| 失敗したサービスを一覧表示 | systemctl list-units --state=failed |
| サービスの詳細状態を確認 | systemctl status サービス名 |
| デフォルトtargetを確認 | systemctl get-default |
| 起動時間を分析（遅いサービスを特定） | systemd-analyze blame |
| サービスの自動起動を有効化 | systemctl enable --now サービス名 |
| 特定サービスのログを確認 | journalctl -u httpd -n 50 |
「サービスが起動しない」「起動が遅い」「再起動後にサービスが落ちている」といった
現場でよくあるトラブルを、原因の見当をつけながら調査できるようになります。
まずは
systemctl list-units --state=failed を実行してみてください。失敗しているサービスがなければ安心、あればそこから調査を始めましょう。
systemd の理解は、Linuxサーバーを「なんとなく動かす」から
「なぜ動いているか・なぜ止まるかを説明できる」レベルへの一歩です。
サービスの起動ログを毎日確認する習慣をつけることで、
障害の予兆を早期に発見できるようになります。
ログの詳細な読み方については、Linuxのログファイルの種類と確認方法もあわせてご覧ください。
makeコマンドによるソフトウェアのビルドについては、makeコマンドとMakefileの使い方で詳しく解説しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：makeコマンドとMakefileの使い方｜ソースコードのビルドからCMakeとの違いまで
- 前のページへ：Linuxのディレクトリ構造を一覧で理解する｜/etc・/var・/usr・/homeの役割と使い分け
- この記事の属するカテゴリ：【Linux入門】初心者のための基礎知識・講座へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます