本ページの読み方
「動かす／止める」という基本操作だけでなく、「なぜ自動起動しないのか」「なぜ設定変更が反映されないのか」といった、実際の運用でつまずきやすい場面を中心に構成しています。サービス名は例として<service>と表記しているので、実際のサービス名（httpd／sshd／firewalld等）に置き換えて使ってください。
目次
1. 基本操作（状態確認・起動・停止・再起動）
サービス（デーモン）1つに対して行う、最も基本的な操作です。
| 操作 | コマンド例 | どんな時に使うか |
|---|---|---|
| 状態確認 | systemctl status <service> | 動いているか、直近のログにエラーがないかをまとめて確認したい時 |
| 開始 | sudo systemctl start <service> | 停止中のサービスを今すぐ動かしたい時 |
| 停止 | sudo systemctl stop <service> | サービスを今すぐ止めたい時 |
| 再起動 | sudo systemctl restart <service> | 設定ファイルを変更した後、プロセスごと再起動して反映させたい時 |
| 再読み込み | sudo systemctl reload <service> | プロセスを止めずに設定だけ再読込したい時（対応しているサービスのみ。例：httpd、nginx） |
| 稼働状態のみ判定 | systemctl is-active <service> | スクリプト等で稼働状態だけを簡潔に判定したい時（active/inactive/failedを返す） |
| 失敗状態か判定 | systemctl is-failed <service> | そのサービスが失敗（failed）状態かどうかだけを確認したい時 |
2. 自動起動の制御（enable / disable / mask）
「今動いているか」と「次回OS起動時にも自動で動くか」は別の設定です。ここを混同すると、再起動後にサービスが上がってこない・逆に止めたはずのサービスが起動してしまう、といったトラブルにつながります。
| 操作 | コマンド例 | どんな時に使うか |
|---|---|---|
| 自動起動ON | sudo systemctl enable <service> | 次回OS起動時からも自動で動かしたい時（今すぐは起動しない、次回起動時から有効） |
| 自動起動ON＋即時起動 | sudo systemctl enable --now <service> | 自動起動の設定と、今すぐの起動を1コマンドで済ませたい時（enableとstartを同時実行） |
| 自動起動OFF | sudo systemctl disable <service> | 次回OS起動時からは自動で動かしたくない時 |
| 完全に起動を封じる | sudo systemctl mask <service> | 自動起動だけでなく、手動startや他サービスの依存関係経由での起動も含めて、完全に起動できなくしたい時 |
| mask解除 | sudo systemctl unmask <service> | mask状態を解除して、再び起動可能な状態に戻したい時 |
| 自動起動設定の確認 | systemctl is-enabled <service> | 現在の自動起動設定（enabled/disabled/masked/static等）を確認したい時 |
disableとmaskの違い（よくある罠）
disableは「次回OS起動時の自動起動」を止めるだけで、手動でのstartや、他のユニットが依存関係として起動する経路は防げません。完全に起動を禁止したい場合はmaskを使う必要があります（内部的には/etc/systemd/system/<service>を/dev/nullへのシンボリックリンクに置き換えることで、起動そのものを不可能にしています）。
また、サービスによっては「.service」の自動起動を無効化しても、対応する「.socket」ユニットが有効なままだと、実質的にサービスが起動できてしまうケースがあります。本サイトのUbuntu 26.04構築記録でも、ssh.serviceを無効化したにもかかわらずssh.socketが有効なままだったため、SSH接続自体は可能だったという実例を確認しています（初期設定：ユーザー・サービス管理）。止めたつもりのサービスに接続できてしまう場合は、関連する.socketユニットの状態も確認してください。
3. 設定変更を反映する（daemon-reload / edit）
ユニットファイル（.service等）自体を編集した場合、サービスの再起動だけでは変更が反映されません。systemd自体に設定の再読み込みを行わせる必要があります。
| 操作 | コマンド例 | どんな時に使うか |
|---|---|---|
| ユニット定義の再読込 | sudo systemctl daemon-reload | ユニットファイルを編集した後、変更内容をsystemdに認識させたい時。これを忘れると、restartしても変更前の設定のまま動き続ける |
| 安全な上書き設定を追加 | sudo systemctl edit <service> | ベンダー提供のユニットファイルを直接編集せず、差分だけを安全に追加したい時（/etc/systemd/system/<service>.d/override.confが自動生成される） |
| ユニット全体を編集 | sudo systemctl edit --full <service> | ドロップイン方式ではなく、ユニットファイル全体をコピーして丸ごと編集したい時 |
| 実際に効いている設定を確認 | systemctl cat <service> | ベンダー設定とオーバーライドがマージされた、実際にsystemdが読み込んでいる内容を確認したい時 |
編集後に忘れがちな手順
ユニットファイルを編集 → daemon-reload → restart、の順番がセットです。systemctl editを使った場合は保存時に自動でdaemon-reload相当の処理が行われますが、vi等で直接ファイルを編集した場合は手動でdaemon-reloadを実行する必要があります。
4. 全体を俯瞰・調査する（一覧・障害・タイマー）
個別のサービスではなく、サーバー全体でどんなサービスが動いているか・失敗していないかを棚卸しする際に使います。
| 操作 | コマンド例 | どんな時に使うか |
|---|---|---|
| 稼働中サービス一覧 | systemctl list-units --type=service | 現在ロードされている全サービスの状態を一覧確認したい時 |
| 自動起動設定の棚卸し | systemctl list-unit-files --state=enabled | 自動起動が有効になっているサービスだけを洗い出したい時。構成把握やセキュリティ監査（不要なサービスが自動起動していないか）に有効 |
| 失敗しているサービス一覧 | systemctl --failed | 起動に失敗しているサービスがないか、まとめて確認したい時 |
| 依存関係の確認 | systemctl list-dependencies <service> | そのサービスがどのユニットに依存しているか、起動順序を把握したい時 |
| タイマー一覧 | systemctl list-timers | cronの代替であるsystemdタイマーの、次回実行予定と前回実行結果を一覧確認したい時 |
5. ログを確認する（journalctl）
systemctl statusだけでは分からない詳細な経緯を追う場合は、journalctlでそのサービスのログを直接確認します。
| 操作 | コマンド例 | どんな時に使うか |
|---|---|---|
| 特定サービスのログ | journalctl -u <service> | 特定サービスのログだけに絞って確認したい時 |
| リアルタイム追跡 | journalctl -u <service> -f | 起動直後やトラブル発生中など、ログの流れをリアルタイムで追いたい時（tail -f相当） |
| 期間指定 | journalctl -u <service> --since "10 min ago" | 直近の一定時間分だけログを確認したい時 |
| 重要度で絞り込み | journalctl -u <service> -p err | 大量のログの中から、エラー以上の重要度のものだけに絞りたい時 |
| 直近起動分のみ | journalctl -b | 直近の起動（boot）以降のログをまとめて確認したい時 |
| ログ容量の確認 | journalctl --disk-usage | ジャーナルログがディスクをどれだけ消費しているか確認したい時 |
| 古いログの削除 | sudo journalctl --vacuum-time=7d | ログの肥大化でディスクを圧迫している時に、指定期間より古いログを削除したい時 |
6. ユニットファイルの置き場所と優先順位
同じサービスに対して複数の場所にユニットファイルが存在する場合、systemdは以下の優先順位でマージ・上書きします。
| ディレクトリ | 用途 | 優先度・特徴 |
|---|---|---|
/usr/lib/systemd/system/ | パッケージ（dnf/apt）が提供するデフォルトのユニット定義 | 最も低い。直接編集するとパッケージ更新時に上書きされて消える |
/etc/systemd/system/ | 管理者による恒久的な上書き設定・独自ユニット | 最も高い。systemctl editの生成先もここ |
/run/systemd/system/ | 実行時に動的生成される一時的なユニット | 再起動で消える。主にsystemd自身やツールが生成 |
恒久的な変更は/etc配下に
サービスの挙動を変更したい場合は、/usr/lib/systemd/system/配下のファイルを直接編集せず、systemctl editで/etc/systemd/system/配下にオーバーライドを作成してください。パッケージ更新のたびに設定が消える事故を防げます。