Pourquoi systemd s’est imposé face à SysV init

Pourquoi systemd s’est imposé

L’histoire de systemd commence avec deux problèmes que SysV init ne pouvait pas résoudre. SysV init (System V init, le système de démarrage Linux hérité d’AT&T Unix) ne permettait pas de décrire les dépendances d’un service ni de déterminer quels processus lui appartenaient une fois qu’il était lancé. systemd a répondu à ces deux problèmes grâce à des fonctionnalités du noyau inaccessibles depuis un shell script : les control groups pour suivre les processus et les sockets d’écoute ouvertes à l’avance pour gérer l’ordre de démarrage. La suite raconte comment ces deux solutions se sont étendues au reste de l’espace utilisateur, là où les objections ont commencé. Plusieurs de ces objections étaient fondées.

Ce que faisait réellement l’init SysV

Sur un système SysV, le PID 1 (processus d’ID 1, le premier processus lancé par le noyau) lisait /etc/inittab, sélectionnait un niveau d’exécution, puis exécutait les scripts correspondant à ce niveau. Les scripts se trouvaient dans /etc/init.d/. Les liens symboliques dans /etc/rc3.d/ déterminaient lesquels étaient exécutés et dans quel ordre. Ainsi, /etc/rc3.d/S20nginx pointait vers /etc/init.d/nginx et était appelé avec l’argument start.

#!/bin/sh
### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

case "$1" in
  start)
    start-stop-daemon --start --quiet --pidfile /run/nginx.pid \
      --exec /usr/sbin/nginx
    ;;
  stop)
    start-stop-daemon --stop --quiet --retry TERM/30/KILL/5 \
      --pidfile /run/nginx.pid
    ;;
esac

Le 20 dans S20nginx indique une position, pas une dépendance. Il signifie que ce script s’exécute après S19 et avant S21. Il n’indique pas pourquoi. Rien ne peut donc le vérifier, et aucun outil ne peut exécuter sans risque deux scripts indépendants en parallèle sans qu’un administrateur ait déterminé que cela est sûr.

Le programme rc exécutait chaque script à tour de rôle et attendait sa fin. Un script bloqué pendant trente secondes en attendant une adresse réseau bloquait tout le démarrage pendant trente secondes, y compris les services qui n’utilisent jamais le réseau.

L’en-tête LSB (Linux Standard Base) situé au début de ce script tentait de corriger ce problème de l’intérieur. Debian 6.0, en 2011, a fait de insserv la valeur par défaut : il lisait Required-Start dans chaque script, construisait un graphe, puis renumérotait les liens symboliques. Debian pouvait alors exécuter simultanément les scripts indépendants avec startpar. Cela a amélioré la situation, mais n’a pas résolu le problème de fond. La dépendance reposait toujours sur la fin d’exécution d’un script. Le retour 0 de S20nginx signifie qu’une fonction shell s’est terminée correctement. Il ne signifie pas que nginx accepte des connexions.

Les cinq problèmes qu’aucun script init ne pouvait résoudre

• Démarrage en parallèle. L’ordre des noms de fichiers impose un ordre total entre tous les services de la machine. Le démarrage prend donc au minimum la somme des durées de chaque service.
• État de préparation. Un script de démarrage se termine lorsqu’il a forké le daemon, pas lorsque celui-ci peut traiter une requête. Le script suivant démarre donc souvent trop tôt.
• Supervision. Un daemon effectue deux fork, puis son processus parent se termine. Le daemon est ainsi détaché du terminal et rattaché à PID 1. init voit la fin d’un processus enfant, mais ne dispose d’aucun lien fiable avec le processus qui a survécu.
• Démarrage à la demande. inetd, le super-serveur Internet, pouvait lancer un daemon lorsqu’une connexion arrivait. Mais il s’agissait d’un système distinct, avec son propre fichier de configuration. Il ne faisait rien pour ordonner le démarrage des autres services.
• Contrôle des ressources. Aucun élément d’un script init ne pouvait limiter la mémoire d’un service ni sa part du CPU. ulimit s’appliquait à un seul processus, et nice ne modifiait que le scheduler. Un processus enfant hors de contrôle d’un service ressemblait donc à n’importe quel autre processus de la machine.

