LPIC Level1 復習ラジオ 21：systemd総復習

目次

1. initとsystemd
2. ユニットの基本
3. systemctlによる状態確認
4. サービスの起動・停止・再読み込み
5. 自動起動の有効化と無効化
6. target
7. serviceユニット
8. ユニットファイルと設定変更
9. journalctl
10. 実践的な障害確認手順
11. 30秒チェック
12. 要約

initとsystemd

Linuxでは、カーネルの起動後にユーザー空間を初期化する最初のプロセスが動作します。systemdを採用する環境では、systemdが通常PID 1として起動し、システムとサービスを管理します。

ps -p 1 -o pid=,comm=,args=
readlink -f /sbin/init

/sbin/initは、systemdへのシンボリックリンクになっている場合があります。

SysV initとの違い

従来は/etc/init.d/以下のスクリプトやランレベルを中心に管理しました。systemdでは、サービス、ソケット、マウント、タイマー、デバイスなどをユニットとして管理します。

systemctl status ssh.service
systemctl --user status example.service

引数なしのsystemctlは通常、システムマネージャーを操作します。--userを付けると、利用者ごとのユーザーマネージャーを操作します。

ユニットの基本

ユニットは、systemdが管理する対象です。ユニット名は、名前と種類を表すサフィックスで構成されます。

sshd.service
multi-user.target
home.mount
backup.timer
example.socket

systemctl status ssh
systemctl status ssh.service

多くの操作では、種類を省略すると.serviceとして補完されます。ただし、targetなどを操作するときは完全なユニット名を書くと明確です。

依存関係と順序

systemctl list-dependencies ssh.service
systemctl list-dependencies --reverse ssh.service

Wants=やRequires=は、ユニットを一緒に起動する要求関係です。After=やBefore=は起動順序を表します。「必要とすること」と「後に起動すること」は別です。

statusの主な項目

loadedやenabledは、現在動作しているという意味ではありません。設定状態と実行状態を分けて考えます。

systemctlによる状態確認

詳細な状態

systemctl status ssh.service
systemctl status ssh.service --no-pager -l

statusは、ロード状態、稼働状態、PID、直近ログなどをまとめて表示します。詳細なログはjournalctlで確認します。

判定用コマンド

systemctl is-active ssh.service
systemctl is-enabled ssh.service
systemctl is-failed ssh.service

これらは終了ステータスも返すため、シェルスクリプトの条件判定にも使えます。

if systemctl is-active --quiet ssh.service; then
    echo "ssh is active"
fi

一覧表示

systemctl list-units
systemctl list-units --type=service
systemctl list-units --type=service --state=running
systemctl list-units --failed

systemctl list-unit-files
systemctl list-unit-files --type=service
systemctl list-unit-files --state=enabled

list-unitsは主に、現在メモリへロードされているユニットを表示します。list-unit-filesは、ディスク上のユニットファイルと有効化状態を表示します。

プロパティ表示

systemctl show ssh.service
systemctl show ssh.service \
  -p ActiveState \
  -p SubState \
  -p MainPID \
  -p FragmentPath \
  -p UnitFileState

showは、機械処理にも向いた形式で内部プロパティを表示します。

サービスの起動・停止・再読み込み

sudo systemctl start ssh.service
sudo systemctl stop ssh.service
sudo systemctl restart ssh.service

startは現在起動し、stopは現在停止します。restartは停止してから再度起動するため、短時間のサービス停止が発生する可能性があります。

サービス自身の設定を再読み込み

sudo systemctl reload nginx.service
sudo systemctl reload-or-restart nginx.service
sudo systemctl try-restart nginx.service

• reload：サービスのプロセスを終了させず、サービス自身へ設定再読み込みを要求する
• reload-or-restart：reload可能ならreloadし、不可能ならrestart
• try-restart：現在動作中の場合だけrestart

reloadとdaemon-reload

sudo nginx -t
sudo systemctl reload nginx.service

