snap update causes disabled maas systemd service to start again

[Trent Lloyd]

If you stop/disable the systemd service for the MAAS snap, an automatic snap update or snap refresh causes it to start again - though it still shows as disabled.

I would expect the snap to maintain the disabled/enabled state of the service and ideally also the currently stopped/started state of the service.

During a maintenance period, etc.. an automatic snap update could happen at any time even in a small window of expecting systemctl disable/stop to work.

= Reproduction steps =

snap install maas --stable
systemctl disable snap.maas.supervisor
systemctl stop snap.maas.supervisor
systemctl status snap.maas.supervisor
snap refresh maas --edge
systemctl status snap.maas.supervisor

= Example output =

● snap.maas.supervisor.service - Service for snap application maas.supervisor
     Loaded: loaded (/etc/systemd/system/snap.maas.supervisor.service; disabled; vendor preset: enabled)
     Active: active (running) since Wed 2020-03-25 09:29:13 AWST; 25min ago

[Trent Lloyd (lathiat)]

I would also argue that a snap update should not start a stopped service. I think dh_systemd also attempts to handle this though I might be wrong.

[Trent Lloyd (lathiat)]

You also cannot mask a service because snapd appears to be writing the service directly to /etc/systemd instead of into /lib/systemd, so systemctl can't add a mask override.

Filed as a separate bug:
Bug #1868909 systemd units should not be placed in /etc/systemd (cannot mask a service) Edit

[Ian Johnson (anonymouse67)]

Trent, what version of snapd are you using? What's the output of `snap version` ?

[Ian Johnson (anonymouse67)]

This is not a snapd bug because the post-refresh hook in the maas snap has this:

```
# ensure that services are running as migration needs running postgres
snapctl start "${SNAP_INSTANCE_NAME}.supervisor"
```

If you refresh the snap without this snippet in your post-refresh hook, then the service will be stay disabled across refreshes. If you want to check if the service is running from your post-refresh hook, you can use `snapctl services`.

[Trent Lloyd (lathiat)]

Thanks Ian re-targeting the bug to MAAS, updated the description to match.

Note that this is tangentially related to Bug #1803212 which is for the behavior of "snap restart" and similar to not take action when the service is disabled.

[Alberto Donato (ack)]

@Trent

FTR you can control snap services via "snap (start|stop|restart)", rather than interacting with individual systemd units.

snap stop --disable will also disable all of them.

[Björn Tillenius (bjornt)]

Seems like the fix wasn't the right one. Now when I tried to refresh from 2.7/stable to 2.7/edge, the post-refresh hook fails, since postgres isn't running. By the looks of it, snapd stops the services before calling the post-refresh hook.