systemd 262 intègre le Live Update Orchestrator et prépare les mises à jour sans redémarrage
Le 1er septembre 2026, la release candidate systemd 262-rc1 ajoute l’option LUOSession= qui connecte les services au Live Update Orchestrator. La majeure apporte aussi un PID 1 statiquement lié pour les conteneurs minimaux et une mesure du nombre de kexec via systemd-analyze time.
1er septembre 2026. La version systemd 262-rc1 est publiée, première release candidate de la prochaine majeure du gestionnaire d’init et de services Linux. 1er septembre 2026, 8 h 07 (EDT). Michael Larabel détaille la liste des changements sur Phoronix. Linux 6.9. C’est la version minimale requise par la nouvelle valeur weighted-interleave de l’option NUMAPolicy=. Pourquoi c’est important : systemd cesse d’être un simple gestionnaire de services pour devenir la brique qui rend la mise à jour à chaud orchestrée et observable.
Le Live Update Orchestrator entre dans systemd
La nouveauté la plus lourde de sens est l’option LUOSession=, disponible sur les unités de service. Elle demande à systemd de créer des sessions du Live Update Orchestrator et de les transmettre à travers l’interface du file descriptor store, le magasin de descripteurs de fichiers qui permet à un service de confier des ressources au gestionnaire.
Concrètement, cela rapproche systemd d’une mise à jour sans interruption de service. Le Live Update Orchestrator coordonne les remplacements de composants à chaud, typiquement en combinant le patching noyau en direct et le redémarrage des services utilisateur, sans arrêter la machine. Jusqu’ici, cette orchestration vivait hors de systemd. En intégrant la notion de session directement dans les unités, systemd permet à un service de déclarer qu’il participe à une mise à jour à chaud et de confier sa continuité au gestionnaire.
Deux métriques vont avec cette intégration. Sur les noyaux qui exposent le Live Update Orchestrator via D-Bus et Varlink, systemd publie désormais KExecsCount ainsi que les horodatages de l’arrêt courant et précédent. La commande systemd-analyze time s’en sert pour rapporter le temps passé en kexec et en mise à jour à chaud. Pour la première fois, on peut mesurer combien de fois un système a été mis à jour sans redémarrage complet et combien de temps cela a pris.
Un PID 1 statique pour les très petits conteneurs
Deuxième changement structurant : systemd peut maintenant être compilé en un binaire PID 1/exécuteur statiquement lié, pensé pour les très petits conteneurs. La recette est précisément documentée dans les notes de version :
meson setup build --default-library=static --prefer-static \
-Dbuild-static=true -Dsystemd-multicall-binary=trueCes builds n’utilisent plus dlopen() pour charger leurs composants, ce qui supprime la dépendance au chargeur dynamique et réduit la surface du binaire. L’intérêt n’est pas cosmétique : un conteneur minimal peut démarrer avec systemd comme PID 1 sans embarquer la moindre unité de service sur disque.
Ce point mérite l’attention des équipes qui construisent des images de conteneurs distroless ou qui standardisent sur systemd comme gestionnaire d’init dans des environnements restreints. Un binaire unique, sans dépendance de chargement dynamique, c’est une image plus petite, une chaîne de dépendances plus courte et un risque d’échec de démarrage plus faible.
Des unités embarquées en secours
Dans la même logique de robustesse, le gestionnaire embarque désormais un jeu d’unités de base en mémoire. Les cibles de redémarrage et d’arrêt, le service systemd-poweroff et la cible multi-user existent en version de repli, directement dans le binaire.
Si les fichiers d’unités ne peuvent pas être chargés depuis le disque, par exemple parce que le système de fichiers est corrompu ou qu’aucun fichier n’est installé dans un conteneur, systemd retombe sur ces versions intégrées. C’est un filet de sécurité qui rend le binaire « légèrement plus robuste », comme le formulent les notes de version, et qui permet de démarrer un conteneur avec systemd en PID 1 sans installer d’unités.
Ce que changent les autres options
Le reste de la liste est moins spectaculaire, mais plusieurs points touchent directement l’exploitation au quotidien :
- NUMAPolicy= accepte deux nouvelles valeurs. preferred-many requiert Linux 5.15 ou plus récent ; weighted-interleave requiert Linux 6.9 et utilise les poids configurés dans les fichiers sysfs weighted_interleave du noyau. C’est un contrôle plus fin du placement mémoire sur les machines à plusieurs nœuds NUMA.
- systemd-firstboot reconnaît la valeur headless sur la ligne de commande noyau
systemd.firstboot=. Elle supprime toutes les invites interactives tout en effectuant une auto-configuration non interactive, comme la sélection de la seule locale installée. C’est fait pour les installations sans écran ni console. - systemd-coredump prend en charge le protocole de socket de coredump du noyau, disponible depuis Linux 6.17. Sur les noyaux compatibles, le service écoute sur
/run/systemd/coredumpd/kernelet le service d’enregistrement déclare le socket viakernel.core_pat. - systemd-vmspawn étend son option
--coco=à Intel TDX, en plus de AMD SEV-SNP. Le firmware de machine virtuelle confidentielle est sélectionné via les descripteurs QEMU, et l’option--secure-boot=yespeut opter pour un firmware avec clés pré-enrôlées. - Une intégration dm-clone fait son apparition. Les entrées de
/etc/clonetabsont traduites par systemd-clonesetup-generator en unités [email protected], ordonnées par clonesetup.target, pour créer et retirer les clones device-mapper au démarrage.
Chacun de ces points pris isolément semble mineur. Ensemble, ils dessinent une direction cohérente : un systemd qui se rapproche des environnements conteneurisés, des machines confidentielles et des infrastructures qui ne peuvent plus se permettre un redémarrage par mise à jour.
Pourquoi la mise à jour sans redémarrage devient sérieuse
Le besoin est ancien, mais il était resté morcelé. Le patching noyau en direct existe depuis des années, tout comme les mécanismes de kexec qui permettent de réexécuter le noyau sans passer par le firmware. Ce qui manquait, c’était la couche d’orchestration qui coordonne l’ensemble, expose une session par service et rend le résultat mesurable.
L’intégration dans systemd change la donne parce que systemd est déjà le point de passage obligé de la gestion des services. Si un service peut déclarer sa participation à une session de mise à jour à chaud, et si le gestionnaire sait combien de kexec ont eu lieu et combien de temps ils ont pris, alors la mise à jour sans redémarrage sort du bricolage pour devenir une opération que l’on planifie, que l’on surveille et que l’on audite.
Pour un SRE ou un RSSI, l’enjeu est direct : chaque redémarrage évité est une fenêtre de maintenance supprimée, une indisponibilité en moins et, dans le cas du patching de sécurité, un délai d’exposition raccourci. La capacité à vérifier via systemd-analyze time qu’un correctif a bien été appliqué à chaud apporte la preuve qui manquait aux audits.
Le paysage du patching à chaud dans lequel il s’insère
Le Live Update Orchestrator ne vient pas de nulle part. Linux a mis une décennie à construire les briques qu’il coordonne. Le patching noyau en direct existe sous deux formes, kpatch chez Red Hat et le Kernel Live Patching chez SUSE, toutes deux capables d’appliquer un correctif à un noyau en cours d’exécution sans redémarrage. De son côté, kexec permet depuis longtemps de démarrer un nouveau noyau directement depuis un noyau actif, en court-circuitant le firmware, ce qui raccourcit sans supprimer l’interruption.
Ce qui manquait, c’était un gestionnaire capable de combiner ces primitives, de redémarrer les services utilisateur et d’en garder la trace. systemd est l’hôte naturel, puisqu’il possède déjà le cycle de vie des services et le file descriptor store. L’option LUOSession= est la couture qui relie cette machinerie existante à la couche d’orchestration, et KExecsCount transforme un tour de passe-passe ponctuel en une métrique que l’on peut rapporter.
Pour les opérateurs, le sens est subtil mais réel. Une mise à jour à chaud n’est digne de confiance que si l’on peut prouver qu’elle a eu lieu. Avec systemd-analyze time qui rapporte désormais le temps de kexec et de mise à jour à chaud, la réponse à la question « cette machine a-t-elle vraiment été corrigée ? » cesse d’être une supposition.
Verdict
Si vous opérez des flottes Linux qui tolèrent mal les redémarrages, suivez la trajectoire de systemd 262 dès que la version stable sortira : l’option LUOSession= et la mesure de KExecsCount posent les fondations d’une mise à jour à chaud orchestrée que vous voudrez adopter avant qu’elle ne devienne la norme.
Si vous construisez des images de conteneurs minimales, testez dès maintenant le build statique en PID 1/exécuteur unique. Le gain de taille et la suppression de dlopen() sont immédiats, et les unités embarquées en secours vous protègent contre les démarrages ratés sur un système de fichiers abîmé.
Si vous êtes sur une version stable antérieure, rien ne presse : 262-rc1 est une release candidate, et la plupart de ces changements n’arrivent en production qu’à la sortie de la 262 définitive. Mais la direction est claire, et elle mérite d’être suivie de près.