I'm having trouble figuring out how to remove systemd units that no longer have files. They still seem to linger in the system somehow.
The old broken units I am trying to remove:
core@ip-172-16-32-83 ~ $ systemctl list-units --all firehose-router*
UNIT LOAD ACTIVE SUB DESCRIPTION
<E2><97><8F> [email protected] not-found failed failed [email protected]
<E2><97><8F> [email protected] not-found failed failed [email protected]
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.
2 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
The files do not exist, yet a reload still has these units lingering:
core@ip-172-16-32-83 ~ $ systemctl list-unit-files [email protected]
core@ip-172-16-32-83 ~ $ sudo systemctl daemon-reload
core@ip-172-16-32-83 ~ $ systemctl list-units --all firehose-router*
UNIT LOAD ACTIVE SUB DESCRIPTION
<E2><97><8F> [email protected] not-found failed failed [email protected]
<E2><97><8F> [email protected] not-found failed failed [email protected]
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.
2 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
There are no files related to them that I can find:
core@ip-172-16-32-83 ~ $ sudo find /var/run/systemd -name "*firehose-router*"
core@ip-172-16-32-83 ~ $ find /etc/systemd/ -name "*firehose-router*"
core@ip-172-16-32-83 ~ $ find /usr/lib/systemd/ -name "*firehose-router*"
core@ip-172-16-32-83 ~ $
So how do I get rid of these?
The command you're after is
systemctl reset-failed
When systemd analyzes unit definition files, it takes note of any other related units called out in the file - whether those other units exist or not.
When a unit shows up as "not-found", it's not necessarily an error - all we know is, a local unit definition claims to have some relationship with it. This relationship might not be one we care about. For example, it could be
"Before:"
some other unit, but we don't use that other unit.failed
- happens when a unit has entered a failed state and can be reset with thesystemctl reset-failed
commandnot-found
- happens when you've removed a unit but systemd still has a reference to it, like when a unit gets enabled and a symlink gets placed in/etc/systemd/system
, this can be fixed by removing references to the unit in/etc/system/systemd/*.wants/
then runningsystemctl daemon-reload
For example, assume the following bash script:
And 3 systemd units:
example-foo.service
,example-bar.service
, andexample-baz.service
Now, let's start and enable the units. Observe how symlinks get created.
Confirm there are actually 6 files for our 3 units.
Now, check the state of all 3 units, they're running.
Now, simulate a failure by sending a SIGKILL to
example-foo.service
. Observe how the unit is in a failed state.To reset a unit in a failed state use the
systemctl rese-failed
command. Observe how the unit is now in an inactive state.Okay, now let's remove the example-bar.service unit. Observe how the unit is in a not-found state; however, the example-bar.service broken symlink is still in /etc/system/system/multi-user.target.wants
Remove the broken symlink and confirm the example-bar.service unit is gone.
It seems that systemd maintains links but does not know what to do with them when you delete the unit file.
You could try to remove them manually in
/etc/systemd/system/suspend.target.wants/
and such but of coursesystemctl reset-failed
from a previous answer sounds like a better option.