Systemd 260 supprime SysV et redéfinit le démarrage sous Linux.

L'arrivée de systemd 260 marque un tournant Pour l'écosystème Linux. Cette nouvelle version du système d'initialisation et gestionnaire de services le plus répandu dans les distributions modernes intègre des changements majeurs, dont certains révolutionnaires, qui affectent la compatibilité avec les logiciels existants ainsi que la gestion de la sécurité, du réseau, des conteneurs et même de l'intégration d'agents d'IA. Si vous administrez des serveurs ou utilisez Linux au quotidien, cette version mérite une attention particulière.

Au-delà des gros titres, le protagoniste principal est le Suppression définitive de la prise en charge des scripts d'initialisation SysV classiquesCela marque la fin d'une ère pour Linux et nécessite une réévaluation des services existants. Parallèlement, systemd 260 introduit de nouveaux utilitaires, augmente les exigences minimales du noyau, améliore l'intégration avec TPM2, renforce l'isolation des services, étend les capacités réseau et de conteneurisation, et peaufine de nombreux détails destinés aux environnements de bureau, aux serveurs et aux déploiements cloud.

Fin du support pour SysV init : quels changements pratiques ?

L'une des nouvelles fonctionnalités de systemd 260 qui a suscité le plus de discussions est… Suppression complète de la prise en charge des scripts de démarrage de type System V, les scripts typiques stockés dans /etc/init.d/ qui ont longtemps constitué le socle du lancement de services sous Linux. Ce support était depuis longtemps considéré comme obsolète et l'on avait prévenu qu'il finirait par disparaître ; ce moment est désormais arrivé.

Avec cette version, Les composants chargés de traduire les scripts SysV en unités systemd ont été supprimés.Des pièces comme celles-ci disparaissent systemd-sysv-generator, qui générait des unités « à la volée » à partir de /etc/init.dEt aussi systemd-sysv-install, en plus d'autres éléments de compatibilité tels que systemd-rc-local-generator y rc-local.service, qui soutenait le classique /etc/rc.local.

Ce mouvement implique que Tout service qui dépend encore exclusivement de scripts SysV cessera de démarrer correctement une fois que la distribution adoptera systemd 260.à moins qu'une unité native n'ait été créée .serviceDans les infrastructures modernes, l'impact sera relativement faible, mais dans les environnements utilisant des logiciels anciens ou développés sur mesure, il pourrait y avoir plus d'une surprise si un audit préalable n'est pas réalisé.

Pendant ce temps, certains Les options du système de construction Meson liées à SysV ont été marquées comme obsolètes ou supprimées.Des paramètres tels que -Drc-local=, -Dsysvinit-path= y -Dsysvrcnd-path= Elles restent obsolètes, tandis que des options telles que -Dintegration-tests= y -Dcryptolib= Elles disparaissent directement de l'arbre de compilation, simplifiant ainsi le code source.

En termes opérationnels, cela signifie également que systemd se concentre désormais exclusivement sur les unités nativessans couches intermédiaires ni génération automatique de services à partir de scripts existants. Le message est clair : si un élément important de votre système existe encore sous forme de script dans /etc/init.d/Il est temps de procéder explicitement à cette migration.

Pourquoi SysV a été supprimé : nettoyage technique et avenir de l’écosystème

La décision de supprimer la compatibilité avec l'initialisation SysV n'est pas arbitraire. Du point de vue du projet, Maintenir un code hérité pour un mécanisme de démarrage pratiquement obsolète était une charge. Cela a compliqué la maintenance et l'évolution du framework. La prise en charge de la compatibilité était considérée comme obsolète depuis des années, et son utilisation réelle dans les distributions courantes devenait de plus en plus marginale.

En supprimant cette couche, systemd réduit la complexité interne et élimine les chemins d'exécution difficiles à tester et à sécuriser.Avec moins de chemins spécifiques pour gérer les services hérités, l'équipe de développement peut se concentrer sur le perfectionnement du moteur d'unités natif principal, l'amélioration de la sécurité, des performances et de l'intégration avec les nouvelles API du noyau et de l'espace utilisateur.

