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

[Lennart Poettering]

On Sat, 14.12.13 14:19, Shawn Landden (shawn at churchofgit.com) wrote:

> It would be nice if systemd could implement the service supervisor
> side of the service readiness protocol that upstart calls "expect
> stop":
> 
> The service doesn't fork, and when considers itself ready it raises
> SIGSTOP.  The supervisor can observe this via the usual mechanisms,
> being the service's parent, and when it occurs it sends the service
> CONT and starts whatever was waiting for readiness.

Oh, no. That Upstart SIGSTOP hackery is completely broken. SIGSTOP is
poperty of the admin, the init system cannot just take possession of
that and turn it into something that it really isn't. The admin must be
able to freeze processes when he wants to, and the init system should
not interfere with that and immediately undo it, nor should it get
confused if the admin uses it independently of the init system. Thus,
SIGSTOP is really nothing the init system should touch, ever.

It's similar to Upstart's ptrace hackery: an init system should not take
away functionality that belongs to the admin, and by using ptrace
Upstart makes it unavailable to the admin because there can be only one
tracer per process at a time. On an Upstart system where this is used
you cannot gdb or strace (!!!) the initialization phase of those daemons
anymore.

This is really not how we should do it: the admin must be capable of
tracing and pausing the boot process, and an init system should not make
that impossible. 

> The sd_notify(3) protocol is just about tolerable, and it is good that
> it's documented, but it is quite unattractive for a daemon author:
> Either they have to add a build- and runtime- dependency on a
> systemd-specific library, or they have to reimplement a fairly tedious
> piece of socket code.

Well, to make this more palatable we actually made the code available
under MIT license (i.e. much less restrictions than the otherwise GPL2+
sources of systemd), and made it embeddable so that people can just drop
sd-daemon.c + sd-daemon.h into their sources and forget about
it. sd-daemon.c/sd-daemon.h nowadays even compiles fine on Solaris and
other OSes in order to make this as little cumbersome as possible.

Developers hence have the choice to either link to dynamically, or to
embedd it, if they don't want the dependency. Or alternatively, they can
just reimplement sd_notify(), which is intentionally designed to be as
trivial as it gets. i.e. you just send one datagram containing text to the
socket mentioned in $NOTIFY_SOCKET, that's all. 

Finally, on purpose we actually kept this so simple and left all
systemd-specific identifiers out of the protocols (i.e. it's called
$NOTIFY_SOCKET not $SYSTEMD_SOCKET or so), so that other folks can
implement it too without having to "leak" the name "systemd" into their
sources, in particular to make this easy for Upstart... (they were never
interested though, but at least we can say we tried).

> For a daemon author, raise(SIGSTOP) is lovely and simple.

For an admin raise(SIGSTOP) is just bad. Let's not forget that
developers better write programs that don't make the admin's/user's life
hard... They usually curse at us anyway, but let's not make the most
obvious mistakes by making it impossible to pause processes or tracing
the boot-up phase...

ennart

-- 
Lennart Poettering, Red Hat