Le 30/03/2015 19:24, Steve Litt a écrit :
> Hi Didier,
>
> If your post says what I think it says, you're saying that modern init
> systems should always start services concurrently, not consecutively.

     Maybe this is a little too extremist and is going farther than what 
I meant. Let me moderate it a little.

     Typically, the early init phase happens in initramfs and finishes 
with switch_root or pivot_root to the final rootfs. At this time, when 
/sbin/init starts, /, /dev, /proc, /sys are already mounted and /dev is 
at least partly populated (totally in the case of a static /dev).

     Which part of the dependencies is best managed by init and which by 
the daemons is a matter of expertise. Starting things sequentially is 
certainly a too extreme way to manage the dependencies. But my point was 
rather on the daemons. I'm not saying that init should be a fork-bomb (I 
discovered this expression recently and enjoy it :-) ).

     My point is that services should be able to wait for their 
resources by themselves, not only in the initialization phase, and be 
able to react to changes in these resources.

      For a daemon we had two design options proposed:
     1) resource allocation, then orphanning, then service, then death 
if resource lost,
     2) statefull program providing service when resource is available.

     The first is the traditional fashion; it is fragile and unsafe to 
supervise; it was devised long ago, far before the advent of 
hotplugging. The second is a survivor, easy to supervise and fits with 
hotplugging.

     Didier