Il existe également une composante claire de conformité aux normes actuelles de gestion des servicesAujourd'hui, la quasi-totalité des principales distributions Linux ont adopté systemd comme système d'initialisation principal et proposent des unités natives pour leurs paquets. Maintenir SysV comme solution de fortune revenait, en pratique, à soutenir un modèle de démarrage qui n'est plus compatible avec les méthodes modernes de description des dépendances, des cgroups, de la journalisation structurée et du contrôle des ressources.

Du point de vue de la performance, Supprimer les couches de compatibilité permet de réduire certains frais généraux. et éviter les transformations inutiles au démarrage. Bien que l'impact en millisecondes puisse paraître minime, dans les systèmes hautement optimisés ou ceux comportant de nombreux services, cela contribue à maintenir un comportement plus prévisible ; de plus, il est utile de savoir comment modifier le délai d'expiration du menu de démarrage pour les tests et la validation.

Pour les administrateurs système, le message pratique est que SysV appartient désormais au passé dans les environnements basés sur systemd.Nous devons supposer que le modèle de référence est constitué des unités .service, ainsi que les autres types d'unités (prises, minuteries, cibles, etc.), et adapter les outils internes, la documentation et la formation à cette réalité.

Comment vérifier si votre système dépend toujours de SysV et que faire ?

Avant que votre distribution ne passe à systemd 260, il est fortement recommandé Vérifiez si vous avez encore des services qui dépendent de scripts classiques.La vérification de base consiste à lister le contenu de /etc/init.d/, où ces scripts d'ouverture résident traditionnellement :

ls /etc/init.d/

Si vous voyez des scripts qui n'ont pas leur équivalent dans /etc/systemd/system ou sur les itinéraires unitaires typiques, C'est un signe clair qu'il y a du travail à faire.L'existence du script ne suffit pas : ce qui compte, c'est qu'il soit encore utilisé concrètement pour démarrer ou arrêter des services.

Une autre astuce utile est rechercher les unités générées à partir de SysV dans les versions antérieures de systemdBien qu'elles n'existent plus dans la version 260, elles peuvent encore être utiles dans les systèmes actuels pour identifier ce qui a dysfonctionné après la mise à jour :

systemctl list-unit-files | grep generated

Si cette commande affiche des services marqués comme « générés », ils proviennent généralement d'anciens scripts. Il est conseillé de les localiser et de planifier leur remplacement par des unités locales., de préférence avant la mise en production de la version mise à jour.

En matière de migration, une approche rapide consiste Enveloppez temporairement le script SysV dans une unité systemd, en précisant dans ExecStart y ExecStop appels de script avec arguments start y stopCe n'est pas la solution la plus élégante, mais elle vous permet de gagner du temps pendant que vous réécrivez le service de manière plus idiomatique.

À moyen terme, la ligne de conduite recommandée est définir des unités qui appellent directement le binaire ou la commande principale du service, en tirant parti des directives modernes telles que Restart=Des limites de ressources, l'intégration de cgroups et des options de sandboxing avancées, au lieu de continuer à s'appuyer sur des scripts hérités remplis de logique spécifique.

Nouvelles fonctionnalités et principaux changements techniques dans systemd 260

Bien que les adieux à SysV suscitent beaucoup d'attention, systemd 260 intègre un bon nombre de nouvelles fonctionnalités. Ces mises à jour concernent la sécurité, le réseau, le noyau, les conteneurs, la portabilité des services et même la présentation des informations système. Il s'agit d'une version particulièrement robuste, intégrant de nombreuses modifications internes, conçue pour tirer pleinement parti des capacités des noyaux récents.

Un des points importants est le augmentation de la version minimale du noyau prise en chargeSystemd 260 ne fonctionne plus sur les noyaux aussi anciens que Linux 5.4 : La version minimale requise est Linux 5.10.De plus, le projet lui-même recommande Utilisez au moins Linux 5.14, et souligne qu'un noyau 6.6 est l'option idéale si vous souhaitez profiter pleinement de toutes les fonctionnalités présentes dans cette version.

Cette augmentation des exigences n'est pas négligeable, car Cela nous oblige à abandonner les distributions ou les environnements qui sont encore ancrés à des noyaux très anciens.Courante dans certains déploiements d'entreprise ou embarqués, cette mise à jour permet à systemd de s'appuyer sur des API noyau plus modernes, de mieux exploiter les cgroups v2, de nouvelles politiques d'ordonnancement et des améliorations de sécurité absentes des versions précédentes.