sudo systemctl edit nginx.service
sudo systemctl daemon-reload
sudo systemctl restart nginx.service

アプリケーションの設定ファイルを変更したのか、.serviceユニットを変更したのかで、必要な操作が異なります。

失敗状態の解除

sudo systemctl reset-failed ssh.service
sudo systemctl reset-failed

reset-failedは、失敗状態や起動回数制限に関する記録をリセットします。失敗原因を修正するコマンドではありません。

自動起動の有効化と無効化

sudo systemctl enable ssh.service
sudo systemctl disable ssh.service

enableは、ユニットの[Install]セクションに基づいてシンボリックリンクを作成し、起動時などに要求されるよう設定します。通常、その場ではサービスを起動しません。

disableは自動起動用のリンクを削除します。現在動作中のサービスを停止する操作ではありません。

sudo systemctl enable --now ssh.service
sudo systemctl disable --now ssh.service

--nowを付けると、有効化と起動、または無効化と停止を同時に行います。

代表的な有効化状態

mask

sudo systemctl mask example.service
sudo systemctl unmask example.service

disableは自動起動を外すだけで、手動のstartは可能です。maskは通常、ユニットを/dev/nullへリンクし、手動起動や依存関係からの起動も拒否します。

target

targetユニットは、複数のユニットをまとめる同期点や、システムの起動目標として使われます。SysV initのランレベルに似た役割を持つものがありますが、完全に同じ仕組みではありません。

デフォルトtarget

systemctl get-default
sudo systemctl set-default multi-user.target
sudo systemctl set-default graphical.target
readlink -f /etc/systemd/system/default.target

default.targetは通常、multi-user.targetまたはgraphical.targetへのリンクです。

現在の状態を切り替える

sudo systemctl isolate multi-user.target
sudo systemctl isolate rescue.target

isolateは、指定targetに不要なユニットを停止する場合があります。GUI、ネットワークサービス、遠隔接続が停止する可能性があるため注意します。

activeなtarget

systemctl list-units --type=target
systemctl list-units --type=target --state=active

ネットワーク関係

• network.target：ネットワーク管理機能の起動に関係する同期点
• network-online.target：ネットワークが利用可能になることを必要とする処理の同期点

network.targetがactiveでも、IPアドレス取得や外部通信が完了しているとは限りません。必要に応じてwait-onlineサービスとの関係も確認します。

systemctl isolate runlevel3.target
systemctl isolate runlevel5.target

互換用のrunlevel3.targetやrunlevel5.targetは、それぞれ代表的にmulti-user.targetやgraphical.targetへの別名です。

serviceユニット

.serviceユニットは、systemdが制御・監視するプロセスを記述します。

[Unit]
Description=Example Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/example
Restart=on-failure

[Install]
WantedBy=multi-user.target

主な項目

主なType

activeでも正常とは限らない

systemctl is-active nginx.service
ss -lntp
curl -I http://127.0.0.1/
journalctl -u nginx.service

active (running)は、systemdがサービスを稼働中として管理している状態です。アプリケーションが正しく応答することや、外部依存先へ接続できることまで保証しません。

Type=oneshotは、正常終了後にinactive (dead)になることがあります。RemainAfterExit=yesなら、プロセス終了後もactiveとして扱われます。

ユニットファイルと設定変更

パッケージ提供ユニットを直接編集すると、更新時に上書きされる可能性があります。管理者独自の変更にはdrop-inを使うのが基本です。

読み込まれる内容を確認

systemctl cat ssh.service
systemctl show ssh.service \
  -p FragmentPath \
  -p DropInPaths

drop-inを作成

sudo systemctl edit ssh.service

通常、次のような場所へ上書き設定を作ります。

/etc/systemd/system/ssh.service.d/override.conf

[Service]
Restart=on-failure
RestartSec=5s

sudo systemctl daemon-reload
sudo systemctl restart ssh.service

既存値を置き換える例

[Service]
ExecStart=
ExecStart=/usr/local/bin/example --new-option

