transition from systemd to snapd breaks functionality

note that this is not reproducable on any machine i tried, as described in:

https://forum.snapcraft.io/t/have-a-snap-be-run-only-when-started-manually/20493

The mechanism to manually start disabled snap services seems to work just as it should (and given how many snaps in IoT use such a setup (disabling services after install from a hook and starting them from some master daemon snap on demand) there would be quite an outcry if it failed):

$ sudo snap stop --disable lxd
Stopped.
$ sudo snap start lxd
Started.
$

on a side-note the apport data above points to a manually modified conffile in /etc/sudoers.d/99-snapd.conf, this contains the default PATH settings for sudo when dealing with snaps, did you modify it on purpose ... ?

That's what it looks like here (the 20.04 machine I sent the bug report from):

# snap start lxd
error: cannot perform the following tasks:
- start of [lxd.activate lxd.daemon] (# systemctl start snap.lxd.activate.service snap.lxd.daemon.service
Failed to start snap.lxd.activate.service: Unit snap.lxd.activate.service not found.
Failed to start snap.lxd.daemon.service: Unit snap.lxd.daemon.service not found.
)
- start of [lxd.activate lxd.daemon] (exit status 5)

# snap list | fgrep lxd
lxd 4.6 17629 latest/stable canonical* disabled

But

# snap enable lxd
lxd enabled

# snap start lxd
Started.

So my 20.04 machine is definitely unable to start a disabled LXD snap.

> # snap enable lxd
> lxd enabled

could it be that you disabled the whole snap instead of just the daemon in the snap (i think then it is indeed expected that the systemd units go away) ?

you need to use "snap stop --disable lxd" to disable the service, not "snap disable lxd" which takes the whole of the snap out of function and disables all connections into the system (i.e. service units).

Ah, yes.

When looking for a solution I ran onto some ubuntu answers page which claimed that snap stop --disable is the same as snap stop + snap disable.

And the snap manpage I've read is not explicit about the fact that there's two different sorts of 'disabled', that disabling the snap and disabling daemons are different things.

The manpage explanation for snap disable and snap stop --disable are slightly different, but

"Disable a snap in the system. The disable command disables a snap. The binaries and services of the snap will no longer be available..."

and

"As well as stopping the service now, arrange for it to no longer be started on boot."

do not reveal that these are different things, it just looks like some sloppy short version.

It's not obvious from the docs, that there's two functionally different "disabled" states.

Btw., snap list should show both disabled states.

yeah, i agree, the docs could be better here ... the output of "snap stop --help" and "snap disable --help" do show similar text ...

to see the (en/disabled) state of any snap based services you can use the "snap services" command ...

does using snap stop solve your issue though ?

Well, seems so. I will reliably know it after upgrading, but for the moment I don't see any obstacle anymore.

Thanks for helping.

Maybe turn this into a documentation / argument naming bug.

Ahm, yes, there's another problem, but completely different one.

The upgrade procedure vom 18.04 to 20.04 converts LXD images from the old debian based LXD to the snap based LXD and thus from /var/lib/lxd to /var/snap/lxd/common/lxd and thus out of the encrypted directory.

I'm not sure whether it causes any trouble with LXD or snap to mount an ecrypted file system to /var/snap/lxd/common/lxd or
/var/snap/lxd/common

and whether I could do it before upgrading to avoid data beeing copied to non-encrypted disks.