Pourquoi systemd ?

Publié par Edouard le

Traduction:

systemd est encore un projet jeune, mais il n’est plus un bébé maintenant. L’annonce initiale a été posté il y a exactement un an. Depuis, la plus part des distributions majeures ont décidé de l’adopter, d’une manière ou d’une autre, alors que des distributions plus petites l’utilisent déjà. La première distribution importante utilisant systemd par défaut sera la Fedora 15, pour la fin du mois de mai. On peut s’attendre à ce que les autres distributions suivent le mouvement un peu plus tard (avec une exception). Beaucoup de développeurs l’ont déjà adopté, et il y a même déjà une entreprise qui propose des services et une expertise spécialisés sur systemd. En bref, en un an systemd est devenu un projet prometteur.

Malgré cela, il y a encore des gens qui n’ont pas été convaincu. Si vous faites partie d’une de ces catégories, alors veuillez lire la comparaison des systèmes d’init qui va suivre:

  • Vous travaillez sur des projets pour de l’embarqué, et vous vous demandez s’ils devraient être basés sur systemd.
  • Vous êtes un utilisateur ou un administrateur et vous vous demandez quelle distribution choisir, et vous hesitez si elle doit être basée ou nonn sur systemd.
  • Vous êtes un utilisateur ou un administrateur et vous vous demandez si votre distribution favorite utilisera systemd, même si tout marche déjà bien jusqu’à présent.
  • Vous developpez une distribution qui n’a pas encore basculé sur systemd, et vous vous demandez s’il faut investir du travail pour basculer sur systemd.
  • Et même si vous ne faites pas partie de ces catégories, vous pourriez trouver cette comparaison intéressante.

nonus allons comparer les 3 principaux système d’init utilisés sous Linux: sysvinit, Upstart et systemd. Bien sûr, il y a d’autres systèmes d’init qui existent, mais ils ne jouent virtuellement aucun rôle majeure dans le tableau. A moins que vous utilisez Android (qui est une bete à part de toute façon), vous avez surement déjà utilisé un des ces trois systèmes d’init sur votre nonyau Linux. (OK, ou busybox, mais alors grossièrement vous n’êtes pas en train d’utiliser un système d’init du tout). A moins que vous ayez un besoin exotique il n’y a pas besoin d’aller voir plus loin. Et aussi parce que je suis un peu paresseux, et que je ne veux pas passer du temps à analyser ces autres systèmes en détails pour être complètement honnête avec ceux-ci.

En parlant d’honnêteté, je suis bien sûr l’un des créateurs de systemd. J’essayerais de faire de mon mieux pour être juste envers les deux autres concurrents, mais au final, à prendre quand même avec des pincettes. Je suis sûr que même si je devrais être injuste ou d’une manière incorrect, quelqu’un le signalera dans les commentaires, donc n’hesitez pas à les lire aussi, avant de mettre trop de confiance dans ce que je dis.

nonus ne regarderons que les fonctionnalités déjà implémentées dans une version déjà disponible. Les fonctionnalités futures ne comptent pas.

Fonctionnalités générales

