On Fri, 12 Jun 2015 17:31:10 +0100
Matthew Melton <mjm@???> wrote:

>
>
> ---- 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

Hi Matt,

I don't know. How's that for an authoritative answer?

The one thing I *do* know is that we need to provide a sd_notify
interface, even if it does nothing at all and drops passed information
on the floor.

Later, if we decide to actually *use* the info sent us via sd_notify, I
don't know whether the proper venue for that use would be logs or
something else. Personally, I'd really prefer we *don't* use dbus for
these notifications. I know that's theoretically what dbus is for, but
I don't trust dbus as far as I can throw the rocky mountains.

I'm at a disadvantage here because the only process management I really
understand is daemontools and daemontools-encore.

SteveT

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