By making use of the
after directive from Expose a more consistent subset of systemd's service directives we’re able to set a service app to run after another app that’s defined in the same snap
Is there a way to make the dependency be with respect to a service that is not in the same snap? E.g. provided by a different snap, or just any systemd service - the name of which is known.
I appreciate this may lead to issues given that there’s no guarantee that the called-for service is actually installed, but would be great to know of any way to potentially do this.
There is no way to use
after to specify ordering relative to anything outside of your snap.
One option to get cross-snap ordering is to make use of socket activation. For example, imagine we have one snap defining a daemon like so:
plugs: [network, network-bind]
# this could also be a path if we want a unix domain socket
… where the web server adopts the already opened sockets with
sd_listen_fds() (or the equivalent from whatever language it is written in).
If a second snapped daemon tries to connect to port 8000, it will block while the first service starts up and gets to a point where it can accept the connection. This means we don’t actually care which order the servers are started up, since systemd will ensure the dependency is started at the point where it is used.
Thanks @jamesh for the prompt advice! That’s an interesting workaround.
In my case the “first” service (from another snap) provides an API endpoint, I and the second service makes some calls to that endpoint. So the workaround I’ve got at the moment (for the second service) is to simply attempt a test call until is succeeds, and then proceed once it does (i.e. once the first service is up).
If you’ve got any influence over that other snap, having them convert to use socket activation certainly sounds like it would fix the ordering problem.