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
systemctl show app-worker --property=Result,ExecMainCode,ExecMainStatus,NRestarts --no-pagersystemctl reset-failed app-worker
simulated output
What it looks like
::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.