systemd入門 LinuC101 第3回

新卒インフラエンジニア向けLinuC 101 試験対策シリーズの第3回です。前回はブートプロセスの最終段階でPID 1として起動する systemd の存在を確認しました。今回はその systemd の中身—サービス管理・unitファイル・ターゲット・依存関係—を体系的に学びます。

systemd は現代のLinux運用の中核です。systemctl で日々サービスを操作し、トラブル時には journalctl で原因を追う—この流れを身につけられれば、新卒インフラエンジニアとして即戦力になります。

今ここマップ

LinuC 101 試験対策シリーズ（全12回）

  第1回 Linuxの起動・接続・停止
  第2回 ブートプロセスの仕組み
▶ 第3回 systemdマスター講座               ← いまここ
  第4回 プロセス管理とハードウェア基礎
  第5回 仮想マシンとコンテナの基礎
  第6回 パッケージ管理マスター
  第7回 ファイル操作の実践
  第8回 パーミッション・所有者・特殊権限
  第9回 コマンドライン・リダイレクト・パイプ
  第10回 テキスト処理（grep / sed / awk）
  第11回 vi/vim 入門
  第12回 ディスク・パーティション・ファイルシステム

この記事で身につくこと

1. systemdのunit / target / dependency という3つの概念を言葉で説明できる
2. systemctl status / start / stop / restart / enable / disable / reload を使い分けられる
3. unitファイルの構造（[Unit] / [Service] / [Install]）を読める
4. 簡単なカスタム unit ファイルを作成し、サービスとして起動できる
5. systemctl list-dependencies で依存関係を可視化できる

systemd の全体像

なぜ systemd に置き換わったのか

かつての Linux には SysV init という古典的な仕組みがありました。しかし時代とともに以下の限界が顕在化しました。

• 逐次起動による遅さ：シェルスクリプトが順番に走るため、起動時間が長い
• 依存関係の貧弱な表現：「Aの後にB」程度しか書けず、複雑な依存を組めない
• サービスの状態管理が弱い：起動失敗・再起動・ログ統合などが各スクリプト任せ

これらを根本から再設計したのが systemd です。並列起動、宣言的な依存記述、unitという統一抽象、journalによるログ統合—これらが systemd の主要設計思想です。RHEL 7 / CentOS 7 以降の主要ディストリビューションは軒並み systemd に移行し、AlmaLinux 9 も例外ではありません。

PID 1 として動作する

カーネル起動後に最初に立ち上がるユーザー空間プロセス、それが PID 1 です。systemd はこの PID 1 を担います。

実行コマンド（linuc-almaで実行）：

$ ps -p 1 -o pid,comm

実行結果：

    PID COMMAND
      1 systemd

PID 1 のコマンドは systemd です。実体パスを確認してください。

実行コマンド：

$ ls -la /sbin/init /usr/sbin/init

実行結果：

lrwxrwxrwx. 1 root root 22  3月 11  2025 /sbin/init -> ../lib/systemd/systemd
lrwxrwxrwx. 1 root root 22  3月 11  2025 /usr/sbin/init -> ../lib/systemd/systemd

歴代の /sbin/init は systemd 本体（/usr/lib/systemd/systemd）へのシンボリックリンクになっています。SysV init 時代のスクリプト互換性を保ちつつ、中身は systemd という設計です。

systemd のバージョン確認

実行コマンド：

$ systemctl --version | head -1

実行結果：

systemd 252 (252-51.el9.alma.1)

AlmaLinux 9.6 では systemd 252 を採用しています。バージョンによって使えるオプションが異なるので、トラブルシュート時はまずバージョン確認の習慣をつけてください。

unit という抽象

systemd の最大の特徴は、サービス・ソケット・タイマー・マウントなど多様な要素を 「unit」 という共通インターフェースで扱う点です。

unit種別	拡張子	用途
service	.service	デーモン・スクリプト等のサービス
target	.target	複数ユニットをまとめた到達点（旧ランレベル相当）
socket	.socket	ソケット（オンデマンド起動）
timer	.timer	cron代替の定期実行
mount	.mount	ファイルシステムマウント
path	.path	ファイル・ディレクトリ変更監視
device	.device	デバイス検出
slice	.slice	cgroupによるリソース制御

