Steve Litt <slitt@???> writes:
> Rainer Weikusat <rainerweikusat@???> wrote:
>
>> Continue the fine practice of uniformly starting and stopping
>> everything at a default policy of "20", IOW, in parallell. Software
>> is supposed to solve technical problems, not to work around people's
>> mental deficiencies (such as the inability to understand that 'X was
>> true a second ago' doesn't imply anything about 'X' right now or at
>> any other time in future).
>
> [snip]
>
>> > * A separate new file containing the LSB definitions - which to a
>> > certain extent is just adding more cruft, but in a separate file.
>>
>> I consider this a much better idea for implementing such a system.

[...]

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

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

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.

[...]

> In other words, from my experience with Runit, over 95% of our
> discussions about dependency, and when to declare a depended-upon
> process actually running, and how a daemon can notify its init system
> that it's now functional, is purely academic.
>
> This is one of the reasons that Runit ./run scripts are so short and
> understandable.

'Dependency information' is something like '5 lines per script'. While
it should be in these scripts and it shouldn't exist to begin with (see
above), that's a negligible part of a typical init script. The bulk of
an init script is usually code people consider necessary, just as they
also consider 'topological sorting on start' necessary. Some of this
code may actually be good for something. In this case, it ought to be
turned into a real program (possibly a script) which is invoked by name
with certain arguments, as one would usually call a function (that's
another ages-old software design principle [functional decomposition]
which is also generally ignored by wepp devsloppers and other people
whose image of the themselves is "the guy who gets shit done").

A typical init script I'm using looks somewhat like this:

-------------
#!/bin/sh
#
# establish ssh/vtun based VPN to jones machine
#

PATH=/usr/local/sbin:/sbin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
export PATH

case "$1" in
        start)
                printf 'Starting jones VPN: ' >&2

                daemon chdir / monitor -n avpn ssh-vpn mes-pgsql 5001:5001 jones jones2

                printf 'jones\n' >&2
                ;;

        stop)
                printf 'Stopping jones VPN: ' >&2

                monitor-ctrl avpn stop

                printf 'jones\n' >&2
                ;;

        restart)
                $0 stop
                $0 start
                ;;

        *)
                printf 'Usage: jones-vpn start|stop|restart\n' >&2
                exit 1
                ;;
esac

exit 0
-------------

I'm planning to get rid of the double printf as soon as I have the time
(can become another tool). This could be abstracted further but at some
level of simplicity, copy'n'paste really is the method of choice.