On Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote:
> On Sat, 13 Jun 2015 10:37:19 +0100
> KatolaZ <katolaz@???> wrote:
> > 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....

Quite honestly, it really *does* matter to me that I can boot Alpine
Linux on my netbook in ~5 seconds rather than the ~10 seconds it takes
using LFS-based init scripts on my built-from-scratch system.
It really is nice to be able to grab it, press the power button, and
have it ready to use by the time I get downstairs; the old 45-second+
boots were rather awkward for conversations where some online document
was enquired about.

Alpine is OpenRC+busybox init; the built-from-scratch system is
musl/busybox/sysvinit/LFS bootscripts, but I've thought about reverting
to busybox init and doing a simpler rc script that does what I need.

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

Maybe if you have a print server?

For a moment, I thought "minutes to be processed" was ridiculous
hyperbole; I use a laser printer that gets ~20 pages per minute.
(I had a *lot* of papers to write and print in college.)

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

man 8 dhclient:
    -sf <script-file>
    Path to the network configuration script invoked by dhclient
    when it gets a lease. If unspecified, the default
    /sbin/dhclient-script is used.

Busybox udhcpc and toybox dhcp use "-s" for this.

You could use the script to start the network tools directly, or write
some indicator that lets the process manager start spawning network
programs.

HTH,
Isaac Dunham