宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「サーバーが起動しない」「どのサービスが起動に失敗しているのかわからない」
Linuxサーバーを管理していると、こうした起動トラブルに遭遇することがあります。

CentOS 7以降のRHEL系では、起動の仕組みがSysVinitからsystemdに変わりました。
systemdを正しく理解することで、起動プロセスの確認やトラブル時の原因特定が格段にスムーズになります。

この記事では、systemdによるOS起動プロセスの流れから、
journalctl -bによる起動ログの確認、systemctl list-unitsによるサービス状態の把握まで、
実務で使える手順を実際のコマンド出力例と合わせて解説します。
【この記事でわかること】
・systemdはCentOS 7 / RHEL 7以降の標準initシステムで起動順序をユニットで管理する
・journalctl -b でこの起動セッションのログを確認できる
・systemctl list-units --state=failed で失敗したサービスを一覧表示できる
・systemctl list-units --type=service で全サービスの起動状態を確認できる

「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

systemdとは？CentOS 7以降の起動の仕組み

CentOS 6以前はSysVinit（System V init）が使われており、/etc/rc.d/init.d/配下のスクリプトが順番に実行されていました。
CentOS 7 / RHEL 7からはsystemdに変わり、起動の設計が根本的に変わっています。

1. SysVinitとsystemdの違い

