Un bootscript tu le réutilises, c'est fait pour démarrer ou arrêter ton programme. Mais ton programme init va pas décider de ce qui doit ou non rester en vie après le démarrage, de ce que j'ai pu en voir jusqu'à présent c'est spécifique à systemd ça. Je n'ai vu aucun système d'init qui tue une application parce que tu ne lui as pas dit qu'il fallait la garder en vie. Je ne suis pas fondamentalement contre ce genre de système, juste ça n'a rien à voir avec l'init.
C'est faux évidemment, sysvinit s'occupe de lancer ou de tuer tes applications en fonction du runlevel choisi.
Et évidemment, une majorité de sysadmin très vocaux contre systemd ne le savent pas, parce que tout simplement, mon expérience a montré qu'une majorité de sysadmin ne comprend rien au système d'init et tous ses écueils, et le groupe contre systemd semble entièrement inclus dans ce groupe.
Ce qui n'est pas étonnant au final, vu qu'il faut vraiment ne pas avoir eu à gérer sysvinit correctement (indice : c'est impossible de le gérer correctement) pour ne pas voir l'immense avancée avec systemd.
Les bootscripts qui outrepassent complètement le comportement normal de sysvinit sont déjà un exemple flagrant. Normalement, tout devrait se faire dans inittab avec sysvinit. Et si l'init ne tuait jamais rien, cela signifierait qu'en cas de passage au runlevel 0 ou 6, il se contente d'éteindre sans avertir les applications, bonjour le massacre.
[^] # Re: Ne pas utiliser, recompiler... ou changer une option.
Posté par ookaze . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
C'est faux évidemment, sysvinit s'occupe de lancer ou de tuer tes applications en fonction du runlevel choisi.
Et évidemment, une majorité de sysadmin très vocaux contre systemd ne le savent pas, parce que tout simplement, mon expérience a montré qu'une majorité de sysadmin ne comprend rien au système d'init et tous ses écueils, et le groupe contre systemd semble entièrement inclus dans ce groupe.
Ce qui n'est pas étonnant au final, vu qu'il faut vraiment ne pas avoir eu à gérer sysvinit correctement (indice : c'est impossible de le gérer correctement) pour ne pas voir l'immense avancée avec systemd.
Les bootscripts qui outrepassent complètement le comportement normal de sysvinit sont déjà un exemple flagrant. Normalement, tout devrait se faire dans inittab avec sysvinit. Et si l'init ne tuait jamais rien, cela signifierait qu'en cas de passage au runlevel 0 ou 6, il se contente d'éteindre sans avertir les applications, bonjour le massacre.