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.
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.
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.
@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.
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
I will try, thank you!
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
?
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.
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
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.
Milestoned for 2.36:
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?
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.
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.
I really like the “requires” naming. Makes things nice and clear.