Les daemontools ont 20 ans !

Posté par  . Édité par Ysabeau 🧶, Bruno Ethvignot, palm123, olivierweb, Yves Bourguignon, Anonyme, volts, nud et vieille_moule. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
47
14
juil.
2021
Administration système

Ce lundi 12 juillet 2021, nous fêtions l’anniversaire des 20 ans de la 1ʳᵉ version stable des daemontools, qui sont un mécanisme de supervision (ou watchdog) des daemons, décorrélé de l’init.


La raison principale d’être des daemontools était de relancer automatiquement les daemons à sa charge lors d’un plantage.
Pour cela, une mécanique simple mais efficace est utilisée :

  • surveillance d’un dossier, par exemple /etc/service ;
  • pour chaque sous-dossier contenant un fichier run, lancement d’un watchdog qui sera chargé d’exécuter run ;
  • si le sous-dossier contient à nouveau un sous-dossier nommé log qui contient un fichier run, la sortie d’erreur du fichier run principal est redirigée vers l’entrée standard du fichier run des logs.

Ce mécanisme n’implique en rien que les fichiers run soient des scripts Bourne (il suffit qu’ils soient exécutables), mais, en pratique, cela a probablement été la majorité des cas, pour des raisons de simplicité, et peut-être de portabilité, la simplicité des daemontools étant telle que ce fonctionnement est aisé à implémenter sur tout système compatible POSIX.

Contrairement aux scripts que l’on peut trouver notamment dans l’implémentation de rc.d par Debian (exemple pour apache2 : rc.d vs runit), ces scripts sont généralement triviaux et courts : moins de 10 lignes.

Dans mon expérience (avec runit, un héritier), le plus gros et le plus alambiqué pèse 31 lignes, udev nécessitant le lancement de commandes une fois le daemon fin prêt afin de s’initialiser correctement.

Outre le redémarrage automatique des daemons, cet outil a apporté d’autres fonctionnalités bien utiles, notamment :

  • se débarrasser des fichiers de PID, qui traditionnellement permettent d’envoyer un signal à un daemon précis, mais qui en réalité impliquaient le risque de situation de compétition (race-condition) menant à tuer un autre processus par erreur ;
  • possibilité de traiter les journaux par un outil autre que syslogd, et notamment, de façon isolée, avec la possibilité d’avoir un journal par daemon, ce qui permet par exemple une gestion plus fine des droits d’accès aux journaux ainsi que d’éviter qu’un éventuel bug du logger n’impacte l’ensemble des journaux système.

Bien sûr, ce n’est pas exempt de défauts (rien ne l’est) :

  • si un processus gèle, mais ne meurt pas, la situation ne sera pas détectée automatiquement (il faudrait pour cela un watchdog actif, qui sonde régulièrement la cible de manière non-intrusive pour éviter tout biais) ;
  • il n’est pas possible de savoir si un daemon est en cours de lancement (dans le fichier run donc) ou effectivement démarré (le processus apache2 existe, par exemple) en consultant simplement la sortie de svstat.

Cet outil, toujours disponible notamment sous Debian, a donné naissance à divers héritiers, qui, chacun, corrigent une ou plusieurs limitations, les plus connus étant peut-être runit, s6 et nosh.

L’un d’eux, runit est notamment utilisé par défaut par la distribution void-linux et empaqueté (à destination des utilisateurs avancés) pour d’autres distributions telles que Artix Linux (dérivée de Archlinux pour supporter officiellement les autres systèmes d’init différents de Systemd) ou Debian (il s’agit d’une des trois options du paquet init, les autres étant sysvinit-core et systemd-sysv). Il est également à noter que des développements ont lieu via Debian.

Un autre, nosh est également intéressant car capable d’importer les unit de systemd.

Bien que, de nos jours, systemd soit chargé de cette tâche sur la majorité des distributions Linux, je tenais à faire cet hommage à un outil qui, j’en suis sûr, a permis a de nombreux sysadmin de mieux dormir la nuit, en tous cas, suffisamment pour que des gens maintiennent toujours des outils utilisant cette approche, 20 ans après !

Joyeux anniversaire !

PS : les daemons apache2 et udev n’ont été utilisés que pour illustrer certains propos.

Aller plus loin

  • # Sous FreeBSD

    Posté par  . Évalué à 4.

    Je les utilise sous FreeBSD.

    Comme il n'y a pas systemd, je ne savais pas comment faire, et comme j'ai vu que les daemontools existaient sous FreeBSD, j'ai essayé, et ça fonctionne très bien !

    [root@mail ~]# svstat /var/service/getmail/
    /var/service/getmail/: up (pid 758) 596833 seconds
    
  • # supervisord

    Posté par  . Évalué à 5.

    Plus que les vrais "init systems" qui prennent en charge d'autres paramètres (userspace et autre), il me semble qu'un vrai successeur serait supervisord?

  • # un bon sysadmin dirait...

    Posté par  (Mastodon) . Évalué à -3.

    Bien que, de nos jours, systemd soit chargé de cette tâche sur la majorité des distributions Linux, je tenais à faire cet hommage à un outil qui, j’en suis sûr, a permis a de nombreux sysadmin de mieux dormir la nuit, en tous cas, suffisamment pour que des gens maintiennent toujours des outils utilisant cette approche, 20 ans après !

    …que ça s'apparente plus à cacher la merde du chien.

    En tout cas en général si j'ai un binaire qui crash, je regarde pourquoi et je le remplace par un autre outil si ce n'est pas résolu facilement par un changement de config.

    • [^] # Re: un bon sysadmin dirait...

      Posté par  . Évalué à 9. Dernière modification le 15 juillet 2021 à 14:47.

      Et le vrai sysadmin, il prend la voiture pour aller rebooter les systèmes distants de plusieurs centaines de kilomètres dès qu'il y a une merde possiblement pas liée au logiciel, mais qui plante quand même les softs?

      Dans l'absolu, je suis d'accord, les logiciels devraient être corrigés avant tout. Sauf que bon… ça, c'est la situation idéale, pas le monde que j'ai expérimenté. Mais bon, je ne suis pas sysadmin, juste un dev système qui a bossé sur du "mobilier urbain" (enfin, urbain… ça veut pas dire que ça peut pas être déployé au fin fond d'une forêt, loin de la).

    • [^] # Re: un bon sysadmin dirait...

      Posté par  . Évalué à 10.

      Ça n'empêche pas de regarder pourquoi le binaire crash, ça permet juste de diminuer l’indisponibilité le temps de justement trouver la solution ou de remplacer le binaire problématique (ce qui ne se fait pas en 5 minutes, le temps d'adapter une configuration et des dépendances inverses qui peuvent être conséquents).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: un bon sysadmin dirait...

      Posté par  . Évalué à 1.

      Tu es trop fort …

    • [^] # Re: un bon sysadmin dirait...

      Posté par  (site web personnel) . Évalué à 2.

      Si tu es pro : tu planifies une modification,
      - tu vérifies sa pérennité
      - tu vérifies qu'elle n'aura pas d'effet de bord sur les performances et la stabilité logicielle.
      - tu proposes un plan de déploiement.
      - etc…

      Tout cela en fonction du temps libre que tu as, de la marge d'acceptation, et du potentiel de valorisation par l'équipe.
      Je me suis déjà entendu dire que l'on ne m'avait rien demandé, ça calme…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.