:: Re: [DNG] Lead BusyBox developer on…
Kezdőlap
Delete this message
Reply to this message
Szerző: Rainer Weikusat
Dátum:  
Címzett: dng
Tárgy: Re: [DNG] Lead BusyBox developer on sysvinit
Didier Kryn <kryn@???> writes:
> Le 18/02/2016 18:05, Steve Litt a écrit :
>> On Thu, 18 Feb 2016 16:15:55 +0100
>> Didier Kryn<kryn@???> wrote:
>>
>>> >      Hence the argument already exposed by several persons on this
>>> >list, in particular Laurent: let's pid1 do*only*  what no other
>>> >program can do.
>> ================================================
>> NOTE: My response is based on*my*  reading and interpretation of
>> Laurent's emails here and on the supervision list and a few to me
>> personally. It's very possible I've misread or misinterpreted...
>> ================================================

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


while(!done) {
        /*
         *      Add single user shell entry at the end.
         */
        if (fp == NULL || fgets(buf, sizeof(buf), fp) == NULL) {
                done = 1;
                /*
                 *      See if we have a single user entry.
                 */
                for(old = newFamily; old; old = old->next)
                        if (strpbrk(old->rlevel, "S")) break;
                if (old == NULL)
                        snprintf(buf, sizeof(buf), "~~:S:wait:%s\n", SULOGIN);
                else
                        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");
}        


>
>     So probably Laurent didn't use these words but he clearly
> advocates in that sense.

>
>>
>> U sure that was Laurent who said "let pid do*only* what no other
>> program can do"? Laurent prioritizes PID1 being able to*respawn* the
>> process supervisor, which from my understanding means that PID1 must
>> *contain* the process supervisor. Laurent has opined that the
>> architectures of Runit,http://ewontfix.com/14/ and Suckless Init +
>> daemontools-encore + LittKit or Suckless Init + s6
>> + LittKit all suffer from the inability for PID1 to respawn the process
>> supervisor, and if I'm not mistaken the PID1 used by s6 (when s6 is
>> used as a whole init) contains the supervisor.
>>
>> From Laurent's point of view, if the supervisor (runsvdir or
>> svscanboot or whatever) dies or is killed AND all the gettys
>> also die, one loses all control of the computer and must
>> hardware reboot, and that's a bad thing.
>>
>> My opinion is that although this is indeed a bad thing, I'm
>> willing to risk it to get the breathtaking simplicity of Rich
>> Felker's vision inhttp://ewontfix.com/14/.
>>
>
>
>     Rich is a little more explicit about pid1; I quote:

>
> <<The right way: Do away with everything special about pid 1 by making
> pid 1 do nothing but start the real init script and then just reap
> zombies>>
>
>     Which is exactly "do only what no other program can do".

>
>     The scheme proposed by Laurent is that pid1 supervises the
> supervisor. However Dennys explains that it is not mandatory because
> even if the supervisor dies, the services don't necessarily die in the
> same time and you still have a chance to restart the supervisor, or
> reboot gently. Note that, for the paranoid, the supervisor itself
> might be supervised by another process which isn't necessarily pid1, a
> super-simple supervisor dealing with only one child and without a
> config file :-)

>
>                                         Didier

>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng