- I'm using a wireless Logitech USB keyboard which acts just like an
unreliable datagram service, ie, it loses, reorders or duplicates
keystrokes whenever it feels like that (wired version of the same
model is no better) -

Didier Kryn <kryn@???> writes:
> Le 18/02/2016 18:05, Steve Litt a écrit :

[...]

>     I probably mixed with the explanations of Laurent in his
> motivations for s6 (http://skarnet.org/software/s6/why.html). I quote
> the paragraph under the title "Supervision suites should be bug-free,
> lightweight and easy to understand.":

>
> <<System V init is understandable, and reasonably lightweight; but it
> is still too big for what it does - poorly. The /etc/inittab file
> needs to be parsed; that parser has to be in process 1...>>

But the /etc/inittab syntax is fairly simple. This means the complete
parser (just the parser, not the code "executing" "the parse-tree") is

/* try to fopen /etc/inittab as fp */

while(!done) {
        /*
         *      Add single user shell entry at the end.
         */
        if (fp == NULL || fgets(buf, sizeof(buf), fp) == NULL) {
                done = 1;

                /* some 'execution' code here */

                continue;
        }
        lineNo++;
        /*
         *      Skip comments and empty lines
         */
        for(p = buf; *p == ' ' || *p == '\t'; p++)
                ;
        if (*p == '#' || *p == '\n') continue;

        /*
         *      Decode the fields
         */
        id =      strsep(&p, ":");
        rlevel =  strsep(&p, ":");
        action =  strsep(&p, ":");
        process = strsep(&p, "\n");
}        

NB: The rlevel and process fields additionally need to be 'parsed'.

I wouldn't write it myself in this way and I also think this leaves
something to be desired from a structual point of view, ie the way the
loop is terminated is messy, but it's certainly no terribly complicated
piece of arcane code (to someone who's proficient in C).

[...]

>     The scheme proposed by Laurent is that pid1 supervises the
> supervisor.

There's obviously a "Quis custodiet ipsos custodes?" problem here but
the (IMHO) sensible way to deal with it is to accept that not all
conceivable failures can be guarded against instead of "create a cascade
of processes doing nothing watching over processes also doing nothing":
'Real' servers tend to fail for unforeseen reasons because they're
complicated. So, use a simple program restarting the complicated ones if
they suddenly terminate and be happy that only bugs in the simple
program will have lasting consequences.