C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).
[^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
Posté par Misc (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).