Le défaut de supervision était le plus gênant au quotidien. Le fichier PID servait de contournement : le daemon écrivait son identifiant de processus dans /run/nginx.pid, puis la fonction d’arrêt relisait ce fichier. Si le daemon était tué de force, le fichier restait présent. Le kernel réutilisait alors ce numéro pour un autre processus, et start-stop-daemon --stop --pidfile envoyait un signal au processus qui le possédait désormais. Un fichier PID obsolète permet à un script init de tuer le mauvais processus.

launchd a d’abord résolu le problème des sockets

Apple a intégré launchd à Mac OS X 10.4 en 2005. Dave Zarzycki l’a écrit. Un seul processus a remplacé init, rc, xinetd, crond et watchdogd.

L’idée à reprendre était l’activation par socket. launchd crée d’abord chaque socket en écoute, puis démarre les daemons. Un client qui se connecte à un daemon qui n’a pas encore démarré ne reçoit pas de refus de connexion, car le kernel conserve la connexion dans la file d’attente backlog de cette socket jusqu’à ce que le daemon appelle accept(). L’ordre de démarrage entre deux daemons ne dépend plus d’une déclaration manuelle. C’est la socket qui le gère.

launchd repose sur Mach IPC (communication interprocessus), qui appartient au kernel XNU d’Apple et n’a pas d’équivalent sous Linux. Porter le code n’a jamais été réaliste. L’idée, elle, s’est diffusée.

Upstart a fait des événements l’unité de travail

Upstart, le gestionnaire de services de Canonical écrit par Scott James Remnant, a été publié avec Ubuntu 6.10 en octobre 2006. Fedora 9 à Fedora 14 l’ont utilisé, tout comme RHEL 6 et Chrome OS. Il a remplacé le runlevel par un événement. Un job indiquait quels événements devaient le démarrer et l’arrêter.

# /etc/init/example.conf
start on filesystem and net-device-up IFACE!=lo
stop on runlevel [!2345]
respawn
respawn limit 10 5
exec /usr/local/bin/exampled

Deux problèmes sont apparus lorsque le nombre de jobs a augmenté. Le premier concerne le sens des dépendances. Un job indique « démarrez-moi lorsque cet événement se produit ». Les informations sur les dépendances se trouvent donc dans le mauvais fichier : un service sait ce dont il a besoin, mais il ne peut pas savoir qui en aura besoin l’année suivante. Ajouter un service impliquait souvent de modifier un job existant pour qu’il émette un nouvel événement.

Le second concerne le suivi des processus. Upstart suivait un daemon qui se forkait en comptant les appels fork() avec ptrace, configurés comme expect fork ou expect daemon. Si le nombre de forks était incorrect, Upstart supervisait un processus qui s’était déjà arrêté ou attendait un fork qui avait déjà eu lieu. Le symptôme était initctl start qui restait bloqué sans erreur. Le fichier du job ne permettait pas d’en expliquer la cause.

Upstart exigeait également des contributeurs qu’ils signent l’accord de contribution de Canonical. Ce n’était pas un défaut d’ingénierie, mais cela a influencé les personnes qui ont travaillé sur le projet.

Repenser le PID 1, avril 2010

Le 30 avril 2010, Lennart Poettering a publié un article intitulé « Repenser le PID 1 ». Kay Sievers a travaillé avec lui sur le projet. L’argumentaire reposait sur quatre points.

• Démarrer moins de services. Beaucoup peuvent attendre qu’une requête les sollicite réellement.
• Ne pas déclarer l’ordre de démarrage lorsqu’un socket peut l’induire. Ouvrir tous les sockets en une seule passe, puis tout démarrer en même temps.
• Suivre les processus avec des control groups plutôt qu’avec des fichiers PID.
• Décrire un service dans un fichier déclaratif, afin qu’une même description fonctionne sur toutes les distributions.

La première release est sortie la même année. Fedora 14 a proposé systemd comme option en novembre 2010, puis Fedora 15 en a fait la configuration par défaut en mai 2011.