ExecStart=などは、空の代入で既存値をリセットしてから新しい値を指定する場合があります。項目ごとに上書き規則が異なるため、対象のmanページを確認します。

構文確認と復元

systemd-analyze verify /etc/systemd/system/example.service
sudo systemctl revert ssh.service

verifyは、構文や一部の参照関係を検証します。実行ファイル、権限、外部接続まで正常とは限りません。

revertは、管理者側の上書きを削除し、提供元の設定へ戻すために利用できます。削除対象を確認してから実行します。

daemon-reloadはsystemd自体を再起動する操作ではありません。ユニット設定と依存関係を再読み込みします。

journalctl

systemd-journaldは、カーネル、サービス、標準出力・標準エラー、syslog経由などからログを収集し、構造化されたjournalとして保存します。journalctlは、そのjournalを表示・検索します。

基本表示

journalctl
journalctl -n 50
journalctl --no-pager

特定サービス

journalctl -u ssh.service
journalctl -u nginx.service -n 100
journalctl -u nginx.service -f

-uはユニット指定、-fは新しいログの継続表示です。

起動単位

journalctl -b
journalctl -b -1
journalctl --list-boots

• -b：現在の起動
• -b -1：一つ前の起動
• --list-boots：保存されている起動履歴

カーネルログ

journalctl -k
journalctl -k -b
journalctl -k -p warning

時刻指定

journalctl --since "2026-07-11 09:00:00"
journalctl --since "1 hour ago"
journalctl --since today --until now
journalctl -u ssh.service --since "10 minutes ago"

優先度

journalctl -p err
journalctl -p warning..alert
journalctl -b -p err

emerg, alert, crit, err, warning, notice, info, debug

-p errは、err以上の高い優先度を表示します。

フィールド検索

journalctl _PID=1234
journalctl _UID=1000
journalctl _COMM=sshd
journalctl _SYSTEMD_UNIT=ssh.service

出力形式

journalctl -u ssh.service -o short-iso
journalctl -u ssh.service -o verbose
journalctl -u ssh.service -o json-pretty

使用量と保持

journalctl --disk-usage
sudo journalctl --vacuum-time=14d
sudo journalctl --vacuum-size=500M

障害調査に必要なログまで削除しないよう注意します。

永続保存

再起動後もjournalが保持されるかは、journald.confのStorage=設定や/var/log/journal/の有無などに依存します。

ls -ld /var/log/journal /run/log/journal 2>/dev/null
systemctl cat systemd-journald.service

/run/log/journalは揮発性領域、/var/log/journalは永続保存に使われます。実際の動作は設定とディストリビューション方針を確認します。

実践的な障害確認手順

1. ユニット名を確認する

systemctl list-unit-files --type=service | grep -i ssh
systemctl list-units --type=service --all | grep -i ssh

ディストリビューションによって、SSHサービス名がssh.serviceまたはsshd.serviceなど異なる場合があります。

2. 状態を分けて確認する

systemctl status ssh.service --no-pager -l
systemctl is-active ssh.service
systemctl is-enabled ssh.service
systemctl is-failed ssh.service

3. ログを確認する

journalctl -u ssh.service -b -n 100 --no-pager
journalctl -u ssh.service --since "15 minutes ago"
journalctl -p err -b

エラー行だけでなく、直前の設定読み込み、依存先、ポート競合、権限不足なども確認します。

4. ユニット定義を確認する

systemctl cat ssh.service
systemctl show ssh.service \
  -p FragmentPath \
  -p DropInPaths \
  -p ExecStart \
  -p User \
  -p Group

5. アプリケーション自身の設定を検証する

sudo sshd -t
sudo nginx -t
sudo apachectl configtest

systemdのユニットが正しくても、アプリケーション設定が不正なら起動できません。

6. 実行ファイル、権限、ポート

systemctl show ssh.service -p ExecStart
ls -l /usr/sbin/sshd
namei -l /usr/sbin/sshd
ss -lntp
ps -ef | grep '[s]shd'