本記事は service と target の操作に集中しますが、socket や timer も同じ systemctl コマンドで操作できる—この一貫性が systemd の強みです。

第1章：systemctl の基本操作

1.1 サービス状態を確認する

「サーバーで動くべきサービスは動いているか」を確認するのが日常運用の出発点です。systemctl status がメインの確認コマンドです。

実行コマンド：

$ systemctl status sshd

実行結果：

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-05-09 19:04:16 JST; 2h 51min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 758 (sshd)
      Tasks: 1 (limit: 24743)
     Memory: 9.1M
        CPU: 492ms
     CGroup: /system.slice/sshd.service
             └─758 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

 5月 09 21:35:24 linuc-alma sshd[11707]: Accepted publickey for developer from 192.168.1.100 port 60967 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc

読み方のポイント：

• ● sshd.service — 緑の●はアクティブ。赤の×は失敗、白の○は停止中
• Loaded: ...; enabled; preset: enabled — unitファイルがロード済みかつ自動起動有効
• Active: active (running) since ...; 2h 51min ago — 動作中で、いつから動いているか
• Main PID: 758 (sshd) — メインプロセスのPID
• CGroup: — このサービスに属するプロセスツリー
• 末尾には journalctl -u sshd 由来のログ末尾10行

この出力1つで「サービスの稼働状況・自動起動設定・PID・直近のログ」が一望できる—これが systemd の体験設計です。

1.2 状態を1単語で取得する

スクリプトで条件分岐したいときは、is-active や is-enabled が便利です。出力は1単語で、終了ステータスでも判定できます。

実行コマンド：

$ systemctl is-active sshd
$ systemctl is-enabled sshd

実行結果：

active
enabled

覚えておきたい状態の対応：

コマンド	主な戻り値
systemctl is-active	active / inactive / failed / activating
systemctl is-enabled	enabled / disabled / static / masked / alias

1.3 サービスを操作する

サービスの起動・停止・再起動は systemctl <サブコマンド> <unit> 形式です。

サブコマンド	動作	使う場面
start	サービス起動（一時的）	停止中サービスを動かす
stop	サービス停止	メンテ前に止める
restart	停止→起動	設定変更を反映する確実な方法
reload	停止せず設定再読込	無停止で設定変更したい
enable	自動起動を有効化	再起動後も動かしたい
disable	自動起動を無効化	不要なサービスを永続停止
--now	enable/disableに付与で即時start/stop	2手間を1コマンドで

例（コマンド形のみ。実機操作は本記事ではしない）：

$ sudo systemctl start sshd
$ sudo systemctl restart sshd
$ sudo systemctl reload sshd
$ sudo systemctl stop sshd
$ sudo systemctl enable sshd
$ sudo systemctl enable --now sshd     # 即起動＋永続化
$ sudo systemctl disable --now sshd    # 即停止＋永続無効化

reload と restart の違いは新人が混同しやすいポイントです。reload はプロセスを終了させずに設定を再読込するため、SSH等のセッションが切れません。restart は一度プロセスを終了させるため、SSHのアクティブ接続は影響を受けます（ただし sshd は restart しても接続中の既存セッションは続きます）。

1.4 unitの一覧を取る

「今動いているサービスは何か」を知るには list-units、「定義されているサービスは何か」を知るには list-unit-files です。

実行コマンド：

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

実行結果（抜粋）：

  UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
  auditd.service           loaded active running Security Auditing Service
  chronyd.service          loaded active running NTP client/server
  crond.service            loaded active running Command Scheduler
  dbus-broker.service      loaded active running D-Bus System Message Bus
  firewalld.service        loaded active running firewalld - dynamic firewall daemon
  NetworkManager.service   loaded active running Network Manager
  rsyslog.service          loaded active running System Logging Service
  sshd.service             loaded active running OpenSSH server daemon
  systemd-journald.service loaded active running Journal Service

実行コマンド：