Pourquoi les cgroups rendent la supervision fiable

Un cgroup (control group) est une fonctionnalité du noyau qui permet de regrouper des processus. Elle a été intégrée à Linux 2.6.24 en 2008. systemd place chaque service dans son propre cgroup. Un processus fils hérite du cgroup de son parent, et un processus non privilégié ne peut pas s’en extraire. Le double fork ne dissimule donc rien : le PID 1 conserve à tout moment l’ensemble exact des processus appartenant à une unité. Arrêter un service consiste à tuer tous les processus de son cgroup, ce que fait le comportement par défaut de KillMode=control-group.

systemctl status affiche ce groupe :

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-08-11 09:14:22 UTC; 3min ago
   Main PID: 1042 (nginx)
      Tasks: 3 (limit: 4653)
     Memory: 6.1M (peak: 7.4M)
     CGroup: /system.slice/nginx.service
             ├─1042 "nginx: master process /usr/sbin/nginx"
             ├─1043 "nginx: worker process"
             └─1044 "nginx: worker process"

Ce bloc répond entièrement au problème du fichier PID obsolète. Aucun fichier ne peut devenir obsolète, car la liste correspond à l’état du noyau.

Le même arbre transporte les limites, car les cgroups ont d’abord été conçus pour la comptabilisation, avant d’être utilisés pour le suivi des processus. MemoryMax=, CPUQuota= et TasksMax= tiennent chacun sur une ligne. Définir une limite stricte de mémoire et de CPU pour un service consiste aujourd’hui à ajouter un fichier drop-in ; en 2009, il aurait fallu modifier un script shell que personne n’avait écrit.

Pourquoi toutes les distributions ont changé entre 2011 et 2015

• Fedora 15, mai 2011.
• openSUSE 12.1, novembre 2011.
• Mageia 2, mai 2012.
• Arch Linux, valeur par défaut pour les nouvelles installations à partir d’octobre 2012.
• RHEL 7, juin 2014.
• SLES 12, octobre 2014.
• Debian 8, avril 2015.
• Ubuntu 15.04, avril 2015.

La date de RHEL 7 a eu une portée plus longue que les autres, car CentOS 7 l’a recompilée. C’est là que la plupart des administrateurs ont découvert pour la première fois un fichier d’unité, une étape de la longue histoire qui va de Red Hat Linux à CentOS, puis à Rocky et AlmaLinux.

Les raisons étaient essentiellement peu spectaculaires, ce qui explique la rapidité de la transition.

• Un même fichier d’unité fonctionne sur toutes les distributions. Les projets upstream ont donc commencé à fournir un fichier .service, et les distributions ont cessé de maintenir un script shell par paquet et par version.
• Le suivi des sessions graphiques est passé à systemd-logind après l’abandon de ConsoleKit vers 2012. GNOME avait besoin de logind. Une distribution sans systemd devait donc trouver un remplacement. Ce remplacement, elogind, est la version extraite de logind de systemd, maintenue séparément.
• udev, le gestionnaire de périphériques, a été fusionné dans l’arbre source de systemd en avril 2012. Les distributions qui fournissaient udev suivaient désormais le dépôt de systemd. Gentoo a créé un fork, eudev, en réaction.
• Les conteneurs ont renforcé l’importance d’un suivi fiable des processus et des limites par service, car ces deux fonctions reposent sur les cgroups. La question de savoir quel superviseur contrôle le processus d’un conteneur reste d’actualité lorsque vous faites redémarrer une stack Docker Compose après un reboot.

La décision de Debian a été la plus médiatisée. Le Technical Committee a voté en février 2014. Le vote était à égalité, et le président, Bdale Garbee, a voté en faveur de systemd pour départager les voix. Ubuntu a annoncé quelques jours plus tard qu’elle suivrait Debian plutôt que de continuer avec Upstart. Un groupe de développeurs Debian a créé un fork de la distribution, Devuan, en novembre 2014, puis a publié Devuan 1.0 en mai 2017.

Les objections, présentées équitablement

