Le gestionnaire des processus et services Systemd

Mise à jour : 31/10/2024

systemd est le gestionnaire de services et de démarrage pour les systèmes Linux, utilisé par défaut sur la plupart des distributions. Il se lance automatiquement lors de la première étape de démarrage du système et prend en charge l’activation et la gestion des services. En tant que premier processus du système (PID 1), systemd contrôle le fonctionnement des services et reste actif jusqu’à l’arrêt du système.

Histoire et Évolution de systemd

L’importance de systemd et de systemctl dans la gestion des services Linux ne peut être pleinement comprise sans examiner l’histoire qui a conduit à leur création et à leur adoption généralisée.

Initialement, les systèmes Linux utilisaient des systèmes d’initialisation basés sur des scripts, tels que init.d. Bien qu’ils aient permis de gérer efficacement les services à une époque, ces systèmes présentaient plusieurs limitations. La gestion des dépendances entre les services était souvent source de complexité, ce qui pouvait entraîner des échecs lors du démarrage ou de l’arrêt des services. De plus, le démarrage séquentiel des services rallongeait significativement le temps nécessaire pour initialiser complètement le système, rendant l’ensemble du processus moins optimal, surtout à mesure que les infrastructures devenaient plus complexes.

Pour surmonter ces difficultés, systemd a été développé par Lennart Poettering et Kay Sievers et introduit en 2010. Son objectif était de répondre aux défis des systèmes d’initialisation traditionnels en proposant un modèle de gestion des services plus moderne et efficace. Contrairement aux anciens systèmes, systemd permet un démarrage parallèle des services, réduisant ainsi considérablement les temps d’initialisation. Il facilite également la gestion des dépendances, automatisant et simplifiant ce processus pour rendre le démarrage et l’arrêt des services plus fluides et fiables.

Au fil des années, systemd est devenu une norme incontournable dans le monde Linux. Adopté par la majorité des distributions, qu’elles soient basées sur Red Hat, Debian, ou d’autres, systemd s’est imposé comme un composant essentiel pour la gestion des services. Son interface, systemctl, offre aux administrateurs système une commande centralisée pour contrôler, démarrer, arrêter et superviser les services, apportant cohérence et efficacité à la gestion des systèmes Linux. Aujourd’hui, systemd est omniprésent et sa large adoption reflète l’importance de son rôle dans l’évolution de l’administration des systèmes Linux modernes.

Architecture globale de systemd

systemd est construit sur une architecture modulaire et flexible, pensée pour fournir une gestion centralisée et unifiée des services et des processus système. Cette architecture repose sur plusieurs composants essentiels qui fonctionnent de manière coordonnée pour démarrer, surveiller et arrêter les services, tout en optimisant les performances et la consommation des ressources.

L’élément central de systemd est le gestionnaire de services, qui prend en charge le démarrage et la gestion des services et processus système. Contrairement aux systèmes init classiques, systemd est capable de démarrer les services en parallèle, ce qui réduit le temps de démarrage en évitant les goulets d’étranglement. Cette fonctionnalité repose sur un système de gestion des dépendances, où chaque service peut définir ses prérequis et déterminer l’ordre optimal de démarrage, arrêt ou redémarrage.

À côté de ce gestionnaire, journald est responsable de la gestion des journaux. Il capture et stocke les événements générés par l’ensemble des services sous forme de journaux. Ces logs peuvent être consultés facilement avec la commande journalctl, qui permet de filtrer et d’analyser les événements selon divers critères, comme les dates, les unités ou encore les niveaux de priorité. Cela centralise la gestion des journaux et facilite le diagnostic et la résolution des problèmes. Plus d’infos ici

Un autre composant clé est logind, qui gère les sessions utilisateur et s’intègre avec l’interface graphique pour permettre la gestion des permissions et des accès. logind supervise également les sessions distantes et locales, gérant les connexions et les déconnexions tout en respectant les permissions de sécurité établies.

systemd utilise également les cgroups (groupes de contrôle) pour contrôler l’allocation des ressources comme le CPU, la mémoire et les E/S disque pour chaque service. Cela permet de limiter l’impact d’un service spécifique sur l’ensemble du système, en le confinant aux ressources qui lui ont été allouées. Par exemple, un service consommant trop de mémoire peut être restreint dans son utilisation, empêchant ainsi la saturation des ressources pour d’autres services.

Enfin, l’architecture de systemd repose sur des unités ou units, qui représentent des objets configurables au sein du système, tels que des services, des montages, des périphériques ou des points de montage. Chaque unité est définie par un fichier de configuration spécifique (unité ou unit file) et est gérée indépendamment, ce qui permet une grande flexibilité dans l’administration du système. Par exemple, un fichier de type service configure un service précis et peut inclure des instructions sur le moment et les conditions de son lancement.

Le concept d’unités dans systemd

Dans systemd, le concept d’unités (ou units) est fondamental pour la gestion des services, périphériques, montages et autres éléments du système. Une unité représente un objet géré par systemd et est configurée via un fichier d’unité, ou unit file. Ces fichiers, stockés généralement dans le répertoire /etc/systemd/system ou /usr/lib/systemd/system, définissent le comportement et les dépendances de chaque unité. Chaque unité a un type spécifique qui détermine sa fonction et la manière dont elle interagit avec d’autres éléments du système.

