:: Re: [DNG] Technical overview of ini…
Top Page
Delete this message
Reply to this message
Author: Didier Kryn
Date:  
To: dng
Subject: Re: [DNG] Technical overview of init systems
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