Back to lessons

Linux Survival Basics

Reset Failed State After Capturing Evidence

systemctl --failed still shows an old service failure after the issue was fixed, and you need to clear the recorded failed state deliberately.

Command

systemctl reset-failed app-worker

What changed

systemd clears the recorded failed state for the service, so future --failed output reflects new failures.

Danger

caution

When to use it

Use after documenting or fixing a failure when the failed state itself is stale noise.

When not to use it

Do not run it before collecting status and journal evidence, and do not confuse clearing state with fixing the service.

Undo or recovery

There is no meaningful undo for clearing the marker; use saved logs or incident notes for prior evidence.

Expected output

Either no output or a short confirmation that the failed state was reset.

demo script

Disposable terminal steps

  1. systemctl show app-worker --property=Result,ExecMainCode,ExecMainStatus,NRestarts --no-pager
  2. systemctl reset-failed app-worker

simulated output

What it looks like

disposable vessel
::fixture-ready::
$ systemctl show app-worker --property=Result,ExecMainCode,ExecMainStatus,NRestarts --no-pager
Result=exit-code
ExecMainCode=1
ExecMainStatus=217
NRestarts=5
::exit-code::0
$ systemctl reset-failed app-worker
Reset failed state for app-worker.service.
::exit-code::0

YouTube Short

Reset failed only after evidence.

reset-failed clears the marker; it does not fix the cause. Capture status and logs first, then clear stale failure state.

LinkedIn hook

Clear the red failed state only after you have captured the evidence.

Question: Do your runbooks capture evidence before clearing systemd failed state?

experiments

A/B tests to run

Metric: save_rate

A: Clear state after evidence.

B: reset-failed is not a fix.