In this article, we’ll see how to list all the failed units in our system using the systemctl command.
We’ll learn how to use these commands to check our unit file status and determine if a particular unit file has failed. While the commands we’ll discuss should work in any Linux environment that uses systemd, we’ll also look at the syntax of other similar commands.
2. Failed Units
After booting our computer, all the enabled services start and are queued to execute. Most of these processes are independent, while some are interdependent.
Usually, all these processes should start and run correctly without any issues. However, in some circumstances, a process might fail to execute successfully. This can either happen during the boot-up or after the boot is complete. A failing unit might result in a failed state, preventing a process from being activated or run.
Units often fail because of missing dependencies (e.g., file or mount points), misconfiguration, missing configuration files, incorrect permissions, lack of system resources, and corrupted files.
Let’s run these commands and see the output they give out. First, we’ll list the state of various failed service units:
$ systemctl list-units --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION ● fwupd-refresh.service loaded failed failed Refresh fwupd metadata and update motd LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e., generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 1 loaded units listed.
Alternatively, we can use these syntaxes and get the same kind of output:
$ systemctl list-units --type=service --state=failed $ systemctl --failed
If we suspect a particular unit file (or if it usually fails), we can always check its status:
$ systemctl is-failed fwupd-refresh.service failed
We mustn’t forget to add the unit name after the command. If we do, it displays a “Too few arguments” error message.
The is-failed option checks if the unit file specified is in a failed state. If so, it returns an exit code of 0. Otherwise, it returns the number that the process exited with.
$ sudo systemctl list-units | grep -i failed ● fwupd-refresh.service loaded failed failed
In addition, we can also use systemctl status name-of-unit to show what status it’s in:
$ systemctl status fwupd-refresh.service × fwupd-refresh.service - Refresh fwupd metadata and update motd Loaded: loaded (/lib/systemd/system/fwupd-refresh.service; st> Active: failed (Result: exit-code) since Tue 2022-10-25 18:43> TriggeredBy: ● fwupd-refresh.timer Docs: man:fwupdmgr(1) Process: 554218 ExecStart=/usr/bin/fwupdmgr refresh (code=exit> Main PID: 554218 (code=exited, status=1/FAILURE)
If there’s no failed unit, we’ll get the following output:
$ systemctl list-units --type=service --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed.
There are several types of units file available in our system. These unit files are *.service, *.socket, *.device, *.mount, *.automount, *.swap, *.target,*.path, *.timer, *.snapshot, *.slice and *.scope. We can use these to filter further and find the status of the targeted unit file.
3. Resolving Failed Units
After identifying the failed units, we can resolve their state using either of the following commands:
$ systemctl reset-failed $ systemctl reset-failed name.service
Running either of the commands won’t give us any output. It only moves us to a new line. To confirm that the failed unit has been resolved, let’s check the status of the unit file before and after we apply the command:
$ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● fwupd-refresh.service loaded failed failed Refresh fwupd metadata and update LOAD = Reflects whether the unit definition was properly loaded. 1 loaded units listed. $ sudo systemctl reset-failed fwupd-refresh.service $ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed.
Upon checking the status now, we find that there isn’t any failed unit.
In this tutorial, we’ve looked at how to check the status of failed services in our system. Further, we also looked at how we can resolve these failed services and get them back working. Knowing the states of our services is essential, especially if we’re using scripts that run sequentially and are interdependent on other processes.