$ systemctl list-unit-files --type=service | head -10

実行結果：

UNIT FILE                                  STATE           PRESET
auditd.service                             enabled         enabled
autovt@.service                            alias           -
blk-availability.service                   disabled        disabled
chrony-wait.service                        disabled        disabled
chronyd-restricted.service                 disabled        disabled
chronyd.service                            enabled         enabled
console-getty.service                      disabled        disabled
container-getty@.service                   static          -
cpupower.service                           disabled        disabled

STATE が static のものは、単独では enable できないユニット（多くは依存先として呼ばれるテンプレート）です。alias は別名定義です。

第2章：unit ファイルを読み解く

2.1 unit ファイルの置き場所

unit ファイルには優先順位のあるディレクトリ階層があります。

パス	役割	編集
/etc/systemd/system/	管理者カスタム（最優先）	✅ ここに自作unitを置く
/run/systemd/system/	ランタイム生成（次優先）	❌ 通常触らない
/usr/lib/systemd/system/	パッケージ提供（最低優先）	❌ 直接編集禁止（dnf updateで上書き） |

同名のunitが両方にあれば /etc/systemd/system/ 側が勝ちます。これにより、パッケージのデフォルトを残したまま、管理者がカスタマイズできます。

2.2 sshd.service を読み解く

systemctl cat はunitファイルを安全に表示します（パスを覚えていなくてもOK）。

実行コマンド：

$ 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
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

3つのセクションで構成されています。

2.3 [Unit] [Service] [Install] セクションの主要キー

セクション	主要キー	意味
[Unit]	Description	人間向けの説明
[Unit]	Documentation	関連man/URLへの参照
[Unit]	After=	「これより後に起動」（順序）
[Unit]	Before=	「これより前に起動」（順序）
[Unit]	Requires=	強い依存（先方が失敗すると自分も失敗）
[Unit]	Wants=	弱い依存（先方の有無を問わず起動継続）
[Service]	Type=	simple / forking / oneshot / notify / dbus 等
[Service]	ExecStart=	起動時のコマンド
[Service]	ExecReload=	reload時のコマンド
[Service]	Restart=	異常終了時の挙動（on-failure / always 等）
[Install]	WantedBy=	enable時にどのターゲットの依存となるか
[Install]	RequiredBy=	WantedByの強い版

sshd の例で読み解くと：

• 「ネットワークと sshd-keygen が起動した後に動く」（After）
• 「sshd-keygen も同時に起動してほしい」（Wants — 弱依存）
• 「Type=notify」— sshd は systemd に「準備完了」を通知するタイプ
• 「ExecStart=/usr/sbin/sshd -D」— -D オプションで非デタッチ起動
• 「Restart=on-failure」— sshd が異常終了したら自動再起動
• 「WantedBy=multi-user.target」— enableすると multi-user.target の依存に組み込まれる

第3章：自作スクリプトを systemd 化する

systemd の威力を実機で確かめるには、自分で書いたスクリプトをサービス化するのが一番です。logger でログを書くだけの hello-linuc.service を例に作ってみます。

3.1 unit ファイルを作成

実行コマンド：

$ sudo tee /etc/systemd/system/hello-linuc.service > /dev/null <<EOF
[Unit]
Description=Hello LinuC oneshot service
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t hello-linuc "Hello from LinuC training"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

キーポイント：

• Type=oneshot：1回実行して終了する処理用（バックグラウンド常駐ではない）
• RemainAfterExit=yes：実行終了後も active (exited) の状態を保つ。「実行済み」を表現するのに便利
• WantedBy=multi-user.target：enable時に通常の multi-user モードでの起動対象になる

3.2 systemd に再読込させる

新しいunitファイルを置いた直後、systemdはまだそれを認識していません。daemon-reload で再読込が必要です。

実行コマンド：

$ sudo systemctl daemon-reload

戻り値は空（成功時）。エラーがあれば即座に表示されます。

3.3 起動と永続化

enable --now で起動と永続化を1コマンドで実行します。

実行コマンド：

$ sudo systemctl enable --now hello-linuc.service

実行結果：

