サービスが失敗した後、systemctl reset-failed は実際に何をするのか？

systemctl reset-failed はユニットの失敗状態とリスタートカウントをリセットします。このコマンドは新しいチェックを準備しますが、サービスを修復するわけではありません。

systemdのユニットがfailed状態に遷移すると、すぐにsystemctl reset-failedを実行したくなるかもしれません。VM、ワークステーション、またはサーバー上で、このコマンドは目に見える状態を取り除くことができますが、停止の原因には触れません。

診断はサービスの状態とそのログから始まります。その後、ターゲットユニットをリセットし、結果を確認し、エラーが理解できていれば個別に起動を試みることができます。

リセットする前にサービスを確認する

failedとマークされたユニットは、systemdによって追跡される状態を示しています。それだけでクラッシュの理由を示すわけではありません。実際に関係するユニットのステータスとログから始めてください：

systemctl status mon-service.service
journalctl -u mon-service.service

journalctlはログ内のサービスメッセージを見つけるために使用できます。特にユニットがループして再起動する場合は、failed状態を取り除く前にそれを読むべきです。

現在の状態、サブステータス、実行結果、およびリスタートカウントを分けるために、ユニットのプロパティも確認してください：

systemctl show mon-service.service -p ActiveState -p SubState -p Result -p NRestarts

これらの4つの値は異なる質問に答えます：

• ActiveStateは、systemdによって追跡される全体的な状態を示します。
• SubStateはユニットのサブ状態を示します。
• Resultは失敗に至った実行の結果を示します。
• NRestartsは記録されたリスタートの回数を示します。

reset-failed コマンドは状態を消去するが、エラーは消さない

確認後、関係するユニットのみを対象にします：

sudo systemctl reset-failed mon-service.service

systemctl reset-failed <ユニット>はユニットのfailed状態と、起動制限に関連するリスタートカウントをリセットします。このコマンドはユニットを再起動しません。

それはExecStart、権限、依存関係、またはユニットによって使用されるバイナリを変更することはありません。また、ログを消去することもありません。systemctlのマニュアルページはこの動作とその他の利用可能なサブコマンドを説明しています。

failedの消失は、修復したという誤った印象を与えることがあります。サービスは依然として無効な設定、欠損依存関係、または失敗するExecStartコマンドを含んでいる可能性があります。

新しい起動の前に結果を確認する

リセット後にプロパティを再確認します。チェックはユニットの状態とカウントに関するもので、コマンドの出力をコピーすることに関してではありません：

systemctl show mon-service.service -p ActiveState -p SubState -p Result -p NRestarts

原因が理解され修正された場合、起動は別のアクションになります：

sudo systemctl start mon-service.service
systemctl status mon-service.service
journalctl -u mon-service.service

ステータスとログで、この起動後の状態を確認できます。ユニットがすぐに再び失敗する場合は、試行を停止し、Resultまたはログで指摘された原因を修正してください。

ユニットファイルを変更した後は、sudo systemctl daemon-reloadでユニットファイルを再読み込みしてください。このステップは自動的にreset-failedの後に続くわけではありません。systemdのリロードに関するフォルダでは、このケースが別途取り扱われています。

タイマーによって起動されるサービスの場合、systemdのタイマーの動作が、サービスユニットとそのトリガーの関係を説明しています。リセットされた状態は、プログラム、設定、または失敗を引き起こす依存関係を修正するものではありません。