---- Steve Litt wrote ----

> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Could a convention be to use the logs to notify any listeners that the service has been successfully started? Since most services use the logs anyway would it be trivial to have a /var/log/running log?

A scripted dependency can check the log using grep or whatever. Before starting. No need for another binary.

A bit like how fail2ban does its magic...

I'll go back to lurking.

Matt