Systemd 259 rend le journal persistant par défaut et déprécie officiellement les scripts SysV

2 août 2026 — L’équipe systemd a publié la version 259, et c’est l’une des mises à jour les plus structurelles depuis la v256. Trois changements impactent directement les administrateurs Linux : le journal devient persistant par défaut, les scripts d’init SysV sont officiellement dépréciés avec une date de retrait programmée pour la v260, et le support d’iptables est entièrement retiré de systemd-networkd et systemd-nspawn. Si vous gérez des serveurs en production, cette release mérite une heure de votre calendrier avant la fin du trimestre.

Le journal persistant par défaut : fin de l’incertitude

Jusqu’à la v258, systemd-journald appliquait une logique conditionnelle : si le répertoire /var/log/journal existait, le journal était stocké de manière persistante sur le disque ; sinon, il tombait en mode volatile dans /run/log/journal, effacé à chaque redémarrage. Cette heuristique — aussi pratique fût-elle sur les systèmes embarqués — créait un angle mort pour les administrateurs qui supposaient à tort que leurs logs survivaient aux reboots.

Avec la v259, le journal est persistant par défaut. Le démon crée automatiquement /var/log/journal s’il est absent, et les logs y sont écrits sans condition préalable. Le mode volatile reste disponible via Storage=volatile dans /etc/systemd/journald.conf, mais le comportement par défaut ne laisse plus de place au doute.

Pourquoi ça compte. Un incident de sécurité ou une corruption de disque survenant juste avant un reboot laissait jusque-là les administrateurs sans aucune trace des événements précédant l’arrêt. Le nouveau comportement garantit que les logs survivent aux redémarrages, sauf choix explicite contraire. La documentation précise que cette persistance s’applique également aux namespaces de journal introduits en v257 — chaque conteneur ou service isolé bénéficie désormais du même niveau de rétention.

SysV init : dépréciation officielle, retrait en v260

Le support des scripts d’init System V — via systemd-sysv-generator et systemd-sysv-install — est formellement déprécié dans la v259 et sera intégralement retiré dans la v260. Les distributions et les projets qui maintiennent encore des scripts SysV doivent migrer vers des unités systemd natives avant la prochaine release majeure.

La fenêtre est courte : la v260 est attendue dans le cycle de publication habituel, soit environ trois mois après la v259. Pour un administrateur, le diagnostic est simple :

# Lister les scripts SysV encore présents sur le système
ls -la /etc/init.d/ | grep -v README
# Vérifier si systemd-sysv-generator est actif
systemctl status sysv-generator 2>/dev/null || echo "Générateur SysV absent"

Si la première commande retourne autre chose qu’un fichier README, vous avez du travail. Chaque script doit être converti en une unité .service native, ou le service qu’il gère doit être remplacé par une alternative moderne.

Ce qui va casser concrètement. Les logiciels qui s’installent encore via update-rc.d ou qui placent manuellement des scripts dans /etc/init.d/ cesseront de fonctionner après le démarrage lorsque la v260 sera déployée. C’est particulièrement vrai pour certains logiciels propriétaires de sauvegarde, des agents de monitoring legacy, et des daemons Java anciens qui livrent encore des scripts /etc/init.d/ plutôt que des fichiers .service.

La v259 émet des avertissements explicites dans le journal à chaque utilisation du générateur SysV. Les administrateurs peuvent activer le traçage :

journalctl -b | grep -i "sysv-generator"

iptables retiré : nftables devient la norme unique

systemd-networkd et systemd-nspawn abandonnent complètement le support d’iptables dans la v259. Toutes les règles de filtrage réseau générées par ces composants passent exclusivement par nftables. C’est une ligne de fracture claire : le kernel Linux supporte encore iptables via le module nf_tables qui émule l’interface legacy, mais les composants systemd refusent désormais toute dépendance à cette couche.

Pour un serveur qui utilise systemd-networkd avec des règles de firewall, le changement est transparent si votre distribution est récente. Fedora, Arch Linux et Debian Trixie utilisent déjà nftables par défaut. Les administrateurs RHEL 9 ou dérivés qui exploitent encore iptables doivent vérifier que leurs règles networkd sont compatibles avant la mise à jour.

TPM 2.0 obligatoire, cgroup v2 avec HugeTLB, et nouvelles NvPCR

