J’ai la joie d’administrer des postes en réseau avec des Fedora (donc systemd) en poste client (j’ai des utilisateurs qui veulent des versions récentes d’un certain nombre de trucs) et des services Unix classiques : NFS, autofs...
Bon, j’ai dû laisser tomber pour la Fedora 17, la version de systemd qui était dessus plantait complètement autofs. Et là, je n’en étais pas à résoudre le problème moi-même comme à l’époque des scripts bash, alors que les développeurs de Fedora eux-mêmes n’ont pas réussi avant la sortie de la 18 (en rétroportant une correction ; mêmes eux n’ont pas les compétences pour le corriger eux-mêmes).
La Fedora 19 marchait correctement au début (peut-être après ajout d’une dépendance sur un des services systemd, mais ça restait raisonnable).
J’ai fait une mise à jour (à la suite de la faille sur OpenSSL) et là, c’est le drame, l’arrêt qui se remet à merder complètement s’il est lancé directement depuis une session utilisateur : blocages de l’ordre du quart d’heure ou plus, dus en particulier aux partages NFS qui sont démontés après l’arrêt du réseau et systemd qui les attend... longtemps.
Alors, j’ai configuré logind pour qu’il tue les processus de l’utilisateur à la fermeture de session (sinon, il traînait des processus qui bloquaient le montage, en particulier un de Gnome et un de... systemd).
J’ai ajouté un pseudo-service intermédiaire démontant (lors de l’arrêt) les partitions NFS et définissant surtout des dépendances avec autofs d’un côté et le réseau de l’autre pour s’assurer de l’ordre.
J’ai aussi ajouté une temporisation de quelques secondes à l’arrêt du service autofs.
Alors, ça marche moyennement (entre 30 s à 1 minute pour l’arrêt, pas mieux que le démarrage), mais ça remerde bien plus si je retire n’importe laquelle de mes modifs.
À voir les traces, systemd essaye de faire un arrêt très rapide... en lançant les arrêts des services dans l’ordre des dépendances, mais pour certains (notamment autofs et les démontages NFS) en parallèle, sans attendre que l’arrêt du service soit fini pour commencer l’arrêt de celui dont il dépend. C’est quand même génial !
Sur un système client typique avec répertoires sur NFS, c’est la catastrophe.
Même Slackware avec son arrêt sauvage type BSD à l’ancienne s’en sortirait mieux.
Pour l’arrêt, il envoie un Ctrl-C aux processus, puis les tue salement après quelques secondes s’ils ne se sont pas terminés, mais avant tout cela... il démonte les partitions NFS !
Le seul argument que j’aie à la décharge de systemd, c’est qu’après avoir configuré une Ubuntu 12.04 de la même manière, je sais qu’Upstart en est à un stade encore pire : il lance autofs avant le réseau, donc même le démarrage rate (l’intérêt d’autofs, c’est d’aller chercher la table de montage sur le serveur avec LDAP ou NIS). Pour que ça marche, il faut rajouter les dépendances soi-même, sauf que c’est moins pratique à configurer qu’avec systemd et mal documenté...
Alors évidemment, systemd, ça marche sur un ordinateur portable, donc autonome. Des systèmes grand public (dans le mauvais sens du terme) comme Ubuntu et Windows aussi.
Et pour démarrer aussi vite que systemd sur un portable, pas besoin de quelque chose d’aussi compliqué. Sur une Arch avant systemd, je lançais dbus et un autre service puis quasiment tous les autres en parallèle sans aucun problème et le démarrage était aussi rapide.
Partant d’un a priori positif sur systemd du point de vue de la conception avant que Fedora ne l’utilise vraiment, mon avis devient de plus en plus négatif (ça se voit au fil des posts).
Mais le temps que je perds dessus se cumule et son fonctionnement ne s’améliore pas réellement (par rapport à la Fedora 17, si, mais la version qui était dessus était bien pire que les précédentes).
En tant qu’administrateur système, Systemd est la plus grosse plaie que j’aie eu récemment.
Et que fait un système avec systemd qui me manquerait sans ? Rien !
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
# Lennux Is Not UniX
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
J’ai la joie d’administrer des postes en réseau avec des Fedora (donc systemd) en poste client (j’ai des utilisateurs qui veulent des versions récentes d’un certain nombre de trucs) et des services Unix classiques : NFS, autofs...
Bon, j’ai dû laisser tomber pour la Fedora 17, la version de systemd qui était dessus plantait complètement autofs. Et là, je n’en étais pas à résoudre le problème moi-même comme à l’époque des scripts bash, alors que les développeurs de Fedora eux-mêmes n’ont pas réussi avant la sortie de la 18 (en rétroportant une correction ; mêmes eux n’ont pas les compétences pour le corriger eux-mêmes).
La Fedora 19 marchait correctement au début (peut-être après ajout d’une dépendance sur un des services systemd, mais ça restait raisonnable).
J’ai fait une mise à jour (à la suite de la faille sur OpenSSL) et là, c’est le drame, l’arrêt qui se remet à merder complètement s’il est lancé directement depuis une session utilisateur : blocages de l’ordre du quart d’heure ou plus, dus en particulier aux partages NFS qui sont démontés après l’arrêt du réseau et systemd qui les attend... longtemps.
Alors, j’ai configuré logind pour qu’il tue les processus de l’utilisateur à la fermeture de session (sinon, il traînait des processus qui bloquaient le montage, en particulier un de Gnome et un de... systemd).
J’ai ajouté un pseudo-service intermédiaire démontant (lors de l’arrêt) les partitions NFS et définissant surtout des dépendances avec autofs d’un côté et le réseau de l’autre pour s’assurer de l’ordre.
J’ai aussi ajouté une temporisation de quelques secondes à l’arrêt du service autofs.
Alors, ça marche moyennement (entre 30 s à 1 minute pour l’arrêt, pas mieux que le démarrage), mais ça remerde bien plus si je retire n’importe laquelle de mes modifs.
À voir les traces, systemd essaye de faire un arrêt très rapide... en lançant les arrêts des services dans l’ordre des dépendances, mais pour certains (notamment autofs et les démontages NFS) en parallèle, sans attendre que l’arrêt du service soit fini pour commencer l’arrêt de celui dont il dépend. C’est quand même génial !
Sur un système client typique avec répertoires sur NFS, c’est la catastrophe.
Même Slackware avec son arrêt sauvage type BSD à l’ancienne s’en sortirait mieux.
Pour l’arrêt, il envoie un Ctrl-C aux processus, puis les tue salement après quelques secondes s’ils ne se sont pas terminés, mais avant tout cela... il démonte les partitions NFS !
Le seul argument que j’aie à la décharge de systemd, c’est qu’après avoir configuré une Ubuntu 12.04 de la même manière, je sais qu’Upstart en est à un stade encore pire : il lance autofs avant le réseau, donc même le démarrage rate (l’intérêt d’autofs, c’est d’aller chercher la table de montage sur le serveur avec LDAP ou NIS). Pour que ça marche, il faut rajouter les dépendances soi-même, sauf que c’est moins pratique à configurer qu’avec systemd et mal documenté...
Alors évidemment, systemd, ça marche sur un ordinateur portable, donc autonome. Des systèmes grand public (dans le mauvais sens du terme) comme Ubuntu et Windows aussi.
Et pour démarrer aussi vite que systemd sur un portable, pas besoin de quelque chose d’aussi compliqué. Sur une Arch avant systemd, je lançais dbus et un autre service puis quasiment tous les autres en parallèle sans aucun problème et le démarrage était aussi rapide.
Partant d’un a priori positif sur systemd du point de vue de la conception avant que Fedora ne l’utilise vraiment, mon avis devient de plus en plus négatif (ça se voit au fil des posts).
Mais le temps que je perds dessus se cumule et son fonctionnement ne s’améliore pas réellement (par rapport à la Fedora 17, si, mais la version qui était dessus était bien pire que les précédentes).
En tant qu’administrateur système, Systemd est la plus grosse plaie que j’aie eu récemment.
Et que fait un système avec systemd qui me manquerait sans ? Rien !
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone