SwordArMor

Problèmes avec systemd et pourquoi j’aime l’init de BSD

Préambule

Ceci n’est pas un article que j’ai écrit, mais une traduction de “Problems with Systemd and Why I like BSD Init” écrit par Randy Westlund. Tout « moi » est donc en fait lui.

La traduction

Dans le le premier article de mon blog, je disais que systemd était l’une des choses qui m’ont poussées à jeter un œil aux BSDs et éventuellement à migrer vers FreeBSD. Des gens me demandaient quel était mon problème avec systemd, mais je n’avais jamais rien écrit à ce propos. Finalement, voici ce que j’en pense.

J’ai été réticent à parler de systemd ici car j’étais fatigué de voir tout le monde se battre à son sujet. La liste de diffusion de Gentoo (et toutes les autres sur internet) est devenu une énorme arène de guerre où chacun pense que systemd est soit une menace tout en attaquant personnellement Lennart Poettering, soit chacun pense que systemd va tous nous sauver de nous même et tout le monde devrait l’utiliser. J’étais juste malade de voir tout le monde tomber dans l’excès.

Pour ma part, je ne suis pas fan de systemd mais je ne pense pas que ça soit la fin du monde non plus. J’ai regardé un très bon interview avec Lennart dans le Linux Action Show où il expliquait comment il l’a implémenté, et il a certaines bonnes raisons. Pour écrire un daemon pour Linux, vous êtes obligé de maintenir différents scripts pour chaque distribution car elles placent les choses à des endroits différents. Et sysVinit n’est pas le meilleur avec la gestion des dépendances. Développer des choses pour Linux en tant qu’ordinateur de bureau n’est pas aussi facile que ça devrait l’être, en grande partie à cause du manque d’homogénéité.

J’ai évité ceci quand j’utilisais Linux à la maison, mais ces jours-ci je dois utiliser Linux au travail et je ne plus plus y couper. Après avoir utilisé systemd pendant un moment, il y a définitivement des choses que j’aime dedans. Il rend les choses plus faciles. Comme prendre un daemon que j’ai écrit et en faire un service. Les fichiers de services sont sympas, et leur dire de redémarrer mon service s’il crash est très pratique. J’aime le fait que les fichiers de service vont fonctionner sur toutes les distributions Linux qui utilisent systemd. Je peux simplement écrire un fichier de service de mémoire [NDT : service files], alors que je dois partir d’un exemple pour un script de rc.

D’un autre côté, il rend les choses difficiles encore plus difficiles. Si je veux faire quelque chose de complexe pour lequel systemd n’a pas été prévu, je suis foutu. Avec l’init de BSD, je peux simplement éditer le script /etc/rc et le remplacer par du code shell arbitraire. Par défaut, il regarde dans /etc/rc.d/ et exécute les scripts activés ici, mais je peux changer ça en moins de cinq minutes.

Voici le /etc/rc de FreeBSD. /sbin/init appelle ce script, et /etc/rc appelle les scripts activés dans /etc/rc.d/.

https://github.com/freebsd/freebsd/blob/master/etc/rc

Regardez à quel point il est léger. Je peux changer tout ce que je veux. Je peux enlever la partie où il démarre les services et en démarrer manuellement juste un ou deux. Je peux changer la destination de la sortie console, comme la rediriger vers un fichier. Je peux dire à ce script d’appeler tout ce que je veux, comme je le veux. Flexibilité illimitée.

Je ne suis pas un expert des systèmes d’init, mais j’ai utilisé OpenRC depuis un long moment et je suis maintenant assez familier avec l’init de BSD. Pour ce que je comprends, l’init de BSD est supérieur au vieux sysVinit que Linux avait pour habitude d’utiliser. Et l’OpenRC de Gentoo est similaire à l’init de BSD. Je n’ai pas d’expérience particulière avec le classique sysVinit. Voilà d’où je viens.

Systemd est très opaque. Ce que je veux dire par là est qu’il est très compliqué à débugguer. Je ne peux pas regarder à l’intérieur et voir ce qu’il fait, parce que c’est un binaire compliqué. Je ne peux pas facilement voir la façon dont il se comporte. L’init de BSD est juste un script, donc je peux l’inspecter, ajouter des déclarations d’état, et le changer de toutes les façons que je veux. Il est facile de regarder à l’intérieur et de comprendre exactement ce qu’il va faire et comment.

