Systemd installe votre OS, remplace sudo et n’a plus aucun concurrent sérieux

Avril 2010. Lennart Poettering publie un billet de blog intitulé « Rethinking PID 1 » et propose un init system qui parallélise le boot par activation de sockets. Juin 2026. systemd 261 sort avec un installateur d’OS (systemd-sysinstall), un service de métadonnées cloud (systemd-imdsd), un outil de gestion du stockage (storagectl) et le support du Live Update Orchestrator du noyau Linux pour les mises à jour sans redémarrage.

L’init system qui ne devait que lancer des services est devenu une plateforme système complète. Et il n’a plus aucun concurrent sérieux.

La guerre est finie — systemd a gagné

Le dernier rival crédible de systemd était Upstart, l’init system développé par Canonical pour Ubuntu. Abandonné en 2014 quand Ubuntu est passé à systemd, Upstart n’a jamais été porté au-delà de la version 1.13. SysVinit survit dans quelques distributions minimalistes (Alpine Linux, Devuan, Gentoo avec OpenRC), mais sa dernière version majeure (3.10, octobre 2024) a ajouté… une meilleure compatibilité avec machinectl de systemd.

GNU Shepherd 1.0, sorti en décembre 2024 après 21 ans de développement, est utilisé par GuixSD. Il reste confiné à l’écosystème Guile Scheme. Les alternatives comme runit (Void Linux) et s6 (Artix) occupent des niches — aucune n’est déployée par défaut sur une distribution majeure.

Le résultat : 100 % des distributions Linux grand public (Fedora, Ubuntu, Debian, RHEL, openSUSE, Arch Linux) utilisent systemd comme PID 1. openSUSE Tumbleweed a même commencé à migrer de GRUB vers systemd-boot en 2024 — un signe que l’écosystème s’étend au-delà du simple init.

Ce que systemd fait aujourd’hui (au-delà de lancer des services)

Systemd n’est plus un init system. C’est une collection de 70+ binaires qui gèrent des couches entières du système d’exploitation :

• systemd-boot — bootloader UEFI simple, désormais testé par Debian et adopté par openSUSE
• systemd-networkd — configuration réseau déclarative, intégration ModemManager depuis la v260
• systemd-resolved — résolveur DNS avec DNSSEC, DNS over TLS, et split-DNS par interface
• systemd-homed — répertoires utilisateur portables, chiffrés avec LUKS, migrables entre machines
• systemd-sysext — extensions système pour OS immutables (superposition de /usr/ sans reconstruction d’image)
• systemd-portabled — services conteneurisés portables, utilisables sans privilèges depuis la v260
• systemd-repart — partitionnement déclaratif reproductible pour images disque
• systemd-nspawn et systemd-vmspawn — conteneurs légers et machines virtuelles gérés comme des services
• systemd-journald — logging structuré binaire avec signature cryptographique
• systemd-timedated, hostnamed, localed, machined — gestion standardisée de l’heure, du hostname, des locales et des machines virtuelles

La nouveauté, c’est que ces composants ne sont plus des expériences optionnelles : ils sont activés par défaut sur Fedora, intégrés à GNOME via le financement du Sovereign Tech Fund allemand, et arrivent sur Debian.

Varlink remplace D-Bus — et c’est une bonne nouvelle

La décision architecturale la plus importante de ces deux dernières années n’est pas visible pour l’utilisateur final. Depuis systemd 257 (décembre 2024), les bibliothèques sd-json et sd-varlink sont des API publiques de libsystemd.

Varlink est un protocole IPC qui utilise JSON pour le marshalling, sans courtier central (pas de dbus-daemon), sans fichier XML d’interface, et sans le modèle d’authentification complexe de D-Bus. La commande varlinkctl permet d’interagir avec les services Varlink depuis le terminal :

varlinkctl call io.systemd.Manager ListUnits '{}'

Pourquoi c’est important : D-Bus a 20 ans, son bus système est un goulot d’étranglement, et les tentatives de le faire entrer dans le noyau (KDBUS, BUS1) ont échoué. Varlink est la sortie par le haut — plus simple, plus rapide pour les petits messages, et déjà utilisé pour les appels de shutdown, la gestion des jobs et les requêtes d’unités dans systemd 261.

run0 : la fin de sudo n’est plus une blague

Introduit dans systemd 256 (juin 2024), run0 est un symlink de systemd-run qui remplace sudo sans être SUID. Au lieu d’hériter du contexte d’exécution de l’appelant, il demande au service manager (PID 1) de lancer la commande sous l’UID cible dans un PTY isolé. Résultat :

• Pas de setuid. Le binaire n’a pas le bit SUID — la surface d’attaque est réduite.
• Contexte propre. La commande ne voit ni les variables d’environnement ni les descripteurs de fichier du shell appelant.
• Indicateur visuel. Le fond du terminal devient rougeâtre pendant la session privilégiée — un rappel constant que vous êtes en élévation.

