After a failed service, what does systemctl reset-failed actually do?

systemctl reset-failed resets the failure state of a unit and its restart counter. The command prepares for a new check, but it does not repair the service.

When a systemd unit goes to the failed state, the temptation is to immediately run systemctl reset-failed. On a VM, a workstation, or a server, this command can remove the visible state without addressing the underlying cause of the failure.

Diagnosis starts with the service status and its logs. You can then reset the targeted unit, check the result, then attempt a separate start if the error is understood.

Check the service before resetting its state

A unit marked failed indicates the state tracked by systemd. It does not provide, on its own, the reason for the crash. Start with the status and the logs for the unit in question:

systemctl status my-service.service
journalctl -u my-service.service

The link journalctl allows you to find the service message in the logs. Read it before removing the failed state, especially if the unit is restarting in a loop.

To separate the current state, sub-state, execution result, and restart counter, also request the properties of the unit:

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

These four values answer different questions:

• ActiveState indicates the overall state tracked by systemd.
• SubState specifies the sub-state of the unit.
• Result indicates the result of the execution that led to the failure.
• NRestarts gives the number of recorded restarts.

The reset-failed command clears the state, not the error

After reading, target only the affected unit:

sudo systemctl reset-failed my-service.service

systemctl reset-failed <unit> resets the failed state of the unit and the restart counter associated with the start limit. The command does not restart the unit.

It does not modify ExecStart, permissions, dependencies, or the binary used by the unit. It also does not clear the logs. The man page for systemctl describes this behavior and other available subcommands.

The disappearance of failed can thus give a false impression of repair. The service may still contain an invalid configuration, a missing dependency, or a failing ExecStart command.

Check the result before a new start

Review the properties after the reset. The check focuses on the unit’s state and the counter, not on a command output to be copied:

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

If the cause is understood and corrected, starting becomes a separate action:

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

The status and logs allow you to see the state obtained after this start. If the unit immediately goes back to failure, stop the attempts and fix the cause highlighted in Result or in the logs.

Reload the unit files with sudo systemctl daemon-reload after modifying a unit file. This step does not automatically follow reset-failed. The folder dedicated to systemd reloads addresses this case separately.

For a service launched by a timer, the operation of systemd timers explains the relationship between the service unit and its trigger. The reset state does not correct the program, configuration, or dependency causing the failure.