Re: [long/résolu] Re: Grosse fatigue

[Pierre-Elliott Bécue <peb@debian.org>]

BERTRAND Joël <joel.bertrand@systella.fr> wrote on 05/10/2022 at 10:58:12+0200:

> 	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.

Tout ce que cela m'inspire a déjà été évoqué dans mes courriels précédent.

Bon vent !
-- 
PEB