La façon avec laquelle systemd fait le démarrage en parallèle me dérange. Si un service A dépend d’un service B, ils vont traditionnellement démarrer l’un après l’autre ; A va seulement démarrer si B est lancé. Systemd va les démarrer en même temps, mais temporiser tous les messages que A va tenter d’envoyer à B tant que B n’est pas prêt. Donc A va juste penser que B met du temps à répondre, et le système va démarrer plus vite. Vous pouvez désactiver ceci en utilisant la directive 'After', mais ceci ne va pas s’appliquer à tout le système et de toutes façons, désactiver une fonctionnalité n’est pas une réponse à ce qui devrait exister à la place.

Mon problème avec ceci est que, selon moi, l’ordre dans lequel les services démarrent devrait être exactement le même et prédictible pour l’administrateur système. Avec systemd, l’ordre n’est pas déterminé, donc vous ne savez pas ce qui va arriver au prochain démarrage. Je travaille avec des serveurs et des systèmes embarqués ; le temps de démarrage n’est pas ma préoccupation. Un serveur passe plusieurs minutes dans le BIOS pendant le POST de toutes façon, avant même que l’amorceur de démarrage soit chargé ; faire en sorte que le système d’exploitation démarre plus vite ne va pas changer grand chose. Les systèmes embarqués démarrent déjà rapidement car vous faites en sorte d’y mettre le strict minimum. Ce qui m’intéresse, c’est qu’à chaque fois que je démarre, les choses se déroulent exactement dans le même ordre — dans l’ordre que je veux.

Il semblerait que personne ne s’accorde à dire si systemd est modulaire ou non. Je pense que le problème vient des différentes définition de la modularité. Systemd ne met pas tout dans le PID 1 comme certains le suggèrent ; il utilise des modules qui communiquent entre eux. Dans ce sens, il est modulaire. Mais ces modules sont très étroitement imbriqués. Vous ne pouvez pas en enlever certains, ou les remplacer avec d’autres choses. Dans ce sens il est monolithique. Ce n’est pas comme avoir une interface simple et passer les données via l’entrée et la sortie standard, ce qui est la modularité qui a rendu les pipes UNIX possibles. C’est le sens qui importe pour moi.

Je n’aime pas la façon avec laquelle systemd absorbe tout. Ce n’est pas un simple système d’init, il devient un micmac de gestion du système. Ça ne me semble pas modulaire. Pourquoi systemd devrait implémenter NTP alors que ntpd existe déjà ? Je pense que systemd-timesyncd et toutes ces choses comme ça ne sont qu’une réinvention de la roue.

Dans le cas de ntpd, vous pouvez dire que c’est une monstruosité qui doit être remplacée par quelque chose de plus petit, et vous avez raison. Il existe d’autres implémentations. OpenBSD a créé OpenNTPD, qui est très léger, seulement un client, et peut même aller vérifier sur des sites en HTTPS que le temps obtenu par NTP est raisonnable. Nettoyer ou ré-implémenter ntpd est une bonne chose, mais OpenBSD n’a pas jugé nécessaire de l’inclure dans un init.

Édition du 31 octobre 2015 : Merci @myfreeweb de me corriger, OpenNTPD n’est pas seulement un client. Il est, cependant, orienté client, mais c’est perdre en précision pour gagner en simplification. Si vous faites tourner un serveur de temps, vous utilisez sûrement quelque chose d’autre.

Linux est très fragmenté et systemd recolle un peu les bouts ensembles. Ça pourrait être une bonne chose. Mais de la façon dont c’est mené, il va y avoir un point à partir duquel on ne pourra plus dire « GNU/Linux ». Ce sera « GNU/systemd-linuxd ».

Mais une partie de ce qui fait que Linux est si spécial est la capacité à littéralement échanger un composant pour autre chose — même la libc ! Tout ce dont un programme Linux a besoin est un noyau et quelque chose que ressemble à libstdc.so. Il est répandu de construire des systèmes embarqués sous Linux avec ulibc, ou quelque chose de minimaliste. BSD ne peut pas remplacer sa libc, elle est trop incorporée.