Created symlink /etc/systemd/system/multi-user.target.wants/hello-linuc.service → /etc/systemd/system/hello-linuc.service.

「シンボリックリンクが作られた」というメッセージに注目してください。これが「自動起動の正体」です。multi-user.target.wants/ ディレクトリ内のリンクが、target起動時に対象も併せて起動する仕組みなのです。

3.4 動作確認

実行コマンド：

$ systemctl status hello-linuc.service

実行結果：

● hello-linuc.service - Hello LinuC oneshot service
     Loaded: loaded (/etc/systemd/system/hello-linuc.service; enabled; preset: disabled)
     Active: active (exited) since Sat 2026-05-09 21:55:53 JST; 7ms ago
    Process: 12307 ExecStart=/usr/bin/logger -t hello-linuc Hello from LinuC training (code=exited, status=0/SUCCESS)
   Main PID: 12307 (code=exited, status=0/SUCCESS)
        CPU: 3ms

 5月 09 21:55:53 linuc-alma systemd[1]: Starting Hello LinuC oneshot service...
 5月 09 21:55:53 linuc-alma hello-linuc[12307]: Hello from LinuC training
 5月 09 21:55:53 linuc-alma systemd[1]: Finished Hello LinuC oneshot service.

Active: active (exited) が RemainAfterExit=yes の効果。プロセスは終了したが、systemd上は「実行済み」として残っています。logger がjournalに「Hello from LinuC training」を書き込んだことも確認できます。

3.5 演習後のクリーンアップ

演習で作ったunitは、後片付けまで含めて1サイクルです。

実行コマンド：

$ sudo systemctl disable --now hello-linuc.service
$ sudo rm /etc/systemd/system/hello-linuc.service
$ sudo systemctl daemon-reload

実行結果（disableのみ表示）：

Removed "/etc/systemd/system/multi-user.target.wants/hello-linuc.service".

シンボリックリンクが削除され、unitファイル本体も消し、最後に daemon-reload で systemd の認識を更新します。これでサービスは完全に消えました。

第4章：ターゲットと依存関係

4.1 主要なターゲット

ターゲットは「複数のunitをまとめた到達点」です。前回（第1回）のshutdownでも触れましたが、改めて整理します。

ターゲット	意味	旧ランレベル
poweroff.target	電源オフ	0
rescue.target	シングルユーザー（最小）	1, S
multi-user.target	サーバー運用（CUI）	3
graphical.target	GUIデスクトップ	5
reboot.target	再起動	6
emergency.target	緊急（最低限のシステム）	—

4.2 既定ターゲットの確認・変更

実行コマンド：

$ systemctl get-default

実行結果：

multi-user.target

変更するなら set-default：

$ sudo systemctl set-default multi-user.target

4.3 依存関係を可視化する

list-dependencies はunit同士の依存関係をツリー表示します。

実行コマンド：

$ systemctl list-dependencies multi-user.target | head -20

実行結果（抜粋）：

multi-user.target
● ├─auditd.service
● ├─chronyd.service
● ├─crond.service
● ├─firewalld.service
● ├─irqbalance.service
○ ├─kdump.service
○ ├─mdmonitor.service
● ├─NetworkManager.service
● ├─rsyslog.service
● ├─sshd.service
○ ├─sssd.service
● ├─systemd-ask-password-wall.path
● ├─systemd-logind.service
○ ├─systemd-update-utmp-runlevel.service
● ├─systemd-user-sessions.service
● ├─basic.target
● │ ├─-.mount

記号の意味：

• ●（緑） — 現在 active
• ○（白） — 現在 inactive

逆方向（「sshd を要求しているのは誰か」）も見られます。

実行コマンド：

$ systemctl list-dependencies --reverse sshd.service

実行結果：

sshd.service
● └─multi-user.target
○   └─graphical.target

「sshd は multi-user.target に必要とされ、その multi-user は graphical.target にも組み込まれている」と読めます。

第5章：journal で systemd を見る

systemd 系のログは journalctl に統合されています。第2回でブートログを見ましたが、unit 単位でのログ参照も強力です。

