Le Blog Utux

HTTP 200 GET /

systemd, c'est bien.

Rédigé par uTux 22 commentaires

Systemd est un système d'init "moderne" qui remplace le vieillissant sysvinit. L'init c'est le premier process qui démarre après le boot et qui va "orchestrer" le lancement des services : réseau, logs, ssh ... Mais wikipedia explique cela mieux que moi.

Dire que systemd a provoqué de nombreuses polémiques et levées de boucliers de la part des utilisateurs est un euphémisme, c'est un beau bazar dans lequel des troll s'affrontent au lance-flammes. On lui reproche de nombreuses choses : réinventer l'eau chaude alors que sysvinit marche bien, être monolithique et donc contraire à la philosophie UNIX, être le cheval de troie de Red Hat pour à terme remplacer de plus en plus de composants dans Linux, ne pas être portable sur les autres OS, etc. Je pense que la plupart des critiques sont vraies et que dans quelques années nos distributions ne seront plus GNU/Linux mais SystemD/Linux. Néanmoins il est intéressant d'observer qu'après 6 ans d'existence, systemd s'est imposé partout à l'exception de Gentoo (+et Slackware) et ce n'est pas par hasard.

Je ne vais pas énumérer point par point les fonctionnalités de systemd, je vais me contenter d'en présenter deux aspects que je trouve intéressants : création d'un service et d'un containers (nspawn).

Création d'un service

Avez-vous déjà écrit des scripts d'init pour un logiciel sur Linux ? Moi oui. Et entre sysvinit et systemd, c'est le jour et la nuit. Prenons pour exemple Nginx :

C'est quand même beaucoup plus simple avec systemd puisqu'une grosse partie du boulot est faite nativement, par exemple la gestion du pid et des logs. Pour sysvinit par contre c'est au développeur du script de prévoir tous les cas, de coder la vérification du pid, des logs, bref c'est long et pas forcément utile puisque même sur Windows on ne fait plus ça depuis 20 ans.

Création d'un container

Systemd est très lié à Linux et aux cgroups, il est possible d'isoler des processus dans leur propre contexte, de là à créer des containers avec une application ou un système entier il n'y a donc qu'un pas qui a été franchit. Pour l'exemple on va créer un container ubuntu-server-16.04 à partir d'une image cloud (pour nous épargner les étapes debootstrap qui n'ont pas vraiment d'intérêt dans cet article) :

root@localhost:~# wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
root@localhost:~# mkdir /srv/containers/xenial01
root@localhost:~# tar -xf xenial-server-cloudimg-amd64-root.tar.gz -C /srv/containers/xenial01

Note : sur les versions plus récentes de systemd (non disponible sur Debian Jessie), l'utilitaire machinectl permet de télécharger et déployer une image automatiquement. Voir la section Examples de la documentation machinectl.

Puis démarrer un shell dans le container afin de pouvoir créer un mot de passe root :

root@localhost:~# systemd-nspawn -D /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
root@xenial01:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@xenial01:~# exit

Maintenant on peut - si on veut - démarrer complètement le container :

root@localhost:~# systemd-nspawn -bD /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ 
-LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Ubuntu 16.04 LTS!

Ensuite la séquence de démarrage s'affiche et il est possible de se loguer, puis d'arrêter le container avec la commande poweroff :

Ubuntu 16.04 LTS ubuntu console

ubuntu login: root
Password: 
Last login: Mon May 23 09:12:29 UTC 2016 on console
run-parts: /etc/update-motd.d/98-fsck-at-reboot exited with return code 1
root@ubuntu:~# poweroff

