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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
