Disable service in systemd

Ubuntu
1

I installed fluidsynth in Ubuntu 22.04. I did not want the process running all the time. The install set it up service (or session) as a user WantedBy=default.target

I tried systemctl --user disable fluidsynth but when I logged out and back in, fluidsynth was running again.
I ended up removing (deleting) the symlink in the /etc/systemd/user/default.target.wants/ directory. That took care of the problem.
Now if I use systemctl --user enable fluidsynth it recreates the symlink in the ~/.config/systemd/user/default.target.wants/
and when I systemctl --user disable fluidsynth it removes the symlink.
I really don’t need to enable and disable the service, but it is now working as I thought it should of at the beginning.

My question is what was the proper way to remove the initial symlink?

1 Like
2

Maybe it was installed and enabled for all users and a sudo systemctl disable fluidsynth would have done it. But it seems like what you did should have worked.

1 Like
3

When I tried that I got an error.

Failed to disable unit: Unit file fluidsynth.service does not exist.

If I didn’t use --user it would always say

Unit file fluidsynth.service does not exist.

of course when I used --user, it puts/removes the symlink under the home folder (~/.config/systemd/user/).

& yes, you are correct, it was initially setup for all users.

I just couldn’t figure out how to get it to remove the original symlink under /etc/systemd/user/

Big picture- I guess it doesn’t matter. I was just wondering if I was missing something obvious.

1 Like
4

It should have been

systemctl --global [enable/disable] fluidsynth
7 Likes
5

Thanks for the info-
Next time I’ll know how to do it properly.

2 Likes
6

NECROPOST warning :

Gonna check this out… Just lately - my Pop!_OS desktop machine (NEVER happens on my ThinkPad E495 - running Pop!_OS both are AMD Ryzen) get its knickers in a twist - stops responding to mouse select window (I can change windows with Alt+Tab) - and when I look in a terminal window (or remotely over SSH) I can see that some piece of crap called “fluidsynth” is eating VAST amount of CPU…

If/when I kill it - or - try to stop it using systemd - it sticks it’s ugly head in again and it eats CPU…

My usual solution (like this morning) is to reboot… But that’s a bit of a PITA - I have to login to TTY (I’ve disabled GDM) then run “startx” - and that’s AFTER entering my 20 digit passphrase for my LUKS “/” filesystem (Pop! doesn’t use GRUB - it uses something called SystemD-boot - next time I DistroSurf/Hop - I might look for something that still uses GRUB).

I haven’t spent enough time on the issue to figure out if it’s actually “fluidsynth” causing the issue - but when my machine’s idle - that piece of crap shouldn’t be eating CPU cycles!

1 Like
7

That is because the systemd init system has supervision…if a daemon stops it restarts it.
What you need to do is disable the service, rather than stop it.
I dont know how to disable a service in systemd, but you will know… just noticed… that is the title of this topic.

2 Likes
8

systemctl disable servicename

2 Likes
9

Next time it happens - I might do that - but - not sure I want it permanently disabled - but I’ll read the OP’s original post at the top and digest it…

3 Likes
10

What you may want is to remove it from supervision… so you control it. I could do that in S6 but no clue about systemd.

2 Likes
11

To start and stop a service it’s just:

systemctl start servicename
systemctl stop servicename

To have it start automatically at boot time:

systemctl enable servicename

To prevent it from starting automatically at boot time:

systemctl disable servicename

Pretty easy. Pretty flexible.

3 Likes
12

So if I disable the service, then after booting start it manually, is it supervised?

2 Likes
13

In my experience it isn’t supervised at all. Maybe during the initial startup. But if the service stops for some reason there is no attempt to restart it automatically.

At least that’s what I’ve seen.

2 Likes
14

It may be, or may not be. Depends on how the service unit file is written.
Even if disabled, and manually started, systemd will resart the service when the executable fails (exits).
I think this is what @nevj refers to as “supervised”.
The “restart” clause in the unit file describes this behavior.

Restart=

Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but it may also be one of the processes specified with ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog “keep-alive ping” deadline and a service start, reload, and stop operation timeouts.

Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service process exits cleanly. In this context, a clean exit means any of the following:

See here:

4 Likes
15

In Runit or S6 supervised means there is a separate supervision process running , in addition to the daemon process. One of its functions is to restart daemons that stop unexpectedly.

3 Likes
16

I have gdm set to disabled - but some updates occasionally turn it on again - PITA…

I will try to disable fluidsynth if/when it happens again… I won’t hold my breath…

I’m well used to using systemd to do “stuff” - I can still remember when Red Hat had “chkconfig” to enable, or disable systemd stuff - and most people did Windows style “service stop BLAH”… RHEL were pushing us that way even back in SystemD init “times” 10+ years ago… But even Sun were pushing us that way 15+ years ago with Solaris “SMF”…

3 Likes