Systemd – Ce que vous devez savoir

À moins que vous n’ayez vécu sous un rocher, ou pire – que vous ne vous intéressiez pas vraiment au fonctionnement de Linux, vous avez dû entendre parler de systemd, le système d’init (relativement) nouveau remplaçant l’ancien et obsolète SysV init récemment adopté par la plupart des principales distributions Linux.

Qu’est-ce qu’un système d’init ?

Lorsque votre machine Linux démarre, elle exécute d’abord un certain code “intégré”, chargé par le BIOS ou l’UEFI en premier, suivi par le chargeur de démarrage, qui, selon sa configuration, charge un noyau Linux. Le noyau charge les pilotes et, en tant que premier travail, démarre le processus init, qui, étant le premier, se voit attribuer le PID (Identifiant de Processus) 1.

Du point de vue de l’utilisateur, cela ressemble à un démarrage du réseau et des bases de données, etc., mais en réalité, un processus plutôt complexe se déroule en coulisses. Les services sont démarrés, arrêtés et redémarrés, souvent en parallèle les uns des autres. Certains sont exécutés avec des privilèges différents des autres, les statuts des services sont rapportés et enregistrés, et de nombreuses autres tâches sont effectuées pour faire fonctionner les différentes parties de votre système et interagir avec ses utilisateurs et son environnement.

Cependant, la manière dont cela est implémenté n’est pas uniforme, et c’est réellement à ce stade que tout cesse d’être commun et bien défini.

L’ancien système d’init

Le système d’init utilisé par la plupart des distributions Linux grand public jusqu’à récemment était le System V init (ou SysV init en abrégé), qui a dérivé son nom du UNIX System V (prononcé “Système Cinq”), le premier système UNIX commercialement disponible. Le système d’exploitation System V avait une méthode spécifique pour exécuter son processus init, et SysV init est resté fidèle à cela au fil des ans.

Et cela fait de nombreuses années. Le UNIX System V a été initialement publié en 1983, faisant de SysV init une approche de plus de 30 ans pour démarrer les machines Linux.

La nécessité d’un changement

Comme cela a été noté, SysV init est obsolète et aurait depuis longtemps dû être remplacé. Certaines des raisons en sont :

• SysV init utilise /sbin/init pour démarrer le processus init, mais init lui-même a un rôle très limité. init ne fait guère plus que commencer /etc/init.d/rc, selon la configuration lue depuis /etc/inittab, qui à son tour exécutera des scripts pour effectuer le véritable travail du processus init. Cela, sauf si panelisé explicitement (comme avec startpar sur Debian), se produira de manière séquentielle, un script démarrant après l’autre, rendant le processus entier lent car chaque script doit attendre que le précédent se termine.
• SysV init n’a pas accès aux PID ou aux processus qu’il a (indirectement) démarrés. Il ne fait que lire les PID et les associer à des processus actuels d’une manière circonstancielle et compliquée.
• Pour les administrateurs système essayant de modifier l’environnement sous lequel un certain processus démarrerait, c’est assez difficile avec SysV init. (Pour y parvenir, ils devront modifier le script d’init responsable de démarrer le processus donné.)
• Il y a certaines fonctionnalités communes à chaque service que SysV n’implémente pas, mais que chaque processus devrait implémenter lui-même, telles que “se fixer en tant que démon” (devenir un démon système), ce qui est un processus long et élaboré. Au lieu d’implémenter ces étapes une fois, SysV exige que chaque processus fasse le travail lui-même.
• SysV laisse également certaines fonctionnalités à des programmes externes et ne sait rien sur les services démarrés par ceux-ci.

Tout ce qui précède, et bien d’autres défauts de conception, ou plutôt la conception obsolète du système de SysV, ont rendu la création d’un système init moderne depuis longtemps nécessaire.

Entrée de systemd

Il y a eu de nombreuses tentatives pour créer un système d’init alternatif, dont systemd n’est qu’un exemple. Ubuntu a utilisé son propre système d’init appelé upstart. Gentoo utilise encore OpenRC. D’autres systèmes d’init incluent initng, busybox-init, runit, Mudur et d’autres.

La raison pour laquelle systemd est un vainqueur clair est qu’il a été adopté par la plupart des principales distributions. RHL et CentOS ont naturellement suivi la voie de systemd, car Fedora était la première distribution à adopter officiellement systemd en 2011. Mais systemd est réellement devenu le système d’init qui les régit tous, lorsque Debian 8 a officiellement switché vers systemd, entraînant Ubuntu et ses dérivés avec lui, surmontant l’opposition initiale de Canonical (ou plus précisément de Mark Shuttleworth) envers systemd.

Comment systemd est-il différent ?

• Systemd vise à fournir une méthode unique et centralisée pour gérer le processus d’init du début à la fin.
• Il démarre et arrête des processus et des services tout en gardant une trace de leurs dépendances. Il peut même démarrer un processus en réponse à l’exigence de dépendance d’un autre processus.
• En plus de démarrer et d’arrêter des processus au moment du démarrage, Systemd peut également démarrer à tout moment lorsque le système est opérationnel en réponse à certains événements déclencheurs, comme lorsqu’un appareil est branché.
• Il ne nécessite également pas que les processus se démonisent eux-mêmes. Contrairement à SysV init, systemd peut gérer des services fonctionnant sans avoir à passer par le long processus de devenir des démons.
• Contrairement à SysV init, systemd connaît et suit tous les processus, y compris les PID, et obtenir des informations sur les processus est beaucoup plus simple pour les administrateurs système sous systemd.
• Systemd prend en charge des conteneurs qui sont essentiellement des environnements de services isolés sans l’exigence de machines virtuelles. Cela a un grand potentiel pour des conceptions de systèmes plus sûres et plus simples à l’avenir.

Bien sûr, ce ne sont là que quelques-uns des principaux avantages. Pour une discussion complète sur les avantages de systemd, vous devriez lire la “Déclaration de Position Systemd” de Debian 8.

Controverse

Bien sûr, systemd n’a pas été accueilli par tous. En fait, beaucoup l’ont et continuent de le faire de manière négative, l’appelant monolithique et encombrant, certains l’accusant même de suivre la “voie de Windows” en centralisant tout. Beaucoup soutiennent que ce n’est pas “la voie de Linux”, et certainement systemd ne semble pas être en accord avec les normes POSIX. Si nous considérons systemd comme une boîte à outils (au-delà du simple binaire), c’est effectivement énorme.

Néanmoins, systemd est clairement un pas en avant, et bien qu’il ne soit pas parfait, une grande partie des critiques qu’il a reçues a été abordée par son auteur et développeur original, Lennart Poettering. C’est définitivement une avancée nécessaire et un pas en avant par rapport à l’ancien système d’init. Linus Torvalds, le créateur de Linux, ne semble pas trop se soucier de systemd, et qui sommes-nous pour discuter avec “Le Créateur”.

Conclusion

Ayant été adopté par toutes les principales distributions Linux, systemd est là pour rester. Quoi que certains administrateurs système disent pour quelque raison que ce soit, systemd est l’avenir de Linux grand public, que les utilisateurs individuels l’apprécient ou non, ce qui, à la lumière de ses avantages distincts, n’est pas nécessairement une mauvaise chose.

Pour l’utilisateur moyen, cela apporte des temps de démarrage plus rapides et probablement des systèmes plus fiables, tandis qu’à l’avenir, les distributions l’adoptant pourront devenir plus “compatibles” les unes avec les autres. Du côté utilisateur, nous bénéficierons certainement du design de système plus moderne et contemporain qu’il apporte à nos bureaux.