Steve Litt <slitt@???> writes:
> 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":

[...]

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

You recently posted two 'runit scripts' both of which contained code to
set the same environment variables to the same values. Call that "an
inline name-value database" if you like. Any change to the environment
setup now needs to be made twice which opens an opportunity for changing
one copy but not the other.

This could be avoiding by putting this information in a file of its own
and sourcing it from both scripts. Or by using one script for both
tasks.

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

What you just referred to as 'pure genius'.

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

Not really: make (the program) uses a so-called topological sort in
order to determine what files should be re-built in which order in case
of source code changes based on declared dependencies. This works for
building software because source code files are passive: They don't
change on their own. But the same approach doesn't work for working out
a 'startup order' of processes based on declared dependencies because
the state of processes does change, including that they may suddenly
terminate and then be unavailable for some time.

[...]

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

'network connectivity' is not a static property: It may be available
now, no more avaible in two seconds and again available half a second
after that. This means the following scenario is possible

1. Daemon check succeeds.
[internet break down]
2. Daemon tries to do something. What now?

or

1. Daemon checks fails
[internet back up]
2. Daemon exits.

Cursing admin the starts it manually.