1.2システム起動のカスタマイズ

「このサービスはなぜ起動しないのか」「設定を変えたつもりが反映されない」— こうした問い合わせに答えるには、systemd の設定がどこから読まれ、どこで上書きされるかという階層構造の理解が欠かせません。201 試験ではこの階層と systemctl の実務コマンドが重点的に問われます。

1.2.1systemdの設定ファイル階層

• /usr/lib/systemd/＝パッケージが提供するデフォルトのユニットファイル。パッケージ更新で上書きされるため直接編集しない。
• /etc/systemd/＝管理者がカスタマイズするための階層。デフォルトを上書きしたい場合はここに同名ファイルやドロップイン（.d/ ディレクトリ）を置く。
• /run/systemd/＝実行時（揮発性）の設定。再起動で消える一時的なユニット・状態が置かれる。
• 優先順位＝/etc/ が /usr/lib/ を上書きし、/run/ はさらにその場限りで優先される。systemd-delta＝この3階層でどのファイルがどこで上書きされているかを一覧できるコマンド。

1.2.2systemctlによるユニット操作と障害モード

• 確認系＝systemctl status <unit>（詳細状態）・systemctl list-units（現在ロード済みユニット一覧・--type=service などで絞り込み）。
• 起動制御＝start／stop（今すぐの起動・停止）・enable／disable（次回起動時からの自動起動の有効/無効・シンボリックリンクの作成/削除）。
• 禁止系＝mask（ユニットを完全に起動不可にする。/dev/null へのシンボリックリンクを作成し start すら失敗させる）・unmask（解除）。disable より強力で、依存関係からの巻き添え起動も防ぐ。
• rescue モード（rescue.target）＝最小限のサービス＋ルートログインで単一ユーザー保守。emergency モード（emergency.target）＝ルートファイルシステムを読み取り専用でマウントし、rescue すら起動できない最終手段。

設定変更の実務フローを追いましょう。ベンダー提供のユニット（例：/usr/lib/systemd/system/sshd.service）を直接編集するのは避け、代わりに /etc/systemd/system/sshd.service.d/override.conf のようなドロップインを /etc/ 側に手動作成します。こうすると /etc/ 階層が /usr/lib/ のデフォルトを上書きし、パッケージ更新でも設定が失われません。どのファイルがどこで上書きされているか怪しいときは systemd-delta を実行して三層の重なりを一覧します。変更後は systemctl stop sshd → systemctl start sshd の順で反映します。恒久的に自動起動させたくないサービスは systemctl disable <unit> で無効化しますが、他のユニットの依存関係で巻き添え起動する懸念があるなら systemctl mask <unit> まで踏み込みます。システムがブートループに陥った場合は、GRUB2 のカーネル行に systemd.unit=rescue.target を追記して最小構成での保守を試み、それでも起動しないほど深刻なら systemd.unit=emergency.target でルートFSを読み取り専用のままシェルに入り、設定ファイルの点検・修正を行います。

1.2.3この節のまとめ

• 設定階層＝/usr/lib(既定)＜/etc(管理者)＜/run(実行時)。差分は systemd-delta で確認
• start/stop＝今すぐ／enable/disable＝次回起動から／mask＝完全ロック。rescueよりemergencyがさらに最小限