J'ai rien contre le langage shell, mais en mettre un gros pâté dans un initscript est pour moi un indicateur de solution gruik posée à la va-vite. Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques...), pas porté (chacun fera sa petite cuisine dans son coin), inélégant, le contraire du prétendu "esprit" du SysV RC qu'on nous chantes chaque fois qu'on parle de SystemD.
En des temps immémoriaux, à ma première LSF, pour monter les systèmes de fichiers l'initscript était un simple appel à mount -a.
Maintenant pour faire ça t'a des centaines de lignes dans /etc/rc.sysvinit pour RHEL, Pour Debian des milliers de lignes dans /etc/init.d et /etc/network/if-up.d...
Bon ces scripts font des choses utiles genre attendre le réseau pour monter du NSF, des dizaines de mainteneurs de distributions ont implémentés ce genre de truc, mais personne n'a penser à moderniser mount pour qu'ils réponde aux nouveaux besoins de l'init, alors que c'est son rôle :
mount -a [-t type] [-O optlist]
(**usually given in a bootscript**) causes all filesystems mentioned in fstab (of the proper type
and/or having or not having the proper options) to be mounted as indicated, except for those
whose line contains the noauto keyword. Adding the -F option will make mount fork, so that the
filesystems are mounted simultaneously.
Des scripts shell je suis le premier à en faire, mais dès que tu te pose la question "comment faire ça proprement ?" ben tu les sort de l'init.
Avec LXC beaucoup de distributions ont ajoutés un initscript "complexe" pour lancer de containers au démarrage.
Alors c'est pratique, tu file le nom de tes containers dans /etc/default/lxc et ils seront démarrés/arrêtés automatiquement.
Mais si j'en arrête un par moi même, l'init gueulera à l’arrêt du service que toto était lancé et qu'il ne l'est plus, ou plein d'autres petits dysfonctionnements.
On s’aperçoit vite que pour faire ça proprement, il faut un système qui permette la gestion complète des containers "automatiques" ajout/suppression/démarrage/arrêt/démarrage-individuel/arrêt-individuel/statut d'un containers/statut de tous les containers... et que la place d'un tel utilitaire n'est pas dans l'init, par contre un l'init peut appeler cet utilitaire pour le démarrage/arrêt du service.
Après faire ça en shell, pourquoi pas, c'est un choix de langage comme un autre.
[^] # 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é à 5.
J'ai rien contre le langage shell, mais en mettre un gros pâté dans un initscript est pour moi un indicateur de solution gruik posée à la va-vite. Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques...), pas porté (chacun fera sa petite cuisine dans son coin), inélégant, le contraire du prétendu "esprit" du SysV RC qu'on nous chantes chaque fois qu'on parle de SystemD.
En des temps immémoriaux, à ma première LSF, pour monter les systèmes de fichiers l'initscript était un simple appel à mount -a.
Maintenant pour faire ça t'a des centaines de lignes dans /etc/rc.sysvinit pour RHEL, Pour Debian des milliers de lignes dans /etc/init.d et /etc/network/if-up.d...
Bon ces scripts font des choses utiles genre attendre le réseau pour monter du NSF, des dizaines de mainteneurs de distributions ont implémentés ce genre de truc, mais personne n'a penser à moderniser mount pour qu'ils réponde aux nouveaux besoins de l'init, alors que c'est son rôle :
Des scripts shell je suis le premier à en faire, mais dès que tu te pose la question "comment faire ça proprement ?" ben tu les sort de l'init.
Avec LXC beaucoup de distributions ont ajoutés un initscript "complexe" pour lancer de containers au démarrage.
Alors c'est pratique, tu file le nom de tes containers dans /etc/default/lxc et ils seront démarrés/arrêtés automatiquement.
Mais si j'en arrête un par moi même, l'init gueulera à l’arrêt du service que toto était lancé et qu'il ne l'est plus, ou plein d'autres petits dysfonctionnements.
On s’aperçoit vite que pour faire ça proprement, il faut un système qui permette la gestion complète des containers "automatiques" ajout/suppression/démarrage/arrêt/démarrage-individuel/arrêt-individuel/statut d'un containers/statut de tous les containers... et que la place d'un tel utilitaire n'est pas dans l'init, par contre un l'init peut appeler cet utilitaire pour le démarrage/arrêt du service.
Après faire ça en shell, pourquoi pas, c'est un choix de langage comme un autre.