Si on ne spécifie aucune option au niveau du réseau, le container utilisera l'interface de l'hôte. Attention donc aux services qui écoutent sur les mêmes ports, typiquement SSH, le mieux est encore d'utiliser une interface réseau virtuelle. Je ne rentre volontairement pas dans les détails afin de ne pas faire un article indigeste, mais il est possible d'aller plus loin notamment au niveau des interfaces réseau (bridge, macvlan, veth), des limitations du système (mémoire, cpus...) ou encore de l'intégration avec SELinux. On peut aussi utiliser debootstrap, dnf ou pacstrap pour créer un container (pas besoin d'une image cloud). Pour cela voir la documentation systemd-nspawn et systemd.resource-control (elles ne sont pas si indigestes que ça).

Systemd-nspawn est une alternative intéressante à LXC permettant de gérer des containers thin (on lance uniquement une application) ou thick (on lance tous les services) sans avoir à installer quoi que ce soit.

BONUS : sous debian, ça ne change rien pour les utilisateurs

Si je peux comprendre que beaucoup de gens n'aiment pas systemd et ne souhaitent pas l'utiliser, en revanche je ne comprends pas pourquoi cette grogne est focalisée chez les utilisateurs de debian au point de créer le fork devuan. Parce que si vous êtes utilisateur de debian, systemd ne change rien pour vous. Tout d'abord le boulot est fait par les mainteneurs des paquets, vous n'avez jamais touché à un système d'init de votre vie, et avec systemd vous n'y toucherez pas non plus. Ensuite, si vous faites un peu de sysadmin, là encore rien ne change pour la majorité des opérations.

Voici pour comparer la manière dont on démarre apache :

root@localhost:~# service apache2 start # avec sysvinit
root@localhost:~# service apache2 start # avec systemd

C'est pareil, parce que debian est une distribution pour fainéants (comme moi) très bien foutue. Même chose pour le réseau, ça se gère toujours dans /etc/network/interfaces rien ne change.

Sous Archlinux par contre tout change par exemple le fichier /etc/rc.conf a disparu au profil de fichiers éclatés pris en charge par systemd. Ce n'est pas méchant mais il a fallu réapprendre certaines choses. Malgré une grogne passagère la chose semble avoir bien été acceptée par les utilisateurs, en tous cas ils ne sont pas partis forker leur distribution.

Conclusion

Au final, après avoir lu tant de troll, tant de FUD sur systemd, je trouve que c'est plutôt bien. C'est simple à utiliser et c'est puissant puisqu'on peut imaginer un jour remplacer LXC et cela ouvre plein de possibilités au niveau des serveurs, par exemple avoir des instances apache et nginx isolées dans les containers thin, ou encore des applications portables à la manière de Snap ou xdg-app. Pour 99% des utilisateurs de Linux la transition est transparente puisque prise en charge en amont par les mainteneurs.

Je prends donc le risque d'invoquer une armée de troll dans les commentaires mais moi j'approuve systemd.

22 commentaires

#1  - Frédéric Bezies a dit :

Une simple remarque. Dans la liste des distributions sans systemd, tu peux rajouter : Funtoo, Void Linux, Slackware, NuTyX et bien entendu, la Devuan.

Répondre
#2  - uTux a dit :

Concernant Slackware, oubli impardonnable de ma part !
Pour les autres, je ne connais pas du tout (excepté Devuan). Ce sont de vraies distributions ?

Répondre
#3  - Frederic Bezies a dit :

Les sites officiels des distributions en question, tu pourras juger sur pièce.

Funtoo => http://www.funtoo.org/Welcome
Void Linux => http://www.voidlinux.eu/
NuTyX (basée sur la LFS) => http://nutyx.org/

Voila ;)

Répondre
#4  - uTux a dit :

Parce que si ce sont encore des dérivés de Debian ou Ubuntu je ne vais pas m'amuser à les citer.

Répondre
#5  - Lib a dit :

Il ne faut pas oublier, dans les distributions sans systemd, Alpine Linux vers laquelle s'est récemment tourné Docker, le pionnier et spécialiste en containers, abandonnant Ubuntu comme distrib officielle.