Le support du TPM 1.2 est supprimé de systemd-boot et systemd-stub. Seul le TPM 2.0 est conservé, une décision que l’équipe justifie par la disponibilité universelle des modules TPM 2.0 depuis 2020. Les machines équipées uniquement d’un TPM 1.2 — certaines générations de serveurs Dell PowerEdge et HPE ProLiant antérieures à 2017 — perdent le support du measured boot via systemd.

Sur le plan de la gestion des ressources, cgroup v2 est désormais monté avec la comptabilité HugeTLB activée (memory_hugetlb_accounting). Les pages mémoire HugeTLB sont comptabilisées dans les limites mémoire globales, ce qui signifie qu’un conteneur qui consomme massivement des huge pages peut désormais atteindre sa limite MemoryMax — ce qui n’était pas toujours le cas avant.

L’innovation la plus technique de cette release concerne les NvPCR (Non-Volatile PCRs). Le standard TPM 2.0 limite les PCR classiques à 24 registres partagés, un goulot d’étranglement qui force des compromis entre la couverture des mesures et la stabilité des chaînes de confiance. Les NvPCR étendent cet espace de mesure sans perturber les PCR existantes. Concrètement, systemd-analyze gagne des commandes pour inspecter à la fois les PCR classiques et les nouvelles NvPCR :

# Lister les PCR et NvPCR disponibles
systemd-analyze pcrs
# Afficher les mesures matérielles et d'identité
systemd-analyze tpm2-measure

Varlink pousse D-Bus vers la sortie, et musl entre par la petite porte

Varlink, le protocole IPC orienté JSON introduit par Lennart Poettering, continue sa montée en puissance. La v259 expose désormais les paramètres d’exécution du service manager via Varlink, ajoute les appels Reload et Reexecute, et étend les API Varlink à systemd-repart, systemd-resolved, systemd-machined et systemd-creds. La parité fonctionnelle avec D-Bus est atteinte pour le service manager.

Parallèlement, systemd introduit un support expérimental de la compilation contre musl libc, une première dans l’histoire du projet. Les limitations sont explicites : pas de garantie de support à long terme, et certaines fonctionnalités — notamment autour de libseccomp et libselinux — sont absentes en configuration musl. Cette ouverture vise les environnements conteneurisés minimalistes, où la taille de glibc (plusieurs mégaoctets) est un luxe que musl (moins d’un mégaoctet) permet d’éviter.

Enfin, systemd cesse de linker directement contre libcap. La fonctionnalité a été réimplémentée en interne, réduisant l’arbre de dépendances et éliminant un point de friction pour les conteneurs. Le chargement dynamique (dlopen) remplace désormais les liens statiques vers Linux audit, PAM, libseccomp, libselinux, libmount et libacl, ce qui réduit le nombre de bibliothèques chargées en mémoire pour les processus qui n’utilisent pas activement ces fonctionnalités.

Ce que vous devez faire avant la v260

La v259 est une release de préparation. Elle donne les signaux, émet les avertissements et laisse le temps d’agir avant que la v260 ne supprime définitivement le support SysV.

• Si vous avez des scripts dans /etc/init.d/ : migrez-les vers des unités .service avant la fin du trimestre. Vérifiez avec journalctl | grep sysv-generator combien de scripts sont encore chargés à chaque démarrage.
• Si vous utilisez systemd-networkd avec iptables : passez à nftables maintenant. La v259 retire le support ; il n’y a pas de période de grâce.
• Si vous dépendez du measured boot sur TPM 1.2 : planifiez un remplacement matériel ou utilisez un shim externe.
• Si vous auditez les logs : le comportement par défaut de journald change. Vérifiez que votre rotation de logs dimensionnée pour /run en mémoire ne va pas saturer /var/log sur disque.

Systemd 259 est un pivot silencieux : elle ne casse pas vos systèmes aujourd’hui, mais elle trace une ligne rouge que la v260 ne franchira pas sans conséquences. Le trimestre commence maintenant.

Références

• Systemd v259 release notes — GitHub, publié le 2 août 2026
• Systemd 259 Released With Major Changes — Linuxiac, 2 août 2026
• LWN.net — Systemd v259 released, consulté le 9 août 2026