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-reglages-tmpfs/65979/13
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-starting-service
- 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
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 ;-)
--
Benjamin Boudoir
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
