systemd 262-rc1 est sorti le 1er septembre 2026, et le changement à lire en premier s'appelle LUOSession=. Une unité de service peut désormais demander à systemd de créer une session Live Update Orchestrator, le mécanisme noyau fusionné dans Linux 6.19 qui fait traverser un kexec à des descripteurs de fichiers pour qu'une charge de travail survive au remplacement du noyau. systemd garde la session dans le magasin de descripteurs, exactement là où elle a sa place. Autour, deux réglages plus modestes règlent des problèmes que nous rencontrons tous en production : RestartRandomizedDelaySec= pour étaler les tempêtes de redémarrage, et ActivatingConcurrencyMax= pour empêcher une slice de tout démarrer d'un coup.
The short answer
systemd 262-rc1 relie le système d'init au Live Update Orchestrator du noyau. Une unité de service peut poser LUOSession= et systemd crée la session LUO, puis la transmet via le magasin de descripteurs de fichiers, pour qu'une charge de travail conserve ses descripteurs préservés pendant un remplacement de noyau par kexec. Le gestionnaire expose aussi KExecsCount et les horodatages d'arrêt sur D-Bus et Varlink, et systemd-analyze time en tire le temps de mise à jour à chaud. Ailleurs dans la version, les unités de service gagnent RestartRandomizedDelaySec= pour ajouter de la gigue aux redémarrages automatiques, les slices gagnent ActivatingConcurrencyMax= pour limiter les activations simultanées, et systemd peut maintenant être compilé en un unique binaire PID 1 lié statiquement pour de très petits conteneurs.
Il existe un type de notes de version qui vous dit où va la plateforme, et c'est le cas ici. systemd 262-rc1, étiqueté le 1er septembre 2026, contient beaucoup d'habituel : nouveaux réglages d'unités, dépréciations, renommages d'options. En dessous, une ligne relie le système d'init à une fonction noyau qui change le coût d'une mise à jour de noyau.
systemd peut maintenant détenir une session de mise à jour à chaud
La partie noyau est arrivée dans Linux 6.19. Le Live Update Orchestrator permet à certains descripteurs de fichiers porteurs d'état de survivre à un kexec. Un pilote enregistre un gestionnaire pour son type de fichier, ce gestionnaire sauvegarde l'état avant la transition et le restaure après, et le descripteur ressort de l'autre côté en pointant sur la même chose. Les descripteurs adossés à de la mémoire sont le cas vedette : un memfd qui contient la mémoire d'une machine invitée reste en RAM pendant le remplacement du noyau au lieu d'être détruit puis reconstruit.
Le cadre regroupe les ressources préservées en sessions nommées, et chaque session est elle-même un descripteur de fichier obtenu via /dev/liveupdate. Ce choix est délibéré. Tout ce qui est dans une session est lié à la durée de vie du descripteur de session : si le processus qui le détient s'arrête, le noyau récupère l'ensemble au lieu de laisser fuir de l'état préservé. Jusqu'ici, détenir ce descripteur était le travail d'un agent dédié en espace utilisateur.
systemd 262 ajoute LUOSession= aux unités de service. Vous le posez, systemd crée la session et la transmet au service par le magasin de descripteurs, le mécanisme que systemd utilise déjà pour rendre ses descripteurs à un service après un redémarrage. La correspondance est bonne. Le magasin de descripteurs existe précisément pour survivre au processus auquel il appartient, sous la supervision de PID 1, le seul processus de la machine qui puisse raisonnablement prétendre être encore là de l'autre côté d'un kexec.
Le gestionnaire a aussi gagné l'observabilité qui va avec. Sur les noyaux qui prennent LUO en charge, systemd expose KExecsCount ainsi que les horodatages d'arrêt courant et précédent, sur D-Bus comme sur Varlink, et systemd-analyze time les lit pour rendre compte du temps de kexec et de mise à jour à chaud. Si vous mettez à jour des noyaux sans redémarrer, il vous faut un chiffre qui dise combien de temps la charge a réellement été suspendue. Il existe maintenant.
Deux réglages qui règlent de vrais problèmes de production
Le reste de la version est plus modeste, mais deux réglages d'unité et de slice sont du genre que l'on adopte dans la semaine où on les découvre.
RestartRandomizedDelaySec= ajoute un délai supplémentaire tiré uniformément au hasard aux redémarrages automatiques, par-dessus RestartSec= et toute temporisation exponentielle déjà configurée. Le mode de défaillance visé est familier à quiconque a vu un hoquet de base de données emporter un parc entier : tous les services dépendants tombent dans la même seconde, attendent exactement le même intervalle, et réessaient à l'unisson. La dépendance revient, absorbe tout le parc d'un coup, et meurt à nouveau. La gigue est le remède standard, et elle coûte désormais une ligne dans un fichier d'unité.
ActivatingConcurrencyMax= se pose sur les unités de slice et plafonne le nombre d'unités de cette hiérarchie qui peuvent être en cours d'activation en même temps. Tout ce qui dépasse le plafond est mis en file et démarré automatiquement dès qu'une place se libère. Si vous avez déjà observé un démarrage où trente services décident tous de préchauffer leurs caches au même moment et où chacun rampe vers son délai maximal, voilà le bouton.
À côté, le gestionnaire a gagné une méthode D-Bus EnqueueUnitJobMany() qui met en file des travaux de démarrage, d'arrêt, de redémarrage ou de rechargement pour plusieurs unités en une seule transaction. C'est important parce que les dépendances d'ordonnancement entre les unités nommées sont alors résolues correctement, au lieu d'être décidées par l'ordre dans lequel vous les avez tapées. systemctl et portablectl l'utilisent quand le gestionnaire la propose et retombent sur des appels unité par unité sinon. Nos notes sur systemd-oomd et les réglages zram de Fedora CoreOS couvrent un autre cas où un réglage par défaut de systemd a discrètement changé le comportement d'un nœud sous pression.
Un PID 1 qui tient dans un très petit conteneur
Deux changements rendent systemd utilisable là où il était jusqu'ici malcommode.
Le gestionnaire embarque désormais un jeu d'unités de base, basic.target, sysinit.target, multi-user.target, reboot.target, shutdown.target, systemd-poweroff.service et compagnie, et s'en sert quand il ne peut rien charger depuis le disque. Les fichiers et masques trouvés sur le disque restent prioritaires. Conséquence pratique : un conteneur peut démarrer avec systemd en PID 1 sans aucun fichier d'unité installé, et une machine dont le /usr est abîmé a plus de chances d'atteindre un état où vous pouvez la réparer.
Par ailleurs, systemd peut maintenant être compilé en un unique binaire PID 1 et exécuteur lié statiquement, en configurant Meson avec --default-library=static --prefer-static -Dbuild-static=true -Dsystemd-multicall-binary=true. Ces compilations n'utilisent plus du tout dlopen() pour les bibliothèques optionnelles et remplacent NSS par une consultation simplifiée des fichiers passwd et group. C'est une cible de déploiement franchement différente : un init qui tient en un fichier, sans découverte de bibliothèques à l'exécution.
Attention, les options Meson ont changé de forme ici. -Dbuild-executor-shared=single est remplacée par -Dsystemd-multicall-binary=true, et -Dstandalone-binaries= prend maintenant une liste de motifs séparés par des virgules désignant les binaires qui reçoivent une variante .standalone, au lieu d'un booléen. Les anciennes valeurs sont traduites mais dépréciées, et les répertoires de compilation existants peuvent devoir être recréés.
Les petits points à connaître
NUMAPolicy= accepte deux nouvelles valeurs. preferred-many demande Linux 5.15 ou plus récent, et weighted-interleave demande Linux 6.9 ou plus récent et tire ses poids des fichiers sysfs weighted_interleave du noyau. Si vous réglez le placement NUMA à la main pour des services limités par la bande passante mémoire, l'entrelacement pondéré s'exprime maintenant dans l'unité.
ConditionCPUFeature= comprend les fonctions arm64 remontées par les hwcaps ELF, et les noms peuvent s'écrire ARCH.FEATURE, par exemple arm64.bti, pour lever l'ambiguïté sur les déploiements à architectures mêlées.
systemd-coredump parle le protocole de socket de vidage mémoire introduit dans Linux 6.17. systemd-firstboot accepte systemd.firstboot=headless pour supprimer toute invite interactive, la pièce qui manquait aux premiers démarrages réellement sans surveillance. systemd-vmspawn étend --coco= à Intel TDX en plus d'AMD SEV-SNP. Les nouveaux répertoires personnels adossés à FSCRYPT utilisent par défaut les politiques FSCRYPT v2. Les unités de socket acceptent les suffixes IEC sur MessageQueueMessageSize=.
systemd-repart ne désactive plus de force la copie sur écriture quand il crée des fichiers d'image. Une nouvelle option --cow= accepte yes, no ou auto, avec auto par défaut, ce qui laisse la politique du système de fichiers ou du répertoire parent inchangée. Si vous comptiez sur l'ancien comportement NOCOW sur Btrfs, passez --cow=no explicitement.
Les ruptures, dans l'ordre où elles vous rattraperont
Type=notify-reload. Ces services doivent désormais capter ou bloquer ReloadSignal= au moment où ils envoient READY=1. S'ils ne font ni l'un ni l'autre, le démarrage échoue sur une erreur de protocole. Auparavant ils démarraient quand même, et un rechargement ultérieur pouvait déclencher l'action par défaut du signal et arrêter le service. Le nouveau comportement est le bon, mais il transforme un défaut latent en échec de démarrage.
Liste de champs journalctl. -F et --field sont maintenant refusés quand ils accompagnent un filtre d'unité, d'amorçage, de temps, de curseur ou de motif. L'ancienne implémentation utilisait sd_journal_query_unique(), qui ne sait pas exprimer ces filtres, et les ignorait donc en silence en renvoyant les valeurs de champ du journal entier. Tout script qui semblait lister les champs d'une seule unité vous donnait autre chose, et il le dit désormais.
UnsetEnvironment=. Il est appliqué après l'expansion des variables d'environnement de ExecStart= et des lignes apparentées. Les variables listées restent utilisables dans la ligne de commande tout en étant absentes de l'environnement du processus exécuté. Les unités qui comptaient sur la suppression des références $VAR en mot entier doivent être mises à jour.
Horloges de limitation de débit. Les minuteries de limitation de sd-event, et donc les minuteries du gestionnaire comme StartLimitIntervalSec=, passent de CLOCK_MONOTONIC à CLOCK_BOOTTIME. Le temps passé en veille compte désormais dans l'expiration. Après une mise à jour ou une réexécution, un état de limitation sérialisé par un gestionnaire plus ancien peut expirer une fois plus tôt que prévu.
Socket de contrôle d'udevd. Le socket historique disparaît et udevadm utilise systématiquement l'IPC Varlink. /run/udev/control est maintenant un lien symbolique vers le socket Varlink, conservé uniquement pour que les vérifications existantes de présence d'udevd trouvent toujours quelque chose lié à ce chemin. N'en déduisez pas que l'ancien protocole y fonctionne encore.
systemd-sysupdate. Les unités sont renommées systemd-sysupdate-update.service et systemd-sysupdate-update.timer, avec des liens de compatibilité, ce qui libère la place pour un systemd-sysupdate@.service d'activation Varlink. Le binaire lui-même revient de bindir vers libexecdir et redevient expérimental, d'autres ruptures étant attendues.
Options Meson supprimées. -Dlibiptc=, -Dlibidn=, -Drc-local=, -Dsysvinit-path= et -Dsysvrcnd-path= ont disparu.
C'est une version candidate, donc la 262 finale peut encore bouger. La direction, elle, ne bougera pas. PID 1 devient la brique qui détient l'état dont votre charge de travail a besoin pour survivre au remplacement du noyau sous ses pieds.
Sources et pour aller plus loin
- Notes de version systemd v262-rc1, GitHub, 1er septembre 2026
- systemd 262-rc1 Released With Live Update Orchestrator Integration, Phoronix, 1er septembre 2026
- Live Update Orchestrator, documentation du noyau Linux
- Memfd Preservation via LUO, documentation du noyau Linux
- Live Update Orchestrator, LWN.net
Questions fréquentes
Que fait réellement LUOSession= dans un fichier d'unité ?
Il demande à systemd de créer une session Live Update Orchestrator pour le compte du service et de la lui transmettre via l'interface du magasin de descripteurs de fichiers. LUO est le cadre noyau fusionné dans Linux 6.19 qui permet à certains descripteurs de fichiers porteurs d'état, memfd, vfio et iommufd entre autres, de survivre à un remplacement de noyau par kexec. La session est représentée par un descripteur de fichier, et la durée de vie de tout ce qui est préservé à l'intérieur est liée à ce descripteur : le noyau nettoie automatiquement si son détenteur disparaît. Jusqu'ici, un agent en espace utilisateur devait posséder ce descripteur et le maintenir en vie pendant la transition. systemd peut maintenant être ce détenteur, ce qui tombe beaucoup mieux, parce que le magasin de descripteurs est déjà le mécanisme que systemd utilise pour faire traverser un redémarrage de service à des descripteurs.
Qui en a besoin, concrètement ?
Toute personne qui exploite des charges de travail de longue durée sur des machines qui doivent être mises à jour plus souvent qu'elles ne peuvent supporter un redémarrage complet. Le cas canonique est un hyperviseur dont la mémoire des machines virtuelles vit dans un memfd. Avec LUO, la mémoire invitée reste en place pendant le kexec et les machines reviennent sur le nouveau noyau sans migration. La même forme s'applique à tout service qui détient un gros jeu de données en mémoire coûteux à reconstruire. Si vous redémarrez vos parcs pendant une fenêtre de maintenance sans que personne ne le remarque, vous n'en avez pas besoin. Si un redémarrage signifie vider puis remplir un nœud pendant vingt minutes, c'est la direction que prend la pile logicielle.
À quoi sert RestartRandomizedDelaySec= ?
Il ajoute un délai supplémentaire tiré uniformément au hasard, en plus de RestartSec= et de toute temporisation exponentielle, lorsqu'une unité redémarre automatiquement. Le problème qu'il règle est la synchronisation. Quand une dépendance partagée tombe, tous les services qui en dépendent tombent au même instant, attendent exactement RestartSec=, puis réessaient au même instant. La dépendance revient, prend tout le parc simultanément, et retombe. Randomiser le délai casse ce pas cadencé. C'est le raisonnement classique de la gigue dans une politique de réessai, disponible maintenant en une ligne dans un fichier d'unité au lieu de quelque chose à recoder dans chaque service.
Que change ActivatingConcurrencyMax= ?
Il plafonne le nombre d'unités d'une hiérarchie de slice qui peuvent être simultanément dans l'état activating. Tout ce qui dépasse le plafond est mis en file et démarré automatiquement dès qu'une place se libère. C'est un limiteur pour le démarrage et pour les lancements en masse. Si vous avez une slice pleine de services qui martèlent chacun le disque ou une base de données au démarrage, les lancer tous en même temps les ralentit tous et peut pousser le groupe entier au-delà de ses délais de démarrage. Poser une limite de concurrence transforme la bousculade en file d'attente. À associer avec la nouvelle méthode EnqueueUnitJobMany(), qui permet à systemctl de soumettre des travaux de démarrage ou d'arrêt pour plusieurs unités en une seule transaction, afin que les dépendances d'ordonnancement soient respectées quel que soit l'ordre de saisie.
Que vérifier avant de mettre à jour ?
Quatre points. Les services de Type=notify-reload doivent désormais capter ou bloquer ReloadSignal= au moment où ils envoient READY=1, sinon le démarrage échoue sur une erreur de protocole : auditez tout ce qui utilise ce type. Les scripts qui appellent journalctl -F ou --field avec un filtre d'unité, d'amorçage, de temps, de curseur ou de motif seront maintenant rejetés au lieu d'ignorer silencieusement le filtre. UnsetEnvironment= est appliqué après l'expansion de ExecStart=, donc les variables que vous retirez restent utilisables dans la ligne de commande, ce qui est généralement l'effet souhaité mais change le comportement des unités qui comptaient sur l'ancien couplage. Enfin les minuteries de limitation de débit comme StartLimitIntervalSec= passent de CLOCK_MONOTONIC à CLOCK_BOOTTIME : le temps passé en veille compte désormais.