BERTRAND Joël <joel.bertr...@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