En parallèle, un nouveau champ FANCY_NAME= dans le fichier /etc/os-releaseCe domaine est similaire à celui déjà connu PRETTY_NAMEmais avec la particularité unique de pouvoir inclure des séquences ANSI et des caractères spéciaux, tels que les émojis. Gestionnaire Systemd, systemd-hostnamed et l'outil hostnamectl Ils peuvent afficher cette valeur pour offrir une présentation plus attrayante visuellement de la distribution, notamment dans les interfaces interactives ou les outils de diagnostic.

Au-delà de l'aspect cosmétique, systemd 260 continue d'explorer plus en profondeur l'utilisation de Varlink En tant que mécanisme de communication et API, il étend sa présence à divers composants. Ceci facilite l'interaction programmatique avec le système, l'intégration avec des outils externes et, de manière générale, une méthode plus structurée pour interroger et modifier l'état des services et des ressources.

Des améliorations ont également été constatées dans des domaines tels que Gestion des ressources basée sur cgroups v2, optimisations du temps de démarrage, un meilleur intégration avec les conteneurs et les machines virtuelles et des améliorations dans la gestion des journaux grâce à journaldCependant, bon nombre de ces changements sont progressifs et sont plus perceptibles dans les déploiements de grande envergure ou très perfectionnés.

Sécurité et isolation : TPM2, PrivateUsers et nouvelles politiques de mémoire

En matière de sécurité, systemd 260 progresse sur plusieurs fronts. Notamment, L'intégration avec TPM2 est renforcéeLe module SPM (Secure Platform Module) est présent sur de nombreuses cartes mères et périphériques UEFI modernes. Ces puces servent notamment à protéger les clés de chiffrement et à automatiser le déverrouillage des disques ou des partitions au démarrage.

Plus précisément, udev intègre désormais une nouvelle fonction intégrée appelée tpm2_idCette fonctionnalité permet l'extraction et l'identification automatiques du fabricant et du modèle des modules TPM2 connectés lors de la phase de découverte du matériel. Ces informations peuvent ensuite être utilisées pour des politiques de sécurité plus spécifiques, des scripts d'audit ou des outils d'inventaire nécessitant de connaître précisément le module TPM présent sur chaque machine.

Une autre amélioration importante provient de mise en œuvre complète de PrivateUsers=fullCette option d'isolation permet de cartographier l'ensemble des identifiants utilisateur au sein d'un service. Cette modification élimine la solution de contournement utilisée pour détecter correctement les instances imbriquées de systemd à partir des versions antérieures à 257, simplifiant ainsi le comportement en présence de conteneurs ou d'environnements imbriqués.

Pour ceux qui ne connaissent pas, PrivateUser est une fonctionnalité de sandbox qui isole l'espace utilisateur d'un service.Cela garantit que les processus au sein du système utilisent une table d'identifiants uniques (UID) différente de celle du système hôte. Ceci renforce l'isolation contre l'élévation de privilèges et contribue à limiter l'impact des vulnérabilités sur des services spécifiques.

De plus, systemd 260 introduit un nouvelle directive de service appelée MemoryTHP=Cela vous permet de contrôler l'utilisation des pages transparentes volumineuses (THP) au niveau de chaque unité. Les THP peuvent améliorer les performances pour certaines charges de travail gourmandes en mémoire, mais peuvent aussi engendrer des problèmes pour d'autres. Disposer d'une option spécifique pour activer, désactiver ou ajuster leur comportement par service permet d'optimiser les performances beaucoup plus efficacement sans avoir à appliquer de politiques globales.

Nouveautés concernant systemd-logind, systemd-udevd et le contrôle d'accès aux périphériques

