Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1278919

Bug#1124643: s-s-d: honour --notify-await when --background not used

Cross-posted to 2 groups.

Show all headers | View raw

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!

Back to linux.debian.bugs.dist | Previous | Next | Find similar

Thread

Bug#1124643: s-s-d: honour --notify-await when --background not used Andrew Bower <andrew@bower.uk> - 2026-01-18 20:30 +0100

csiph-web