Hello,
Le 09/12/2016 à 10:50, Benjamin Boudoir a écrit :
Le 08/12/2016 19:21, Mrjk a écrit :
Salut,
Loin de moi de vouloir relancer un troll qui devient vieux comme le monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le point de vue de l'admin qui fait de la prod qui m’intéresse (je ne sais pas si tu es dans ce cas).
En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté un grand confort, surtout quand on utilise des outils du type Ansible/Puppet sur différentes plateforme. Une interface pour tous les masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher a systemd.
Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu que systemd améliorait avec cet outil. J'ai un playbook qui réinstalle sysv au lieu de systemd sur toutes les machines que l'on gère.
Les raisons de mon désamour de systemd sont très nombreuses et je vais la résumer en quelques points :
- systemd est incapable de faire démarrer une machine dans toutes les
conditions (notamment l'utilisation de FS en réseau / tmpfs / RO)
https://www.debian-fr.org/t/pb-demarrage-suite-maj-wheezy-jessie-a-cause-reg... pour une solution
- systemd peut avoir des problèmes pour éteindre certaines machines
(je l'ai déjà retrouver à ne pas réussir à démonter des points montés en réseau avec un timeout de... 5 minutes. Par point de montage. 2h de down pour une upgrade de kernel ça fait super mal quand même, ça va que c'était que pour de l'interne)
Semble être ça, non ? Effectivement il semble qu'il y ait un pb, mais il y a des pistes de solution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314
- systemd est peut-être plus modulaire que beaucoup d'anti le disent,
dans les faits il l'est beaucoup moins que Lennart Poettring veut bien le faire croire et beaucoup de distribs se retrouvent presques forcées d'intégrer des extensions à systemd qui sont au mieux inutiles, au pire dangereuses (genre systemd-resolvd)
Est-ce obligatoire ? Des faits, des liens ?
- systemd casse des features du kernel (chroot, LXC, terminaux
virtuels, ...) et ses développeurs refusent de corriger leur code
Je ne sais pas quel problème tu rencontres exactement, mais pour le chroot, tu peux faire des chroot assez facilement avec systemd directement : http://0pointer.de/blog/projects/changing-roots.html
Tu dois parler de ça pour LXC ? https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd
C'est quoi le pb des terminaux virtuels ?
- systemd rend plus complexe l'écriture de scripts (start / stop /
restart / status ne retournent pas d'état, les commandes retournent leur résultats dans un pager par défaut, etc.)
echo $? te donne un return code normalement, non ?
- BEAUCOUP de surprises sur des binaires usuels qui changent de
comportement (genre halt qui n'éteint plus électriquement une machine)... Même si, j'avoue que c'est juste chiant parce que ça casse les habitudes, en vrai une fois que tu le sais ça va vite a prendre en compte. Et faut vérifier tes scripts au cas où.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753830
Je serais moins virtulent avec systemd, si ce n'était qu'un système d'init. Le problème c'est que ses développeurs veulent le faire grossir en fonctionnalités avant même de savoir faire booter un système Linux correctement. C'est fâcheux, vraiment. C'est avant tout une question de confiance dans le produit fini et en l'état, je suis incapable de prédire que ma prod tournera correctement (ni même démarrera) avec systemd. Accessoirement, je préfère les scripts d'init que je peux facilement débugger alors qu'avec systemd si quelque chose ne démarre pas, je peux me brosser pour avoir les détails qui m'intéressent.
Read the sources, Luke ;-) OK elle est facile et c'est clair qu'un script shell c'est plus simple à écrire... mais faire des scripts shells merdiques par rapport à script init de qq lignes, il y a matière à débat
Après, je dis pas que y'a des choses pratiques dans systemd, notamement :
- Les scripts d'init faciles à faire
- L'utilisation de cgroups pour chaque daemon lancé
- La gestion de daemons utilisateurs
Ah quand même un peu d'objectivité ;-)
Cependant, c'est rien qui n'ait pas déjà été fait ailleurs de façon plus propre. Partant de là, j'ai du mal à comprendre que systemd ait été autant poussé en avant alors qu'il casse plus de choses qu'il n'en corrige tout en retirant aux admins la possibilité de contourner les problèmes.
Je me demande si tes pbs ne seraient pas plus du au fait que chez Debian, ils ne sont pas partis tous dans la même direction par rapport à systemd, au contraire de RedHat (après le dev principal de systemd bosse chez RH si j'ai bien suivi)... Si je pousse un peu ton raisonnement tu devrais aussi rester sous un kernel 2.4 parce que le kernel 2.6.9 était bien pourri, pour autant désormais j'entends plus bcp de personnes critiquer les versions plus récentes.
Cdlt,
JYL