Expose a more consistent subset of systemd's service directives

snapd
#38

Work on this feature is already under way. It will be part of the next release or the one after it in the worst case.

#39

Great, I also +1 the request for watchdog support. Currently if a start rate limit has been reached for a service, the service is put in a permanently failed state and no remedial action is possible. I’d love the option to be able to reboot the system under this scenario. Such a feature is particularly important for unattended consumer IoT applications.
The current workaround of editing the unit files through a configure hook during installation obviously breaks confinement as @hcochran has noted.

#40

Took a quick stab at watchdog support https://github.com/snapcore/snapd/pull/4504 It seems that due to security concerns this will require some additional work though.

1 Like
#41

Is there any branch with these systemd improvements (post command, start timeout…)?

#42

Came here to ask the same; is there a rough timelines set for implementing these? Took a look at The snapd roadmap but this doesn’t seem to be mentioned on there.

#43

We’re still working on these improvements, and pieces have been frequently landing. We got before and after in, and @mborzecki is now working on service timers which I’m really looking forward to having as well.

It would be nice to tackle starts-with and friends next, but if the lack of something else is blocking you, please let us know the details and we might change the priorities.

#44

Just curious on status ie any follow up to @svet and @ribalkin? Thanks!

#45

FYI, service watchdog support has landed in master. The service can specify desired watchdog timeout by adding watchdog-timeout property in its declaration:

name: foo
version: 1.0
apps:
  i-want-watchdog:
    command: bin/app
    daemon: simple
    watchdog-timeout: 1s
    restart-condition: never
    plugs: [daemon-notify]

As the watchdog is actually driven/tracked by systemd, the service needs access to systemd’s notification socket. This access is provided by daemon-notify interface, which needs to be listed in the plugs section. Since there were some reliability related incidents regarding the notification socket in the past, the interface is not auto connected and needs connecting manually.

The snapd roadmap
#46

@mborzecki, hi!

Is that setting supposed to be used in snapcraft.yaml?

I added watchdog-timeout setting to an app and snapcraft started to fail with the following error:

Issues while validating None: The 'apps/ping' property does not match the required schema: Additional properties are not allowed ('watchdog-timeout' was unexpected)

snapcraft version is 2.42.1.

#47

You may need to use passthrough until snapcraft learns about the new setting. Eg:

apps:
    ping:
        command: foo
        daemon: simple
        plugs: [daemon-notify]
        passthrough:
            watchdog-timeout: 10s
1 Like
#48

I will try, thank you!

#49

Any idea when the before / after keywords for ordering services (from Service ordering) will land support in snapcraft so we don’t have to use passthrough?

#50

I never saw a link to a PR for before/after. Any idea what snapd release contains it? Multi-project bugs are the way to go for this type of coordination.

2 Likes
#51

Looks like the PR’s that merged that specifically were https://github.com/snapcore/snapd/pull/4373 and https://github.com/snapcore/snapd/pull/4357 which I think means it went into 2.31

#52

Is there any update on the restart-delay feature @mborzecki ? Currently we have an ugly hack where we create a shim that sleeps before starting the service proper.

#53

Milestoned for 2.36:

2 Likes
#54

While we’re waiting for start-timeout, do you have an advice on a workaround?

I’m troubleshooting an issue in microstack where the install fails due to openvswitch taking too long to start. It looks like others have run into a similar issue and solved it by setting the Timeout property in the relevant systemd .service file.

What’s the best way to do something like that, currently, in a snap?

#55

It’s been a while, but I’ve been thinking of “starts-with” and “stops-with” for reasons unrelated to snapd, and I think the more natural form is actually “start/stop-with”. We have several options with “start-”, “restart-”, etc, prefixes already.

#56

Actually, both of these options have the issue of their directionality being unclear. After a conversation with Michael and Samuele, we’ve settled on “requires” as the term, as it’s well known and expresses well the direction of the dependency. This allows the case of service A starting whenever B runs, but A can also start without B, which is the most natural scenario that shows up in service dependencies.

#57

I really like the “requires” naming. Makes things nice and clear. :slight_smile:

1 Like