218
73
If I install a new service then decide I don’t want that application anymore and delete it, the service is still listed in the output from systemctl
as error.
Where is this coming from and how can I remove them thoroughly?
218
73
If I install a new service then decide I don’t want that application anymore and delete it, the service is still listed in the output from systemctl
as error.
Where is this coming from and how can I remove them thoroughly?
352
My recipe for service obliteration (be careful with the rm
statements!)
systemctl stop [servicename]
systemctl disable [servicename]
rm /etc/systemd/system/[servicename]
rm /etc/systemd/system/[servicename] symlinks that might be related
systemctl daemon-reload
systemctl reset-failed
It is possible that the systemd service 'wraps' the old style scripts in /etc/init.d, so you may want to clean that up too, but that is not where systemd services live.
34
You are probably looking for reset-failed
:
$ sudo systemctl reset-failed
$
From the systemd man page:
reset-failed [PATTERN...]
Reset the "failed" state of the specified units, or if no unit name is passed, reset the state of all units. When a unit fails in some way (i.e. process exiting with non-zero error code, terminating abnormally or timing out), it will automatically enter the "failed" state and its exit code and status is recorded for introspection by the administrator until the service is restarted or reset with this command.
2That isn't what the question is asking for at all. Why on earth has this been upvoted 17 times? – psusi – 2018-11-07T16:54:20.027
2This is the only correct answer. The other ones with more upvotes and the check mark are workarounds. – Thomas – 2018-11-21T11:37:01.560
5I have not read the OP's question, but this was the answer I was looking for. – CousinCocaine – 2019-09-03T08:41:54.490
24
Sounds like you uninstalled it, but didn't remove the systemd hook:
# systemctl disable [servicename]
5
Adding on to @mark-lakata's answer and keeping in mind the attentiveness required for the rm
command. [chkconfig]
can simplify the process!(click here to read about chkconfig)
To re-iterate the list of commands:
systemctl stop [servicename]
chkconfig [servicename] off
systemctl daemon-reload
systemctl reset-failed
Note: The 1st command is optional depending on whether you want keep the service running in the present session or not (as for this question the command should be used).
The 2nd command takes care of both disabling and removing (following the symlinks) the service.
1chkconfig
was the original command to enable/disable SysVinit services. In systems using systemd
, it may be present as a backward compatibility command; but the native systemctl
command is just as simple: systemctl disable [servicename]
– telcoM – 2018-07-29T13:29:26.477
2Okay, but the reason for me using this command is, you then don't have to explicitly run the rm command – garlicFrancium – 2018-07-29T19:23:53.633
chkconfig not found in ubuntu 16 – Nam G VU – 2019-11-14T10:26:16.270
1
Removing a service from systemd :
Systemd uses unit (file to define services) to remove a service the unit have to be removed... here is a list of unit locations :
/etc/systemd/system/ (and sub directories)
/usr/local/etc/systemd/system/ (and sub directories)
~/.config/systemd/user/ (and sub directories)
/usr/lib/systemd/ (and sub directories)
/usr/local/lib/systemd/ (and sub directories)
/etc/init.d/ (Converted old service system)
Refresh systemd :
systemctl daemon-reload
systemctl reset-failed
Ghost services (not-found) :
Systemd can list ghost (not-found) services even if the unit is deleted for many reasons
(*) if a service is mentioned in other unit but does not exist systemd will still list that service with the state not-found even if there is not unit file... you can search what unit is using that service with a text search and edit those units (not recommended if you plan to install that service later)
12
Be aware that there are multiple locations where Systemd unit files are stored, notably
– Mark Edington – 2017-03-08T00:18:21.883/usr/lib/systemd/system
and also/etc/systemd/system/
. For reference see: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html#tabl-Managing_Services_with_systemd-Introduction-Units-Locations10I had also to remove
/etc/init.d/[servicename]
before runningsystemctl reset-failed
– Andrea – 2017-06-07T15:21:07.6137Right, I forgot to disable before removing the unit files. BTW, to find all unit files to remove, I inspect the output of
systemctl cat [servicename]
. – Amir – 2017-09-17T14:55:52.727It may be a "wrapped" old style script in /etc/init.d/ but if you dont remove it you will find it still showing up under services left over from your removal. I can tell you that was the case for me. You could simply add that to your answer to make it more complete but hopefully the next person that needs it will look at the comments. – Marlon – 2017-11-29T01:30:06.450
@Marlon - If your
/etc/init.d
service is still running after removing the wrapper service, then it is configured outside the narrow scope of this question (which is simply about systemd). If you have sym links from/etc/r c*
pointing to/etc/init.d
, then you are not running systemd. – Mark Lakata – 2017-11-30T02:53:50.7033That worked, thank you, but I am not sure why I am made to clean up this garbage manually. – Rolf – 2018-03-31T01:19:27.257
Why doesn't systemd provide a command to cleanup? Systemd knows how to cleanup after deleted *service and *.timer files. Why does systemd think users know the inner workings of the program??? – jww – 2019-06-19T02:07:18.873
You may need to unmask the service, if you had it masked before, to be able to disable it:
systemctl unmask [servicename]
– Shayan – 2019-08-22T19:50:45.470systemctl list-unit-files | grep enabled will list all enabled services – Jorj – 2019-08-25T17:12:38.037