Restart condition not respected for "oneshot" systemd service

snapcraft
1

Pretty simple: I have a snap with

restart-condition: on-failure

in its snapcraft.yaml (specifically, https://github.com/ammpio/ammp-connect/blob/master/snap/snapcraft.yaml#L26)

Yes when it’s installed, the systemd service file for the corresponding unit states

Restart=no

which is obviously not what I want (and not in line with the behavior described in https://snapcraft.io/docs/services-and-daemons).

Any ideas what’s going on? I checked the build log (I’m using the snapcraft build service for this) but there was no mention of this there. Maybe just a bug?

2

sounds like a bug to me … i know for sure that restart-condition: always definitely seems to get transferred into a resulting unit:

ogra@ubuntu:~$ grep Restart /etc/systemd/system/snap.kodi-pi-standalone.kodi-pi-standalone.service
Restart=always
ogra@ubuntu:~$
3

This seems to be a planned behavior of snapd back from:
https://github.com/snapcore/snapd/commit/41b3422d67b06c343317c4b74b4d5b2c0cc1b59e

More details should be in the LP bug listed in the commit or https://github.com/systemd/systemd/issues/2582 (though I’m getting 501 from github when trying this one).

4

well, then it is still a documentation bug, https://snapcraft.io/docs/services-and-daemons says:

* restart-condition
  Defines when a service should be restarted, using values returned from systemd service exit status.
  Can be one of [on-failure|on-success|on-abnormal|on-abort|on-watchdog|always|never].

(it should warn about oneshot being special)

5

Thanks for helping out!

Yes, I see the comment there

any restart condition other than “no” is invalid for oneshot daemons"

And from what I can tell this isn’t really the case any more. Funnily, one of the links to the systemd issue deals with setting up a WireGuard tunnel (Wireguard - waiting for DNS before trying to start the interface · Issue #30459 · NixOS/nixpkgs · GitHub), which is exactly my use case here also.

I suppose it would be good to get this straightened out. In the meantime I guess I’ll just work around with a retry loop in the shell script itself.

6

Also FWIW I did just manually set Restart=on-failure in my systemd unit file, which led to a bad-setting error (Debian buster). So the snapd behavior does actually appear fairly reasonable.

7

Yes in order to enable specifying Restart=<anything-other-than-no> for oneshot daemons, we need to effectively check what version of systemd is on the system, and if it’s a new enough one, then allow through the setting, but if not then use Restart=no.

Could you file a bug at bugs.launchpad.net/snapd so we can track this?

8

Yup, filed here: https://bugs.launchpad.net/snapd/+bug/1915337