Périmètre. Un seul projet fournit désormais PID 1, le daemon de journalisation, la gestion des sessions de connexion, le gestionnaire de périphériques, un daemon de configuration réseau, un résolveur DNS (domain name system), un client NTP (network time protocol), un moteur d’exécution de conteneurs et un boot loader. La défense habituelle, selon laquelle il s’agit de binaires séparés que vous n’êtes pas obligé d’installer, est exacte, mais elle ne répond pas à l’objection. Dès qu’un environnement de bureau a besoin de logind et que logind est fourni par systemd, le choix n’est plus libre. C’est ce que l’argument entendait par couplage, et c’est bien ce qui s’est produit.

Le journal binaire. journald écrit dans un format binaire indexé, au lieu d’utiliser du texte brut. Vous obtenez des fonctions que le texte ne permettait pas : filtrage par unité et par priorité, champs structurés et métadonnées que le programme émetteur ne peut pas falsifier, car journald enregistre lui-même l’unité et le cgroup. journalctl -u nginx -p err --since "-1h" remplace un grep par une expression régulière de date. Le coût est également réel. Sur une machine qui ne démarre pas, vous ne pouvez pas lire le journal avec less depuis un shell de secours. Vous devez indiquer à journalctl le disque monté :

sudo journalctl --directory /mnt/var/log/journal --boot -1 --priority err

Il existe ici un autre piège, qui surprend généralement une seule fois. journald conserve les journaux dans /run/log/journal, qui correspond à la mémoire, sauf si /var/log/journal existe. Sur une machine où ce répertoire n’existe pas, journalctl -b -1 n’a rien à afficher après un redémarrage, précisément au moment où vous en avez besoin. Vérifiez et corrigez ce point :

journalctl --disk-usage
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

journalctl --disk-usage doit maintenant afficher les journaux archivés sous /var/log/journal. Si vous voulez également du texte brut, définissez ForwardToSyslog=yes dans /etc/systemd/journald.conf et gardez rsyslog installé.

La capacité à déboguer le démarrage. Lorsqu’une unité se bloque, la console affiche une ligne, puis plus rien :

[  *** ] A start job is running for Wait for Network to be Configured (1min 32s / no limit)

Les outils permettant d’aller plus loin existent bien : systemctl list-jobs pendant le blocage, systemd-analyze blame et systemd-analyze critical-chain ensuite, ainsi que systemd.log_level=debug sur la ligne de commande du noyau. La formulation équitable de l’objection est la suivante : n’importe qui connaissant sh pouvait lire un script init de haut en bas, tandis qu’une unité bloquée exige de savoir laquelle d’une douzaine de commandes utiliser. C’est un coût réel. Chaque administrateur le paie une fois, mais beaucoup d’administrateurs l’ont payé en même temps.

Une valeur par défaut qui change pour tout le monde. systemd 230, en 2016, a modifié la valeur par défaut de logind afin que les processus utilisateur restants soient tués à la déconnexion. Les sessions tmux et screen détachées étaient supprimées à la fin de la session qui les avait lancées. Les distributions fournissaient KillUserProcesses=no dans /etc/systemd/logind.conf, et la réponse officiellement prise en charge est loginctl enable-linger <user>. Une valeur par défaut dans un seul projet a modifié une habitude dont dépendaient des millions de personnes. C’est ce que signifie concrètement « trop d’éléments de l’espace utilisateur au même endroit ».

Une dépendance par défaut constitue une surface d’attaque. En mars 2024, la backdoor présente dans xz-utils ciblait sshd sur Debian et Ubuntu. OpenSSH en amont ne lie pas libsystemd. Ces distributions l’ont modifié pour que sshd puisse signaler son état prêt à systemd, et libsystemd tirait liblzma, où se trouvait la backdoor. Le protocole de notification de disponibilité lui-même consiste en un seul datagramme envoyé à la socket indiquée dans $NOTIFY_SOCKET ; aucune bibliothèque n’a donc jamais été nécessaire. En réponse, systemd a chargé les bibliothèques de compression avec dlopen, afin qu’elles ne soient plus liées par défaut. Une catégorie de bogue apparentée présente la même structure : en 2017, une valeur User= commençant par un chiffre était considérée comme invalide, et l’unité s’exécutait en tant que root au lieu d’échouer ; une faute de frappe devenait donc une élévation de privilèges. Les versions ultérieures refusent de démarrer l’unité.

