On Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote:
> On Sat, 13 Jun 2015 10:37:19 +0100
> KatolaZ <kato...@freaknet.org> 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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
