Hi all,

When Irrwahn mentioned that cups needed depoetterization, my first
thought was "what in the world does cups need with systemd? And then I
realized the problem.

Like a lot of us, I'm on the supervision@??? mailing list,
where they discuss all things init, mainly from the perspective of
daemontools-inspired inits. For months, literally, the supervision list
has been wringing its hands over the very real problem that, for process
dependency purposes, one must know that process X is not only running,
but ready to handle its business. Knowing process X is running isn't
sufficent, because some processes take a long time between running
and being ready for business. Cough, cough, dhclient, cough cough. I
mean, look at the kludge I use to make sure the network's running before
running sshd, for instance:

======================================
#!/bin/sh
if ! ifconfig | grep "\s*inet addr:"; then
sleep 5
exit 1
fi
exec /usr/sbin/sshd -d -q
======================================

Systemd "offers" daemons the sd_notify(3) call, by which they can
inform systemd that they're ready. I said "offers", because as soon as
a critical mass of daemons have drunk the Kool Aid, it will be about as
much of an "offer" as "Windows certified" is an "offer". In fact, I
fully expect that, before long, daemons will need to become "systemd
certified" to be included in some distros.

The tough thing is, this ready-notification is actually a good idea
that solves a lot of problems and presents a lot of opportunities. It's
just too bad it was "standardized" by an atrocity like systemd. Over
and over again, you can expect every single daemon to become
poetterized as it adopts sd_notify(3).

In the beginning, depoetterization of these daemons might consist
solely of removing package dependencies, but sooner or later
non-optional sd_notify will become manditory for systemd certification.
Why? You know why.

So we play their silly game and code a stub sd_notify, that does
nothing. Or perhaps even better, lists the daemon as ready for business
in some kind of table that init can refer to.

I don't know much about sysvinit, but with daemontools-encore, and
probably runit, it wouldn't be super-hard to have a table of all
services with all of their dependencies, and when all a service's
dependencies become ready for business, the service is run
affirmatively. This is probably what systemd had in mind in the first
place: Too bad they had to tack on all the other crap.

So, if we code up a dummy sd_notify to interface replace the one from
systemd, we can make ongoing future depoetterization easier, and very
possibly give ourselves a better, easier to administer init.

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key