実行コマンド：

$ journalctl -u sshd -n 5 --no-pager

実行結果：

 5月 09 21:55:26 linuc-alma sshd[12162]: Accepted publickey for developer from 192.168.1.100 port 56496 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
 5月 09 21:55:26 linuc-alma sshd[12162]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)
 5月 09 21:55:26 linuc-alma sshd[12162]: pam_unix(sshd:session): session closed for user developer
 5月 09 21:55:37 linuc-alma sshd[12198]: Accepted publickey for developer from 192.168.1.100 port 59830 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
 5月 09 21:55:37 linuc-alma sshd[12198]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

主要オプション：

• -u <unit> — unit 別フィルタ
• -n N — 末尾N行
• -f — tail -f 相当（リアルタイム追跡）
• --since "1 hour ago" — 期間指定
• -p err — 優先度フィルタ（err以上）
• --no-pager — pagerを使わずstdoutに直接出す

サービスが起動失敗したときの基本動線は systemctl status <unit> で概要 → journalctl -u <unit> -n 50 で詳細 です。この2コマンドだけで多くのトラブルが原因特定できます。

現場での使いどころ

• サービス障害の初動：監視からアラート → systemctl status <unit> → journalctl -u <unit> -n 50 の3ステップで多くのケースを切り分け
• 独自バッチのサービス化：cron + シェルでなく、Type=oneshot の service + timer に置き換えると、ログ統合・依存記述・並列制御の恩恵が得られる
• サービス公開時のチェックリスト：start の後に必ず enable、is-enabled で確認、再起動テスト—の3点セット
• 運用変更前の依存確認：「このサービスを停止すると何が困るか」を list-dependencies --reverse で先に確認
• パッケージのデフォルト設定を上書き：drop-in 設定（/etc/systemd/system/<unit>.d/override.conf）でカスタマイズ。systemctl edit <unit> が便利

やってみよう

検証環境（linuc-alma）で以下を順番に実行してください。演習3はファイル作成と削除を含むため、必ず最後のクリーンアップまで実施してください。

理解度チェック

○か×で答えてください。回答と解説は次回冒頭で振り返ります。

1. systemctl start <unit> を実行すると、再起動後もサービスが自動起動するようになる。
2. 管理者カスタムのunitファイルは /etc/systemd/system/ に配置するのが推奨される。
3. systemctl enable は multi-user.target.wants/ 等にシンボリックリンクを作成する。
4. unitファイルを変更したら、systemctl daemon-reload を実行しないとsystemdは新しい定義を認識しない。
5. systemctl list-dependencies --reverse <unit> は、その unit を要求している側のツリーを表示する。

次回予告

第4回は「プロセス管理とハードウェア基礎（ps, top, lsblk, lspci, lsusb）」です。systemd の下で動く個々のプロセスを観察する手段、そしてLinuxが認識しているハードウェアの構成を確認する手段を学びます。「重い」「リソース不足」と言われたときの初動が身につく回です。

LinuC 101 試験対策シリーズ 全12回

• 第1回 Linuxの起動・接続・停止：systemctl・login・shutdownの基本
• 第2回 ブートプロセスの仕組み：BIOS/UEFI → GRUB → systemd の流れ
• 第3回 systemdマスター講座：サービス管理・unitファイル・ターゲット（本記事）
• 第4回 プロセス管理とハードウェア基礎（ps, top, lsblk, lspci, lsusb）
• 第5回 仮想マシンとコンテナの基礎：KVM・Docker・Podman 入門
• 第6回 パッケージ管理マスター：dnf / apt / rpm / dpkg の実践
• 第7回 ファイル操作の実践：cp, mv, find, リンク, FHS
• 第8回 パーミッション・所有者・特殊権限（SUID/SGID/Sticky）
• 第9回 コマンドライン・リダイレクト・パイプの基礎
• 第10回 テキスト処理の三種の神器：grep / sed / awk + 正規表現
• 第11回 vi/vim 入門：現場で使えるエディタ操作
• 第12回 ディスク・パーティション・ファイルシステム（fdisk, mkfs, mount, LVM）