De plus, comme tu l'as très bien fait remarquer, systemd s'est "imposé", non pas partout, mais dans les distribs les plus populaires et les plus "grand public". Mais, beaucoup en reviennent et sans aller jusqu'au fork, de nombreuses versions alternatives (et non dérivées) de ces grosses distribs qui permettent d'éviter systemd apparaissent ou se désolidarisent de la distribution principale si elles existaient déjà.
Si tu considères qu'on peut parler d'un monde systemd/linux, alors il faut considérer que ces alternatives restent GNU/linux et les voir comme des distributions à part entière. Pour en citer quelques unes : AntiX16 (avec l'appui non négligeable la communauté Mépis), Trios, les alternatives à Arch et en particulier Manjaro-OpenRC.

Ce qui me fait d'ailleurs penser que les articles prônant systemd vantent souvent quelques avantages par rapport à sysvinit mais restent étrangement silencieux sur une comparaison avec des sytèmes d'init non invasifs, modernes et efficaces tels que epoch, runit, openRC, DMD...

Répondre
#6  - uTux a dit :

Oui ce sont les distributions les plus "populaires" qui ont adopté systemd, mais cela représente la majorité. Debian, ubuntu (et donc Mint), redhat (et donc CentOS), Fedora, archlinux, mageia, opensuse.... je crois qu'on a fait le tour, le reste représente un faible pourcentage.

Répondre
#7  - Lib a dit :

Debian et donc Ubuntu qui en est une dérivée, ont adopté systemd mais Mint, basée sur Ubuntu est circonspecte sur l'adoption. D'ailleurs, LMDE (Linux Mint Debian Edition) ne l'a pas adopté et prend le temps de voir. Vu que eudev est parfaitement fonctionnel, que le maintien de ConsoleKit a été repris avec ConsoleKit2 et qu'on arrive à s'absoudre de beaucoup des dépendances dures artificiellement crées à systemd, il y a de fortes chances que LMDE et même Linux Mint basculent dessus à plus ou moins long terme et donc se libèrent de systemd.
Et non, les distributions les plus populaires ne représentent ni la majorité des utilisateurs, ni la majorité des distributions, un simple coup d'oeil à distrowatch permet de s'en rendre compte. Et à mon humble avis, l'hémorragie d'utilisateurs des systemd distribs est loin d'être finie.
Pour d'autres très connues sans systemd, en plus de celles citées plus haut, celles qui me viennent à l'esprit : PClinuxOS, AV Linux, Obarun, Exe Linux, GoboLinux, Puppy, Refracta, Dragora, Vector, Void, Salix, GuixSD, LFS, gNewSense, Crux, Salix, PiSi... Sans compter tous les systèmes embarqués bien sûr.

Répondre
#8  - uTux a dit :

Mint utilisera systemd, ils n'ont pas les moyens de maintenir à eux seuls sysvinit...

Répondre
#9  - Lib a dit :

Ils n'ont pas besoin de le faire, mais ils en trouveront les moyens si nécessaire, ne serait-ce qu'en mutualisant le travail avec les nombreuses distribs et dérivées qui restent sur sysvinit (en particulier devuan) en attendant d'adopter une des alternatives moins polémique, restrictive et problématique que systemd (comme l'une de celles que j'ai cité précédemment).

Je dois rappeler que le bureau qui a fait, en partie, et avec d'autres outils maison, le succès de Mint, c'est Cinnamon. Nombreux sont les utilisateurs qui sont partis vers Cinnamon et Mate au moment du virage à 90 degrés entre gnome 2 et gnome 3 et, avec la tendance du couple systemd-gnome3 de considérer qu'en dehors d'eux rien ne doit exister, il me semble plutôt logique que Mint s'éloigne de celui-ci.

Répondre
#10  - Atrealis a dit :

Perso, tant que je ne peux pas convertir le script de mon serveur minecraft sous systemd à 100%, ce sera non.
Sous systemd, start, stop et restart sont OK, mais je perds backup et update.
Et en plus, status m'affiche le status de screen et non pas celui de mon serveur (screen->java->serveur.jar)

Répondre
#11  - uTux a dit :

Pourquoi Screen ?

Répondre
#12  - Atrealis a dit :

Parce que java ne sait pas s’exécuter en arrière plan. Si on lance le jar en arrière-plan via &, en fermant le terminal, java se ferme aussi. De plus, on ne peux pas contrôler le serveur sans passer par l'injection de commandes via screen (comme save ou quit)
Pour te donner une idée de la chose, voici le script init que j'utilise actuellement: https://www.zerobin.net/?418a3880bee467c7#MIclEGssQArL3E9lpaduSI37QmtTT33arMNQ3fOsTQU=

Répondre
#13  - uTux a dit :

Avec systemd tu n'as pas besoin de screen.
J'ai déjà écrit des services systemd pour des trucs qui se coupent si on ferme le terminal, ça ne pose pas de souci.
A mon avis tu peux t'inspirer des services "nodejs" qui existent, c'est assez similaire.
Par exemple Ghost : https://github.com/TryGhost/Ghost-Config/blob/master/systemd/ghost.service
Par contre pour la partie sauvegarde/restauration, je ne sais pas. Tu pourrais mettre ça dans un script car ça ne me semble pas lié avec l'init.

Répondre
#14  - Atrealis a dit :

ouais mais du coup, sans screen, je pourrais plus le contrôler. Et sans la commande save-all avant de quitter, par exemple, je vais perdre des données (sans compter une possible corruption suivant comment le serveur est fermé).

Répondre
#15  - uTux a dit :

save-all peut être mis dans le ExecStop= je pense.
Après j'ai l'impression que tu es sur un usage bancal, ce n'est pas tout à fait un service.

Répondre
#16  - Paul Gonin a dit :

Je suis d'accord systemd c'est bien !
La gestion des logs avec journalctl est également un plus significatif... pas besoin d'être un gourou sed et awk pour jeter un oeil aux entrées du journal du jour ou depuis une date en particulier.

Je crois aussi qu'en termes de performances, en particulier pour les cas de systèmes soumis à fortes charges

Répondre
#17  - Vincent a dit :

Bon article, merci de m'avoir fait découvrir cette partie de systemd ! Je ne connaissais pas. As-tu eu des retours sur une utilisation en prod ? Où cela reste de l'expérimental ?

Répondre
#18  - uTux a dit :

Systemd-nspawn ? Stable oui, production ready, je ne sais pas.
Je me tâte à migrer mes services dessus afin de pouvoir m'amuser avec.

Répondre
#19  - Vincent a dit :

Oui oui je parle bien de Systemd-nspawn ;)
Ok merci bien, je vais un peu faire mumuse alors !

Répondre
#20  - PCh a dit :

"Parce que si vous êtes utilisateur de debian, systemd ne change rien pour vous."
=> voui, ou presque. En tous cas, pas pour moi: systemd m'a carrément empêché 2 de mes machines de démarrer, le jour où Jessie est passée en stable et que mes upgrades ont eu fini leur travail, et que mes machines ont dû redémarrer (l'une portable avec sa batterie épuisée, l'autre suite à une coupure de courant).
Le remède auquel j'ai eu recours afin d'ôter systemd:
apt install sysvinit-core
Et mes machines démarrent à vitesse V, comme avant!

Répondre
#21  - uTux a dit :

Je dirais que cela fait partie des risques inhérents aux upgrades.
De plus comme tu le souligne il est toujours possible de revenir à sysvinit.

Répondre
#22  - fassil a dit :

'LLo,
Cela va sans doute pouvoir "re-troller" de + belle avec la version 230 à venir pleine de surprises, si j'ai bien tout saisi sur Phoronix, pfuuu..!

Répondre

Écrire un commentaire

Quelle est le troisième caractère du mot wy6vdub ?