Sauf qu'un service de démarrage c'est pas juste un daemond start et daemond stop. Parfois un script de service doit vérifier plusieurs choses pour se lancer comme la présence de répertoire, trouver un fichier de configuration, initialiser une base de données. Etc.
Précisément, ça participe au cahier des charges d’un gestionnaire de service. C’est précisément à cause ces besoins qu’il faut un gestionnaire de service et ne pas se reposer sur des scripts. S’il manque une chose c’est qu’il faut l’ajouter au cahier des charges du gestionnaire de service, ça ne doit pas être un argument pour dire « oh et puis merde, implémenter un gestionnaire de service c’est trop complexe parce que les services c’est trop complexes, je vais donc faire un script et procrastiner la résolution du problème ».
Les services ne deviennent pas moins complexes en faisant des scripts parce qu’on n’implémente pas de gestionnaire de service, donc un gestionnaire de service ne devient pas moins nécessaire en faisant un script. Faire un script c’est juste un patch sur une jambe de bois.
Un gestionnaire de service c’est quelque chose de trop sérieux, trop complexe, trop important et trop critique pour le faire avec des scripts.
Si un service de démarrage c'était juste un daemond start et daemond stop on n’aurait pas besoin de systemd et des scripts ce serait parfait.
C’est moins déconnant d’écrire un service en shell que d’écrire un gestionnaire de service en shell, parce que des services triviaux ça existe, mais un gestionnaire de service ce n’est jamais trivial (ou alors ça ne répond pas aux besoins et les gens doivent pallier les manquements par des scripts, c’est ça sysvinit, chaque script est un palliatif).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: moi c'est l'inverse
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Linux ne m'intéresse plus. Évalué à 9.
Précisément, ça participe au cahier des charges d’un gestionnaire de service. C’est précisément à cause ces besoins qu’il faut un gestionnaire de service et ne pas se reposer sur des scripts. S’il manque une chose c’est qu’il faut l’ajouter au cahier des charges du gestionnaire de service, ça ne doit pas être un argument pour dire « oh et puis merde, implémenter un gestionnaire de service c’est trop complexe parce que les services c’est trop complexes, je vais donc faire un script et procrastiner la résolution du problème ».
Les services ne deviennent pas moins complexes en faisant des scripts parce qu’on n’implémente pas de gestionnaire de service, donc un gestionnaire de service ne devient pas moins nécessaire en faisant un script. Faire un script c’est juste un patch sur une jambe de bois.
Faire un script pour démarrer un service c’est comme parser du HTML avec des expressions régulières ou écrire son propre parseur CSV (cf. précédente discussion) ou encore valider des adresses e-mail soi-même. On se dit que c’est pas compliqué et qu’on va faire un script ça fera bien l’affaire. Non.
Un gestionnaire de service c’est quelque chose de trop sérieux, trop complexe, trop important et trop critique pour le faire avec des scripts.
Si un service de démarrage c'était juste un
daemond startetdaemond stopon n’aurait pas besoin de systemd et des scripts ce serait parfait.C’est moins déconnant d’écrire un service en shell que d’écrire un gestionnaire de service en shell, parce que des services triviaux ça existe, mais un gestionnaire de service ce n’est jamais trivial (ou alors ça ne répond pas aux besoins et les gens doivent pallier les manquements par des scripts, c’est ça sysvinit, chaque script est un palliatif).
ce commentaire est sous licence cc by 4 et précédentes