Comprendre la relation entre les démons (Daemon) et les unités systemd sous Linux

👻 Les assistants invisibles de Linux : Démons (Daemon) et Unités (Unit)

Lorsque l'on gère un système Linux, d'innombrables 'démons' opèrent en arrière-plan. Nous les gérons à l'aide d'un outil appelé systemd. Quelle est la relation entre ces deux entités, et pourquoi portent-elles des noms si particuliers ? Tout comme il y a une philosophie derrière chaque ligne de code, la structure d'un système Linux recèle des intentions de conception claires.

1. Pourquoi 'Démon (Daemon)' ? : L'entité intelligente et invisible

Le nom 'démon' tire son origine des 'Daemons', des esprits bienveillants de la mythologie grecque qui aidaient les humains de manière invisible, agissant comme des intermédiaires entre les dieux et les hommes. Par la suite, après l'hypothèse du 'Démon de Maxwell' proposée par le physicien Maxwell, des développeurs du MIT ont attribué ce nom en 1963 à des "programmes qui fonctionnent en arrière-plan, prenant des décisions et exécutant des tâches de manière autonome, sans intervention de l'utilisateur".

• Essence : Un démon n'interagit pas directement avec l'utilisateur. Il réside en mémoire même après la fermeture du terminal, attendant des requêtes réseau ou surveillant l'état du système. Il représente un 'processus en arrière-plan' par excellence.

2. systemd est-il aussi un démon ? : Le "démon maître qui gère les démons"

Oui, tout à fait. Le 'd' à la fin de son nom en est la preuve. systemd est le processus numéro 1 (PID 1) qui s'exécute le premier après le démarrage du noyau Linux, et c'est le 'démon maître' qui orchestre et gère tous les autres démons.

Avant cela, la gestion des démons sous Linux était désordonnée et hétérogène. systemd est apparu pour mettre fin à cette confusion et gérer tous les éléments du système selon une spécification standardisée. Cette spécification standard est ce que l'on appelle une 'Unité (Unit)'.

3. Unité (Unit) : Le 'cahier des charges standard' qui pilote les démons

Si le démon est l'« entité » qui exécute réellement le travail, alors l'unité est le « cahier des charges » qui décrit comment gérer cette entité. Le démon maître systemd lit ce cahier des charges (Unité) que nous avons rédigé et, en fonction de son contenu, active ou désactive chaque démon.

• Clarté de l'intention : Sans la spécification d'unité, chaque développeur aurait écrit son propre code pour lancer les démons. Mais grâce à ce cahier des charges standard qu'est l'unité (par exemple, un fichier .service), nous pouvons définir de manière très précise et robuste "dans quel environnement, dans quel ordre, et comment redémarrer en cas de problème".
• Extensibilité flexible : Les unités ne sont pas uniquement destinées aux démons (Services). Elles traitent tous les éléments de Linux, comme les 'timers' pour exécuter des tâches à des moments précis, ou les 'mounts' pour connecter des périphériques, sous la forme d'un même 'cahier des charges'. Cela permet d'étendre l'ensemble du système avec une logique cohérente.

4. Aperçu de la relation en un coup d'œil

En résumé :
Le démon maître systemd lit les unités (cahiers des charges) et dirige les nombreux démons (travailleurs) pour qu'ils fonctionnent précisément selon les règles établies.

5. La diversité des travailleurs : Bien distinguer 'Démon' et 'Unité de service'

Lorsque nous parlons de "lancer un service", l'apparence du travailleur (démon) en arrière-plan n'est pas unique. En effet, tout ce qui s'exécute en arrière-plan, quelle que soit la langue de programmation ou la forme, peut être un démon.

Diverses formes de travailleurs :

• Démon de script : Si vous enregistrez du code Python que vous avez écrit, comme Django ou FastAPI, en tant qu'unité, il devient un démon Python exécuté via l'interpréteur python3.

• Démon binaire : Des programmes comme Nginx ou sshd, pré-compilés en C ou Go, sont des démons sous forme de fichiers exécutables.

• Démon de script shell : Même un simple fichier .sh, s'il tourne en boucle infinie en arrière-plan, peut être un excellent travailleur (démon).

L'unité de service est le 'lien' :

Strictement parlant, sshd ou votre script Python ne sont pas des 'services' en soi. Ce ne sont que des démons (travailleurs). Le fichier .service (unité) que nous créons directement dans le répertoire /etc/systemd/system/ ou qui est automatiquement enregistré lors de l'installation d'un paquet, est le cahier des charges qui enregistre ce travailleur comme un membre officiel du système.

Conclusion

Le démon désigne l'état d'un "programme s'exécutant en arrière-plan", tandis que l'unité de service est la spécification normalisée qui permet à systemd, le maître, de contrôler ce démon. C'est grâce à ce cahier des charges que systemd peut donner des ordres de la même manière, que le travailleur soit un script Python ou un binaire.

Qu'en pensez-vous ? J'utilise Linux comme système principal depuis environ 4 à 5 ans, et même si je pensais avoir compris ces deux concepts, il m'était très difficile de les expliquer à quelqu'un d'autre. Je suppose que je pensais savoir, mais en réalité, je n'avais pas une compréhension complète. Maintenant que j'ai enfin pu les définir et les organiser avec mes propres mots, j'ai l'impression que mon esprit s'est éclairci.

L'écriture est vraiment gratifiante. Même si cela prend du temps, écrire permet d'organiser ses pensées.