transition from systemd to snapd breaks functionality
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Hi,
I currently can't upgrade a server machine (not the one this report is coming from) from 18.04 to 20.04 since snapd breaks a required functionality.
Under 18.04 I was running LXD on an encrypted file system, where virtual machine root file systems are kept encrypted. After booting the machine I need to login, enter password to uncrypt, and then start LXD once its /var directory with the containers is available. After discussing this requirement with the ubuntu LXD maintainers, I set all LXD systemd units on disabled and can easily start them once the encrypted file system is online. This is possible, because systemd allows to start a disabled service (without enabling it, thus at next boot time again, it waits to be started manually).
Under 20.04 LXD is not available as a debian package/systemd unit anymore. I just comes as a snap.
snapd also has enable/disable and start/top.
But then snapd differs from systemd in that you can't start a disabled snap without enabling it.
Thus, once LXD is started as a snap, it will automatically start at next boot. There is no manual start (without manual stop). If it runs, it will automatically run after reboot.
In general, it's not possible to have a snap only started and run manually, because it must be enabled to run and thus will run automatically.
Degrade in functionality.
Regards
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: snapd 2.46.1+20.04
ProcVersionSign
Uname: Linux 5.4.0-48-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: LXQt
Date: Sun Oct 18 23:27:31 2020
InstallationDate: Installed on 2020-06-12 (128 days ago)
InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)
modified.
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 ... ?