run0 apt update        # Lance apt en root, terminal teinté en rouge
run0 -- bash            # Shell root en contexte isolé

Ce n’est pas un gadget : run0 élimine la classe de vulnérabilités liées à l’héritage d’environnement qui a affecté sudo pendant 30 ans (CVE-2023-22809, CVE-2023-27320, entre autres).

UKI, Secure Boot et l’amorçage vérifié

Le support des Unified Kernel Images (UKI) continue de mûrir. Une UKI combine le noyau Linux, l’initramfs, la ligne de commande du noyau et les signatures Secure Boot dans un seul binaire PE signé — ce que systemd-boot peut charger et vérifier en une étape.

systemd 257 a ajouté l’outil systemd-sbsign pour signer les binaires EFI PE, et systemd-keyutil pour centraliser les opérations de certificats. systemd 258 permet d’embarquer des images firmware UEFI dans les UKI pour le confidential computing. systemd 261 ajoute RestrictFileSystemAccess=, qui utilise un programme BPF LSM pour restreindre l’exécution aux binaires situés sur un système de fichiers signé par dm-verity.

Concrètement : une chaîne de confiance complète, du firmware jusqu’au process userspace, sans GRUB, sans shim, sans pièce mobile.

systemd-sysinstall : l’installateur qui n’existait pas

systemd 261 (juin 2026) introduit systemd-sysinstall, un installateur textuel qui exploite systemd-repart pour le partitionnement, les credentials systemd pour la configuration, et copie l’OS depuis un média temporaire. L’argument : si systemd gère déjà le partitionnement, le réseau, le chiffrement et les utilisateurs, pourquoi déléguer l’installation à un outil tiers ?

Ce n’est pas un concurrent d’Anaconda ou Calamares — c’est une brique pour les images minimals, les appliances et les déploiements automatisés où un installateur graphique n’a pas sa place.

mstack, IMDSD, storagectl : les nouveaux venus

La cadence des nouveautés ne ralentit pas :

• mstack (v260) définit une spécification de répertoire .mstack/ qui se comporte comme un OverlayFS structuré, pensé pour les conteneurs et le sandboxing léger. systemd-mstack est l’outil CLI qui l’accompagne.
• systemd-imdsd (v261) unifie l’accès aux métadonnées des instances cloud (AWS EC2, Azure, GCP, Oracle Cloud, Hetzner, Tencent) via une interface standard. Fini le scripting par fournisseur pour récupérer l’IP locale ou les clés SSH.
• storagectl (v261) expose les ressources de stockage via une API Varlink unifiée, pour le stockage utilisateur géré.

Ce qui a disparu : cgroup v1 et scripts SysVinit

Systemd nettoie aussi. systemd 258 (juillet 2025) a supprimé le support de cgroup v1. systemd 260 (mars 2026) a supprimé le support des scripts de service System V. Le kernel minimum requis passe de Linux 5.4 à 5.10.

Le message est clair : systemd ne fait plus de rétrocompatibilité avec l’infrastructure d’avant 2015. Si vous avez encore des scripts /etc/init.d/, vous avez eu dix ans pour migrer.

Verdict : systemd est la plateforme, pas l’alternative

Il n’y a plus de débat « systemd contre X ». Le débat est clos par le marché : toutes les distributions majeures ont convergé, les alternatives sont cantonnées à des niches, et systemd continue d’absorber les couches qui l’entourent — boot, DNS, réseau, conteneurs, installation, métadonnées cloud.

Pour un administrateur Linux en 2026 :

• Si vous gérez un parc de machines, apprenez systemd-networkd et systemd-resolved — ils remplacent NetworkManager et resolv.conf sur les serveurs.
• Si vous déployez sur du cloud public, adoptez systemd-imdsd pour unifier l’accès aux métadonnées.
• Si vous faites du poste de travail, testez run0 comme alternative à sudo — le gain de sécurité est réel, sans changement d’habitude.
• Si vous construisez des images immuables, combinez systemd-sysext, systemd-repart et UKI — vous éliminez toute une classe de problèmes de boot et de mise à jour.

Systemd a gagné la guerre des init systems. Il est désormais en train de gagner celle de la plateforme système.

Références

• systemd 261 release notes — 19 juin 2026
• systemd 260 release notes — 17 mars 2026
• systemd 258-rc1 — Phoronix — 23 juillet 2025
• systemd 257 released — Phoronix — 10 décembre 2024
• systemd 2024 highlights — Phoronix — 25 décembre 2024
• systemd run0 — Phoronix — 30 avril 2024
• Systemd Looking At A Future With More Varlink — Phoronix — 28 septembre 2024
• Rethinking PID 1 — Lennart Poettering — 30 avril 2010
• ArchWiki: systemd — consulté juillet 2026
• GNU Shepherd 1.0 — Phoronix — 9 décembre 2024