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:
apps:
webserver:
command: run-webserver
daemon: simple
plugs: [network, network-bind]
sockets:
web:
# this could also be a path if we want a unix domain socket
listen-stream: 8000
… 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.