C'est pas comme si j'avais pas cité les bashisms entre-autres.
Quasiment toutes les distribs sont passés à du pure SH (Debian, Gentoo...), mais reste quelques bashisms chez RH par ex, et si l'auteur d'un programme fournit un initscript pour RH, ben ça marchera pas ailleurs.
Après, tous ces init utilisent le même langage, mais pas les mêmes fonctions,
CentOS : /etc/rc.d/init.d/functions
Debian : /lib/lsb/init-functions
Gentoo : /lib/rc/sh/runscript.sh
Et ces fichiers contiennent tous des commandes spécifiques à chaque init (log_warning_msg pour un, ewarn pour l'autre...)
Sortir le gros de la gestion du daemon hors de l'init permet un meilleur contrôle de l'utilisateur via un outil unifié, mais aussi de minimiser le code spécifique à la distribution.
Après bizarre de voir les bsdistes me tomber dessus alors que j'ai cité jail en bon exemple, mais bon j'ai dit systemd, c'est un gros mot.
[^] # Re: systemd
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 3. Dernière modification le 05 décembre 2013 à 13:10.
C'est pas comme si j'avais pas cité les bashisms entre-autres.
Quasiment toutes les distribs sont passés à du pure SH (Debian, Gentoo...), mais reste quelques bashisms chez RH par ex, et si l'auteur d'un programme fournit un initscript pour RH, ben ça marchera pas ailleurs.
Après, tous ces init utilisent le même langage, mais pas les mêmes fonctions,
CentOS : /etc/rc.d/init.d/functions
Debian : /lib/lsb/init-functions
Gentoo : /lib/rc/sh/runscript.sh
Et ces fichiers contiennent tous des commandes spécifiques à chaque init (log_warning_msg pour un, ewarn pour l'autre...)
Sortir le gros de la gestion du daemon hors de l'init permet un meilleur contrôle de l'utilisateur via un outil unifié, mais aussi de minimiser le code spécifique à la distribution.
Après bizarre de voir les bsdistes me tomber dessus alors que j'ai cité jail en bon exemple, mais bon j'ai dit systemd, c'est un gros mot.