Le 18/02/2016 18:05, Steve Litt a écrit :
On Thu, 18 Feb 2016 16:15:55 +0100
Didier Kryn<k...@in2p3.fr> 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...>>
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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
