Ubuntuでサービスが動かないとき何を見る？ ― systemctlとjournalctlをつなげて追う

この記事について
この記事はsystemd公式マニュアルを確認し、Ubuntuでサービス障害を切り分ける手順として整理しています。

検証ステータス：📘 公式仕様確認済み・対象Ubuntu実機未確認
読み取り中心の確認コマンドと、状態を変更するコマンドを明確に分けています。

Ubuntuでサービスが起動しないときは、systemctl statusだけで判断せず、Unit定義 → systemdが記録した状態 → service process → journalの順につなげて見ると原因を追いやすくなります。最初からrestartを繰り返すより、失敗時の情報を残したまま調べる方が安全です。

最初に実行する確認コマンド

サービス名を nginx とした例です。

systemctl status nginx --no-pager
systemctl is-active nginx
systemctl is-enabled nginx
journalctl -u nginx --no-pager -n 80

statusは全体像、is-activeは現在の状態、is-enabledは自動起動設定、journalctlは時系列の記録を見るために使います。

flowchart LR
    A[Unit definition] --> B[systemd manager]
    B --> C[service process]
    B --> D[active / failed / inactive]
    C --> E[stdout / stderr]
    E --> F[journal]
    D --> G[systemctl]
    F --> H[journalctl]

activeとenabledは別の話

enabledだから今動いている、とは限りません。

たとえば、手動で起動したserviceはactiveでもdisabledということがあります。

flowchart TB
    A[service] --> B{is-active}
    A --> C{is-enabled}
    B -->|active| D[現在動作中]
    B -->|failed| E[失敗状態]
    C -->|enabled| F[自動起動の設定あり]
    C -->|disabled| G[自動起動の設定なし]

statusのどこを見るか

systemctl status nginx --no-pager

見るポイントは次です。

• Loaded: どのUnitを読み込んだか

• Active: 現在の状態

• Main PID: 主プロセス

• Resultや終了理由に関係する表示

• 直近のjournal抜粋

statusの末尾だけでは不足する場合があるため、失敗時はjournalctlへ進みます。

journalを時系列で追う

直近80行:

journalctl -u nginx --no-pager -n 80

現在のbootに絞る:

journalctl -u nginx -b --no-pager

時間を区切る:

journalctl -u nginx --since "30 minutes ago" --no-pager

「errorという文字だけgrepする」より、失敗直前の数十行を読む方が、設定読込 → 起動 → 失敗という流れを把握しやすいことがあります。

systemdが実際に読んでいるUnitを見る

編集したつもりのファイルと、systemdが実際に使っている定義が一致しているかを確認します。

systemctl cat nginx

さらに、Unitの読み込み元などを機械的に見るならsystemctl showも使えます。

systemctl show nginx   -p FragmentPath   -p DropInPaths   -p ActiveState   -p SubState   -p Result   -p ExecMainStatus

これにより、「別のdrop-inが効いていた」「想定したUnit fileではなかった」といった切り分けがしやすくなります。

Unitを変更したときだけdaemon-reloadを考える

Unit fileやdrop-inを変更した後は、systemd managerへ定義を再読込させる必要があります。

sudo systemctl daemon-reload

daemon-reloadはservice processそのものを再起動するコマンドではありません。

flowchart LR
    A[Unit fileを変更] --> B[daemon-reload]
    B --> C[systemd managerが定義を再読込]
    C --> D{process再起動も必要?}
    D -->|Yes| E[restart等を検討]
    D -->|No| F[定義確認で終了]

「設定ファイルを書き換えたから、とりあえずdaemon-reloadとrestart」という固定手順にはせず、何を変更したかで判断します。

restartを最初にしない理由

再起動すれば一時的に直る障害もありますが、原因調査では情報を失う場合があります。

おすすめの順番です。

flowchart TB
    A[障害を検知] --> B[status]
    B --> C[journalctl]
    C --> D[systemctl cat / show]
    D --> E[アプリ固有のconfig test]
    E --> F{原因を特定}
    F -->|No| G[依存関係・port・権限等を追加確認]
    F -->|Yes| H[必要な変更]
    H --> I[必要ならreload/restart]
    I --> J[再度statusとjournalで確認]

Nginxなら nginx -t、PHP-FPMならバージョンや設定に応じたconfig testなど、「サービス固有の検証」をsystemd調査と組み合わせます。

systemdだけを見ても分からない場合

systemdはプロセスを管理しますが、アプリケーション固有の設定エラーまで意味を理解してくれるわけではありません。

たとえば次も別途確認対象になります。

• 設定ファイルの構文

• portの競合

• file permission

• EnvironmentFileの値

• 実行ユーザー

• dependency

• アプリ固有ログ

systemctlは「全部を解決するコマンド」ではなく、OSサービス管理の入口です。

まとめ

• status、is-active、is-enabledは役割が違う

• journalctlで失敗までの時系列を追う

• systemctl cat / showで実際のUnit定義を確認する

• Unit変更後のdaemon-reloadとprocess restartを分けて考える

• restartの前に、失敗時の情報を採取する

• systemd調査とアプリ固有のconfig testを組み合わせる

公式情報・一次情報

systemd — systemctl
https://www.freedesktop.org/software/systemd/man/latest/systemctl.html

systemd — journalctl
https://www.freedesktop.org/software/systemd/man/latest/journalctl.html

systemd — systemd.unit
https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html