How to remove systemd services

Question

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?

score 754 · Accepted Answer · edited Apr 06 '20 at 08:42

754

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] # and symlinks that might be related
rm /usr/lib/systemd/system/[servicename] 
rm /usr/lib/systemd/system/[servicename] # and 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.

edited Apr 06 '20 at 08:42

Mike

103
4

answered Jul 06 '15 at 16:46

Mark Lakata

8,340
2
18
16

17

Be aware that there are multiple locations where Systemd unit files are stored, notably `/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-Locations – Mark Edington Mar 08 '17 at 00:18
18

I had also to remove `/etc/init.d/[servicename]` before running `systemctl reset-failed` – Andrea Jun 07 '17 at 15:21
16

Right, 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 Sep 17 '17 at 14:55
It 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 Nov 29 '17 at 01:30
@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 Nov 30 '17 at 02:53
9

That worked, thank you, but I am not sure why I am made to clean up this garbage manually. – Rolf Mar 31 '18 at 01:19
1

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 Jun 19 '19 at 02:07
You may need to unmask the service, if you had it masked before, to be able to disable it: `systemctl unmask [servicename]` – Shayan Aug 22 '19 at 19:50
systemctl list-unit-files | grep enabled will list all enabled services – Jorj Aug 25 '19 at 17:12
8

@MarkLakata Why do we need to do `systemctl reset-failed` in the end? – tuk May 19 '20 at 04:14
1

I wonder why systemctl doesn't offer an interface to remove the service automatically instead of manually looking for the files and deleting them. – rkachach Jun 08 '20 at 13:16
1

I tried all of them, it does not work on ubuntu-16.04 LTS. On newer Linuxes, `systemctl reset-failed` is the key, but I had to give it multiple times, combined with some `daemon-reload`s. I am sorry to say, but I find it disastrous. – peterh Sep 03 '20 at 14:35
It's a good idea to make sure that there are no links to the deleted service in the directories `/etc/systemd/system/*.target.*`, although these *might* be cleaned up automatically. – Philip Kearns Apr 01 '21 at 10:54
I have some in: `./etc/systemd/user/` and `./etc/systemd/user/multi-user.target.wants/` – Pound Hash Apr 13 '22 at 21:45
Very interesting that a daemon-reload doesn't reset-failed automatically... Super helpful note! – Arcsector Sep 22 '22 at 00:54
Anyone trying this might wanna run `find /usr/lib/systemd/system | grep "[servicename]"` and `find /etc/systemd/system | grep "[servicename]" to find any references to their service. My service was hiding in the subfolder `/etc/systemd/system/multi-user.target.wants/` and I don't know how many other subfolders exist for services. – Mossmyr Feb 16 '23 at 11:15

score 87 · Answer 2 · answered Apr 13 '16 at 09:41

87

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.

answered Apr 13 '16 at 09:41

Vebjorn Ljosa

2,069
2
18
21

14

That isn't what the question is asking for at all. Why on earth has this been upvoted 17 times? – psusi Nov 07 '18 at 16:54
6

This is the only correct answer. The other ones with more upvotes and the check mark are workarounds. – Thomas Nov 21 '18 at 11:37
17

I have not read the OP's question, but this was the answer **I** was looking for. – CousinCocaine Sep 03 '19 at 08:41
7

This was exactly what I needed. The service apparently was removed, but the failed state was still kicking around. – Jack BeNimble Jun 19 '20 at 17:21
1

It sounds like this just resets the state for a service that should no longer exist. You should very likely delete the service files themselves, not simply change the state of a service you no longer want. – pzkpfw May 19 '22 at 08:30
There are no service files to delete if it is a transient unit. – Christopher Monsanto Dec 17 '22 at 17:44

score 42 · Answer 3 · answered Dec 01 '12 at 05:39

42

Sounds like you uninstalled it, but didn't remove the systemd hook:

# systemctl disable [servicename]

answered Dec 01 '12 at 05:39

nerdwaller

17,054
2
44
44

garlicFrancium · Answer 4 · 2020-03-15T15:08:22.920

15

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 OR for newer systems systemctl disable [servicename]
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.

edited Mar 15 '20 at 15:08

answered Jul 29 '18 at 12:48

garlicFrancium

279
2
8

2

`chkconfig` 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 Jul 29 '18 at 13:29
3

Okay, but the reason for me using this command is, you then don't have to explicitly run the rm command – garlicFrancium Jul 29 '18 at 19:23
1

chkconfig not found in ubuntu 16 – Nam G VU Nov 14 '19 at 10:26
1

@NamGVU updated my answer – garlicFrancium Mar 15 '20 at 15:08
`systemctl disable` is not removing the unit files for me – afarley Feb 06 '21 at 19:22

score 7 · Answer 5 · answered Jul 11 '20 at 09:17

7

A simple Oneliner could be:

service=YOUR_SERVICE_NAME; systemctl stop $service && systemctl disable $service && rm /etc/systemd/system/$service &&  systemctl daemon-reload && systemctl reset-failed

Set service to your desired service that should be deleted. E.g. service=gunicorn.service

answered Jul 11 '20 at 09:17

Leonleon1

71
1
2

1

+1 for a single operation. This could easily be set in a script with the service string as argument, simplifying the process. – Ben Dec 03 '20 at 15:38

intika · Answer 6 · 2020-08-24T01:16:59.120

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

unit still present on one of the systemd directory
unit does not exit but a file link is still present on one of the systemd directory
the service is used in other unit(s)*

(*) 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)

Sources: Linuxhacks.org
Disclosure: I am the owner of Linuxhacks.org

score 3 · Answer 7 · answered Dec 27 '20 at 09:31

the best and official way to remove a service and its override files is:

systemctl revert servicename

this will delete anything created with:

systemctl edit
systemctl set-property
systemctl mask

which will revert the given unit to its vendor configuration

How to remove systemd services

7 Answers7

Linked