Les daemontools ont 20 ans !

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

• Site officiel de daemontools (130 clics)