Le 10/12/2016 23:27, Jean-Yves LENHOF a écrit :
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
La solution la plus simple est quand même d'utiliser un init qui sait démarrer :-) Une fois que ton desktop démarre plus, t'as plus tellement accès à ce genre de ressources.
- 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
Effectivement, c'est un des bugs rencontré.
- 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
Je t'avoue que j'ai pas tellement envie de lire ça, donc j'ai juste cherché ce que je voulais : systemd-nspawn c'est le trashfix de systemd parce qu'ils ont cassé chroot. J'ai plus les détails de ce qui était
Tu dois parler de ça pour LXC ? https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd
Tiens, oui, y'a aussi. Non, je parle du fait que si tu as dbus dans un conteneur LXC sur un hôte avec systemd, tu peux balancer des commandes à ton PID 1 depuis ton conteneur. J'ai eu plusieurs conteur qui ont éteint électriquement leur hôte parce qu'un shutdown avait été fait dessus :-)
C'est quoi le pb des terminaux virtuels ?
https://bugzilla.redhat.com/show_bug.cgi?id=817186
- 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 ?
Oui, toujours 0. Bon, là j'avoue que j'ai appris plus tard que ça dépend du type de service (mais j'ai pas retrouvé mon lien). En tout cas, sous Debian j'ai eu plusieurs scripts qui cassaient après une utilisation de type "service service reload && faituntruc" parce que le service n'avait pas reload / restart / stop / start.
Exemple : http://serverfault.com/questions/751030/systemd-ignores-return-code-while-st...
- 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ù.
L'avis qu'on a de si oui ou non c'est un comportement intelligent ou pas ne doit pas entrer en ligne de compte. A partir du moment ou des tas de softs reposent dessus, tu peux pas juste changer silencieusement le comportement d'un binaire. C'est quoi déjà un des arguments des pro-systemd ? Ah oui, c'est une API unique pour toutes les distribs.... Mouais.
Surtout que bon, c'est pas comme si systemd trashait pas ses API régulièrement (genre systemd-sysv ou systemd-fstab). D'ailleurs, une unit de type mount c'est pas beaucoup plus chiant à écrire qu'une ligne de fstab, sérieusement ?
Je suis d'avis que l'init devrait être indépendant de l'API pour les couches hautes.
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
Bah "read the sources" dans un script d'init en shell c'est vachement plus simple que dans un ensemble de binaires bloatés que tu peux pas toujours mettre à jour ;-)
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)...
C'est rigolo parce que plus tôt :
- 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 ?
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,
Rien à voir. Entre une upgrade et un changement complet d'un système pour un nouveau qui n'améliore pas l'existant. Aussi, la branche 2.4 a continuée d'être maintenue un bon moment alors que systemd ne maintient que sa master et ne supporte pas les vieux kernels... D'ailleurs, ils vont faire comment RHEL / CentOS alors qu'ils sont sensés supporter leurs distibs pendant 10+ ans ? ( https://access.redhat.com/support/policy/updates/errata/ )
pour autant désormais j'entends plus bcp de personnes critiquer les versions plus récentes.
Normal, on est retourné utiliser des inits capables de faire démarrer nos machines et les éteindre sans bugs ;-)