Voici les types d’unités principaux qu’on rencontre dans systemd :

Service (.service) : ce type d’unité est le plus utilisé et définit les services qui s’exécutent en arrière-plan. Par exemple, le serveur web Apache utilise une unité de type service pour gérer ses processus. Le fichier .service définit des détails comme les commandes à exécuter pour démarrer, arrêter ou redémarrer le service, ainsi que les dépendances nécessaires.
Mount (.mount) : les unités de type mount gèrent les points de montage de systèmes de fichiers. Elles facilitent la gestion des montages automatiques en définissant des configurations spécifiques pour chaque point de montage, comme les options de montage ou les dépendances.
Target (.target) : une cible est une unité qui permet de regrouper plusieurs unités sous un même objectif. Par exemple, le multi-user.target regroupe les services nécessaires pour un environnement multi-utilisateur en ligne de commande. Les cibles sont souvent utilisées pour structurer le processus de démarrage et arrêter proprement des groupes de services liés.
Timer (.timer) : ces unités servent à planifier l’exécution d’autres unités, généralement des services, de manière périodique ou ponctuelle. Par exemple, une unité timer peut être configurée pour lancer un service de nettoyage de journaux une fois par jour.
Device (.device) : ce type d’unité gère les périphériques matériel détectés par le noyau. Elle est automatiquement créée et activée lorsque de nouveaux périphériques apparaissent, permettant ainsi à systemd de superviser l’état et les actions sur les périphériques.

Chaque unité est définie par un fichier de configuration qui inclut des directives spécifiques comme [Unit], [Service], [Install], etc. Ces directives permettent de personnaliser le comportement des unités, notamment en définissant des dépendances et des ordres de démarrage précis. Par exemple, la directive After= permet d’indiquer qu’une unité doit démarrer après une autre unité, assurant ainsi un ordre logique lors du démarrage des services.

En utilisant des unités, systemd peut contrôler avec précision chaque composant du système. Par exemple, pour démarrer un service web Apache, on pourrait utiliser la commande systemctl start apache2.service, qui invoque le fichier de configuration de l’unité apache2.service pour exécuter les actions nécessaires. De la même manière, les unités facilitent l’arrêt, le redémarrage ou la reconfiguration des services, tout en intégrant des mécanismes de supervision pour s’assurer que chaque unité reste active et fonctionne correctement.

Exemple de fichier d’unité de type target :

#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

Dépendances entre les Unités

Les unités systemd peuvent avoir des dépendances les unes sur les autres, ce qui signifie que l’activation ou la désactivation d’une unité peut affecter d’autres unités. Les dépendances sont spécifiées dans les fichiers de configuration des unités et peuvent être de deux types principaux :

Dépendances Requises (Required) : Si une unité A a une dépendance requise à une unité B, alors A ne peut pas être activée sans que B soit également activée. Si B échoue, A échouera également.
Dépendances Souhaitées (WantedBy) : Si une unité A a une dépendance souhaitée à une unité B, alors A peut être activée même si B n’est pas activée. Cependant, si B est activée, A sera également activée.

Les dépendances permettent de gérer l’ordre dans lequel les unités sont activées et désactivées, garantissant ainsi un démarrage et un arrêt du système cohérents.

Exemple de dépandances :

Les unités Targets

Les “targets” systemd sont des unités spéciales qui agissent comme des points de référence pour le démarrage et l’arrêt du système. Elles regroupent des unités liées par un objectif commun. Par exemple, la cible multi-user.target représente le niveau de fonctionnement multi-utilisateur, tandis que la cible graphical.target représente le mode graphique.

Les targets permettent de gérer l’état global du système en activant ou en désactivant un groupe d’unités liées. Elles sont souvent utilisées pour basculer entre différents modes de fonctionnement, tels que le mode mono-utilisateur, le mode multi-utilisateur ou le mode graphique.

Les unités Services

Les unités de type “service” sont des composants qui fournissent des fonctionnalités spécifiques au système. Elles peuvent être démarrées, arrêtées, redémarrées et surveillées par systemd. Les services sont généralement liés à des processus en cours d’exécution, mais ils peuvent également représenter des tâches planifiées ou des actions à exécuter à des moments spécifiques.

Les unités Timers

Les unités de type “timer” sont utilisées pour planifier l’exécution d’autres unités à des moments spécifiques. Elles permettent de définir des tâches à répétition, telles que l’exécution d’un script toutes les heures ou le redémarrage d’un service tous les jours à une heure précise. Les timers sont généralement associés à des unités de type “service”.

Conclusion

En comprenant l’architecture de systemd et en maîtrisant ses principaux composants, chaque administrateur peut améliorer la stabilité et la performance de son environnement Linux. Pour approfondir vos connaissances sur certains aspects abordés ici, je vous invite à consulter les liens inclus dans cette introduction, qui détaillent davantage l’utilisation de journald, des services et des timers. Ce guide va évoluer au fil du temps, alors n’hésitez pas à le consulter régulièrement pour monter en compétences sur systemd.