Restart condition not respected for "oneshot" systemd service

Pretty simple: I have a snap with

restart-condition: on-failure

in its snapcraft.yaml (specifically,

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


which is obviously not what I want (and not in line with the behavior described in

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?

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

This seems to be a planned behavior of snapd back from:

More details should be in the LP bug listed in the commit or (though I’m getting 501 from github when trying this one).

well, then it is still a documentation bug, 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)

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 (, 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.

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.

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 so we can track this?

Yup, filed here: