systemctl reset-failedの意味と使い方｜failed状態・起動制限の確認
systemctl reset-failedはsystemdの失敗状態や起動制限のカウンターをリセットするための操作です。「実行すれば障害が直るのか」「いつ使うべきか」を区別し、原因確認から安全な再試行まで順に説明します。
このページの目的
reset-failedの対象・副作用を理解し、起動失敗の根本原因を残したまま状態だけ消す誤操作を避けます。
最初にやること
systemctl statusとjournalctl -uで最初の失敗を保存し、systemctl showで起動制限を確認します。原因を修正した後に限り、必要に応じてreset-failedを検討します。
関連するsystemdガイド
systemdが起動しない・failed
起動失敗の種類とログ、Unit構文、実行パス、依存サービスを切り分けます。
原因を確認 → 実行エラーstatus=203/EXEC
実行ファイル・権限・shebangのエラーを切り分けます。
エラーを調べる → 反映手順daemon-reloadとrestart
Unit定義を修正した場合の再読込とサービス再起動の違いを確認します。
変更手順を確認 →reset-failedが行う状態・カウンターのリセットと再試行の判断です。アプリ本体・Unit設定の根本原因は起動失敗ガイドで確認してください。Unitを再起動する前に確認
Unitの実行パス、Restart、起動制限など、再起動を繰り返す前に確認したい設定をレビューできます。
systemctl reset-failedは何をする？
systemctl reset-failed example.serviceは指定したUnitのfailed状態を消去し、サービスの起動回数制限のカウンターや再起動カウンターをリセットします。サービスそのものを修復したり、設定ファイルを書き換えたり、停止中のサービスを自動的に起動したりするコマンドではありません。
失敗状態を消しただけでは「アプリが正常稼働した」ことにはなりません。is-activeや実際のアプリケーション疎通を別途確認します。
いつ使う？ Start request repeated too quicklyとの関係
| 状況 | 判断 |
|---|---|
failedが残っている | 先に失敗理由と発生時刻を保存。監視上の見かけを整えるためだけなら実行理由を明確にする |
Start request repeated too quickly | StartLimitIntervalSec・StartLimitBurstに達している可能性。最初の起動失敗を修正してから再試行する |
| Unitの構文ミスやExecStart先が存在しない | 先に設定・ファイル・権限を修正。reset-failedでは根本原因は直らない |
| 実行中サービスが安定している | 通常、状態リセットのために追加操作する必要はない |
短時間に何度も起動失敗した場合、systemdの起動回数制限によって再試行が拒否されることがあります。reset-failedは制限カウンターをリセットできますが、原因が残れば同じ障害を繰り返します。
実行前：最初の失敗と設定値を保存
システムのバージョンによって、systemctl showのプロパティ名や表示内容は異なることがあります。特にStartLimitIntervalUSecは、古い環境では確認方法が異なる場合があります。Unit定義と実際の状態を突き合わせてください。
restartすると、原因が見えにくくなったり、依存サービスに負荷を与えたりします。必要なら管理者と合意してサービスの自動再起動方針から確認してください。操作手順と注意点
reset-failedの対象Unitを省略すると、全Unitのfailed状態をリセットする動作になります。障害の証跡・監視への影響を避けるため、Unit名を指定するのが基本です。
systemctl daemon-reloadはUnitの構成変更を再読込する別操作です。Unitのファイルを編集した場合は適切なタイミングで再読込してください。reset-failedを代用にしないでください。
結果別の次の対応
| 確認結果 | 次に実施すること |
|---|---|
| failedが消えてサービスはinactive | 状態リセットのみ成功。必要なら変更承認後に起動してアプリケーションの動作を確認 |
| 再試行直後に再びfailed | journalの最初のエラーを調査。設定・パス・権限・アプリログを修正する |
| 起動制限が再発 | Restart=によるループ、StartLimitBurst、依存先の不調を再評価。無制限化は避ける |
203/EXECが表示 | 専用ガイドで実行ファイル・インタープリタ・権限を確認 |
| 起動成功でも機能しない | アプリケーションのログ・ポート・依存先への接続・ヘルスチェックを確認 |
リセット後・修正後の再確認
期待するActiveStateと実際のアプリ動作が一致するか確認します。失敗状態が消えたことだけを正常化とみなさず、業務リクエストが応答するか、監視アラートが回復しているか、一定時間の再発がないかまで確認します。