sysvinitUpstartsystemd
Interface avec D-Busnonouioui
Démarrage sans Shellnonnonoui
Services modulaires codés en C
disponibles très tôt au boot
nonnonoui
Read-Aheadnonnon[1]oui
Activation basée sur surveillance de socketnonnon[2]oui
Activation basée sur surveillance de socket:
compatibilité avec inetd
nonnon[2]oui
Activation évènementielle par surveillance d’un busnonnon[3]oui
Activation évènementielle par un matérielnonnon[4]oui
Configuration des dépendances matériel
avec des règles udev
nonnonoui
Activation évènementielle par surveillance
d’un chemin (inontify)
nonnonoui
Activation basée sur un timernonnonoui
Gestion de mountnonnon[5]oui
Gestion de fscknonnon[5]oui
Gestion des quotanonnonoui
Gestion de automountnonnonoui
Gestion de la swapnonnonoui
Prise d’instantanés de l’état du systèmenonnonoui
Support de XDG_RUNTIME_DIRnonnonoui
Suppression optionnelle des processus restants
quand un utilisateur se delogue
nonnonoui
Intégration des Control Groups Linuxnonnonoui
Génération d’enregistrement pour audit
des services démarrés
nonnonoui
Intégration de SELinuxnonnonoui
Intégration de PAMnonnonoui
Support des disques durs encryptés (LUKS)nonnonoui
Gestion du certificat SSL ou du mot de
passe pour LUKS, incluant Plymouth,
Console, wall(1), TTY et les agents Gnome
nonnonoui
Gestion du périphérique loopback pour le réseaunonnonoui
Gestion de binfmt_miscnonnonoui
Gestion de la localisation globale du systèmenonnonoui
Configuration de la Console et du clavier setupnonnonoui
Infrastructure pour créer, supprimer et
nettoyer les fichiers temporaires et volatiles
nonnonoui
Gestion de sysctl pour /proc/sysnonnonoui
Intégration de Plymouthnonnonoui
Sauvegarde/restauration d’un random seednonnonoui
Chargement statique des modules kernelnonnonoui
Gestion automatique de la console sérienonnonoui
Gestion d’un identifiant unique de la machinenonnonoui
Gestion dynamique du nonm d’hôte et des meta
données de la machine
nonnonoui
Arrêt fiable des servicesnonnonoui
Enregistrements /dev/log très tôt au bootnonnonoui
Démon minimal de syslog basé sur kmsg
pour un usage embarqué
nonnonoui
Relance sur plantage de service sans perte de
connectivité
nonnonoui
Mises à jour de service sans indispononnonoui
UI graphiquenonnonoui
Outils et profilage intégrésnonnonoui
Services instanciésnonouioui
Intégration de PolicyKitnonnonoui
Accès distant/Support Cluster intégrés dans
les outils clients
nonnonoui
Peut lister tous les processus d’un servicenonnonoui
Peut identifier le service d’un processusnonnonoui
CPU Cgroups automatiques par service, pour contrôler l’utilisation CPUnonnonoui
Cgroups automatiques par utilisateurnonnonoui
Compatibilité SysVouiouioui
Services SysV contrôlables de la même manière que les services natifsouinonoui
/dev/initctl compatible SysVouinonoui
Re-exécution avec une sérialisation complète des étatsouinonoui
Démarrage interactifnon[6]non[6]oui
Support des container (remplacement évolué de chroot())nonnonoui
Démarrage basé sur des dépendancesnon[7]nonoui
Désactivation de services sans éditer un fichier
de configuration
ouinonoui
Masquage de services sans éditer un fichier
de configuration
nonnonoui
Arrêt du système robuste avec le PID 1nonnonoui
Support intégré de kexecnonnonoui
Génération dynamique de servicenonnonoui
Support en amont depuis d’autres
composants de l’OS
ouinonoui
Fichiers de service compatibles entre distributionsnonnonoui
Transmission de signaux vers servicesnonnonoui
Arrêt fiable des sessions utilisateurs avec
l’arrêt du système
nonnonoui
Support de utmp/wtmpouiouioui
Fichiers de services facilement compréhensible,
parfait pour la manipulation avec des outils de gestion
nonnonoui

¹ L’implémentation de Read-Ahead pour Upstart est disponible via un paquet séparé « ureadahead », nécessite un patch non standard sur le kernel.

² L’implémentation de l’activation par socket pour Upstart est disponible en tant que « preview », mais ne supporte pas la parallélisation et du coup rate complètement l’intérêt de l’activation par socket.

³ L’implémentation de l’activation par Bus pour Upstart disponible comme patch, pas encore intégré.

⁴ L’implémentation de l’évènementiel via udev sur les périphérique au niveau d’Upstart est disponible en tant que « preview », en transmettant intégralement la base udev, peu pratique.

⁵ L’utilitaire de gestion mount « mountall » pour Upstart est disponible dans un paquet séparé, ne couvrant que les montages lors du boot, avec un système très limité de dépendance.

⁶ Certaines distributions offrent cette implémentation dans le shell.

⁷ Les scripts d’init LSB supportent ceci, s’ils sont utilisés.

Réglages disponibles sur les services natifs

sysvinitUpstartsystemd
Ajustement de l’OOMnonoui[1]oui
Répertoire de travailnonouioui
Répertoire racine (chroot())nonouioui
Variables d’environnementnonouioui
Variables d’environnement depuis un fichier extérieurnonnonoui
Limitation des ressourcesnonpartiel[2]oui
umasknonouioui
Groupement des Utilisateurs/Groupes/Groupes supplémentairesnonnonoui
Classe/priorité de l’ordonnancement des IOnonnonoui
Valeur de nice pour l’ordonnancement CPUnonouioui
Politique/priorité d’ordonnancement CPUnonnonoui
Contrôle de la remise à zero de l’ordonnanceur CPU sur fork()nonnonoui
Affinité CPUnonnonoui
Timer Slacknonnonoui
Contrôle des capacitésnonnonoui
Contrôle du bit de sécuriténonnonoui
Contrôle des Control Groupsnonnonoui
Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: rendre des répertoires inacessiblesnonnonoui
Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: rendre un répertoire en lecture seulnonnonoui
Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: /tmp privénonnonoui
Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: héritage de montagenonnonoui
Entrée depuis la Consoleouiouioui
Sortie via Syslognonnonoui
Sortie via kmsg/dmesgnonnonoui
Sortie sur un TTY donnénonnonoui
Contrôle du signal Killnonnonoui
Exécution conditionnelle: par l’identification d’une virtualisation CPU /containernonnonoui
Exécution conditionnelle: par la présence d’un fichiernonnonoui
Exécution conditionnelle:: par un framework de sécuriténonnonoui
Exécution conditionnelle: par ligne de commande kernelnonnonoui

