On Wed, Jan 07, 2026 at 03:04:41AM +0100, Guillem Jover wrote: > On Sun, 2026-01-04 at 20:45:50 +0000, Andrew Bower wrote: > > If you specify --notify-await thinking that it will enact the systemd > > readiness protocol on a daemon you will be disappointed unless you > > also specified --background. > > > > It would be nice if the notify socket was created, passed on and used > > in all cases where --notify-await was specified, not just when > > start-stop-daemon is also doing the daemonisation. I would rather not > > degrade to using --background when a daemon can already self-daemonise > > satisfactorily in order to use this option. > > I don't see how s-s-d could do that when it's not under --background, > because then it cedes control over the executed daemon, and that will > not know what to do with the passed notify socket.
I would have expected this to be achieved with a single fork, wait on child and then wait on the socket if the child exited with return code 0. I suppose that's not much different from doing the full double-fork` daemonization so perhaps there's not much advantage in not just using s-s-d's backgrounding option. In principle, with all things being equal, I would prefer to use the daemon's built-in daemonization code, which does not in principle preclude also performing notify-await, by the method I mentioned, and has the advantage of supporting an early non-zero exit. However, I accept this is now a triple-fork which is a bit ugly in its own right and for limited benefit. Sorry I did not reply sooner - I wanted to take a look at the code for the use case I had in mind (elogind) to see if there were any obvious pros or cons to preferring its built-in daemonisation. I don't think they are so I will probably propose some integration that uses s-s-d's --background option instead of the daemon's own, as I think --notify-await would bring a tangible benefit for dependant services. > > The man page does not make it clear that this is the situation and I am > > sure I have already deployed this option somewhere uselessly having not > > checked the failure case to make sure it was actually effective, so that > > aspect is not so much 'wishlist'! > > Right, I've added consistency checks for the ineffective option > combinations (--notify-timeout w/o --notify-await and --notify-await > w/o --background), where it will error out. > > I'll also try to improve the documentation to make this more explicit. > > Will be part of my next push targeting the next dpkg release. Thanks for uploading a version that clarifies the situation!
