That’s weird. Is it specific to RPiOS installs? I’ve used snapctl in other install hooks and never seen a problem.
well, it works fine on a 20.10 install, using the same snapd version … my guess would be it might be related to PiOS only using partial confinement and perhaps a race due to that … there is no harm moving the hook to be configure instead of install though …
@alan_g ll get back to you once I get off of work and get those results back to you. Thanks for everything!
Here are a couple tests… hopefully this is what you are looking for.
pi@raspberrypi:~ $ sudo snap get scummvm
error: snap “scummvm” has no configuration
pi@raspberrypi:~ $
I’m wondering if you meant “snap install scummvm”:
pi@raspberrypi:~ $ sudo snap install scummvm
error: cannot perform the following tasks:
- restart of [scummvm.daemon] (# systemctl restart snap.scummvm.daemon.service
Job for snap.scummvm.daemon.service failed.
See “systemctl status snap.scummvm.daemon.service” and “journalctl -xe” for details.
)- restart of [scummvm.daemon] (exit status 1)
pi@raspberrypi:~ $ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1920x10 80M@60 smsc95xx.macaddr=DC:A6:32:A7:4D:75 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115 200 console=tty1 root=PARTUUID=1332799d-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
pi@raspberrypi:~ $ sudo snap set scummvm daemon=false
- sudo snap set scummvm daemon=false
error: snap “scummvm” not found
let me know if there’s any other reports you need me to run, I have access to do them tonight.
@OldKid I don’t think there’s anything you need do at this point. I hadn’t read up far enough to see that the install itself was failing.
The install fails because snapd is not allowing use of snapctl in an install hook, something I’ve not seen on other platforms. This is something that needs fixing either in snapd, or by working around it (by the snap author). As there are other snaps that use snapctl in their install hooks the former is to be preferred. (@ogra has asked about this problem on the snappy freenode channel, but I’ve not seen a response yet.)
[Correction]
Actually, reading the OP, it seems that it is the scummvm.daemon task that is failing during install, not the install hook . So moving the logic from the install hook won’t help.
while this is true, the turnaround time for a fix in snapd is usually at least 4 weeks, fixing it (temporarily) on the snap side is quicker and can be rolled back once the real fix landed in snapd …
(especially at the dawn of christmas and probably a good amount of people having as pi400 under the tree it might be good to have a fix earlier 
)
@ogra someone with access to the device needs to work on this and propose a fix. It is far from clear to me how to work around this.
cd snap/hooks
git mv install configure
echo "snapctl restart snap.scummvm.daemon" >> configure
cd -
git commit -am "fix install on PiOS"
git push
You’ve tested that? Because the OP says that scummvm.daemon is what fails (presumably in daemon-start.sh)
@lotharsm are you listening? We may have a fix here.
not yet, but i know the configure hook runs after the install one and before services get started (if it doesnt, we found another bug 
)
It appears that the service starting failing that fails the install. So I’m not convinced that this would help. But I have no device to test on.
well, the error message indicates it fails before it starts the daemon (by definition install hook should run before daemon starts)
Dez 07 11:54:01 raspberrypi scummvm.daemon[2935]: error: error running snapctl: snap "scummvm" has "install-snap" change in progress
(there is no other hook in the snap that runs snapctl)
Maybe I’m misreading, but this suggests that this is when it starts the daemon
In any case, please confirm it works and then tell the snap owner what is needed.
the hook issue might not be fatal (i guess it doesnt exit nonzero when it cant call snapctl) but resulting in the daemon to being started (due to the missing snap setting) which then fails the install …
This is false the configure hook has always been run after services get started
argh, sorry then … so this isnt a potential quick fix indeed
The hook is executed before starting snap services (if it has
any) and before the configure hook.
i kind of mis-read this text as “install hook -> configure hook -> start daemon”, perhaps we could improve the doc a little here to make it clearer (from the description of the install hook on https://snapcraft.io/docs/supported-snap-hooks ) or add a similar line to the description of the configure hook telling that it always starts after services.
I’ve reproduced the issue in a focal VM and I think it has been understood (and discussed on IRC), for the record this is my log: https://pastebin.ubuntu.com/p/ktRYVjdndZ/
The main problem is that bin/daemon-start.sh runs snapctl stop .. to stop the service while at the same time snap is getting installed and snapd currently blocks potentially conflicting snapctl operations “from the outside” (in this case it is systemd restarting the daemon) affecting same snap. This wouldn’t be a problem if called directly from the hook.
For this specific case, as discussed on IRC, the best solution is to use snapctl stop --disable ... from the configure hook.
Also, a related observation - this snap currently calls snapctl get .. from the install hook, such logic should live in configure hook because install hook is only run once on initial installation of the snap when by definition snap has no configuration. Also, when done in configure hook, the snap can react to any snap set .. changes done by the user. Although AFAIU this logic won’t be needed at all once snapctl stop --disable is used.
2 Likes
There’s a lot of misleading comments above, some of them mine. So here’s what I now understand:
Calling snapctl stop ... from a daemon may conflict with the snap being installed. That is detected snapd and problems ensue. Whether there is an actual conflict depends on system, timing and luck.
@lotharsm I now understand the problem and solution. I’ve worked through it with one of my snaps and will get a scummvm PR together once I’ve a successful build of the snap. (May not be before my EOD)
[Update]
I’m getting linker errors building the snap, so won’t be today.
1 Like
Thank you very much for working on this! Unfortunately, the Pi I ordered is still due for delivery, so I can’t test it on my own.
Obviously, any incoming pull requests are very welcome
1 Like