Historique depuis votre invite systemctl

Chaque problème décrit plus haut correspond maintenant à une directive dans un fichier que vous pouvez lire.

• Le démarrage séquentiel est devenu After= et Wants=, et systemd-analyze critical-chain indique ce qui a réellement retardé votre démarrage.
• La vérification de l’état de préparation est devenue Type=notify : lorsque le service peut traiter des requêtes, il écrit READY=1 dans $NOTIFY_SOCKET. Type=forking avec PIDFile= existe encore pour les anciens daemons, et c’est le type qui échoue avec start operation timed out. Terminating. lorsque le fichier PID n’apparaît jamais. Si vous choisissez le mauvais type, l’unité peut signaler l’état active alors que le daemon qu’elle a lancé est déjà arrêté. Il est donc utile de savoir quel Type= correspond réellement au démarrage de votre daemon avant d’écrire cette ligne.
• La supervision est assurée par le cgroup : Restart=on-failure avec RestartSec= remplace un script wrapper, et StartLimitBurst= empêche une boucle de crash de s’exécuter indéfiniment.
• inetd est devenu une unité .socket placée à côté de l’unité .service.
• ulimit est devenu MemoryMax=, CPUQuota= et TasksMax=.
• La ligne su - appuser -c d’un script init est devenue User=, NoNewPrivileges=yes et ProtectSystem=strict. Ainsi, exécuter un service avec un utilisateur non privilégié est la configuration par défaut d’une unité et non une tâche supplémentaire.

[Unit]
Description=Example API
Wants=network-online.target
After=network-online.target postgresql.service
Requires=postgresql.service

[Service]
Type=notify
ExecStart=/usr/local/bin/exampled
Restart=on-failure
RestartSec=2
MemoryMax=512M
CPUQuota=50%
TasksMax=128
User=exampled
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
StateDirectory=exampled

[Install]
WantedBy=multi-user.target

Une ligne de ce fichier correspond à l’erreur que tout le monde fait une fois. Requires=postgresql.service est une exigence, pas un ordre de démarrage : elle indique que votre unité échoue si Postgres échoue, mais elle ne demande pas de démarrer Postgres en premier. Sans After=postgresql.service, les deux démarrent au même moment et votre service tente de se connecter à un port sur lequel rien n’écoute encore. Ces deux directives sont volontairement séparées, car vous pouvez parfois avoir besoin de l’une sans l’autre. ProtectSystem=strict monte le système de fichiers en lecture seule pour ce service. C’est pourquoi StateDirectory= est présent : il fournit au service un chemin accessible en écriture sous /var/lib.

L’endroit le plus clair pour observer un fonctionnement datant de 2005 sur un serveur 2026 est SSH sur Ubuntu 24.04, qui fournit systemd 255 en août 2026. ssh.service est activé par socket par défaut : ssh.socket conserve le socket en écoute, et sshd démarre lorsqu’une connexion arrive. Ainsi, Port 2222 dans /etc/ssh/sshd_config n’a aucun effet, car sshd n’est pas le processus qui a ouvert le port. La modification doit être effectuée dans l’unité socket.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Le ListenStream= vide la valeur héritée de l’unité fournie par le paquet. Si vous l’omettez, les deux ports sont utilisés, car systemd ajoute les valeurs à une liste au lieu de la remplacer. Appliquez ensuite la modification et vérifiez le résultat, en gardant une deuxième session SSH ouverte pendant toute l’opération :

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -lntp | grep 2222

ss doit afficher un socket sur le port 2222 appartenant à systemd, et non à sshd. C’est le fonctionnement conçu pour launchd, vingt ans plus tard, sur votre VPS. Si vous préférez l’ancien comportement, sudo systemctl disable --now ssh.socket puis sudo systemctl enable --now ssh.service vous fournissent un sshd exécuté en continu, qui relit Port depuis sa propre configuration.

