Re:Structural and semantic deficiencies in the systemd archi...
by skarnet on Sunday October 11, 2015 @10:21PM
(#10372182)
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?
[ Parent
| on HN ]
Re:Structural and semantic deficiencies in the systemd archi...
by vezzy-fnord on Sunday October 11, 2015 @10:47PM
(#10372249)
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.
Re:Structural and semantic deficiencies in the systemd archi...
by skarnet on Monday October 12, 2015 @06:24PM
(#10377265)
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? ;)