Systemd et la montagne du destin (de trolleur)

Cet article est la remise en ligne d’un ancien article paru sur le blog libre.

Je n’ai découvert qu’il y a quelques semaines que systemd suscitait autant de haine. Interrogé par la dichotomie entre cette haine et la pourtant très large majorité des distributions qui l’adoptent (à l’heure actuelle RHEL — et par ricochet CentOS — Fedora, Mageia, Debian — et par ricochet Ubuntu et une bonne part des distribution existantes), j’ai donc fait des recherches et posé quelques questions.

Et… ?

Bah je comprends toujours pas.

Troll niveau 0 : le troll raisonnable

Le discours du troll raisonnable tourne essentiellement autour d’un argument de type : “Nan, mais comme système d’init, je dis pas ! Pour le reste par contre…”.

Systemd est en effet accusé d’être trop monolithique. Pour ces trolls, systemd est un très bon système d’initialisation (encore heureux, diviser le temps de boot par 10 par rapport à sysvinit…) mais ils lui reprochent de vouloir cannibaliser l’environnement Linux en prenant en charge des fonctionnalités qui n’ont rien à voir avec l’init.

Et il est vrai que systemd propose beaucoup d’utilitaires annexes :

  • un gestionnaire de logs,
  • un gestionnaire de cron,
  • gestionnaire de connexions réseau
  • etc…

Cet argument repose en fait sur une méconnaissance pure et simple de systemd.

Il est vrai, effectivement, que systemd propose les socket units et les timer units mais rien, absolument rien, ne vous oblige à les utiliser, ni dans les scripts d’init, ni en dehors.

Exemple simple sur Mageia (parce que c’est ma distrib) : cron. Mageia utilise systemd depuis un bout. Pourtant, cron est toujours présent sur la distrib et parfaitement utilisable :

Et il est démarré à l’init ? Oui oui !

C’est beau comme un pet de fille !

Une seconde critique, qui est un raffinement de la première, porte sur la question des logs ; et elle a fait couler beaucoup d’encre. En effet, systemd génère, par défaut, des logs en binaire par l’intermédiaire du démon journald de sorte que, si jamais il y a un problème, les logs ne seraient pas consultables avec un bon vieux vi. Du coup, la question qui vient tout de suite à l’esprit c’est : bah, oui, mais si c’est journald lui-même qui fait de la merde ? Réponse : vous êtes baisés…

Faux ! Complètement faux !

Encore une fois, l’arguement repose sur l’ignorance totale du fonctionnement de systemd. En effet, comme à peu près tout programme sur Linux, journald transmet ses logs à syslogd, le démon de logs historique de Linux. Et ça, vous pouvez toujours le lire avec un bon vieux cat + grep .

Démonstration :

Il y en a plus mais bon, je vais pas vous montrer tous mes logs… Jamais le premier soir ;)

Reste à savoir pourquoi journald stocke quand-même ses logs en binaires.

Hé bien, il se trouve que journalctl, permet d’effectuer des requêtes très fines dans les logs de journald. Exemple :  $ journalctl -o json-pretty -p err  va me montrer les logs au format json lisible avec le niveau de verbosité erreur. Et autant vous dire que les logs sont pas mal bavards.

Alors certes, pour un utilisateur seul, ça peut ne pas avoir grand interêt. On peut s’en sortir à peu près bien avec le classique cat + grep . Par contre, imaginez un peu le bonheur pour l’admin sys qui gère une ferme de 40 serveur qui font tourner 1000 machines virtuelles chacune…

En fait, stocker les logs de systemd en binaire n’a pas beaucoup moins de sens que de stocker une base de données SQLite en binaire. Pourtant, dans le second cas, personne n’y trouve à redire…

Bref, systemd fait beaucoup de choses mais n’oblige à rien. Et surtout, il est bon dans ce qu’il fait.

Troll niveau 1 : le troll de mauvaise foi

Là, on commence à s’approcher du troll classique. Ce troll avance plusieurs arguments à l’encontre de systemd en plus de ceux cités précédemment. Oui, j’ai oublié de vous dire : les argumentairse de chaque niveau de troll sont cumulatifs et peuvent être avancés dans n’importe quel ordre.

Le premier et le plus commun des arguments de mauvaise fois, c’est bien sûr : « systemd est inutilement compliqué pour l’utilisateur et freine l’apprentissage des débutants »

Voyons ça :

Un script sysvinit :

avec systemd :

Ah oui, effectivement, c’est le summum de la complexité…

Mais pourquoi le script de systemd est aussi simple ?

Simplement parce que les scripts d’init d’un service classique réutilisent très souvent les mêmes portions de code. Du coup, plutôt que de laisser à la charge du développeur le soin de réécrire tout le temps les mêmes scripts, systemd se charge lui-même de le faire. L’approche des scripts de systemd est une approche déclarative plutôt que procédurale. C’est un peu le même genre d’approche qu’a Maven pour la compilation.

Diantre, systemd serait donc respectueux de la philosophie Unix du DRY (Don’t Repeat Yourself) ? Calomnie, mon ami ! Systemd, c’est d’la merde j’vous dit !

