Re: [long/résolu] Re: Grosse fatigue
BERTRAND Joël 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
[long/résolu] Re: Grosse fatigue
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 t