Les détails que vous rencontrerez dépendent de la release utilisée. Il est donc utile de connaître la différence entre une release LTS et une release intermédiaire d’Ubuntu avant de planifier une mise à niveau. Sur plusieurs machines, le fait qu’un fichier d’unité soit identique partout explique pourquoi gérer plusieurs serveurs depuis un point central relève maintenant de la configuration et non plus des scripts shell. Lorsque vous écrivez vos propres unités, le couple service et timer remplit le rôle que vous auriez réparti entre un script init et une ligne cron en 2009.

FAQ

Pourquoi les distributions Linux ont-elles remplacé SysV init par systemd ?

Pour deux raisons d’ingénierie et une raison de maintenance. SysV init ordonnait les services selon leur nom de fichier, ce qui définit une position et non une dépendance. Il perdait aussi la trace des daemons qui se détachaient de leur processus parent. C’est pourquoi des fichiers PID obsolètes pouvaient arrêter le mauvais processus. systemd a résolu l’ordonnancement avec l’activation par socket et les directives de dépendance. Il a résolu le suivi des processus avec les control groups. La raison liée à la maintenance a accéléré la transition : un même fichier d’unité fonctionne sur toutes les distributions. Les projets amont fournissaient donc un fichier .service, et les mainteneurs des distributions ont cessé d’écrire un script shell par paquet. Fedora 15 a adopté systemd en mai 2011, et Ubuntu 15.04 a été le dernier grand retardataire, en avril 2015.

systemd est-il un binaire monolithique ?

Non. L’arbre des sources construit de nombreux programmes distincts. Le PID 1 est /usr/lib/systemd/systemd, tandis que journald, logind et udevd sont des processus distincts avec leurs propres binaires. Exécutez ls /usr/lib/systemd/ pour les afficher sur votre système. La critique qui subsiste concerne le couplage des versions plutôt que la taille du binaire : ces programmes sont publiés ensemble et partagent des interfaces privées. Les distributions ont donc tendance à les intégrer comme un ensemble, et des logiciels comme GNOME ont fini par attendre spécifiquement logind.

Puis-je encore utiliser Linux sans systemd ?

Oui. Devuan fournit sysvinit, Gentoo utilise OpenRC par défaut, Void utilise runit, Alpine utilise busybox init avec OpenRC, et Slackware conserve des scripts de style BSD. Le coût est le travail de compatibilité. Les logiciels de bureau qui attendent logind ont besoin de elogind, c’est-à-dire de la version de logind de systemd maintenue comme paquet autonome. De plus en plus de logiciels serveur ne fournissent désormais qu’un fichier .service. Vous devez donc écrire et maintenir vous-même le script de démarrage.

Pourquoi le journal est-il binaire au lieu d’être un fichier texte brut ?

Parce que journald stocke des champs structurés avec un index. Cela permet le filtrage par unité, le filtrage par priorité et l’utilisation de métadonnées que le programme émetteur ne peut pas falsifier. journald enregistre lui-même l’unité, le cgroup et le véritable UID, au lieu de faire confiance à la ligne de journal. En contrepartie, vous devez utiliser journalctl pour le lire, y compris depuis un système de secours. Dans ce cas, indiquez-lui le disque monté avec journalctl --directory /mnt/var/log/journal. Si vous voulez également du texte, définissez ForwardToSyslog=yes dans /etc/systemd/journald.conf.

Qu’est-ce qui a remplacé la modification de mon script /etc/init.d ?

Les fichiers drop-in. Ne modifiez pas l’unité dans /usr/lib/systemd/system/, car une mise à niveau du paquet l’écraserait. Exécutez sudo systemctl edit nginx.service : systemd crée alors /etc/systemd/system/nginx.service.d/override.conf, qui est fusionné avec l’unité fournie par le paquet. systemctl cat nginx.service affiche le résultat fusionné, et systemd-delta liste tous les overrides présents sur la machine. Après toute modification manuelle, exécutez sudo systemctl daemon-reload, sinon la commande suivante affiche Warning: The unit file, source configuration file or drop-ins of nginx.service changed on disk.