Le 11/08/2017 à 10:07, Narcis Garcia a écrit :
Something has to be done (written)
As you know, once everything has been /done/ and everything has
been /written/, there is always more /written/ than /done/ :-)
Nevertheless, let me /write/ the current status of my personnal
cogitations (as Steve mentionned there are some sound discussions
already available, from Laurent Bercot, for example).
There is one thing which has been discussed several times on this
list and on which it took me some time to reach an opinion: the role of
PID1. This process has two distinctive features:
1) it inherits all the zombies. One assumes it wait()s them out.
2) the kernel /panics/ (reboots) when PID1 dies.
The OS can survive some times if PID1 stops collecting the zombies,
maybe enough time for the admin to take action. Nevertheless the kernel
developpers decided there should be a "kernel panic" when PID1 dies.
Kernel panic can be made impossible, by writing a very simple program,
which, only collects zombies. The first PID1 would first fork() another
true Init, and then exec() a pure zombie-collector a program so short
and simple that you're sure it'll never crash. In this situation, the
kernel would have no chance to ever panic, but the system might become
unusable and non-rebootable for other reasons. Therefore, if this
"kernel panic" feature exists, it is not only because PID1 must wait()
the zombies; it is also for the system designer to put vital rescue
capabilites in PID1. Or for PID1 to die if the process with these vital
capabilities dies. Because the ability to wait() zombies is not the only
vital one.
Putting the kitchen sink in PID1 makes the system fragile and
putting nothing may render the system unusable without a power-cycle.
Therefore the first question is what do we want in PID1.
The 11/08/2017 at 21:32, in another thread, Adam Borowski wrote:
For me, sysvinit is good enough -- it's the rc system not init that matters.
Actually all criticism I have read against sysvinit are in reality
against rc, that is the tricks and the bloated script files necessary to
give the admin handles to manage the services. Sysvinit, instead, is
still a very good compromise of what needs to be put in PID1. Or
Busybox's Init, which is sysvinit minus the runlevels.
I think all this only leaves two questions:
1) Which sophistication of supervision/control do we want for the
services?
2) How complicated is a supervisor which can be restarted if it
dies? If this proves too complicated, do we want a kernel panic when the
supervisor dies?
At this point, there might be a choice of the degree of
complexity/capability. A laptop able to boot in 20s doesn't require the
same things as a heavy-duty server.
These are the considerations I would have in mind when comparing
the available supervisor alternatives, but I didn't take the time to do
it yet, sorry because this is probably what you are calling for.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
