[long/résolu] Re: Grosse fatigue

[BERTRAND Joël <joel.bertrand@systella.fr>]

	Ne pouvant obtenir aucune résolution ni de la part de l'équipe de devs
de systemd ni de debian, j'ai pris le taureau par les cornes et j'ai
fait ce que j'aurais dû faire depuis très longtemps. J'ai viré debian
que j'ai remplacé par devuan _sans réinstallation_. Les versions des
paquets sont restées les mêmes, j'ai vérifié. Je me débrouillerai avec
Xilinx dans un second temps.

	La configuration était une debian/testing à jour. Sur cette machine,
remplacer le /etc/apt/sources.list par :

deb http://deb.devuan.org/merged stable main contrib non-free
deb http://deb.devuan.org/merged stable-updates main contrib non-free
deb http://deb.devuan.org/merged stable-security main contrib non-free
deb http://deb.devuan.org/merged testing main contrib non-free
deb http://deb.devuan.org/merged unstable main contrib non-free

	Faire une première passe de téléchargement des fichiers de description
de dépôts :

apt-get update --allow-insecure-repositories

	Installer les clefs :

apt-get install devuan-keyring --allow-unauthenticated

	Mettre à jour les dépôts :

apt-get update

	Installer les premiers paquets :

apt-get upgrade

	On est toujours sous Debian avec systemd. À partir de là, c'est chaud.
On installe eudev et un gestionnaire d'init (finit, rc, sysv, ce que
vous voulez). J'ai installé sysvinit-core parce que finit râle sur une
absence de runlevel due à systemd. Sur le portable de test que j'ai
migré avant ma station de travail, j'ai forcé l'installation de finit en
installant à la main le contenu de data.tar.xz du paquet finit. Ça
fonctionne.

apt-get install eudev
apt-get install sysvinit-core

	On réinstalle ce qui a été cassé au passage :

apt-get -f install

	On redémarre (directement par reboot). Et là, miracle, plus de systemd.
On met le système à jour et on vire les scories :

apt-get dist-upgrade
apt-get purge systemd libnss-systemd
apt-get autoremove --purge
apt-get autoclean

	Et hop...

hilbert:[~] > cat /etc/issue
Devuan GNU/Linux daedalus/ceres \n \l

	Premières constatations :
- la station de travail qui mettait 4 minutes 50 secondes à démarrer
avec systemd (entre le chargement du noyau et l'apparition de wdm) ne
met plus que... 20 secondes ! Entendons-nous bien, plus de 4 minutes
_sans_ timeout parce que le système lançait tout en parallèle et mettait
le réseau par terre. On m'avait vendu systemd comme un truc qui
démarrait beaucoup plus vite. Même si je me contrefiche de cet argument
parce que je ne redémarre pas mes machines tous les jours, c'est assez
symptomatique de la lourdeur du truc ;
- en quasiment huit jours d'utilisation, je n'ai pas réussi avec l'init
SysV à dépasser une charge de 15 côté station (et 8 côté serveur NFS).
Avec systemd et la même utilisation, il n'était pas rare de monter à 60
côté station et plus de 40 côté serveur ! J'ai même chargé la mule en
retirant deux barrettes mémoire. Le poste en question n'a plus que 32 Go
de RAM, ce qui le fait swapper comme un malade :

KiB Mem : 32781360 total,4730928 libr,26204816 util,1845616 tamp/cache
KiB Éch : 10066329+total,70649632 libr,30013660 util.5955912 dispo Mem

Malgré cela, c'est parfaitement stable ;
- je n'observe plus aucun problème bizarre (pour mémoire : des processus
zombies, des shells qui se font la malle en occupant 100% d'un coeur de
CPU, des daemons qui se baugent et qui ne sont pas relancés, X qui part
en vrille et j'en passe).

	La différence entre les deux ? On vire le goulot d'étranglement systemd
(qui doit faire des trucs pas nets vue la différence de charge système)
que l'on remplace par un init classique. Je ne vais pas passer plus de
temps à essayer de comprendre les merdes de systemd, j'ai déjà assez
perdu de temps sur le sujet. J'ai remonté le bug ici (à au moins deux
reprises) et upstream. Ici, ça n'existe pas, systemd est génial;
upstream, le constat est fait mais sans aucune solution.

	Sur le reste parce qu'il y a à dire... J'avais écrit que je ne