Il a eu un très bon interview de quelques développeurs GNOME sur BSD Now il y a peu de temps. Ils disaient qu’ils vont porter leur attention sur la compatibilité avec BSD, mais ils parlaient aussi des raisons de leur dépendance à systemd : il n’y a pas d’API ou de façon standard de faire des choses telles que régler le fuseau horaire, changer de réseau Wi-Fi, ou mener à bien beaucoup de tâches banales avec Linux. Le code de GNOME est plein de #ifdefs donc ils peuvent utiliser du code différent en fonction des distributions ou du système d’exploitation, et ce n’est pas maintenable. Systemd apporte ces API de manière propre et portable, ce qui n’est pas négligeable pour les environnements de bureau.

OpenBSD travaille sur systemBSD, un substrat de systemd. Il fournit les APIs dont GNOME a besoin, mais n’implémente pas le reste. Je pense qu’avoir ce genre d’API est une très bonne chose, et j’aimerais nous voir comme une industrie de la standardisation là-dessus (ou quelque chose du genre).

Sytemd semble toujours instable. Je ne sais pas si c’est parce qu’il a plus de problèmes que les autres logiciels ou si c’est juste que les gens aiment à divulguer ses défectuosités, mais il a quelques problèmes qui pourraient être très drôles s’ils n’étaient pas si critiques. J’ai inclus des liens vers les rapports de bug actuels :

Pour une pièce critique de l’infrastructure, avoir des bugs réguliers de ce genre est un gros problème. Ça peut rendre une machine inutilisable et ruiner la journée de quelqu’un. Comparez ceci avec un projet réellement bien dirigé comme OpenZFS. De ce que j’en sais, personne n’a jamais perdu de données à cause d’un bug dans ZFS. Des projets d’infrastructure comme celui-ci doivent être maintenu à un standard encore plus élevé que le reste des logiciels à cause des conséquences si sévères qu’un bug peut avoir.

Je pense que les développeurs de systemd souffrent du syndrome du Not invented here. Je ne peux rien trouver qui suggère qu’ils ont considéré OpenRC ; ils ont l’air d’avoir des soucis personnels avec Gentoo. Une bonne part des problèmes dans les systèmes d’init qu’ils décrivent ont déjà été résolu par à la fois OpenRC et l’init de BSD. Maintenant ils sont autour de la ré-implémentation de tous les daemons Linux possibles en tant que module de systemd, juste parce qu’ils le peuvent.

Je parlais récemment avec un lecteur qui disait, « À chaque fois que je regarde le développement de systemd, j’ai l’impression que tout est une épreuve. ». Je pense que c’est particulièrement vrai. Systemd a été imposé à la communauté, et tout s’est enchaîné très vite. Il y a eu beaucoup de manœuvres politiques et de bras de fer avec les mainteneurs de distributions pour en faire le choix par défaut partout avant qu’il soit mature.

Debian n’aurait pas dû l’adopter avant au moins quelques années ; ils ont pour habitude d’être une distribution lente, régulière et stable. Leur adoption rapide de systemd a heurté les mœurs et entraîné le départ de la moitié de leur équipe pour Devuan. Ceci ne devrait pas arriver. Si votre équipe est farouchement divisée sur un point, la bonne réponse est de garder le statut quo et d’y revenir à tête reposée. Debian a perdu une grande part de sa réputation de stabilité à cause de ça.

Honnêtement, je pense que si systemd avait été graduellement adopté, au lieu d’être imposé, il aurait été plus populaire. Les gens auraient pu voir Fedora et Arch l’utiliser depuis plusieurs années et peut-être qu’à ce moment tout le monde aurait vu les avantages et aurait voulu l’adopter alors qu’il serait devenu stable. Mais de la façon dont ça s’est passé, la communauté n’a pas eu son mot à dire, et ce n’est pas une bonne chose.

J’aurais accueilli un remplaçant de sysVinit qui soit plus dans la mouvance UNIX. Quelque chose comme systemd aurait pu être bien, mais systemd a trop de défauts à la fois dans sa conception et son implémentation pour être ce dont nous avons besoin.

Je pense que le bon côté des choses est que ça a montré les problèmes causés par le modèle de la dictature du bénévolat que Linux utilise. Je pense que les gens ont fuit vers BSD pour sa communauté tout autant que pour sa supériorité technique.

Je trouve dérangeant que systemd manque de foi en UNIX. Alors venez rejoindre la communauté BSD. On a des cookies ;)