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.


Dng mailing list

Reply via email to