Le système init systemd a franchi le cap des dix ans, mais les opinions qu’il suscite au sein de la communauté Linux restent toujours aussi polarisées. Malgré son adoption par de nombreuses distributions Linux majeures, une opposition farouche perdure.
Le processus de démarrage sous Linux
Lorsque vous mettez votre ordinateur sous tension, le matériel s’active, puis (selon le type de secteur de démarrage utilisé), soit l’enregistrement de démarrage principal (MBR) se lance, soit l’interface micrologicielle extensible unifiée (UEFI) prend le relais. La dernière action de ces deux méthodes consiste à amorcer le noyau Linux.
Le noyau est chargé en mémoire, décompressé et initialisé. Un système de fichiers temporaire est créé en RAM, généralement par un utilitaire comme initramfs ou initrd. Cela permet d’identifier et de charger les pilotes nécessaires. À son tour, le système de fichiers de l’espace utilisateur peut être chargé et se préparer à établir l’environnement de l’espace utilisateur.
La création de cet environnement est pilotée par le processus init, le tout premier processus lancé par le noyau dans l’espace utilisateur. Il est identifié par un identifiant de processus (PID) égal à 1. Tous les autres processus sont des enfants, directs ou indirects, de ce processus init.
Avant l’arrivée de systemd, le principal processus d’initialisation était une évolution du système d’initialisation SysV. Bien qu’il existait des alternatives, SysV était la norme dans la plupart des distributions non dérivées de Berkeley Software Distribution (BSD). Cette filiation avec SysV Unix, ancêtre de Linux, lui conférait une sorte de légitimité « officielle ».
Le processus d’initialisation démarre tous les démons et les services indispensables au bon fonctionnement et à l’interactivité du système d’exploitation. Ces démons gèrent des aspects variés comme la pile réseau, l’activation de composants matériels, et l’affichage de l’écran de démarrage.
De nombreux processus d’arrière-plan continuent de fonctionner après leur démarrage. Ils sont responsables de tâches telles que la journalisation des événements, la surveillance des modifications matérielles lors de la connexion ou déconnexion de périphériques, et la gestion des sessions utilisateur. Logiquement, le système init dispose également de fonctionnalités pour gérer ces services.
On peut utiliser la commande ps pour identifier le processus ayant le PID 1. En utilisant les options f (format complet) et p (PID):
ps -fp 1
Sur la plupart des systèmes modernes, cette commande révèle que le processus ayant le PID 1 est systemd. Sur d’anciennes versions de Manjaro Linux, le processus avec le PID 1 était identifié comme /sbin/init. En examinant ce fichier, on constate qu’il s’agit d’un lien symbolique vers systemd:
ps -fp 1
ls -hl /sbin/init
En utilisant l’option ppid (ID de processus parent) avec ps, nous pouvons voir les processus directement lancés par systemd:
ps -f --ppid 1
Il s’agit d’une liste assez longue, comme on peut le constater dans l’image ci-dessous.
Les alternatives à systemd
Divers projets ont tenté de proposer une alternative au traditionnel système init SysV. L’un des principaux problèmes de SysV est qu’il lance tous les processus en série, l’un après l’autre. Afin d’améliorer l’efficacité du démarrage, de nombreux projets alternatifs exploitent le parallélisme pour lancer les processus simultanément et de manière asynchrone.
Voici quelques exemples :
- Upstart: Développé par Canonical, il a été employé dans Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6, et Fedora 9.
- Runit: Fonctionne sur FreeBSD et d’autres dérivés BSD, macOS et Solaris, ainsi que sur les systèmes Linux. Il constitue également le système d’initialisation par défaut de Void Linux.
- s6-linux-init: Ce remplacement de SysV init a été conçu dans le respect de la philosophie Unix, qui se résume souvent par l’adage « faire une chose, et bien la faire ».
Il existe bien d’autres fonctionnalités et conceptions différentes. Cependant, aucune d’entre elles n’a suscité l’indignation que systemd a engendrée.
Le fonctionnement de systemd
Systemd a été publié en 2010 et a été utilisé pour la première fois dans Fedora en 2011. Depuis, de nombreuses distributions l’ont adopté. Il a été développé par Lennart Poettering et Kay Sievers, deux ingénieurs logiciels chez Red Hat.
Systemd est bien plus qu’un simple remplaçant d’init. Il s’agit en fait d’une suite d’environ 70 binaires qui gèrent l’initialisation du système, les démons et services, la journalisation, et de nombreuses autres fonctions auparavant gérées par des modules dédiés sous Linux. La plupart d’entre elles n’ont aucun rapport direct avec l’initialisation du système.
Voici quelques démons fournis par systemd :
- systemd-udevd: Gestion des périphériques physiques.
- systemd-logind: Gestion des connexions utilisateur.
- systemd-resolved: Résolution des noms de réseau pour les applications locales.
- systemd-networkd: Détection et gestion des périphériques réseau et des configurations associées.
- systemd-tmpfiles: Création, suppression et nettoyage des fichiers et répertoires temporaires.
- systemd-localed: Gestion des paramètres régionaux du système.
- systemd-machined: Détection et supervision des machines virtuelles et des conteneurs.
- systemd-nspawn: Lancement de commandes ou processus dans un conteneur d’espace de noms léger, offrant des fonctionnalités similaires à chroot.
Et ce n’est que la partie visible de l’iceberg, qui constitue également le nœud du problème. Systemd a depuis longtemps dépassé son rôle de simple système d’initialisation, ce qui pour ses détracteurs est la définition même d’un dépassement de périmètre.
« Trop gros, trop de fonctions »
Les adversaires de systemd pointent du doigt l’hétéroclite et large palette de fonctionnalités qu’il englobe. Ces fonctionnalités existaient déjà sous Linux, et certaines nécessitaient sans doute une modernisation. Cependant, l’intégration de toutes ces fonctions dans un système censé être un simple système d’initialisation est déroutant sur le plan architectural.
Systemd a été qualifié de point de défaillance unique pour un trop grand nombre de fonctions critiques, ce qui est un argument qui semble difficile à justifier. Il rejette clairement la philosophie Unix de créer de petits outils collaboratifs, au profit d’un logiciel massif qui fait tout. Bien que systemd ne soit pas un monolithe au sens strict (il se compose de nombreux binaires), il regroupe une pléthore d’outils de gestion disparates.
Même s’il n’est pas monolithique, il est très imposant. Pour avoir une idée de l’échelle, nous avons compté les lignes de code du noyau 5.6.15 et de la branche master de systemd sur GitHub.
Il s’agissait d’une métrique relativement grossière. Elle comptait les lignes de texte, et pas uniquement les lignes de code. Elle incluait donc les commentaires, la documentation, etc. Cependant, cette comparaison nous a donné un point de repère:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Le noyau contenait près de 28 millions (27 784 340, pour être précis) de lignes de texte. En comparaison, systemd en comptait 1 349 969, soit près de 1,4 million. Avec notre métrique approximative, systemd représente environ 5% de la taille du noyau, ce qui est colossal!
À titre de comparaison, le nombre de lignes d’une implémentation moderne de SysV init pour la distribution Arch Linux est de 1721 lignes.
Lennart Poettering n’a visiblement aucune considération pour l’Institute of Electrical and Electronics Engineers (IEEE) Computer Society, ni pour la norme Portable Operating System Interface (POSIX). De fait, il a encouragé les développeurs à ignorer POSIX :
« Alors, prenez une copie de l’interface de programmation Linux, ignorez tout ce qu’elle dit sur la compatibilité POSIX, et développez votre incroyable logiciel Linux. C’est assez libérateur! »
Certains accusent systemd d’être un projet Red Hat conçu pour les intérêts de cette seule entreprise, et imposé de force à l’ensemble du monde Linux. Il est vrai qu’il est né et est géré par Red Hat. Cependant, parmi les 1 321 contributeurs, seule une minorité travaille pour Red Hat.
Alors, quels sont les avantages pour Red Hat ?
Jim Whitehurst, président d’IBM et ancien PDG de Red Hat, a déclaré :
« Red Hat a examiné plusieurs options et a même utilisé Upstart de Canonical pour Red Hat Enterprise Linux 6. Finalement, nous avons choisi systemd parce que c’est la meilleure architecture offrant l’extensibilité, la simplicité, l’évolutivité et des interfaces bien définies pour résoudre les problèmes que nous rencontrons et prévoyons à l’avenir. »
Whitehurst a également mentionné les avantages pour les systèmes embarqués. Red Hat collabore avec « les plus grands fournisseurs de systèmes embarqués au monde, notamment dans les secteurs des télécommunications et de l’automobile, où la stabilité et la fiabilité sont primordiales. »
Ces raisons semblent techniquement valables. On peut comprendre le besoin de fiabilité en entreprise, et il n’est pas irrationnel que Red Hat défende ses propres intérêts, mais est-ce une raison pour que tout le monde fasse de même?
Adopter aveuglément systemd?
Certains opposants à systemd affirment que les distributions et leurs utilisateurs suivent aveuglément l’exemple de Red Hat et l’adoptent sans réfléchir.
Toutefois, comme l’expression « boire le Kool-Aid » l’indique, c’est inexact. Inventée en 1978 suite au suicide collectif de Jim Jones qui a contraint ses 900 disciples à ingérer une boisson aromatisée au raisin au cyanure, cette expression est injuste pour la marque Kool-Aid. Le groupe a consommé du Flavour-Aid, mais Kool-Aid a été associé à cet événement depuis.
Par ailleurs, les distributions Linux n’adoptent pas systemd par réflexe. Cette adoption fait suite à de longues délibérations. Le débat a fait rage sur les listes de diffusion de Debian pendant longtemps. En 2014, la communauté a voté pour adopter systemd comme système d’initialisation par défaut, tout en assurant la prise en charge d’alternatives.
Debian est un exemple majeur, car elle n’est pas dérivée de Red Hat, Fedora ou CentOS. Il n’y a aucune forme de tutelle exercée par Red Hat sur Debian. Et Debian, à l’instar de PID 1, a de nombreux descendants, dont Ubuntu et ses multiples dérivés.
Les décisions prises par la communauté Debian ont une portée considérable. Elles font l’objet de débats intenses et sont soumises à un vote utilisant la méthode de Condorcet. La communauté ne prend pas de telles décisions à la légère.
Elle a voté à nouveau en décembre 2019 pour continuer de se concentrer sur systemd tout en explorant des alternatives. Loin de suivre un mouvement aveuglément, il s’agit d’un bel exemple de démocratie et de liberté de choix en action.
Les limites du choix
Il n’est généralement pas possible de choisir d’utiliser ou non systemd avec une distribution Linux spécifique. Les distributions décident d’elles-mêmes, et c’est vous qui choisissez la distribution qui vous convient. Il se peut qu’une distribution que vous affectionnez ait basculé vers systemd. Un tel changement, comme un groupe de musique favori qui change de genre, peut être perturbant.
Les utilisateurs de Debian, Fedora, CentOS, Ubuntu, Arch, Solus, et openSUSE, opposés à systemd, peuvent se sentir privés de leur distribution favorite. Si leur conviction est suffisamment forte en raison des choix architecturaux, du dépassement de périmètre, ou du non-respect de POSIX, il peut devenir impossible pour eux de continuer à utiliser cette distribution.
Bien sûr, il existe une palette d’opinions. D’un côté, il y a ceux qui ne comprennent pas les enjeux (ou qui s’en fichent), de l’autre, les opposants passionnés. Au milieu se trouvent ceux qui n’apprécient pas le changement, mais pas au point de changer de distribution. Mais qu’en est-il des réfugiés, incapables de rester sur leur distribution préférée pour des raisons de préférences ou de principes ?
Malheureusement, installer un système d’initialisation de son choix n’est pas aussi simple que ça. Tout le monde n’a pas les compétences techniques nécessaires, sans compter les problèmes que posent les dépendances vis-à-vis de systemd pour des applications ou environnements de bureau, comme GNOME .
Qu’en est-il de passer à une autre distribution? Certaines, comme Devuan, sont apparues comme des forks de distributions (ici, Debian) ayant adopté systemd. L’utilisation de Devuan est censée être similaire à la distribution d’origine, ce qui n’est pas le cas pour tous les forks « non-systemd ». Par exemple, si vous quittez Fedora pour passer à AntiX, Gentoo, ou Slackware, votre expérience sera radicalement différente.
Une présence durable
J’apprécie certaines des fonctionnalités de systemd (les mécanismes de contrôle standardisés des processus). Je ne comprends pas la logique d’autres (les journaux binaires). Je n’aime pas certaines de ses actions (la réorganisation des dossiers de démarrage : qui a bien pu demander ça ?).
Des distributions comme Debian font preuve de sagesse en explorant des alternatives afin de ne pas se fermer des portes. Cependant, systemd est là pour durer.
Si vous administrez des machines Linux pour d’autres, familiarisez-vous avec systemd et SysV init. De cette façon, vous serez en mesure de faire face à toutes les situations.
Vous utilisez Linux à la maison? Dans ce cas, choisissez une distribution qui répond à la fois à vos exigences techniques et à votre idéologie Linux.