項目 SysVinit（CentOS 6以前） systemd（CentOS 7以降）
起動方式 シェルスクリプトを順番に実行 ユニット単位で並列起動
起動速度 遅い（直列処理） 速い（並列処理）
設定ファイル /etc/init.d/スクリプト /lib/systemd/system/*.service
ログ確認 /var/log/messages journalctl（バイナリログ）
管理コマンド service / chkconfig systemctl

2. systemdのユニットとは

systemdでは「ユニット（unit）」という単位で起動するリソースを管理します。

・service：デーモンプロセス（httpd、sshdなど）
・socket：ソケット通信の起動トリガー
・target：複数ユニットをグループ化したもの（SysVinitのrunlevelに相当）
・mount：ファイルシステムのマウント
・timer：cronに相当する定期実行

起動時にsystemdはこれらのユニットを依存関係に従って並列で起動します。

3. systemdの起動フロー


BIOS/UEFI
  ↓ ハードウェア初期化
ブートローダー（GRUB2）
  ↓ カーネルをロード
Linuxカーネル起動
  ↓ initramfsの展開・ルートファイルシステムマウント
systemd（PID 1）起動
  ↓ ユニット依存関係の解析
default.target（multi-user.target または graphical.target）へ
  ↓ 各サービスユニットを並列起動
ログイン画面 / ランレベル完了
systemdはPID 1として起動し、すべてのプロセスの親となります。

デフォルトのターゲットは以下のコマンドで確認できます。


$ systemctl get-default
multi-user.target

journalctl -b で起動ログを確認する

systemdのログはjournaldが収集しており、journalctlコマンドで参照します。
起動時のログを確認するには-bオプションを使います。

1. 今回の起動ログを確認する


$ journalctl -b
# 今回の起動（current boot）からのすべてのログを表示する
# 量が多いので less でページング表示される
# qキーで終了

# 実際の出力例（抜粋）
Apr 07 09:00:01 web01.example.com kernel: Linux version 5.14.0-162.23.1.el9_1.x86_64
Apr 07 09:00:01 web01.example.com kernel: BIOS-provided physical RAM map:
Apr 07 09:00:02 web01.example.com systemd[1]: Started Journal Service.
Apr 07 09:00:03 web01.example.com systemd[1]: Reached target Basic System.
Apr 07 09:00:04 web01.example.com systemd[1]: Started OpenSSH Server Daemon.
Apr 07 09:00:05 web01.example.com systemd[1]: Reached target Multi-User System.
Apr 07 09:00:05 web01.example.com systemd[1]: Startup finished in 3.812s (kernel) + 8.476s (userspace) = 12.288s.
最後の行の「Startup finished」で起動完了時間が確認できます。

2. 前回の起動ログを確認する

再起動後に前回の起動ログを参照したい場合は-b -1を使います。


$ journalctl -b -1
# -1 = 1つ前の起動セッション
# -2 = 2つ前の起動セッション

# 過去の起動一覧を確認する
$ journalctl --list-boots
-3 d3e2a9b... Thu 2026-04-03 09:00:01 JST—Thu 2026-04-03 18:30:12 JST
-2 a8c4f1e... Fri 2026-04-04 09:00:02 JST—Fri 2026-04-04 18:31:05 JST
-1 b7d5e2f... Mon 2026-04-06 09:00:00 JST—Mon 2026-04-06 18:29:58 JST
 0 c9f8a3b... Tue 2026-04-07 09:00:01 JST—Tue 2026-04-07 10:25:33 JST

3. エラーのみ絞り込んで表示する

起動ログが大量にある場合、エラーや警告のみ表示させると問題の特定が速くなります。


$ journalctl -b -p err
# -p err : エラー（優先度3）以上のメッセージのみ表示
# 優先度: 0=emerg 1=alert 2=crit 3=err 4=warning 5=notice 6=info 7=debug

$ journalctl -b -p warning
# 警告以上のメッセージを表示

# 特定のサービスのログのみ確認
$ journalctl -b -u httpd
# -u httpd : httpdサービスの起動時ログのみ表示

4. リアルタイムでログを追いかける


$ journalctl -f
# -f : tail -f と同様にリアルタイムで追いかける

$ journalctl -f -u httpd
# httpdサービスのログをリアルタイムで追いかける

systemctl list-units で起動状態を確認する

systemctlコマンドでは現在起動しているユニットの一覧を確認できます。
起動トラブルの診断にはlist-unitsサブコマンドが特に有効です。

1. 起動失敗したサービスを確認する

最もよく使うのが「失敗したユニットのみ表示」するオプションです。


$ systemctl list-units --state=failed
# 起動に失敗したユニットをすべて表示

# 出力例
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
* mysqld.service          loaded failed failed MySQL 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.
この出力で「ACTIVE = failed」になっているサービスが起動失敗しています。

2. 全サービスの起動状態を確認する


$ systemctl list-units --type=service
# type=service でサービス（デーモン）のみ表示

# 出力例（抜粋）
UNIT                      LOAD   ACTIVE SUB     DESCRIPTION
  atd.service             loaded active running Job spooling tools
  auditd.service          loaded active running Security Auditing Service
  chronyd.service         loaded active running NTP client/server
  crond.service           loaded active running Command Scheduler
* mysqld.service          loaded failed failed  MySQL Server
  sshd.service            loaded active running OpenSSH server daemon
  tuned.service           loaded active running Dynamic System Tuning Daemon

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.

7 loaded units listed.

3. 自動起動設定を確認する

サービスがOS起動時に自動起動する設定かどうかはlist-unit-filesで確認できます。


$ systemctl list-unit-files --type=service
# サービスごとの自動起動設定一覧

# 出力例（抜粋）
UNIT FILE                STATE
atd.service              enabled   # 自動起動する
auditd.service           enabled
httpd.service            disabled  # 自動起動しない
mysqld.service           enabled
sshd.service             enabled

# 特定サービスの自動起動状態を確認
$ systemctl is-enabled httpd
disabled

$ systemctl is-enabled sshd
enabled

4. サービスの詳細状態を確認する

特定のサービスの詳細な状態（起動時刻・PID・最近のログ）を確認するにはstatusを使います。


$ systemctl status sshd
* sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-04-07 09:00:04 JST; 1h 30min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1234 (sshd)
      Tasks: 1 (limit: 23456)
     Memory: 5.2M
        CPU: 105ms
     CGroup: /system.slice/sshd.service
             └─1234 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Apr 07 09:00:04 web01.example.com systemd[1]: Starting OpenSSH server daemon...
Apr 07 09:00:04 web01.example.com sshd[1234]: Server listening on 0.0.0.0 port 22.
Apr 07 09:00:04 web01.example.com systemd[1]: Started OpenSSH server daemon.
Active行の「active (running)」が正常起動中を示しています。
「active (exited)」は正常終了済み（ワンショット型サービス）、「failed」は起動失敗を示します。

起動トラブルシュート：よくある起動失敗の調査手順

実際の起動トラブルに遭遇したときの調査フローを解説します。

1. 起動失敗したサービスを特定する


$ systemctl list-units --state=failed
# 失敗したサービスを確認

# 例: mysqld.service が failed になっている場合
$ systemctl status mysqld
# エラーメッセージと直近のログを確認

$ journalctl -b -u mysqld
# 起動時のmysqldのすべてのログを確認

2. 依存関係によるカスケード失敗を確認する

あるサービスの失敗が原因で、依存するサービスも起動失敗する「カスケード失敗」が発生することがあります。


$ systemctl list-dependencies mysqld
# mysqldが依存するユニットをツリー表示
# どこで依存関係が切れているか確認できる

# 例: ネットワーク起動前にDBが起動しようとして失敗している場合
$ systemctl list-dependencies mysqld | grep network

3. ブートプロセス全体の時間を確認する

起動が遅い場合、どのサービスが時間を取っているか確認できます。


$ systemd-analyze
Startup finished in 3.812s (kernel) + 8.476s (userspace) = 12.288s
graphical.target reached after 12.244s in userspace.

$ systemd-analyze blame
# 各サービスの起動にかかった時間を長い順に表示
# 出力例
6.532s mysqld.service
2.245s httpd.service
1.120s NetworkManager.service
  982ms auditd.service
  754ms rsyslog.service

4. 緊急モードでの起動トラブル対応

通常モードで起動できない場合、カーネルパラメーターを変更して起動モードを変えることができます。


# GRUB2の起動メニューで「e」を押して編集モードに入る
# linux行の末尾に以下を追加する

# 緊急モード（最小限のファイルシステムのみ）
systemd.unit=emergency.target

# レスキューモード（シングルユーザー相当）
systemd.unit=rescue.target

サービスの起動・停止・再起動の基本操作

journalctlとlist-unitsで問題を特定したあとの、サービス操作コマンドをまとめます。

1. サービスの起動・停止・再起動


# サービスを起動する
$ sudo systemctl start httpd

# サービスを停止する
$ sudo systemctl stop httpd

# サービスを再起動する（停止→起動）
$ sudo systemctl restart httpd

# 設定を再読み込みする（停止なし）
$ sudo systemctl reload httpd

# 起動できなければ再起動する（reload-or-restart）
$ sudo systemctl reload-or-restart httpd

2. 自動起動の有効化・無効化


# 自動起動を有効にする
$ sudo systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

# 自動起動を無効にする
$ sudo systemctl disable httpd

# 起動して自動起動も有効にする（--now オプション）
$ sudo systemctl enable --now httpd

# 停止して自動起動も無効にする
$ sudo systemctl disable --now httpd

/boot領域の空き容量不足によるカーネル更新エラーの対処

yum updateやdnf upgradeでシステムを更新し続けると、過去のカーネルが/boot領域に蓄積されて
「No space left on device」エラーが発生することがあります。

1. /boot領域の使用状況を確認する


$ df -h /boot
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/sda1        497M  455M   42M   92% /boot

# インストール済みカーネルの一覧を確認
$ rpm -q kernel
kernel-3.10.0-1062.4.3.el7.x86_64
kernel-3.10.0-1062.9.1.el7.x86_64
kernel-3.10.0-1127.19.1.el7.x86_64
kernel-3.10.0-1160.92.1.el7.x86_64
kernel-3.10.0-1160.99.1.el7.x86_64

2. 古いカーネルを削除する（CentOS 7 / yum）


# yum-utilsをインストール（package-cleanupコマンド）
$ sudo yum install -y yum-utils

# 古いカーネルを削除（現世代を含む2世代を残す）
$ sudo package-cleanup --oldkernels

# 3世代を残して削除する場合
$ sudo package-cleanup --oldkernels --count=3

3. 古いカーネルを削除する（Rocky Linux 9 / RHEL 9 / dnf）


# dnfでは直接指定して削除
$ sudo dnf remove kernel-3.10.0-1062.4.3.el7.x86_64

# または保持する世代数を設定ファイルで指定
$ sudo vi /etc/dnf/dnf.conf
# installonly_limit=3 に変更（デフォルトは3）

4. 削除後の確認


$ df -h /boot
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/sda1        497M  210M  287M   43% /boot
# 使用量が92%→43%に改善した

$ rpm -q kernel
kernel-3.10.0-1160.92.1.el7.x86_64
kernel-3.10.0-1160.99.1.el7.x86_64
# 2世代になっていることを確認

本記事のまとめ

systemdによるOS起動プロセスの確認と、起動トラブルの診断に使うコマンドをまとめます。
やりたいこと コマンド
今回の起動ログを確認する journalctl -b
前回の起動ログを確認する journalctl -b -1
エラーのみ表示する journalctl -b -p err
特定サービスの起動ログを確認する journalctl -b -u サービス名
失敗したサービスを一覧表示する systemctl list-units --state=failed
全サービスの状態を確認する systemctl list-units --type=service
自動起動設定の一覧を表示する systemctl list-unit-files --type=service
特定サービスの詳細状態を確認する systemctl status サービス名
起動時間を分析する systemd-analyze blame
デフォルトのターゲットを確認する systemctl get-default
起動トラブルに遭遇したときは、まずsystemctl list-units --state=failedで失敗サービスを特定し、
journalctl -b -u サービス名で詳細ログを確認するという流れが基本です。

systemdの仕組みを理解することで、トラブル時の原因特定と復旧が大幅にスムーズになります。
関連記事として、systemctlとchkconfigでサービスを管理する方法も合わせてご覧ください。

３．古いカーネルの削除を実行します。
「package-cleanup --oldkernels」を実行することで、古いカーネルを削除できます。

$ su -
パスワード:
# package-cleanup --oldkernels
読み込んだプラグイン:fastestmirror, langpacks
--> トランザクションの確認を実行しています。
---> パッケージ kernel.x86_64 0:3.10.0-957.1.3.el7 を 削除
---> パッケージ kernel.x86_64 0:3.10.0-957.21.3.el7 を 削除
---> パッケージ kernel.x86_64 0:3.10.0-957.27.2.el7 を 削除

～中略～

トランザクションの要約
===================================
削除  6 パッケージ

インストール容量: 301 M
上記の処理を行います。よろしいでしょうか？ [y/N]y
↑「y」を入力します。
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  削除中  : kernel-devel.x86_64                                1/6
  削除中  : kernel.x86_64                                      2/6
  削除中  : kernel.x86_64                                      3/6
  削除中  : kernel-devel.x86_64                                4/6
  削除中  : kernel-devel.x86_64                                5/6
  削除中  : kernel.x86_64                                      6/6

～中略～

完了しました!

古いカーネルを削除せず残す場合

--oldkernelsを指定することで、古いkernel/kernel-develを削除しますが、
「package-cleanup --oldkernels --count=3」と指定することで、
現世代を含む3世代のカーネルを残ることができます。
指定しない場合は、現世代を含む2世代のカーネルを残します。

古いカーネルの削除が実行出来ない場合

package-cleanupコマンドが使用できない場合は、
別途インスールが必要です。
下記コマンドを実行して、package-cleanupコマンドをインスールしてください。

# yum install -y yum-utils

古いカーネルを削除後の確認

１．サーバーを再起動します。

# shutdown -r now

２．/boot領域のサイズを確認します。
使用量が、47%→29%に減っている事が分かります。

$ df -h /boot
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/sda1        497M  140M  358M   29% /boot

３．インストールされているカーネルの確認をします。

$ rpm -q kernel
kernel-3.10.0-1062.4.3.el7.x86_64
kernel-3.10.0-1062.9.1.el7.x86_64

保持するカーネル世代の上限を指定する

カーネルは更新するたびに歴管理され、どんどん増えていきますが、
/etc/yum.confファイルにinstallonly_limitパラメーターを設定することで
保持する歴の上限を指定する事ができます。
デフォルトでは5になっていますが、ここを変更することで
保持する歴の上限を指定できます。

# vi /etc/yum.conf
installonly_limit=5

起動トラブル、一人で悩んでいませんか？

journalctlとsystemctlの使い方を覚えるだけで、起動失敗の原因特定が格段に速くなります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。