Reste qu’il est compliqué à apprendre pour les débutants. Compliqué à apprendre pour les débutants ? Hmm… Laissez-moi vous expliquer comment fonctionne le vieux sysvinit :

  1. Au démarrage, il lit le fichier  /etc/inittab  puis se placcde dans le dossier /etc/init.d et exécute un par un les scripts qu’il contient dans l’ordre spécifié.
  2. Habituellement, pour démarrer ou stopper un service, on utilise la commande service . Sauf que bien évidemment, comme ce sont des scripts bash, on peut les exécuter sans ça. Ce qui pose problème, puisque, vu que dans ce cas d’utilisation précis, sysvinit n’est pas informé du changement d’état du service, il pourrait se mettre à répondre de la merde.
  3. Pour régler le problème, voici comment il procède :
    1. il envoie le signal  kill(2)  au PID du service,
    2. si l’envoi du signal échoue, le PID n’existe pas et donc, le service est stoppé,
    3. sinon, il y a bien un programme qui tourne sous ce PID sauf que, comme on l’a vu précédemment, l’utilisateur peut faire de la merde, avoir stoppé le service et le système avoir récupéré le PID pour le donner à une autre appli,
    4. du coup, pour être sûr qu’on parle bien de la même chose, sysvinit check alors que l’appli associée au PID en question est bien le système qui a démarré au départ.

C’est pas le top du top de l’optimisation, ça, si ? Alors je suis désolé, mais là, je ne vois vraiment pas en quoi systemd est plus compliqué à utiliser ou plus hors de portée des débutants… De toutes façons, en général, quand on commence à aborder l’init dans Linux, on est rarement un débutant en Linux…

Troll niveau 2 : la fête du slip !

Alors attention, les enfants. Là, c’est du lourd. Le champion toutes catégories. Le pokemon mythique. Il ne se rencontre que très rarement alors je vous conseille d’économiser vos masterballs, parce que là, vous ne l’aurez pas autrement. Ce troll là, ajoute les arguments précédents à une méconnaissance totale de systemd, acquise aux cours de longues lectures de bullshits, et à une capacité sans égale à mentir ou à détourner les faits. Et là, puisque visiblement c’est un concours de celui qui dira le plus n’importe quoi, les arguments sont nombreux… et stupides. Par exemple, BoycottSystemd (boycottsystemd.org n’existe plus aujourd’hui, à la place il y a un site perso, visiblement d’un contributeur de uselessd, un démon d’init créé pour protester contre systemd, et qui, probablement, administrait le siste sous son ancienne forme mais ces allégations demandent confirmation) nous affirme que :

« systemd clusters itself into PID 1, rather than acting as a standalone process supervisor »

Traduction :

« systemd s’attache lui-même au PID 1, plutôt que d’agir en superviseur de processus indépendant »

Oui… C’est… C’est plus ou moins le principe d’un système d’init… L’OS le démarre en premier donc il possède le numéro d’identification 1… C’est plutôt logique… Ou encore :

« systemd is designed with glibc in mind, and doesn’t take kindly to supporting other libcs all that much »

Traduction :

« systemd est conçu sur la glibc et ne prend pas vraiment en compte le support d’autres libc »

Ouais, enfin, d’un autre côté, quand tu développe un système d’init pour Linux, c’est à peu près plus ou moins normal d’utiliser les bibliothèques de l’API Linux, quoi !

L’une des attaques les plus courantes consiste tout simplement à conspuer les développeurs eux-mêmes et leur attitude. Ce qui prouve à peu près que dalle sur les qualités techniques de systemd. D’aucun les accusent par exemple de cannibaliser d’autres projets Linux avec un forte envie de dictature sur l’écosystème. On cite volontiers en exemple le projet udev qui a fusionné avec systemd. Cet un argument est tellement stupide… Lennart Poettering, l’un des auteurs de systemd, est un ingénieur de chez Red Hat. En concevant systemd, il a juste fait son boulot… Je ne vois pas en quoi ça prouve quoi que ce soit sur ses envies de pouvoir… Et si udev et systemd on fusionné, c’est simplement parce que leurs développeurs respectifs pensaient que c’était la meilleure solution. Personne n’a braqué d’arme sur personne, faut arrêter…

Conclusion

Au final tout ce déferlement de haine me fait pas mal rigoler. Certains ont tellement soif de fantasmes qu’ils s’inventent des histoires farfelues. Le plus intéressant, c’est le fossé qui sépare les trolls haineux des développeurs du noyau Linux qui sont, eux, beaucoup plus mesurés au sujet de systemd. Du coup, on assiste à des réactions très marrantes comme sur ForkDebian où les auteurs du site menacent de… Forker Debian ! Oui ! Franchement, c’est pas la menace la plus bidon du monde, ça ? Vous imaginez un type se pointer dans une bijouterie et sortir ça :

« Bouge pas ! C’est un hold-up ! Ouvre la caisse ou je te fork !
— Nan, pitié ! Pas le fork ! Coupe moi une oreille sur tu veux mais me fork pas ! Tiens, voilà le fric !
— Bon, ok, t’est coopératif. Mais faut que je fasse un exemple. Que les autres voient que je déconne pas. Je te fork un bras pour leur apprendre ! »

Mais sincèrement, moi, j’ai super envie que ces types forkent Debian ! Comme ça, je pourrait regarder cette distrib se trainer lamentablement durant quelques temps avant de mourir dans un râle de douleur et l’indifférence générale.

Note : Debian a été forké le mois dernier sous le nom de Devuan. La nouvelle distribution est développée par la team VUA (Veteran Unix Admins). On n’a absolument aucune idée de qui est cette team VUA et quels contributeurs se cachent derrière ce pseudonyme pompeux. Que la grosse marade commence ! o/

Aucun avis pertinent dans Systemd et la montagne du destin (de trolleur)

Laisser un commentaire

indique des champs obligatoire.