Linux でサービスを運用していると、systemctl status の出力で以下のような状態を目にすることがよくあります。
Active: failed (Result: exit-code)
Unit entered failed state
このメッセージは、systemd が当該サービスを正常に起動または実行できなかったと判断したことを意味します。
以下は、このエラーを迅速に診断・対応するための 3 ステップの手順です。
サービス状態と終了原因の確認 #
まず、サービスの状態と終了原因を確認します。
sudo systemctl status [サービス名]
確認すべきポイントは以下のとおりです。
Main PID
終了したプロセスの ID と、終了時点の状態。
Result
- exit-code
→ プログラム内部のエラーにより正常終了できなかった。 - signal
→ 外部シグナル(例:OOM Killer)によって強制終了された。
この段階では、
「どこで失敗したか」ではなく、
「どの種類の失敗か」を把握することが重要です。
journalctl による詳細ログ解析(重要) #
多くの場合、systemctl status だけでは情報が不足します。
実際の原因は journal ログに記録されています。
sudo journalctl -u [サービス名] -n 50 --no-pager
よく見られるエラーメッセージは以下のとおりです。
- Permission denied
→ 実行ファイル、設定ファイル、ログディレクトリの権限問題。 - Address already in use
→ ポート競合(すでに別のプロセスが使用中)。 - syntax error, invalid config
→ 設定ファイルの文法エラー。 - Out of memory, Killed process
→ メモリ不足によりカーネルがプロセスを強制終了。
このステップで、原因の大半は特定できます。
代表的な原因と対処方法 #
| 原因 | 確認方法 | 対処方法 |
|---|---|---|
| 設定ファイルのエラー | journalctl 内の syntax error を確認 | .conf、.yaml の文法修正 |
| 権限問題 | ls -l で権限を確認 | chown または chmod で修正 |
| ポート競合 | ss -tulpn | grep [ポート] | 既存プロセスの停止またはポート変更 |
| 依存関係の問題 | systemctl list-dependencies [サービス名] | 必要なサービスを先に起動 |
設定変更後に必ず行う作業 #
.service ファイルや設定ファイルを修正した場合、
すぐに再起動してはいけません。
sudo systemctl daemon-reload
sudo systemctl restart [サービス名]
daemon-reload を行わないと、
systemd が 以前の設定を保持し続けることがあります。
まとめ #
systemctl statusで失敗タイプを確認journalctl -uで実際の原因を特定- 設定修正後は
daemon-reloadを実行して再起動
この手順を使えば、
systemd の failed 状態の大半は 5 分以内に解決できます。
🛠 마지막 수정일: 2025.12.22
💡 お困りですか?
Zabbix、Kubernetes、各種オープンソースインフラの構築・運用・最適化・障害解析が必要であれば、いつでもご連絡ください。
📧 メール: jikimy75@gmail.com
💼 サービス: 導入支援 | 性能チューニング | 障害解析コンサルティング