Disabling snapd with systemctl

Question

snapd is enabled by default in Ubuntu as doing a systemctl status snapd quickly reveals which is of course expected. So I tried the following:

$ sudo systemctl disable --now snapd
$ sudo systemctl disable --now snapd.socket

The first command warns that snapd.socket could reactivate snapd (hence my second command) and the second outputs that a symlink has been removed (as expected when disabling most services/sockets with systemctl). I then did a reboot to confirm that the changes persisted. To my surprise, systemctl status snapd outputs the following (trimmed for convenience):

● snapd.service - Snap Daemon
     Loaded: loaded (/lib/systemd/system/snapd.service; disabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-10-31 13:09:38 HKT; 14min ago
TriggeredBy: ● snapd.socket

And systemctl status snapd.socket outputs the following:

● snapd.socket - Socket activation for snappy daemon
     Loaded: loaded (/lib/systemd/system/snapd.socket; disabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-10-31 13:09:38 HKT; 15min ago
   Triggers: ● snapd.service

The outputs above indicate that both the service and the socket have been disabled as expected; however, both statuses are still active (running). Why might that be? Is there perhaps some startup script in Ubuntu that ensures that snapd remains running despite being "disabled"?

In case it matters, this was done on Ubuntu 20.10 (in a freshly created VM for testing), though I've first noticed similar behavior on my bare-metal Ubuntu 20.04 LTS installation on one of my older machines.

P.S. I'm actually not too bothered by snapd running in the background and am not aiming to remove it but would just like to know why Ubuntu exhibits this behavior (and whether disabling it for real without removing it entirely is feasible).

Does this answer your question? How to stop snapd from auto-updating? . Or in short use mask instead of disable. — N0rbert, Oct 31 '20 at 19:07
Thanks, that does answer my immediate question. But following the links prompted me to look into it a bit deeper and I would like to answer my own question with my additional findings. — Donald Sebastian Leung, Nov 02 '20 at 04:49

score 8 · Accepted Answer · answered Nov 02 '20 at 05:01

As @N0rbert suggested in a comment, masking the service instead of just disabling it should do the trick.

However, digging into it a bit deeper, I was lead to a post on systemd in Fedora Magazine published back in late 2015, which states that:

Recall that systemd can understand dependencies between units. This means systemd can tell when one unit must be started to allow another to run.

Furthermore, systemd uses this information to start a required service, even if disabled, to satisfy dependencies.

So following this hint, I listed the reverse dependencies of snapd.service and snapd.socket by doing systemctl list-dependencies --reverse snapd (and similarly for snapd.socket), to see which units depended on snapd. It turns out that snapd.seeded.service (which was enabled) depended on snapd.socket. Once I executed

$ sudo systemctl disable --now snapd.seeded

and rebooted, all three units were inactive (dead) as expected.

Disabling snapd with systemctl

1 Answers1