On Sat, 13 Jun 2015 10:37:19 +0100
KatolaZ <katolaz@???> wrote:

> On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote:
>
> [cut]
>
> >

> >     The question now is who will develop, maintain and package this
> > wrapper? Will Devuan be the official developper of
> > "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who
> > else to take the job? Or are the daemon's developper powerfull
> > enough to tell RH "do it yourself."?

> >
>
> I think there is another, more fundamental question: do we really need
> to know in *real time* when a service/daemon is ready for its job or
> has done what it is supposed to do? AFAIK all this fuss with
> "daemon-readiness" began with the first attempts to have parallel boot
> sequences, which is something that is still *useless* in 95% of the
> use cases: servers don't get restarted evey other minute and "normal"
> users who don't use suspend can wait 30 seconds to have their desktop
> ready, what else? Embedded systems? Well, they usually have just a few
> services running, if any....
>
> What are we really talking about? Isn't this just another
> feature-for-the-feature's-sake-thing? Why should I bother to allow
> cups signalling immediately that it is ready to put my printouts on a
> queue that will anyway need minutes to be processed?
>
> My2Cents
>
> KatolaZ
>

Good questions, all.

In my opinion, this is a legitimate issue, not an attempt to match
another systemd marketing feature (magnesium paddle shifter).

KatolaZ, I just got done converting Plop Linux to init with a
combination of Suckless Init (for the
PID1/interrupt_listening/shutdown_instantiation) and daemontools-encore
for the process management. I have a daemontools service running
dhclient in the foreground (like all daemontools managed daemons). As
you know, dhclient takes between what, 3 and 20 seconds to get an IP
address, so in my LittKit ordered startup script, I have a loop to
detect when there's an IP address, and stall til one appears.

If dhclient had seen fit to inform us of a DHCP lease aquisition in a
way other than backgrounding itself (a feature I don't use because
within daemontools I run the program in the foreground), I could have
detected that. Or possibly written LittKit to afirmatively kick off a
process when all its dependencies are met (and you would be right: that
would be more than is necessary).

I'd hate to have a boot where an outlier dhclient took 50 seconds to
acquire a lease, and all sorts of network-dependent daemons got spawned
in the meantime.

SteveT

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