7. 依存関係と失敗ユニット

systemctl list-dependencies ssh.service
systemctl list-dependencies --reverse ssh.service
systemctl --failed

8. ユニット変更後

sudo systemd-analyze verify \
  /etc/systemd/system/example.service

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl status example.service --no-pager -l
journalctl -u example.service -b -n 100 --no-pager

9. 短時間に起動失敗を繰り返す場合

systemctl show example.service \
  -p Restart \
  -p RestartUSec \
  -p StartLimitBurst \
  -p StartLimitIntervalUSec

sudo systemctl reset-failed example.service
sudo systemctl start example.service

先に失敗原因を修正します。reset-failedだけを繰り返しても、原因が残っていれば再び失敗します。

10. activeでも接続できない場合

systemctl is-active example.service
systemctl show example.service -p MainPID -p SubState
ss -lntp
curl -v http://127.0.0.1:8080/
journalctl -u example.service -b

systemd上の稼働、プロセス、待受、アプリケーション応答、ファイアウォール、外部依存を別々に確認します。

よくある症状

30秒チェック

1. systemdがinitシステムとして起動するとき、通常のPIDはいくつでしょうか。
2. systemctl startとsystemctl enableは何が違うでしょうか。
3. reloadとdaemon-reloadは、それぞれ何を読み直すでしょうか。
4. 現在のデフォルトtargetを表示するコマンドは何でしょうか。
5. multi-user.targetは、従来のどのランレベルに近いでしょうか。
6. staticなユニットは、どのように起動されることが多いでしょうか。
7. 現在の起動における特定サービスのログを表示するコマンドは何でしょうか。
8. systemctl statusがactiveでも、サービスが利用可能とは限らないのはなぜでしょうか。

要約

• systemdは通常PID 1として起動し、Linuxのシステムとサービスを管理します。
• サービス、target、socket、mount、timerなどをユニットとして扱います。
• statusは詳細確認、is-active、is-enabled、is-failedは状態判定に使います。
• list-unitsは主にロード済みユニット、list-unit-filesはディスク上のユニットファイルを表示します。
• startは現在起動し、stopは現在停止します。
• enableは自動起動設定、disableはその設定解除です。
• enable --nowは有効化と起動を同時に行います。
• maskは、手動や依存関係からの起動も拒否する強い無効化です。
• reloadはサービス自身の設定、daemon-reloadはユニット設定を再読み込みします。
• targetは複数ユニットをまとめる同期点や起動目標です。
• multi-user.targetは非グラフィカルな複数利用者環境、graphical.targetはGUIを含む環境です。
• isolateは不要なユニットを停止し、接続断を起こす可能性があります。
• serviceユニットは主に[Unit]、[Service]、[Install]で構成されます。
• After=は順序関係、Wants=やRequires=は要求関係です。
• 管理者独自の変更にはsystemctl editでdrop-inを作ります。
• journalctl -uはユニット、-bは起動、-kはカーネル、-fは継続表示です。
• --since、--until、-pで時刻や優先度を絞り込めます。
• statusのログは一部なので、障害調査ではjournalctlで前後を確認します。
• activeはsystemd上の稼働状態であり、アプリケーションの正常応答までは保証しません。
• 障害時は、ユニット名、状態、journal、ユニット定義、アプリ設定、権限、ポート、依存関係の順に確認します。

参考資料

• systemd 公式サイト
• systemd — System and Service Manager
• systemctl
• systemd.unit
• systemd.service
• systemd.target
• systemd.special
• bootup
• journalctl
• systemd-journald.service
• journald.conf
• systemd-analyze
• systemctl(1) — Linux manual page
• systemd.unit(5) — Linux manual page
• systemd.service(5) — Linux manual page
• systemd.special(7) — Linux manual page
• bootup(7) — Linux manual page
• journalctl(1) — Linux manual page
• systemd-journald.service(8) — Linux manual page