1 Upstart supporte seulement le mécanisme obsolète oom_score_adj, pas l’actuel logique de oom_adj.
2 Upstart ne supporte pas RLIMIT_RTTIME et RLIMIT_RTPRIO.

A noter que certaines de ces options sont relativement faciles à ajouter aux scripts d’init de SysV, en éditant les sources shell. Le tableau au dessus ne cible que les options facilement accessibles qui ne demandent aucune modification du code source.

Autres

sysvinitUpstartsystemd
Maturité> 15 ans6 ans1 an
Services disponibles de la part d’ingénieurs et consultants spécialisésnonnonoui
SCMSubversionBazaargit
Contribution sans Copyrightouinonoui

Résumé

Comme les tableaux précédents le montrent clairement, systemd a laissé derrière lui sysvinit et Upstart dans la plus part des aspects. A l’exception de l’age/maturité du projet systemd gagne dans chaque catégorie. Maintenant, il sera très difficile pour sysvinit et Upstart de rattrapper les fonctionnalités que systemd fournit aujourd’hui. En 1 an, nous avons réussi à pousser systemd plus loin que Upstart a fait en 6 ans.

C’est notre intention d’être moteur dans le developpement de la plateforme Linux avec systemd. Dans le prochain cycle de sortie, nous nous concentrerons plus sur le fait de fournir les mêmes fonctionnalités et amélioration de rapiditié, que nous offrons déjà pour le système, sur l’ouverture de session utilisateur. Cela apportera une intégration plus proche avec les autres parties de l’OS et des applications, rendant la plus part des fonctionnalités que le gestionnaire de services fournit, en le rendant ainsi disponible aux sessions utilisateurs. Certains composants comme ConsoleKit seront rendus redondants avec ces améliorations, et les services s’appuyant sur ceux-ci seront mis à jour. Le fardeau de maintenir ces composants obsolètes reposera de fait sur les vendeurs/intégrateurs qui voudront continuer à s’appuyer sur ceux-ci.

SI vous vous demandez si vous devez adopter ou non systemd, alors systemd gagne quand il vient avec plus de fonctionnalité. Bien sûr cela ne devrait pas être le seul aspect à garder à l’esprit. Dans la longue course, s’attacher à l’infrastructure existante (comme ConsoleKit) à un prix: du travail de portage doit être fait, ainsi qu’un travail additionnel de maintenance. Le faire par vous même signifie une charge de travail accrue.

Cela dit, adopter systemd n’est pas non plus sans effort. Surtout si vous aviez fait des investissements sur les deux autres solutions, adopter systemd signifiera du travail. Le travail basique pour adopter systemd est relativement minime pour le porter sur des systèmes utilisant SysV (vu que la compatibilité est assurée), mais cela peut signifier un travail plus que substantiel quand il s’agira d’Upstart. Si vous cherchez à aller sur un système 100% systemd sans aucune compatibilité avec SysV (recommandé pour l’embarqué, la cible à long terme pour les grosses distributions), vous aurez besoin de pouvoir investir du temps pour convertir tous les scripts d’init vers les fichiers simples d’unité de systemd.

systemd est en phase de devenir une plateforme modulaire, intégrée et compréhensible, fournissant tout le nécessaire pour démarrer et maintenir un environnement utilisateur du système d’exploitation. Il inclut la ré-écriture en C de tous les scripts basiques d’init du début de la phase de démarrage, fournit par les distributions. Spécifiquement pour le cas de l’embarqué, adopter systemd vous fournira en une étape tout ce dont vous avez besoin, et vous pourrez choisir les modules que vous voulez. Les deux autres systèmes d’init ont des composants singuliers et individuels, qui pour être utiles nécessitent un grand nombre de composants additionnels pour décaler l’interfaçage. Le but principal de systemd à fournir une plateforme plutôt qu’un composant permet une intégration plus précise, et une API plus propre. Tôt ou tard, cela remontera jusqu’au niveau des applications. Déjà, il y a les spécifications XDG qui ont été acceptées (sur le basedir XDG, et plus spécifiquement sur XDG_RUNTIME_DIR), et qui ne sont pas supportées par les autres systèmes d’init.

systemd est aussi une belle opportunité pour la standardisation de Linux. Vu qu’il standardise un grand nombre d’interfaces du système qui était avant différentes sur chaque distribution, sur chaque implémentation, adopter systemd permettra de lutter contre la balkanisation des interfaces de Linux. Choisir systemd signifie redéfinir plus précisément ce qu’est la plateforme Linux. Ceci facilite le travail des programmeurs, des utilisateurs tout comme des administrateurs.

Je crois que le mouvement s’amorce clairement avec systemd. Nous vous invitons à rejoindre notre communauté et ainsi faire partie de ce mouvement.

EDIT: Il manquait la fin…

Catégories : Distributions

0 commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

CAPTCHA ImageChange Image