> 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 <slitt_at_troubleshooters.com> wrote:
> On Tue, 11 Oct 2016 11:53:38 +0200
> Jan Bramkamp <crest_at_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
>
>
>
Received on Tue Oct 11 2016 - 19:24:27 UTC