[Pkg-systemd-maintainers] Bug#732157: Bug#732157: Want SIGSTOP-style daemon/service readiness notification

[Ian Jackson]

Michael Stapelberg writes ("Re: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification"):
> control: forwarded -1 https://bugzilla.redhat.com/show_bug.cgi?id=833105
> control: tags -1 + upstream wontfix
...
> thanks for your mail. This feature request was already raised upstream
> and upstream decided to not implement it. Please see the provided URL
> for more details.

I'm afraid I find upstream's response there unconvincing.  Do you
think you might be able to persuade them ?  What would your view be as
the Debian maintainer, supposing I were to supply a patch to implement
the feature - would you be willing to carry the patch ?


In case it's helpful I'll respond to upstream's comments there in
detail:

Lennart Poettering:
> SIGSTOP is a mechanism for stopping processes, not for notifying
> service readiness. We shouldn't attempt to overload OS functionality
> like this, as SIGSTOP might happen for it's real purpose too.

This seems far-fetched, certainly during daemon startup.  Overloading
it for this purpose seems elegant to me.

> I also fail to see in which way:
> #include <signal.h>
> raise(SIGSTOP);
> 
> was any simpler than this:
> #include <systemd/sd-daemon.h>
> sd_notify("READY=1");
> 
> And people can just use the .pc file to add libsystemd-daemon to their build, so that's dead easy.

This of course doesn't answer the question about the build- dependency
(which as Enrico notes probably involves additional configure tests
etc.)  Speaking as the author of a daemon, it's really quite
unattractive.

You (Michael) half-suggest copying libsystemd-daemon's daemon.c into
the package source tree, but of course this is (as you evidently
recognise) not a very good idea.  We should be recommending something
good.

> Another big problem with raise(SIGSTOP) is that if done on an init
> system that can't handle it will result in a freeze. OTOH
> sd_notify() handles this gracefully and just becomes a NOP.

It seems to me that this would be handled by running the daemon with
an argument so that it knows what to expect.  By default it will
probably call daemon(3), after all, and there'll have to be a way to
tell it not do that.  So I don't think this is a realistic problem.

Thanks,
Ian.