On Fri, 22 Jan 2016 13:53:30 +0000
Rainer Weikusat <rainerweikusat@???> wrote:

> Steve Litt <slitt@???> writes:

> > First, about LSB: I haven't needed it at all while initting from
> > Runit. Your start code goes in the ./run script, and if you have to
> > do something special when stopping, which you usually don't, that
> > code goes in the ./finish script. There's no restart code: restart
> > is simply sv down myprocess;sv up myprocess, and any finish script
> > and the run script get run at the appropriate time.
>
> ... and in case 'start' and 'stop' script need to share some
> information, just hack it into both. Simple, eh? Database theorists
> call this "a write anomaly": Since the same information is stored
> redundantly in more then one place, the different copies can (and
> eventually will) diverge (at this point, the mind of the average web
> developer goes "Boom!" because the idea that this could actually mean
> something beyond "boring stuff you have to memoize to pass some
> useless undergrad test and can then happily forget" never crossed his
> mind ...).
>
> It's possible to separate this information out into a third file and
> include it in both start and stop scripts but for simple cases (and
> these scripts should be simple), just using a combined start/stop
> script makes more sense.

Hi Rainer,

I haven't a clue what anything in the preceding two paragraphs means.

>
> > LSB's provides, requires, required_by, before, after, etc is pure
> > genius: I should have thought of it. But my three months of using
> > Runit indicates that it's not really necessary with Runit, even
> > though Runit instantiates respawning processes in undefined and
> > probably random order.
>
> That's pure nonsense because processes are dynamic entities

Exactly *what* is nonsense?

> (they're
> 'alive') whose state changes over time and not files which don't
> modify themselves and whose modification date can be determined by
> looking at file meta-information: The 'make' algorithm makes no sense
> for 'startup ordering': Even assuming a process which reaches a
> "ready to serve requests" state would never stop being ready to do so
> because of external circumstances (which is wrong) and it would
> communicate this to "the holy startup ordering see" (which it
> generally doesn't), it could crash in the next microsecond.

I don't really understand much in the preceding paragraph, but when
processes crash, Runit just restarts them in about a second, and as a
practical matter nothing else crashes or is disturbed. I have no idea
if what I am writing has anything to do with your preceding paragraph.

>
> The way to handle such a situation is not "try to hide it below a heap
> of babble" but accept that this problem cannot be solved in this way:
> Processes requiring services by other processes need to cope with
> those services not being available even if running on single system.
> Insofar they can't, that's a bug which needs to be fixed.

The preceding paragraph makes a good point: If I make a daemon
requiring network connectivity, I should quickly determine whether such
connectivity exists, and exit if it doesn't.

Unfortunately, a lot of daemon authors don't do that, so to some extent
the buck gets passed to the init system.

One wonderful thing systemd did was possess the political power to
force daemon authors to report their state of readiness to the init
system (Type=notify). Unfortunately, that notification method is loaded
up with systemd-isms instead of being something that any supervisor can
read. Laurent Bercot came up with a trivially simple, plain-vanilla
notification system that any supervisor or any daemon could use, but of
course he doesn't have millions per year to force that on daemon
authors, so for now ready-notification remains systemd-only, and
daemontools-inspired inits like Runit are left having to run tests to
deduce the readiness of their dependencies. Which isn't particularly
hard, and in practice is usually unnecessary.

A word about this meme where a daemon stays in the foreground until
it's "ready", and then forks itself. Gimme a dam break: That sort of
kludge might have been necessary in 1985, but it's an atrocity today,
and in my view daemons should never be relied upon to put themselves in
the background: It's just too easy for the init system to do that.

SteveT

Steve Litt
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28