systemdサービスが突然再起動する原因とログの追い方

Linux運用中、systemd管理のサービスが

• 勝手に再起動している
• 停止していないのにPIDが変わっている
• ユーザー操作の記録がない

といった事象に遭遇することがあります。

本記事では、

• 「なぜ再起動したのか」を確定させる方法
• systemd / カーネル / アプリのどこが原因か
• どうなれば解決と判断できるか

を、journalctlを中心にした実務的な手順で解説します。

まず確認すべき前提：再起動とクラッシュは別

systemd環境では、

• プロセスが落ちた
• systemdが再起動した

という2つのパターンがあります。

重要なのは、

「なぜ再起動したか」ではなく
「なぜ落ちたか／落とされたか」

を切り分けることです。

Step1：systemctlで再起動の事実を確認

systemctl status サービス名

ここで以下を確認します。

• Active: active (running)
• Main PID が変わっていないか
• Restarted at の表示

再起動履歴があれば、 「systemdが再起動した」ことは確定です。

---

Step2：journalctlで再起動前後のログを見る

journalctl -u サービス名 --since "YYYY-MM-DD HH:MM"

再起動時刻の

• 直前
• 直後

を必ず確認します。

ここで見るべきは、

• error / fatal / panic
• exit code

といった終了理由です。

代表的な原因とログの特徴

① プロセスが異常終了した（クラッシュ）

ログ例：

code=exited, status=1/FAILURE

この場合、

• アプリケーションエラー
• 設定ミス

が原因でプロセスが落ち、 systemdが再起動しています。

対策：
アプリケーションログ・設定ファイルを確認します。

② OOM Killerによる強制終了

ログ例：

Out of memory: Kill process xxxx (サービス名)

この場合、

• サービス自体は正常
• メモリ逼迫で殺された

という状態です。

対策：
メモリ使用量・swap挙動・OOMスコアを見直します。

③ systemdのRestart設定による再起動

ユニットファイルに

Restart=always

が設定されていると、

• exitコードに関係なく
• systemdが再起動

します。

対策：
Restart=on-failure への変更を検討します。

④ Watchdogによる再起動

応答がない場合、 systemdのWatchdogが

• ハングと判断
• 再起動

するケースです。

ログには、

Watchdog timeout

と出ることがあります。

カーネル・OS起因かを確認する

journalctl -k --since "YYYY-MM-DD HH:MM"

以下があれば要注意です。

• I/O error
• hung task
• OOM Killer

OS起因の場合、 サービス側では解決しません。

どうなれば「解決」と判断できるか

以下を満たせば、

• 再起動原因が特定できた
• 再起動が再現しない
• ログに異常終了が出ない

状態となり、解決と判断できます。

原因不明のまま再起動が止まった場合は、 解決とは言えません。

まとめ

• 再起動の正体は「落ちた or 落とされた」
• journalctlで直前ログを見る
• OOM・Restart設定は最優先で疑う
• 原因が分かれば対処は明確

systemdサービスの再起動は、

必ず理由があります。

ログを正しく追えば、 「突然」ではなくなります。