> Andy, one more observation: I'd think twice about letting the systemd > project set your expectations for init system requirements. They use > cgroups for certain things, and advertise that as a great benefit. It's > not. They make up the term "socket activation" and advertise that if > an init system doesn't have it, that init system is ineffective. This > is false. Follow the money: Plenty of people benefit from systemd > displacing all other init systems, even if systemd is ineffective or > effective only as long as programmers are given a million or so dollars > a year to keep it running despite its crushing complexity. Do not let > the systemd talking points influence the features YOU want in an init > system.
It's quite difficult not to get phased by something that's been all the talk for some years now. The pressure from the so-called majority is strong after all... I personally prefer very minimalist approaches to init and system process supervision, much like the ones used by CRUX Linux. However, I do understand that bare Shell scripts are difficult to maintain and proper supervisors are "there to be used". That's why these discussions, tons of reading and a newly kindled fancy for runit and s6. For my personal use it's enough that runit manages the most essential system daemons so that I don't have to call "shutdown" or "reboot" from a terminal emulator :P. For testing the bare essentials, Gentoo serves me quite nicely. With USE flags I have a good idea of what features are needed by which programs. Best regards, Andy On 11 October 2016 at 18:15, Steve Litt <sl...@troubleshooters.com> wrote: > On Tue, 11 Oct 2016 11:53:38 +0200 > Jan Bramkamp <cr...@rlwinm.de> wrote: > > > > Runit doesn't track dependencies directly, but it can handle them. > > This is done by calling sv start $DEP_1 $DEP_2 etc. in the ./run > > script. > > I've always done it differently, as shown in this run script: > > ================================================ > #!/bin/sh > if test_of_readiness_of_dep1; then > exec this_daemon > fi > sleep 1 > ================================================ > > So if $DEP_1 isn't ready, $THIS_DAEMON waits a second and then fails > and is soon tried again. For a dependency that takes huge amounts of > time, like dhcpcd, that sleep might be 15 instead of 1. > > Your method is obviously more efficient and straightforward than mine. > My method theoretically could act like a bunch of ping pong balls on a > bunch of set mousetraps, although in practice I've never seen any > evidence of that. Your method sets off dependencies consecutively > rather than trial and error, and would seem to be superior, with two > exceptions: > > 1) My method can be used to test for any arbitrary definition of the > dependency being "ready". For instance, my sshd service could run > only after a successful ping of 8.8.8.8 or of google.com, thereby > proving the network is up all the way to the Internet. This is much > more specific than merely testing whether the networking system is > running. > > 2) My method refuses to run $THIS_DAEMON if $DEP_1 is not functional, > rather than starting $DEP_1 and assuming it will start correctly, > instantly. My method refuses to run a daemon when its dependencies > have serious problems. > > I'm wondering if our methods could be combined: > > ================================================ > #!/bin/sh > sv start $DEP_1 > sleep $APPROPRIATE_SECONDS > if test_of_readiness_of_dep1; then > exec this_daemon > fi > sleep 1 > ================================================ > > In the preceding, $APPROPRIATE_SECONDS is probably a small fraction > like 0.1: Just enough time for $DEP_1 to become ready to do its job. > > SteveT > > Steve Litt > September 2016 featured book: Twenty Eight Tales of Troubleshooting > http://www.troubleshooters.com/28 > > >