Dans le domaine de la gestion des sessions et des périphériques, systemd 260 introduit un concept intéressant appelé "xaccess", mis en œuvre dans systemd-logind y systemd-udevdJusqu'à présent, la logique était la suivante : "uaccess", qui accordait des autorisations d'accès aux périphériques (par exemple, une webcam ou un périphérique d'entrée) aux utilisateurs ayant des sessions au premier plan sur la console locale.

Le nouveau mécanisme xaccess vous permet de déléguer l'accès à des appareils spécifiques à des sessions spécialement marquées.même lorsque les utilisateurs ne sont pas physiquement devant la machine. Le cas d'utilisation typique consiste à accorder l'accès aux périphériques de rendu GPU aux sessions graphiques locales utilisées par des utilisateurs distants, qui ne disposent pas d'un poste de travail physique associé.

Ces sessions sont configurées à l'aide de variable d'environnement PAM XDG_SESSION_EXTRA_DEVICE_ACCESS=Ceci spécifie les périphériques supplémentaires qui doivent être autorisés pour la session selon cette logique. Cela complète uaccess et offre une plus grande flexibilité dans les scénarios de bureau à distance, de virtualisation légère, de laboratoires partagés ou d'accès graphique à distance.

Globalement, ces changements indiquent que un contrôle plus précis et plus dynamique des personnes autorisées à accéder au matérielsans avoir à se fier uniquement à des groupes statiques ou à des autorisations globales. Ceci est particulièrement utile dans les systèmes multi-utilisateurs ou les serveurs avec des GPU partagés, où un équilibre entre sécurité et facilité d'utilisation est recherché.

systemd-networkd et ModemManager : Réseaux mobiles et nouvelles options de connexion

Dans le domaine du réseau, systemd 260 apporte des améliorations intéressantes. La plus marquante est que systemd-networkd est désormais intégré à ModemManager via le protocole « simple connect ».Cela facilite la gestion des connexions de données mobiles (3G, 4G, 5G) directement depuis la configuration systemd.

À cette fin, une nouvelle section a été introduite. dans les fichiers de configuration de networkd, qui accepte des paramètres tels que APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Cela vous permet de définir de manière déclarative comment la connexion mobile doit être établie, quelles informations d'identification utiliser et quel comportement adopter en itinérance, entre autres aspects.

En outre, systemd-networkd étend les options disponibles dans les fichiers .link configurer les interfaces EthernetParmi les nouvelles directives figurent des ajustements de capacité tels que ScatterGather=, ScatterGatherFragmentList=, TCPECNSegmentationOffload=, TCPMangleIdSegmentationOffload=, GenericReceiveOffloadList= y GenericReceiveOffloadUDPForwarding=qui permettent un contrôle beaucoup plus précis des optimisations réseau de bas niveau.

Une autre amélioration notable est que Les interfaces Varlink et JSON de systemd-networkd peuvent désormais afficher les adresses IP sous forme de chaîne de caractères lisible par l'homme.En plus du format de tableau d'entiers existant, cela simplifie grandement les choses pour les outils et scripts externes qui interrogent l'état du réseau, en évitant des conversions fastidieuses.

Pris ensemble, ces changements renforcent la position de systemd-networkd en tant que Gestionnaire de réseau capable de gérer tout, des configurations de serveur de base aux scénarios avancés. avec les réseaux mobiles, le réglage fin du déchargement sur les cartes réseau modernes et l'intégration avec des API externes telles que ModemManager.

Conteneurs, portabilité des services et nouveaux outils

Dans le domaine de la virtualisation légère et des conteneurs, systemd 260 introduit plusieurs améliorations significatives. L'une des plus notables est l'ajout de une nouvelle ligne de commande appelée systemd-mstackconçu pour fonctionner de manière interactive avec la nouvelle fonctionnalité « mstack ».

La caractéristique mstack vous permet de définir un OverlayFS en structurant le contenu d'un répertoire .mstack/ conformément à une spécification précise. Cette fonctionnalité s'inscrit dans le cadre des efforts de systemd pour étendre ses outils de conteneurisation et de sandbox, notamment la prise en charge du téléchargement et de la gestion des images OCI via systemd-importdConcrètement, cela facilite l'assemblage des piles de couches du système de fichiers sans dépendre exclusivement d'outils externes.

Des améliorations ont également été apportées à systemd-vmspawnCet outil est conçu pour lancer des machines virtuelles de manière intégrée à systemd. Parmi les nouvelles fonctionnalités, on peut notamment citer : assistance pour l'enregistrement des machines dans systemd-machined au sein de la session utilisateurAussi bien que possibilité de créer des machines éphémères grâce à l'option --ephemeral, qui disparaissent une fois leur travail terminé.

En ce qui concerne systemd-portabledL'entreprise chargée de la gestion des services portables basés sur l'imagerie remporte désormais le capacité à fonctionner en tant que service au niveau utilisateurCela signifie que les utilisateurs sans privilèges d'administrateur peuvent lancer et gérer des services portables dans leur propre espace, à condition qu'ils utilisent un noyau suffisamment récent et que la distribution ait activé cette option.

De plus, systemd-portabled peut désormais générer une politique et définir l'image utilisée pour les services portablesCela empêche toute modification ultérieure jusqu'à ce que l'image soit réattachée. Ceci garantit une intégrité et une fiabilité accrues dans les environnements où il est important d'éviter toute modification silencieuse de l'image en cours d'exécution.

Améliorations apportées à systemctl, à la planification du processeur et à la documentation pour l'IA

Dans l'interface de gestion des services, Dans cette version, systemctl intègre un nouveau verbe appelé enqueue-marked, qui appelle en interne la méthode D-Bus EnqueueMarkedJobs()Cette fonction est conçue pour gérer plus précisément les tâches marquées dans la file d'attente systemd, offrant ainsi un meilleur contrôle aux outils avancés et aux scripts d'automatisation.

On note également une amélioration au niveau de la planification du processeur : Directif CPUSchedulingPolicy= admet désormais la valeur extce qui permet au planificateur SCHED_EXTCe nouveau type de planification, encore émergent dans l'écosystème Linux, offre une plus grande flexibilité pour les charges de travail spécifiques et les systèmes qui souhaitent expérimenter des politiques de planification externes.

Un détail curieux mais significatif est que le projet a ajouté Documentation spécifique pour les agents d'IA au sein du dépôt systemdL’objectif est d’aider les robots et les extracteurs de données basés sur l’IA à mieux comprendre le code, le style de programmation, les directives de contribution et le fonctionnement interne du projet, afin de réduire les erreurs d’interprétation courantes.

À ce sujet, l'équipe systemd Cela exige que les contributions générées à l'aide de l'IA comportent une étiquette de transparence., comme l'étiquette co-developed-by Dans les correctifs, on trouve des traces de l'utilisation de ces outils lors du développement du code. C'est un exemple de la façon dont même un projet aussi basique s'adapte à la réalité de l'IA générative.

Enfin, systemd-repart ajoute la prise en charge de l'exécution de contrôles d'intégrité de base sur les volumes chiffrésCeci est utile dans les déploiements où vous travaillez avec des partitions ou des images protégées et souhaitez valider leur état sans recourir à des utilitaires externes plus complexes.

Impact sur les distributions et les recommandations aux utilisateurs

Concernant le déploiement effectif de systemd 260, la version commencera pour atteindre progressivement les grands canaux de distribution Durant les six premiers mois de son intégration, celle-ci se fait généralement par le biais de branches de développement ou de mises à jour continues. Les distributions comme Arch Linux ou openSUSE Tumbleweed adoptent généralement ces versions assez rapidement.

Au lieu de cela, Les versions à cycle fixe et les éditions LTS prennent généralement plus de temps. Il est important d'intégrer une version majeure de systemd, surtout si la modification compromet la compatibilité avec des technologies anciennes comme SysV init. Par exemple, les projets comme Fedora ne mettent généralement pas à jour la version majeure de systemd au cours du même cycle de publication stable, mais réservent plutôt ces modifications aux versions plus récentes de la distribution.

Pour l'utilisateur d'ordinateur de bureau moyen, La mise à jour de systemd est rarement perçue comme un événement critique.Étant donné que les distributions s'occupent de tout empaqueter pour éviter tout problème, il y a toujours des passionnés qui veulent la dernière version à tout prix, et dans ces cas-là, il vaut mieux opter pour des distributions à mises à jour continues ou des dépôts de test, en acceptant le risque.

En environnement de production, la recommandation est claire : audit des services existants, examen des scripts dans /etc/init.d/Migration de test vers des unités systemd natives dans des environnements de test Il est impératif de valider minutieusement le comportement avant tout déploiement sur les machines critiques. Négliger cette étape peut entraîner l'impossibilité de démarrer les services, des défaillances de la chaîne de démarrage chiffrée ou des problèmes réseau dans les configurations avancées.

Finalement, systemd 260 représente un grand pas en avant vers un écosystème Linux plus homogène et moderne.Mais cela implique aussi d'abandonner des pratiques et des composants utilisés depuis des décennies. Ceux qui anticipent et planifient la transition bénéficieront d'une expérience bien plus fluide lorsque les distributions effectueront le changement et que cette version deviendra la nouvelle base de leurs systèmes.