répondrai plus, mais devant tant de mauvaise foi...

Pierre-Elliott Bécue a écrit :
> Il y en a qui y arrivent apparemment :
> https://wiki.debian.org/DebianEdu/Documentation/Bullseye/Architecture
1/ Je suis en testing pas en stable. Je sais que testing, c'est testing
et pas stable, mais je n'ai pas le choix en raison d'un soft
propriétaire et de ses prérequis ;

2/ En testing, app-armor met le bordel rien que sur un truc aussi
trivial que la commande man. Ne me dis pas le contraire et ne me dis
surtout pas que cela a été testé, c'est moi qui ait remonté le bug quand
j'en ai eu le temps, c'est-à-dire plusieurs semaines après la
constatation du dysfonctionnement. Je ne sais pas si cela a été corrigé
dans le paquet, j'ai un patch local. Vue la latence entre ma détection
du problème et le bugreport, et vu que j'ai été le premier à le
remonter, il ne doit pas y avoir beaucoup d'utilisateurs diskless (je
parle d'utilisateurs normaux, de ceux qui vont utiliser de temps en
temps man par exemple). Au regard des problèmes de certaines unités
systemd en fonctionnement diskless, je pense qu'effectivement, les
utilisateurs diskless sont très très peu nombreux (et que l'équipe de
dev n'en à rien à faire, ce que je peux comprendre vu le faible nombre
de ces configurations dans la nature). Ou alors, ils ne se font pas
entendre et corrigent les merdes dans leurs coins en en prenant leur
parti (ce que j'ai égoïstement fait jusqu'ici sur la plupart des
problèmes) ;

