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

URLをコピーしました！

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サービスの再起動は、

必ず理由があります。

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