URL: https://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-libere Title: systemd : l’init martyrisé, l’init bafoué, mais l’init libéré ! Authors: Collectif ariasuni, M5oul, esdeem, BAud, Stéphane Aulery, xcomcmdr, Anonyme, Nicolas Boulay, Benoît Sibaud, Kaane, Sidonie_Tardieu, Jiehong, Davy Defaud, rogo, Nÿco, _PhiX_, Nils Ratusznik, Anthony Jaguenaud, anaseto, francis latouche, err404, Thomas Debesse, Spyhawk, Nicolas Casanova, NeoX, patrick_g, plietar, Moonz, alendroi, zurvan, GCN, Pierre Jarillon, karteum59, Michaël, Enj0lras, needs, Laurent Pointecouteau, eingousef, woprandi, coid, bubar🦥, jcr83, Cyril Brulebois, François, jseb, Storm, Sébastien Le Ray, vg, Sak, djabal, palm123, Malizor, Yann LD et yohann Date: 2014年11月16日T11:20:31+01:00 License: CC By-SA Tags: systemd, debian, ubuntu, slackware, selinux, lwn et alpinelinux Score: 127 _systemd_ est un projet composé de trois parties distinctes : - un processus d’initialisation, `systemd`, qui s’occupe de gérer le démarrage, du lancement du noyau Linux à l’interface graphique, et de la surveillance des processus ; - un ensemble d’outils qui contrôlent le processus _systemd_, notamment `systemctl`, et qui permettent, entre autres, de suivre, redémarrer et arrêter les différents services d’une machine ; - un jeu d’outils qui peuvent être utilisés comme base pour la création d’un système d’exploitation complet — un peu à la manière de ce que le projet GNU propose, mais avec une portabilité beaucoup plus réduite. La première version de _systemd_ a été publiée le 30 mars 2010. Presque cinq ans plus tard, quasiment toutes les distributions majeures l’ont adopté. Remplaçant un composant central du système, il n’est pas étonnant que l’arrivée de _systemd_ ait provoqué de nombreuses réactions. Elles ont parfois été violentes, mais pourquoi au juste ? Cette dépêche éminemment collective (à peu près tous les contributeurs habituels sont venus participer, pour faire court) présente un état des lieux des opinions en présence, dans une démarche de remise à plat et d’apaisement, un peu similaire à celle entreprise ici ou [là](http://uselessd.darknedgy.net/ProSystemdAntiSystemd/) et visible [ici](//linuxfr.org/tags/systemd/public). ---- [Site officiel du projet systemd](http://freedesktop.org/wiki/Software/systemd/) [Article Wikipédia sur systemd](https://fr.wikipedia.org/wiki/Systemd) [Journal « Pourquoi les zélateurs et détracteurs de systemd ne s’entendront jamais »](https://linuxfr.org/users/mrspackman/journaux/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais) [Systemd: The Biggest Fallacies](http://judecnelson.blogspot.fr/2014/09/systemd-biggest-fallacies.html) ---- # Introduction Les discussions sont souvent enflammées concernant systemd, et comme le sujet est un peu technique, il est parfois difficile de s’y retrouver. Pas de panique, il vous est expliqué de façon simple ce qu’est systemd, comment il se démarque des systèmes qu’il est censé remplacer, ainsi que les arguments des parties en présence. ## Démarrage du système Lorsqu’un ordinateur démarre, il initialise les différents composants de l’ordinateur (processeur, mémoire vive, disque dur, carte graphique, etc.) et effectue quelques vérifications basiques, puis démarre le cœur du système d’exploitation : le noyau (ici, Linux). En effet, c’est la partie qui communique directement avec les périphériques comme le clavier, la souris, la mémoire ou l’écran et permet leur utilisation. Lorsque le noyau est chargé, l’ordinateur n’est pas encore prêt à l’emploi. Le noyau délègue au système d’initialisation le lancement du reste du système, selon la configuration établie par l'administrateur. Il lance les services d'arrière-plan (montage des périphériques de stockage, configuration du réseau, messagerie...) et l'interface utilisateur, qu’elle soit graphique ou pas. Le système d’initialisation possède aussi une autre fonction : récupérer les processus qui sortent de leur session. En effet, dans tous les _Unix-like_ -- et cela inclut GNU/Linux -- tous les processus doivent avoir au moins un processus père, sauf le tout premier processus lancé (PID 1). Si un processus renie son père (on dit qu'il est _démonisé_), le noyau le rattache alors au premier processus. Hormis le noyau, il est donc le premier processus lancé sur la machine (ce qui explique l’appellation « PID 1 » — « processus n°1 ») et le dernier à s'arrêter, car il contrôle tous les autres. Par conséquent, le système d’initialisation est un composant critique du système car s’il ne fonctionne pas, la machine ne démarre pas. D’où sa robustesse requise. Jusqu'à récemment ce programme était souvent SysVinit, mais des remplaçants, plus ou moins compatibles, se sont multipliés ces dernières années, comme [Upstart](http://upstart.ubuntu.com/) qui est l'init par défaut d'Ubuntu. Un init de type SysV fonctionne comme suit : il lit le fichier `/etc/inittab` qui lui indique quoi faire à un niveau d'exécution ([runlevel](http://fr.wikipedia.org/wiki/Run_level)) particulier, puis il démarre, redémarre ou arrête automatiquement les services selon le niveau choisi par l'utilisateur. La syntaxe de ce fichier n’étant pas [turing complète](http://fr.wikipedia.org/wiki/Turing-complet), les administrateurs ont préféré déléguer l’essentiel du démarrage à des scripts `rc` nommés dans ce fichier et appelés par `init`. Ces scripts sont aujourd’hui décriés à cause du travail dupliqué entre les distributions, de la difficulté réelle ou supposée de les maintenir et de leurs limites. Sont-elles supposées ou avérées ? Là est toute la question ! Quelques exemples : - tous ne sont pas, par exemple, forcément compatibles avec des composants tels que selinux (ou autre [LSM](Linux Security Modules) à la mode) ; - il est difficile de lancer un service uniquement suite à un événement. Par exemple, lors du branchement d’une clé USB ; - il est difficile de s'assurer qu'un service (par exemple, sshd) sera relancé automatiquement en cas d'arrêt. Le système d’init nécessite un travail d’intégration important dans la distribution ; il ne peut donc pas, la plupart du temps, être changé facilement par l’utilisateur. ## Adoption de systemd (bonus image Commitstrip : [Systemd World : le parc est ouvert](http://www.commitstrip.com/wp-content/uploads/2014/12/Strip-SystmeD-650-final.jpg)) [systemd est utilisé ou sera utilisé sur](https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception) : - Fedora depuis presque 4 ans, - openSUSE, Mageia, Arch Linux depuis plus de 2 ans, - RHEL (Red Hat Entreprise Linux) et SLES (SUSE Linux Entreprise Server) depuis moins d’un an, - Debian 8.0 et Ubuntu 15.04. Il y a cependant deux absents parmi les distributions majeures : - Gentoo, qui utilise par défaut [OpenRC](http://www.gentoo.org/proj/en/base/openrc/) (une implémentation moderne du format traditionnel SysV), mais laisse la possibilité d’utiliser systemd ; - Slackware, dont la philosophie l’a souvent poussé à adopter les nouvelles technologies bien après les autres distributions. Dans les distributions moins connues, on peut aussi citer [Linuxconsole](http://distrowatch.com/table.php?distribution=linuxconsole) ou [Crux](https://linuxfr.org/news/crux-3-1-une-distribution-kiss-a-la-saveur-bsd). C’est un logiciel relativement jeune pour un composant d’une telle importance. Son adoption a été fulgurante et beaucoup de personnes pensent que ce changement a été trop rapide, pas assez réfléchi, voire carrément forcé. En dehors de l’adoption des logiciels eux-mêmes, la philosophie de systemd a rencontré de l’écho auprès de [FreeBSD qui envisage de développer un système d’initialisation dont le fonctionnement est plus proche de systemd](http://www.phoronix.com/scan.php?page=news_item&px=MTg0ODE). ## Qu’est‐ce qui différencie systemd du système précédent ? Tout d’abord, quelques explications techniques. Le projet systemd est écrit avec le langage de programmation C. Il s’agit d’une collection de logiciels sous forme de binaires. Le pilotage des services se fait grâce à des fichiers de configuration. À première vue, cela ressemble à SysV ([écrit en C](http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/?root=sysvinit), formé de trois exécutables et configuré par le fichier « inittab »), mais la grande différence est que SysV suit une approche minimaliste qui déplace une grande partie de l'initialisation des services dans des programmes écrits en Shell et utilisant des bibliothèques externes (par exemple, « start-stop-daemon » pour l'init Debian). À contrario, systemd implémente un large éventail d'actions afin de décourager l'utilisation de scripts de lancement. En pratique, un service SysV pour sshd a pour élément central un script de quelques centaines de lignes (script Shell qui peut être utilisé indépendamment de l'init), alors que sous systemd le service sera généralement piloté par un fichier texte d'une dizaine de lignes (dans une syntaxe spécifique à systemd). On vante souvent la simplicité des anciens systèmes d’init : en effet, quoi de plus simple que des fichiers textes exécutables, certes pas forcément triviaux, mais dont on peut lire l’exécution ligne par ligne ? En éditant ces fichiers, on a une maîtrise totale du démarrage de l’ordinateur (à partir du moment où l’on est capable de comprendre le code). Mais modifier le système d’init en lui-même peut poser problème lors de mises à jour ou simplement parce que ce code n’a pas été testé. Systemd remplit les mêmes fonctions que les précédents systèmes, mais il met l’accent sur la simplicité d’utilisation et sur une maîtrise du système plus poussée et moins éparpillée, ce qui est parfois vu comme l’opposé de la [philosophie Unix](https://fr.wikipedia.org/wiki/Philosophie_d%27Unix). Ainsi, beaucoup de choses qui nécessitaient auparavant de modifier des scripts Shell existent maintenant sous la forme d’un simple paramètre dans un fichier. Le comportement est codé dans systemd ce qui permet de mutualiser beaucoup de code et de rendre les fichiers souvent beaucoup plus courts. Pour la plupart des gens, utiliser systemd ou SysVinit ne fait aucune différence, y compris pour la vitesse de démarrage ; pour bidouiller, tout dépend des outils que l'on maîtrise, soit les outils systemd et leur syntaxe de configuration, soit la programmation Shell, les outils de suivi de processus et la configuration SysV. ## Alternatives ###Upstart Créé pour Ubuntu, est la seule alternative adoptée par des distributions de famille différentes (RHEL et Fedora, openSUSE). Aujourd’hui, la décision de Debian d’adopter systemd pour sa prochaine version stable a poussé Ubuntu à lui emboiter le pas, Upstart sera donc probablement abandonné. ###OpenRC Développé et utilisé par Gentoo, est l’alternative à systemd la plus souvent citée. Elle est basée sur un init SysV traditionnel, un cœur en C compilé et des scripts Shell. Pour résumer, OpenRC est plus simple, son cœur possède moins de fonctionnalités que systemd et il ne dépend pas de Linux. ###[Uselessd](http://uselessd.darknedgy.net/) C'est un fork jeune et non-stable de systemd. De nombreuses fonctionnalités ont été supprimé, et on peut utiliser [musl](http://www.musl-libc.org/) ou [uClibc](http://www.uclibc.org/about.html) (principalement pour l’embarqué, mais pas uniquement : par exemple des distributions légères comme [Alpine](http://alpinelinux.org/) y ont recours) là où l’auteur principal de systemd [refuse de prendre en compte d’autres libc que la glibc](https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg23523.html). ---- D'autres systèmes d'init moins connus ont aussi vu le jour par le passé : on se souvient du [système d'init de Pardus](https://web.archive.org/web/20110928130624/http://www.pardus.org.tr/eng/projects/comar/SpeedingUpLinuxWithPardus.html), de [InitNG](http://www.initng.org/), d’expérimentations [à base de make -j ...](https://web.archive.org/web/20041018075532/http://www-106.ibm.com/developerworks/linux/library/l-boot.html?ca=dgr-lnxw04BootFaster), de [runit](http://smarden.org/runit/), [fastboot](http://fastboot.org/) et d'autres encore. Aucun d'eux n'a percé, même si certains véhiculaient de bonnes idées. À la suite du rejet par le comité Debian de maintenir par défaut deux systèmes d’initialisation différents, les responsables du site [Debian fork](http://debianfork.org/) ont annoncé qu’ils forkeraient effectivement Debian. La distribution, nommée [Devuan](http://devuan.org/), sera donc une Debian sans systemd. Une collecte de fonds a été lancée pour soutenir le démarrage du projet. Le système d’initialisation de Devuan n'est pas encore connu. ## Apports de systemd Comme on le voit, l’adoption de systemd est loin de s’être faite sans heurts. Quels avantages ont permis à systemd de contrebalancer l’avalanche de critiques, lors des décisions concernant son adoption ? Tout d’abord, techniquement, il ne faut pas perdre de vue que systemd apporte certaines fonctionnalités qui ne se retrouvaient pas dans l’ancien système. En voici une liste non-exhaustive : * Allocation fine des ressources (processeur, mémoire, E/S, etc) aux services, grâce aux fonctionnalités avancées du noyau comme les cgroups ; * Surveillance améliorée (grâce aux cgroups, un processus ne peut pas s'échapper, même en forkant) ; * Log plus complet (commençant plus tôt, comprenant aussi la sortie standard et les sous-processus, proposant un aperçu centralisé de l’état des services ou un résumé des erreurs de démarrage...) ; * Possibilité de *démoniser* tout processus en le relançant automatiquement s'il s'arrête (à la façon de "runit", bien au-delà de ce que permet "start-stop-daemon") ; * Séparation claire entre les services fournis par la distribution et les services créés par l’administrateur, avec la possibilité pour l’administrateur de personnaliser les scripts de la distribution sans avoir à les dupliquer ; * Système de template dans les unités de lancement (par exemple un seul fichier getty@.service peut être utilisé pour gérer un nombre arbitraire d’instances : getty@tty1.service, getty@tty2.service...). À un niveau moins technique, systemd est le seul projet à apporter les espoirs suivants dans le monde GNU/Linux : * Centralisation du développement des briques de base du système, ce qui permet une certaine normalisation entre différentes distributions GNU/Linux ; * Simplification du processus d’empaquetage des services en maintenant un seul fichier service en amont ; * Normalisation des formats de logs, grâce à journald. Ces points sont moins techniques car auraient très bien pu être réalisés avec l’ancien système pour peu que les distributions et les différents projets aient pu se mettre d’accord ; il reste toutefois au crédit du projet systemd d’avoir réussi à lancer cette dynamique. # Arguments et points de débat ## Philosophie UNIX La philosophie UNIX est plutôt : au lieu d’écrire un gros logiciel pour résoudre un problème, écrire plein de petits logiciels qui se concentrent sur une étape de la résolution du problème, fonctionnent orthogonalement et utilisent un protocole clair. L’intérêt est qu’avec cette stratégie, il est beaucoup plus facile d’adapter son travail pour résoudre un problème « voisin » et qu’on résout potentiellement beaucoup plus de problèmes (plus les composants sont orthogonaux, plus la combinatoire de ces composants est intéressante). _Cf._ : . La limite de ce modèle est quand diverses couches doivent intervenir. Les logiciels sont alors sur des sables mouvants, les interdépendances devenant importantes. Il est quasi impossible de faire évoluer les logiciels indépendamment. L'exemple typique est la crosscompilation de Linux, GCC et la libc qui ne fonctionnent que pour des versions bien précises. Un des reproches que l'on fait souvent à systemd est son non-respect de la philosophie Unix. Son résumé le plus connu est celui fait par [[Douglas McIlroy]] :> Écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. Comme tous les aphorismes, derrière ces quelques mots se cache une réalité plus complexe ; ainsi, Eric Raymond décrit environ [17 règles](http://fr.wikipedia.org/wiki/Philosophie_d%27Unix#Raymond_:_L.27Art_de_la_Programmation_Unix), qu’il explicite dans son livre [[L'Art de la Programmation Unix]]. On peut par exemple y lire (chapitre 4) une mise en garde contre une interprétation trop superficielle de cette citation :> Le conseil de Doug McIlroy « faire une seule chose, et la faire bien » est souvent compris comme un conseil de simplicité. En fait, il porte aussi sur l’orthogonalité, ce qui est au moins aussi important. L’orthogonalité est importante car elle garantit l'indépendance réelle. Ainsi l'usage du texte comme format d'échange est primitif, mais a le bon goût de rester un format stable dans le temps. Autrement dit, dans la philosophie Unix, l’approche pour résoudre un problème est d’écrire plein de petits logiciels qui se concentrent sur une étape de la résolution du problème, fonctionnent orthogonalement et utilisent un protocole clair, au lieu d'écrire un gros logiciel. De ce point de vue, la principale critique faite à systemd est de ne pas respecter ces principes d’indépendance et d’orthogonalité (on ne peut pas, par exemple, séparer la gestion du cycle de vie des services de la gestion des cgroups). Pire encore, systemd tend à détruire l’orthogonalité dans des parties qui l’étaient précédemment ; ainsi Lennart a annoncé récemment que udev nécessiterait systemd, alors que les deux problématiques « gestion du matériel » et « gestion de l’initialisation du système » étaient clairement séparées auparavant. Le monde des _Unix-like_ possède en fait plusieurs philosophies — qui toutes tendent vers le même but : rassurer l'utilisateur et l'administrateur système. La chose la plus importante pour une entreprise (ou pour un professionnel de façon générale) est la pérennité de ce qu'il crée. Rien n'est plus désagréable que de mettre en place une méthode de travail pour créer des outils et des produits et de devoir tout mettre à la poubelle du jour au lendemain pour cause de changement massif dans la technologie. C'est parfois nécessaire, la technologie évoluant, mais c'est rarement bien accueilli. De fait, les différentes philosophies existantes dans le libre sont là pour permettre aux professionnels de s'investir sereinement dans une technologie. Parmi les plus populaires, on a le [KISS](http://fr.wikipedia.org/wiki/KISS_principle) (_Keep It Simple, Stupid_), le [[rasoir d'Ockham]] et le [_Don't Repeat Yourself_](http://fr.wikipedia.org/wiki/Ne_vous_r%C3%A9p%C3%A9tez_pas). De plus, chaque gros projet a une philosophie ou, en tout cas, met l'emphase sur un aspect de leur stratégie de développement, toujours dans le but de rassurer l'utilisateur. Pour le noyau Linux, le mot d'ordre est : « ne jamais casser l'expérience utilisateur ». En d'autres termes une correction ne doit jamais entraîner de régressions touchant l'espace utilisateur ([Linus est très attaché à cela](http://marc.info/?l=linux-kernel&m=135628421403144&w=2)). Pour FreeBSD, il s'agit de respecter le [principe de la moindre surprise](http://fr.wikipedia.org/wiki/Principe_de_moindre_surprise). Pour OpenBSD, le but est la sécurité et la chose la plus mise en avant est le respect de [séparation des privilèges](http://fr.wikipedia.org/wiki/s%C3%A9paration_des_privil%C3%A8ges). Concrètement, [chaque outil de systemd fait une chose et la fait bien et tous ces outils sont développés ensemble afin de fournir une « boîte à outils »](http://marmaro.de/docs/studium/unix-phil/unix-phil.pdf) [cohérente](http://fr.wikipedia.org/wiki/Principe_de_moindre_surprise), un peu comme certains *BSD maintiennent tout un tas d’outils de base dans un même dépôt. Systemd en tant qu'ensemble se focalise grandement sur l'aspect « Don't Repeat Yourself » les redondances de code sont limitées au maximum et les étapes de démarrage sont factorisées autant que possible. Cela garantit une bonne maintenabilité du code et évite de devoir agir sur plusieurs éléments séparés du code pour corriger un problème. Et il s'appuie aussi une approche type « rasoir d'Ockham », on enlève tout ce qui n'est pas strictement nécessaire. [Repenser le PID 1](http://0pointer.de/blog/projects/systemd.html). Cependant, l'approche a des défauts, le PID 1 (systemd init) se retrouve à faire de très nombreuses choses (démarrage, suivi, restrictions de droits, application de cgroups, escalade de privilèges, changements de priorité, etc.). C'est une conséquence de la factorisation du code, les fonctions qui permettent (par exemple) de lancer, arrêter et suivre un processus sont souvent très liées, pour éviter de dupliquer du code il faut donc que ces fonctions soient dans le même processus. Un autre défaut de l'approche systemd est que de nombreux processus deviennent fortement interdépendants. L'init systemd a absolument besoin de udev et de journald pour fonctionner par exemple, et bien que les binaires soient disjoints - ils sont fortement couplés (cf section plus bas). Pour finir, dans un souci de simplicité et pour conserver la maintenabilité du projet dans son ensemble, systemd n'hésite pas à couper les ponts avec l'existant ou à intégrer des fonctionnalités de base dans son sein, puis à les faire évoluer dans son sens. C'est sûrement ce dernier aspect qui pose le plus de problèmes, notamment avec l'intégration de udev (processus chargé de matérialiser coté utilisateur les différents périphériques connectés) dans le projet systemd. En l'absence de vision claire la distribution Gentoo a décidé de forker udev (c.-à.-d. développer en parallèle une version plus adaptée à leurs besoins) [udev-ng vs eudev](http://lwn.net/Articles/525773/) Dans cet article, Greg KH annonce que le projet systemd n'a pas de buts à long terme bien définis, mais qu'il va forcer la main des distributions pour qu'elles suivent une structure dans laquelle les modifications sont sous contrôle, plutôt que de continuer à réinventer la roue en permanence. Deux ans plus tard, Lennart Poettering annonce que les nouvelles versions de udev seront incompatibles avec les anciennes et devront nécessairement reposer sur un noyau récent (utilisation de kdbus). [C'est le dernier avertissement pour Gentoo](http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html) Le projet systemd fournit environ 80 binaires. Parmi ces binaires, quelques exemples : - /sbin/init ([systemd](http://www.freedesktop.org/software/systemd/man/systemd.html)) ne s'occupe que de l'init ; - [journalctl](http://www.freedesktop.org/software/systemd/man/journalctl.html) ne s'occupe que de consulter le journal ; - [udev](http://www.freedesktop.org/software/systemd/man/udev.html) s'occupe de découvrir les périphériques et peupler /dev ; - [hostnamectl](http://www.freedesktop.org/software/systemd/man/hostnamectl.html) s'occupe de la gestion du nom d'hôte (_hostname_) de la machine ; - [machinectl](http://www.freedesktop.org/software/systemd/man/machinectl.html) s'occupe de la gestion des conteneurs lancés par systemd ; - [coredumpctl](http://www.freedesktop.org/software/systemd/man/coredumpctl.html) s'occupe des vidanges système (_core dump_) ; - [systemd-analyze](http://www.freedesktop.org/software/systemd/man/systemd-analyze.html) s'occupe d'inspecter la vitesse du démarrage ; - [systemctl](http://www.freedesktop.org/software/systemd/man/systemctl.html) permet de gérer les services. D'un point de vue sécurité, systemd limite aussi les droits et capacités des services qu'il lance (il permet par exemple à Xorg — et Weston — d'être lancé sans qu'il soit root) appliquant ainsi [la séparation des privilèges](http://fr.wikipedia.org/wiki/s%C3%A9paration_des_privil%C3%A8ges). ## Couplage fort vs couplage faible Tout d'abord il faut bien comprendre ce qu'est le [couplage](http://fr.wikipedia.org/wiki/Couplage_%28informatique%29). Lorsque deux outils informatiques doivent interagir l'un avec l'autre et s'échanger des informations, on dit qu'ils sont couplés et la force de ce couplage est évaluée en termes de modifications à faire dans un logiciel quand l'autre évolue. Jusqu'ici, SysVinit était faiblement couplé avec le noyau Linux : SysV n'utilisait que le strict minimum des API de Linux pour démarrer. Systemd change très fortement la donne à ce niveau là. Systemd profite de [multiples API du noyau](http://0pointer.de/blog/projects/the-biggest-myths.html) pour contrôler et gérer les services, notamment : * les [control groups](http://lwn.net/Articles/603762/) ; * [inotify](http://linuxfr.org/news/exploiter-inotify-c-est-simple) ; * les [capabilities](http://lwn.net/Articles/420624/) ; * les [namespaces](http://lwn.net/Articles/531114/) ; * [audit](http://lwn.net/Articles/79326/) ; * [fanotify](http://lwn.net/Articles/339399/). C'est là d'où vient tout son intérêt et sa fiabilité. Mais, au fur et à mesure de ses évolutions, systemd n'hésite pas à se détacher des anciennes versions du noyau, des anciennes versions de D-Bus et udev ou encore des outils systemd précédents. [Exemple](http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html) :>Soyons clair, on s'attend à ce que systemd et le noyau soient mis à jour simultanément. On ne prend pas du tout en charge le mélange d'un noyau vraiment vieux avec un systemd vraiment récent. Jusqu'ici, on s'est concentré sur la prise en charge par systemd du noyau, jusqu'à une version antérieure de 2 ans (ce qui veut dire la 3.4 actuellement), mais même cela devrait être considéré avec précaution. L'avantage de cette méthode est qu'elle permet d'avoir un ensemble limité de situations à prendre en compte et, de fait, limite les problèmes de rétrocompatibilité au minimum. L'inconvénient est que la masse de tests à faire pour monter en version est nettement accrue. En effet une mise à jour de systemd signifie nécessairement une mise à jour de udev et peut signifier une mise à jour de D-Bus, du noyau, des stratégies cgroups/SELinux, voire d'une partie de la hiérarchie de fichiers. Dans un environnement où l'administrateur n'a pas forcément la maîtrise intégrale de ses systèmes (par exemple, pilotes propriétaires pour une baie de disque, programmes propriétaires ou non maintenus, mais nécessaires au fonctionnement de l'entreprise, hébergement de services ou de machines virtuelles pour des clients) - les tests peuvent être très complexes, voire impossibles à faire. La capacité à faire les mises à jour sereinement est mise à mal. Cependant, la capacité à ne pas mettre à jour l'ensemble du système et à bricoler avec une vieille version du noyau (par exemple) est, elle, complètement oblitérée. Plus on prend de retard sur des mises à jour systemd, plus la quantité de tests à faire pour s'assurer d'une non régression augmente et plus il va être dur de faire corriger les soucis rencontrés en _upstream_. Les mises à jour sont donc complexes à faire, mais la non mise à jour n'est pas une option envisageable, même à court terme (systemd évolue à grande vitesse et des changements majeurs non rétrocompatibles se produisent tous les six mois environ — dernier en date udev nécessite désormais kdbus). On peut donc comprendre une certaine réticence vis-à-vis de ce couplage fort par tout administrateur qui a soit de nombreux services au sein de son service informatique (i.e. beaucoup de tests), soit des applications fermées (i.e. d'un jour à l'autre, il va falloir lancer en urgence une migration parce que l'application X ne fonctionnera plus). ## Journaux au format binaire Il est reproché à systemd d'avoir des journaux systèmes (ou *logs*) au format binaire, alors que Syslog les stocke au format texte. Cela permet notamment : - de disposer de fonctions de recherche puissantes via `journalctl` (filtrage par date, application, etc., un peu comme une base de données) ; - d’intégrer des données binaires — telles que la vidange (_dump_) d’un résultant d’un plantage — directement dans le journal ; - de ne pas laisser n’importe qui ayant un accès root le pouvoir de modifier le journal (tel qu’un intrus voulant effacer ses traces). Cependant, pour pouvoir traiter les journaux avec les outils qu’on utilise habituellement pour manipuler du texte, il faut utiliser journald. Cela signifie qu’en cas de problème, le format binaire ne peut pas être lu par une plateforme ne disposant pas de systemd. D’autre part, l’indexation automatique de journald ne concerne que des éléments internes et connus, la recherche d'un élément arbitraire (par exemple une poignée de main SIP) nécessite toujours une recherche complète ou l’utilisation d’un système d’indexation externe type plein texte. Un fichier binaire est plus sensible à la corruption qu’un fichier texte ; par exemple, il suffit généralement d’écrire une suite aléatoire de caractères au début du journal pour rendre l’ensemble du fichier inexploitable. Une autre technique consiste à apposer un sceau (seal) au début. Cependant, comme avec syslog, les journaux sont répartis en plusieurs fichiers et journald est capable de gérer certains types de corruptions. Cela étant dit, des journaux qui se corrompent facilement peuvent devenir une vraie difficulté pour les administrateurs système quand ils doivent diagnostiquer des problèmes. D’autre part, le format binaire de journald lui permet d'être actif très rapidement, et de mettre en log le tout début de l’initialisation de l'espace utilisateur qui était jusqu'alors non supervisable. Un flux binaire a besoin de nettement moins de fonctions du noyaux actives. On n’a, par exemple, pas besoin des locales, des maps de caractères, de faire attention aux caractères de contrôle, etc. Cependant, il est tout à fait possible de paramétrer journald pour envoyer tous les journaux à syslog, retrouvant ainsi le format texte avec des informations supplémentaires (en effet, journald est capable de récupérer des informations plus tôt pendant le démarrage). ## L’embarqué Les fonctionnalités et la maîtrise qu’offre systemd se paye en terme de ressources utilisées. Par exemple, [un développeur Debian nous apprend](https://people.debian.org/~stapelberg/docs/systemd-dependencies.html) que systemd nécessite 236 kio à 550 kio de bibliothèques additionnelles à charger en mémoire et que la taille résidente en mémoire est de 1,8 Mio, soit 1 Mio de plus que Sysvinit. Autant dire que même sur un Raspberry Pi, ça ne fait aucune différence à l’utilisation. Si [systemd est aussi conçu pour et utilisé sur des plateformes embarquées](https://events.linuxfoundation.org/sites/events/files/slides/OSELAS.Presentation-Embedded-Systemd.pdf), systemd peut se révéler trop gourmand sur certaines configuration particulièrement limitées. D’ailleurs, systemd ne fonctionne qu’avec la glibc et ne peut pas être utilisé, par exemple, avec les bibliothèques standards C plus légères qu’on retrouve sur certains systèmes embarqués. ## Réécriture d’outils On dit souvent que systemd réinvente la roue (syndrome [NIH](https://fr.wikipedia.org/wiki/Not_Invented_Here)). En effet, systemd intègre des fonctionnalités fournis par d’autres logiciels (par exemple, inetd ou cron). Cela permet à systemd de rendre ces fonctionnalités plus faciles à utiliser par systemd et par l’utilisateur. systemd propose aussi des outils ayant comme but d’être des alternatives plus simples (moins de code), légères (moins de fonctionnalités) et sécurisées (moins de privilèges nécessaires) par rapport aux outils qui existent déjà, lesquels sont relégués au traitement des cas les plus complexes. Au final, beaucoup de personnes se sont inquiétées de voir systemd réécrire et maintenir des outils qui existaient déjà, doutant de l’utilité réelle de ce travail en comparaison de la charge de développement et de maintenance supplémentaire. ## L’étendue du projet systemd Un argument important porte sur la forme du projet beaucoup plus que le fond technique. En effet, ce qui au départ n’était qu’un projet de système d’initialisation englobe désormais tout un tas d’autres outils et est défini par ses mainteneurs comme une plateforme modulaire qui fait la glu entre les applications et le noyau Linux. Cette plateforme est développée comme un écosystème à la BSD, c’est pourquoi les outils jugés nécessaires sont tous développés en interne et maintenus dans le même dépôt. Il est alors légitime de s’inquiéter qu’un seul projet maintienne autant d’outils importants si on n’a pas confiance (que ça soit techniquement ou que ça soit des relations qu’ils entretiennent avec les autres projets). D’autre part, certains outils sont difficiles à utiliser sans systemd comme udev (cf. [udev](#udev)), ce qui pose des interrogations quant à la possibilité de réutiliser ces composants ailleurs (comme on pourrait l’attendre d’un outil Unix). En effet, il est devenu compliqué d’utiliser udev seul pour les distributions n’utilisant pas systemd, au point qu'on lui associe souvent, par abus de langage, le slogan [adopte, étend et étouffe](https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish). L’équipe de développement de Gentoo a créé un fork d’udev [nommé eudev](http://www.gentoo.org/proj/en/eudev/) qui fonctionne sans systemd. C’est évidemment du travail en plus pour Gentoo mais n’importe quelle distribution peut maintenant utiliser eudev pour se passer de systemd. ![systemd le gros hippopotame qui mange tout sur son passage](http://www.developpez.com/public/images/news/systemd.png) ## Influence de Red Hat dans le développement de systemd On reproche de temps en temps à systemd d’être le produit de Red Hat pour couler GNU/Linux (c’est rarement dit de manière plus subtile). Mais plus précisément, on reproche à Red Hat de forcer l’adoption de leurs logiciels. Il faut rappeler que 26 personnes ont droit de commit sur le projet et 40 personnes contribuent tous les mois. D’un autre côté, Red Hat emploie 3 des 4 plus gros contributeurs à systemd, à savoir Lennart Pottering, Kay Sievers (développeur de udev) et Tom Gundersen (qui est aussi développeur Arch Linux). Pourtant, les équipes de maintenance des distributions ont surement longuement réfléchi avant de choisir d’inclure ou non systemd, car c’est loin d’être un changement trivial. Le fait que Red Hat engage des gens pour travailler dessus est un point positif, c’est sûr, mais c’est loin d’être le seul critère pour l’intégration ou non de systemd. ## Dépendance de GNOME à systemd Depuis la version 3.8, GNOME dépend de systemd pour certaines fonctions liées à la gestion de l’énergie et aux paramètres système. En réalité, systemd fournit une fonctionnalité utile via une interface documentée que le projet GNOME a décidé d’utiliser pour se simplifier la vie, plutôt que ConsoleKit qui n'est plus maintenu depuis plusieurs années. Cela a permis à Ubuntu de réimplanter l’interface pour faire fonctionner GNOME et donc a permis à [Ubuntu GNOME](http://ubuntugnome.org/) de naître. Il est logique que systemd expose de nouvelles interfaces de programmation pour accéder au matériel, et il est compréhensible que GNOME veuille en tirer parti. Il est cependant dommage que le fait d’utiliser GNOME sans systemd demande du travail supplémentaire aux distributions utilisant un autre système d’init. Cela est toutefois cohérent avec la politique de GNOME de réduction du nombre de fonctionnalités. Jusqu'à présent, les autres environnements de bureau ont été plus prudents et essaient d’éviter les dépendances les liant à un système d’exploitation en particulier ou demandant un travail d’intégration supplémentaire. Par exemple, [KDE](http://blog.davidedmundson.co.uk/blog/systemd-and-plasma) et [Xfce4](https://bugzilla.xfce.org/show_bug.cgi?id=8729) tirent parti des avancées de systemd mais fonctionnent sans. Cela demande plus de travail, mais on peut espérer dans le futur que des projets comme [systembsd](http://undeadly.org/cgi?action=article&sid=20140915064856) permettent de profiter de certaines fonctionnalités de systemd sans lui et de se débarrasser du vieux code. ## Attitude des développeurs de systemd ### Lennart Poettering C’est l’auteur de systemd, qui mène toujours aujourd’hui en grande partie son développement. Il est employé par Red Hat pour travailler sur systemd. Il a développé PulseAudio, le logiciel qui gère le son dans la majorité des distributions GNU/Linux. Pourtant, PulseAudio a une mauvaise réputation. Il est souvent désigné coupable par défaut des problèmes de son. L’[histoire](http://www.cio.com.au/article/320807/open_source_identity_pulseaudio_creator_lennart_poettering/) est en réalité [bien plus complexe](http://0pointer.de/blog/projects/jeffrey-stedfast.html). Certains affirment également que « systemd est un jouet qu’il abandonnera quand il en aura marre », rappelant qu’il a abandonné le développement d’[Avahi](https://fr.wikipedia.org/wiki/Avahi_%28logiciel%29). Ce dernier est également peu apprécié à cause de son fonctionnement parfois jugé intrusif. Bref, si parler du comportement des développeurs de systemd est pertinent, il faut éviter de tomber dans le piège de l’[[Argumentum ad personam]] qui n’indique pas grand chose sur la qualité du logiciel. ![Meme](http://www.quickmeme.com/img/79/79b417d9f7891d01de224c362000f90def509ca26398c04072d5ce6701eaea32.jpg) Il y a un poste pour les adorateurs de L. Poettering : [Startup and Shutdown System Expert] (https://jolla.com/jobs) # Conclusion Voilà, à présent vous devriez mieux comprendre les débats enflammés concernant systemd. systemd apporte plein de bonnes choses, mais a aussi ses points négatifs et il devient de plus en plus difficile de s’en passer. Après tout, [utiliser des logiciels libres, c’est une question de choix... non ?](http://pusling.com/blog/?p=366) Cette dépêche ne prétend pas être parfaitement neutre, mais grâce à la participation de courants opposés dans une relative bonne ambiance où chacun à fait des concessions, elle essaie d’être au plus près des faits et d’apporter pour chaque argument un contre-argument. ----- # Les titres de dépêche auxquels vous avez échappé - Pourquoi systemd existe ? - systemd a-t-il des problèmes d’init ? - Pourquoi systemd, pourquoi la vie ? - Pourquoi systemd est bon pour votre santé - La réponse à la question sur l’univers, la vie et systemd - all your init are belong to systemd - Je suis systemd - GNU/Systemdnux - 3 utilisateurs sur 6 aiment dé - systemd : Yes we Kaane ! - The fabulous fairy tale of systemd and the 50 bastards. - Nous partîmes 500 et paf systemd. - xcomcmdrd. - systemd dans ta gueule, connard - systemd, haters are gonna ♫ hate hate hate ♫ - l'antisystemdisme, un mal français - systemd, une lumière dans la nuit - systemd : let's drop Linux - systemd ne t'a rien demandé - systemd président, Zino 1er ministre, MultiDeskOS aux affaires étrangères - (systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !) ah non vous n'y avez pas échappé - systemdivise - systemd : il ne passera pas par moi. - systemd sera le genre humain. - systemd : l'union sacrée - Souriez, vous êtes systemd :) - Kabaled _1 000 commits, 50+ participants, 25+ titres, 1 dialogue de sourds_

AltStyle によって変換されたページ (->オリジナル) /