3/ Une utilisation scolaire n'est pas une utilisation professionnelle
avec des machines qui doivent tourner h24 et 365 jours par an. Le
problème que je soulève se produit tous les deux ou trois jours
en cas d'usage intensif. En aucun cas, ça n'apparaît au bout de quelques
heures, cas d'une utilisation scolaire typique où les postes sont
généralement éteints le soir ou à la fin du cours. Et je râle parce que
ça me fait perdre quelques heures de boulot (ça, je pourrais encore
l'accepter), mais ça interrompt aussi des simulations ngspice qui
tournent plusieurs jours. Ce problème semble apparaître plus souvent sur
des machines chargées, mais les machines qui ont été migrées sous Devuan
ne présentent plus jamais le problème. Peux-tu me rappeler la différence
fondamentale entre Debian et Devuan ?

4/ Les LTPS servers de la zolie image sont sans nul doute des Linux. Ce
n'est _pas_ mon cas et je ne suis pas allé regarder si le serveur nfs
utilisé par Linux est conforme aux specs ou s'il s'agit d'un nfs Canada
Dry qui honore par exemple les CAP_*. Dans mon cas, le serveur est un
NetBSD 9.3 avec une pile de disques internes SAS en raid (matériel)
exportés en NFSv3/TCP et ayant un débit capable de saturer les deux
liens 5Gbps sortants vers le LAN. Et il est conforme puisqu'il parle
déjà sans problème à du FreeBSD, OpenBSD et à un OpenVMS des familles
qui traîne par là. Chaque machine a sa propre racine, accessible sur un
disque dédié et à accès limité à cette machine. Le tftpd est aussi à
accès restreint. Les swaps sont sur d'autres disques agrégés et
entrelacés exportés en iSCSI qui, eux aussi, peuvent mettre le réseau au
taquet. Donc merci de ne pas me demander de changer de serveur NFS, ce
n'est pas le problème. La seule chose sur laquelle on pourrait discuter,
c'est le nombre de threads du serveur NFS, ici 64. L'augmentation du
nombre de threads dégrade les perfs parce que les disques ne suivent
plus. Je préfère qu'un client se tape un "nfs server not responding" que
de mettre le serveur à genou. Et si le problème que j'observe vient de
là, c'est qu'une fois encore, systemd est mal conçu. Pour info, la
racine est montée sur la machine fautive comme suit :

192.168.10.128:/srv/hilbert on / type nfs
(rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=600,retrans=10,sec=sys,local_lock=all,addr=192.168.10.128)

Le fait d'indiquer 'hard' repousse l'apparition du problème. En mettant
soft, c'est la fête du slip. Utiliser udp à la place de tcp dégrade les
perfs globales. L'utilisation des jumbo frames ne change rien.

5/ Le matériel n'est pas comparable. Je ne suis pas sûr que dans une
utilisation scolaire, les machines soient des i9 avec autant de mémoire,
une carte graphique pour faire de la CAO et trois écrans. Je ne suis pas
sûr que les charges des machines et du réseau soient comparables non
plus. Parce que si on rentre dans le détail, la gestion de la mémoire
est aussi folklorique depuis quelque temps même en utilisant
vm.swappiness (ce qui, au passage, charge _aussi_ le réseau. Avec
vm.swappiness=1, je me retrouve avec du swap utilisé alors qu'il reste
plusieurs dizaines de Go de RAM disponibles qui n'ont _jamais_ été
utilisés si j'en crois munin). Ça, je l'admets, ce n'est pas de la
responsabilité de Debian mais du noyau. Mais ça entre aussi en ligne de
compte, cette utilisation du goulot d'étranglement qu'est le réseau peut
créer le problème observé par effet de bord ;

	Mais revenons au problème initial. Il y a un peu plus que quelques
milliers de lignes dans les logs d'auditd. Je ne pense pas t'avoir donné
un accès root à l'une de mes machines en défaut comme je l'ai fait à une
personne de l'équipe de développement de systemd au printemps dernier,
personne qui a passé plusieurs jours à auditer cette machine. Pourquoi
bien plus que plusieurs milliers de lignes ? Parce qu'une fois qu'on a
mis le truc en place, on s'est rendu compte que ça ne donnait
strictement rien sans augmenter sérieusement la verbosité. On a même
audité les transactions NFS côté serveur pour conclure que tout se
passait correctement côté serveur NFS et que le problème provenait des
clients.

	Bref, le problème n'est pas simple contrairement à ce que tu crois,
parce que si c'était simple, il y aurait déjà une solution. Et tu peux
me traiter de tous les noms d'oiseaux, auditd a été mis en place par
quelqu'un qui savait l'utiliser (si tant est que je ne sache pas
l'utiliser).

	Reste sur ton nuage. La question n'est pas de refuser l'évolution, mais
de constater que ce qui fonctionnait raisonnablement et simplement avant
cette "évolution", ne fonctionne plus. La question est aussi de savoir
si un OS auparavant reconnu comme stable n'est pas en train de se
"Windowiser" à grands pas.

	Quant à l'argument d'autorité "nous sommes des adminsys", ça reste un
argument d'autorité. Vous êtes peut-être des adminsys, très bien. Mais
tous les choix qui sont poussés depuis quelques années sont poussés pour
des serveurs ou des machines de bureau dans des configurations standard,
pas pour le reste du monde susceptible d'utiliser Linux en général ou
Debian en particulier. De ce fait, la qualité de l'OS baisse dès qu'on
n'est plus dans ces configurations. Je rajouterais qu'il n'y a pas que
systemd dans le lot. On peut y mettre initramfs, usrmerge et plein
d'autres choses merdico-foireuses qui font qu'on a peur de redémarrer un
système embarqué à distance sans avoir d'une manière ou d'une autre la
main sur une console. J'en suis arrivé à coller des KVM/ip sur des
matériels critiques pour ne pas me déplacer ou envoyer un techos au fin
fond de la pampa en cas de mise à jour obligatoire !

	Réponds ce que tu veux, tu as besoin d'avoir le dernier mot et je te le
laisse. Je ne suis pas tout à fait néophyte. Ça fait 27 ans que
j'administre du Linux (je me suis tapé du VMS et du SunOS avant ça),
j'ai installé ma première Debian il y a 24 ans et j'ai été
particulièrement actif pour un ancien employeur sur le développement des
noyaux sparc32/smp et sparc64/sbus. J'ai un parc de machines (qui est
monté à plusieurs milliers) dans la nature depuis de très longues
années. J'interviens rarement ici parce que j'ai un emploi du temps
chargé et si je mets sur ce point précis les pieds dans le plat, c'est
parce qu'il y a un gros problème que l'équipe de développement n'a pas
traité malgré plusieurs appels (soit ici, soit directement upstream). Je
me contrefiche que tu le prennes mal et je ne crois pas un seul instant,
vu que ce problème s'est produit sur plusieurs installations dans la
même configuration, que je soit le seul impacté.

	Je ne répondrai rien.