[skarnet]

You seem to dislike the idea of asking for notification support in the daemons themselves. Granted, it's impractical, but it's the only way to avoid race conditions which are rare for most services, but very real for a few programs that may take ages to get ready. How would you address the problem of slow starters without support from the daemons, while keeping a "the dependency graph is always respected" invariant?

[vezzy-fnord]

Right, if the problem is slow starters (say, RabbitMQ), then restoring from an image where initialization has already been complete would resolve it. For more complicated cases where there is a race with acquiring some resource, then a readiness notification mechanism could be supported as a niche feature. I'm still not convinced of it in the general case.

[skarnet]

But how would you go with restoring such an image? It won't be instant, there will still be a window where the service manager is continuing its work but the image hasn't been restored yet. One way or the other, you need a synchronization mechanism, so how would you design such a mechanism without support from the daemon?

You don't need a complicated case to have a race with acquiring some resource. A server opening a socket is providing a resource; clients connecting to that socket are using it. Clients should not be started before the server is listening to the socket. How would you solve this case - are you advocating socket activation by the service manager? ;)