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
[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
Re: Grosse fatigue
BERTRAND Joël wrote on 29/09/2022 at 08:32:47+0200: > Tu veux absolument avoir raison, je te laisse avoir raison. C'est > tellement plus facile que de devoir remettre en cause des choix hasardeux. > > Encore une fois, je ne t'ai pas attendu (d'autant qu'avant d'avoir > posté la première fois ici, il y a quelques mois, j'ai filé le bébé aux > développeurs de systemd, même avec un accès distant sur l'une des > machines en défaut. La réponse fut "on ne sait pas ce qu'il se passe".). > Au passage, avant de monter sur tes grands chevaux et de parler de fud, > relis-moi bien attentivement. Parce que même en filtrant à peu près > intelligemment la sortie d'auditd, c'est inapplicable sur des machines > _diskless_ (je pense que c'est le mot que tu as sauté), sauf à savoir > exactement ce que tu cherches. Mais là encore, tu as parfaitement > raison, tout est théoriquement applicable. J'aimerais bien habiter en > théorie, parce qu'en théorie, tout se passe bien. > > auditd _sature_ le serveur nfs, donc même si tu arrives à obtenir > quelque chose, rien ne te dit que ce que tu auras obtenu sera pertinent > parce que tu n'es plus dans les mêmes conditions de fonctionnement. Le > simple fait d'activer auditd en filtrant intelligemment balance des "nfs > server not responding" sur toutes les machines du réseau ! > > Tiens, sinon, histoire de rigoler et parce qu'on se dit tout, Debian > n'est plus depuis au moins la version 11 avec systemd capable de tourner > en diskless sur un serveur nfs (au moins V3/TCP conforme aux specs). Je > te laisse installer une machine dans ces conditions parce que tu ne me > croiras pas une fois de plus. Il y en a qui y arrivent apparemment : https://wiki.debian.org/DebianEdu/Documentation/Bullseye/Architecture Et j'ai des diskless bookworm au taff, donc bon. On a ptet pas l'air, mais il y a beaucoup de devs Debian qui sont ingé sys et réseaux - moi le premier et ont des besoins type scolaire avec des postes diskless de salle de TP ou autre. Les plâtres, on les essuie aussi, donc on essaie de les limiter. C'est juste qu'on est sans doute moins allergiques au changement. -- PEB signature.asc Description: PGP signature
Re: Grosse fatigue
BERTRAND Joël wrote on 29/09/2022 at 08:32:47+0200: > Tu veux absolument avoir raison, je te laisse avoir raison. C'est > tellement plus facile que de devoir remettre en cause des choix hasardeux. > > Encore une fois, je ne t'ai pas attendu (d'autant qu'avant d'avoir > posté la première fois ici, il y a quelques mois, j'ai filé le bébé aux > développeurs de systemd, même avec un accès distant sur l'une des > machines en défaut. La réponse fut "on ne sait pas ce qu'il se passe".). > Au passage, avant de monter sur tes grands chevaux et de parler de fud, > relis-moi bien attentivement. Parce que même en filtrant à peu près > intelligemment la sortie d'auditd, c'est inapplicable sur des machines > _diskless_ (je pense que c'est le mot que tu as sauté), sauf à savoir > exactement ce que tu cherches. Mais là encore, tu as parfaitement > raison, tout est théoriquement applicable. J'aimerais bien habiter en > théorie, parce qu'en théorie, tout se passe bien. > > auditd _sature_ le serveur nfs, donc même si tu arrives à obtenir > quelque chose, rien ne te dit que ce que tu auras obtenu sera pertinent > parce que tu n'es plus dans les mêmes conditions de fonctionnement. Le > simple fait d'activer auditd en filtrant intelligemment balance des "nfs > server not responding" sur toutes les machines du réseau ! Si un filtrage ne laissant *au pire* que quelques milliers de lignes par jour sature ton NFS, il est sans doute temps d'en changer (j'ose pas En effet, fin de la discussion, tu as décidé de te plaindre et que tu avais tout testé (trop dur d'admettre qu'on peut passer des mois sur un problème sans l'aborder par le bon bout de la lorgnette, alors que ça nous arrive à tous ?), reste-donc dans tes convictions plutôt que d'évoluer. Mais du coup ne te sens pas obligé de venir rant sur les listes à nouveau si c'est pour ignorer les réponses et repartir en monologue. Cordialement, -- PEB signature.asc Description: PGP signature
Re: Grosse fatigue
Tu veux absolument avoir raison, je te laisse avoir raison. C'est tellement plus facile que de devoir remettre en cause des choix hasardeux. Encore une fois, je ne t'ai pas attendu (d'autant qu'avant d'avoir posté la première fois ici, il y a quelques mois, j'ai filé le bébé aux développeurs de systemd, même avec un accès distant sur l'une des machines en défaut. La réponse fut "on ne sait pas ce qu'il se passe".). Au passage, avant de monter sur tes grands chevaux et de parler de fud, relis-moi bien attentivement. Parce que même en filtrant à peu près intelligemment la sortie d'auditd, c'est inapplicable sur des machines _diskless_ (je pense que c'est le mot que tu as sauté), sauf à savoir exactement ce que tu cherches. Mais là encore, tu as parfaitement raison, tout est théoriquement applicable. J'aimerais bien habiter en théorie, parce qu'en théorie, tout se passe bien. auditd _sature_ le serveur nfs, donc même si tu arrives à obtenir quelque chose, rien ne te dit que ce que tu auras obtenu sera pertinent parce que tu n'es plus dans les mêmes conditions de fonctionnement. Le simple fait d'activer auditd en filtrant intelligemment balance des "nfs server not responding" sur toutes les machines du réseau ! Tiens, sinon, histoire de rigoler et parce qu'on se dit tout, Debian n'est plus depuis au moins la version 11 avec systemd capable de tourner en diskless sur un serveur nfs (au moins V3/TCP conforme aux specs). Je te laisse installer une machine dans ces conditions parce que tu ne me croiras pas une fois de plus. Pourquoi ? Parce des attributs spéciaux (CAP_quelque chose) non compatibles nfs sont balancés aux disques (et comme par hasard, l'un des trucs qui gueule est justement systemd, d'où mes gros doutes sur les accès disques de ce truc). C'est bien de réinventer la roue, mais lorsqu'on n'est plus iso-fonctionnel ou que la roue est carrée parce c'est moderne, c'est un peu dommage. Je passe sous silence les autres choix merdiques qui ont été faits par des gens qui ne connaissent strictement rien en dehors de Linux ou qui s'en contrefichent (les algos de chiffrement par exemple, ce qui posé des problèmes aux serveurs de mails durant plus de deux ans (!), les formats des fichiers nis et j'en passe ! Mais il y a aussi l'inénarrable app-armor qui a de gros problèmes avec les configurations diskless.). Le système universel a du plomb dans l'aile parce qu'il n'arrive plus à fonctionner correctement qu'avec lui-même et, encore, seulement dans les configurations courantes ! J'en reste là. Certains membres de la communauté debian sont imbuvables et la conséquence est que le système lui-même part à vau l'eau dès qu'on n'est plus dans une configuration dite standard. C'est exactement comme ça qu'on se retrouve avec systemd et les autres concetés comme wayland et usrmerge. Ça fonctionne dans 99% des cas, il faut juste ne pas se retrouver dans les 1%. Et pour ta gouverne, le système fautif est un système pur debian/testing, réinstallé from scratch, avec un seul logiciel qui n'est pas issu des dépôts debian mais de Xilinx (et qui n'installe rien d'autre qu'un gros binaire dans /opt). D'ailleurs sans ce logiciel, ça merdoie exactement de la même façon. Ça merdoyait _aussi_ sur les autres debianeries diskless de la même façon après le passage de sysV vers systemd (voir l'un de mes premiers posts, raison pour laquelle j'ai réinstallé ces postes sous un autre OS). Ce n'est donc pas lié à une machine mais à la distribution et l'inénarrable systemd d'une manière ou d'une autre. Pas la peine de me répondre, je vais réinstaller cette machine sans systemd, je vais juste perdre deux ou trois jours pour la réinstaller (oui, deux ou trois jours parce c'est _diskless_ et rien que pour les modules du noyau, boost ou texlive, il y en a pour plusieurs _heures_ par paquet sur un serveur connecté au backbone à 2*5 Gbps). J'aurais dû faire ça depuis longtemps. Fin de la discussion.
Re: Grosse fatigue
BERTRAND Joël wrote on 28/09/2022 at 11:25:59+0200: > Thomas Parmelan a écrit : >> Le mardi 27 septembre 2022 à 18:23, d'après >> BERTRAND Joël : >> >> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... >> Question naïve, mais qui me turlupine à vous lire tous les deux : si je comprends bien, la session graphique est lancée sous l'identité de root (ce qui est rarement une idée géniale, mais c'est un autre débat). >>> >>> Absolument pas. La session est ouverte en tant qu'utilisateur standard >>> authentifié par ypbind. >> >> Ah, très bien, alors dans ce cas cette ligne "systemd[1]: Stopping User >> Manager for UID 0..." concerne autre chose, peut-être un "su" dans un >> job cron par exemple. Cela devrait être identifiable en regardant les >> lignes précédant celles-ci dans les logs. >> >> Si la session n'est pas ouverte en UID 0, et que c'est bien systemd qui >> la termine, alors il doit y avoir des choses avec le bon UID dans les >> logs, mais je n'ai rien vu de tel dans les extraits précédemment >> fournis. > > Parce qu'en fait, il n'y a strictement rien d'autre (et en règle > générale, il n'y a aucun su). Pour être exact, la ligne précédente > concerne un cron plusieurs minutes avant (deux ou trois de mémoire). Alors vu le nombre de trucs qui ferment avant que systemd ne valide que la slice de l'user 0 est terminée, et considérant que toutes les lignes de logs sont horodatées à la même heure:min:sec, j'aurais tendance à dire que soit ton cron est louche, soit il y a bien une session interactive qui tourne pour root. > Par ailleurs, wdm et X tournent tous deux avec les droits root. -- PEB
Re: Grosse fatigue
BERTRAND Joël wrote on 27/09/2022 at 10:32:17+0200: > Pierre-Elliott Bécue a écrit : >> Salut, >> >> BERTRAND Joël wrote on 26/09/2022 at >> 09:44:54+0200: >> >>> Pierre-Elliott Bécue a écrit : BERTRAND Joël wrote on 23/09/2022 at 10:31:52+0200: > [snip] Ok, donc systemd ne tue pas X. systemd met un terme à la session de root. La raison est que systemd détermine au moment où il le fait que le dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) a terminé, et par défaut dans ce cas, il clos la session, et termine donc tout programme lancé depuis cette session (logique, ça évite que des trucs traînent ad-vitam comme résidus d'une session interactive). Dans la mesure où tu as a priori une session graphique qui tourne, c'est effectivement surprenant, mais il est possible (vu que tu ne postes que les logs qui t'intéressent, qui ne sont pas forcément les logs pertinents) que ta session utilisateur meure pour une raison ou une autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun programme interactif qui tourne. >>> >>> Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de >>> me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en >>> veille) pour constater une fois de plus que la session avait été tuée et >>> que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans >>> deux jours de logs pour trouver toujours le même message après des >>> lignes tout à fait normales. >>> >>> Au passage, ça m'a fait exactement la même chose sur la machine de ma >>> femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu >>> tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne >>> peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. >> >> Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent >> qui tourne ? As-tu un needrestart d'installé qui redémarrerait des >> services agressivement en cas d'upgrade via un unattended-upgrades like? > > Non et non. J'ai déjà indiqué ça plus haut. Ce genre de chose merdoie > allègrement en nfs root (il faut plusieurs heures pour un paquet comme > TeXlive et ça engorge le réseau et le serveur nfs, c'est donc désactivé > par défaut). > > > >>> Il n'y a pas de cron foireux, j'ai naturellement vérifié. ypbind tourne >>> directement rattaché à init, donc ici à systemd et s'il y a un truc qui >>> est stable, c'est bien ypbind. Quand je le lance dans une console, il >>> récupère un signal 15 du père (ici systemd) >> >> Sauf si tu fais des trucs spécifique, en lançant ypbind dans une >> console, c'est elle qui est parent de ypbind. À moins que ypbind se >> détache mais dans ce cas tu ne devrais plus avoir de stdout/stderr. > > Je ne fais rien de spécifique (ypbind -dn). > >>> et c'est pour cela qu'il s'arrête. Ça peut mettre deux ou trois jours, >>> plus encore, mais ce signal 15 du père finit TOUJOURS par >>> arriver. Quand il est lancé en daemon, il n'y a strictement rien comme >>> information pertinente dans les logs. Mais vu qu'il s'arrête en >>> interactif sur un signal 15, je te file mon billet que c'est >>> exactement la même chose lorsqu'il est en tâche de fond. La question >>> est de savoir pourquoi systemd envoie un signal au processus en >>> question. Dernière chose, j'ai installé Devuan avec le même ypbind sur >>> un vieux portable dans la même configuration nis (mais avec un init >>> SysV qui fonctionne et qui fait juste ce qu'on lui demande). Aucun >>> problème. Ce n'est donc pas ypserv qui est en faute mais le père de >>> ypbind (sinon, ypbind se baugerait aussi sur le portable en >>> question). Je te l'accorde, c'est peut-être une interaction de systemd >>> avec tout autre chose qui fait que la conséquence est un arrêt de >>> ypbind. Mais ce quelque chose ne laisse dans ce cas aucune trace dans >>> les logs. >> >> Et systemd est plutôt verbeux, donc c'est peu probable que ça soit lui >> tout seul. >> >>> On est bien d'accord que ypbind n'a aucune raison de se prendre un >>> signal 15 si X se bauge lui-même vu que ypbind n'est pas lancé dans la >>> session X. On est bien d'accord que ce n'est pas ypbind qui s'envoie à >>> lui-même un signal 15. >>> >>> Reste le problème des shells tournant dans des xterm. La session X est >>> tuée, certes, mais tous les shells entrent dans un état bizarre >>> lorsqu'ils sont rattachés à... systemd (parce que, là encore, j'ai >>> vérifié les PPID). Et, naturellement, ce n'est pas un bug non plus. >>> C'est juste un comportement non maîtrisé. Chose surprenante, le fait que >>> les xterms soient tués par la fin de la session X ne tue pas les shells >>> dépendants (?!). >> >> Bon, déjà tu as totalement mis de côté ma solution à base >> d'enable-linger pour creuser. >> >> Ensuite, tu peux aussi installer auditd, et tracker tous les syscalls >> dont les signaux envoyés. Ça te
Re: Grosse fatigue
Thomas Parmelan a écrit : > Le mardi 27 septembre 2022 à 18:23, d'après > BERTRAND Joël : > > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... > >>> Question naïve, mais qui me turlupine à vous lire tous les deux : si je >>> comprends bien, la session graphique est lancée sous l'identité de root >>> (ce qui est rarement une idée géniale, mais c'est un autre débat). >> >> Absolument pas. La session est ouverte en tant qu'utilisateur standard >> authentifié par ypbind. > > Ah, très bien, alors dans ce cas cette ligne "systemd[1]: Stopping User > Manager for UID 0..." concerne autre chose, peut-être un "su" dans un > job cron par exemple. Cela devrait être identifiable en regardant les > lignes précédant celles-ci dans les logs. > > Si la session n'est pas ouverte en UID 0, et que c'est bien systemd qui > la termine, alors il doit y avoir des choses avec le bon UID dans les > logs, mais je n'ai rien vu de tel dans les extraits précédemment > fournis. Parce qu'en fait, il n'y a strictement rien d'autre (et en règle générale, il n'y a aucun su). Pour être exact, la ligne précédente concerne un cron plusieurs minutes avant (deux ou trois de mémoire). Par ailleurs, wdm et X tournent tous deux avec les droits root. > PS étant abonné à la liste, il est inutile de me mettre en copie ;) Au temps pour moi, mauvaise manipulation.
Re: Grosse fatigue
Le mardi 27 septembre 2022 à 18:23, d'après BERTRAND Joël : > >>> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... > > Question naïve, mais qui me turlupine à vous lire tous les deux : si je > > comprends bien, la session graphique est lancée sous l'identité de root > > (ce qui est rarement une idée géniale, mais c'est un autre débat). > > Absolument pas. La session est ouverte en tant qu'utilisateur standard > authentifié par ypbind. Ah, très bien, alors dans ce cas cette ligne "systemd[1]: Stopping User Manager for UID 0..." concerne autre chose, peut-être un "su" dans un job cron par exemple. Cela devrait être identifiable en regardant les lignes précédant celles-ci dans les logs. Si la session n'est pas ouverte en UID 0, et que c'est bien systemd qui la termine, alors il doit y avoir des choses avec le bon UID dans les logs, mais je n'ai rien vu de tel dans les extraits précédemment fournis. PS étant abonné à la liste, il est inutile de me mettre en copie ;) -- Thomas Parmelan
Re: Grosse fatigue
Thomas Parmelan a écrit : > Le samedi 24 septembre 2022 à 22:35, d'après > Pierre-Elliott Bécue : > >> BERTRAND Joël wrote on 23/09/2022 at >> 10:31:52+0200: >> >>> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... > [...] >> Il y a une façon d'éviter que systemd ferme une session en cas de fin de >> tous les programmes interactifs d'un utilisateur, via "loginctl >> enable-linger $username". > > Question naïve, mais qui me turlupine à vous lire tous les deux : si je > comprends bien, la session graphique est lancée sous l'identité de root > (ce qui est rarement une idée géniale, mais c'est un autre débat). Absolument pas. La session est ouverte en tant qu'utilisateur standard authentifié par ypbind. J'interdis par configuration le login root en graphique. Il n'y a pas d'utilisateur "non système" dans les /etc/passwd des postes de travail. Ça permet à un utilisateur d'ouvrir n'importe quelle poste de travail (et ces postes de travail sont interchangeables. En cas de panne, on échange une machine, ce qui permet à l'utilisateur de continuer à travailler comme avant). > Par > défaut l'utilisateur root est exclu du système de "lingering", mais cela > vaudrait peut-être le coup de vérifier de ce côté : > > - dans /etc/systemd/logind.conf, est-ce que KillExcludeUsers est > positionné explicitement (et dans ce cas il faut s'assurer que > "root" est bien listé dedans) ? > > - le problème est-il reproductible par un autre utilisateur ? Tous les utilisateurs normaux des machines diskless sur le réseau en question ont les mêmes problèmes. En revanche, j'ai l'impression qu'un poste bien particulier ne pose pas de souci particulier. À la différence des autres, ce poste n'est utilisé que pour des appels vidéo et n'a pas de swap configuré (donc, a priori, une charge réseau plus faible, le swap étant en iSCSI sur les autres machines).
Re: Grosse fatigue
Le samedi 24 septembre 2022 à 22:35, d'après Pierre-Elliott Bécue : > BERTRAND Joël wrote on 23/09/2022 at > 10:31:52+0200: > > > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... [...] > Il y a une façon d'éviter que systemd ferme une session en cas de fin de > tous les programmes interactifs d'un utilisateur, via "loginctl > enable-linger $username". Question naïve, mais qui me turlupine à vous lire tous les deux : si je comprends bien, la session graphique est lancée sous l'identité de root (ce qui est rarement une idée géniale, mais c'est un autre débat). Par défaut l'utilisateur root est exclu du système de "lingering", mais cela vaudrait peut-être le coup de vérifier de ce côté : - dans /etc/systemd/logind.conf, est-ce que KillExcludeUsers est positionné explicitement (et dans ce cas il faut s'assurer que "root" est bien listé dedans) ? - le problème est-il reproductible par un autre utilisateur ? -- Thomas Parmelan
Re: Grosse fatigue
Pierre-Elliott Bécue a écrit : > Salut, > > BERTRAND Joël wrote on 26/09/2022 at > 09:44:54+0200: > >> Pierre-Elliott Bécue a écrit : >>> >>> BERTRAND Joël wrote on 23/09/2022 at >>> 10:31:52+0200: [snip] >>> >>> Ok, donc systemd ne tue pas X. systemd met un terme à la session de >>> root. La raison est que systemd détermine au moment où il le fait que le >>> dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) >>> a terminé, et par défaut dans ce cas, il clos la session, et termine >>> donc tout programme lancé depuis cette session (logique, ça évite que >>> des trucs traînent ad-vitam comme résidus d'une session interactive). >>> >>> Dans la mesure où tu as a priori une session graphique qui tourne, c'est >>> effectivement surprenant, mais il est possible (vu que tu ne postes que >>> les logs qui t'intéressent, qui ne sont pas forcément les logs >>> pertinents) que ta session utilisateur meure pour une raison ou une >>> autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun >>> programme interactif qui tourne. >> >> Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de >> me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en >> veille) pour constater une fois de plus que la session avait été tuée et >> que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans >> deux jours de logs pour trouver toujours le même message après des >> lignes tout à fait normales. >> >> Au passage, ça m'a fait exactement la même chose sur la machine de ma >> femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu >> tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne >> peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. > > Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent > qui tourne ? As-tu un needrestart d'installé qui redémarrerait des > services agressivement en cas d'upgrade via un unattended-upgrades like? Non et non. J'ai déjà indiqué ça plus haut. Ce genre de chose merdoie allègrement en nfs root (il faut plusieurs heures pour un paquet comme TeXlive et ça engorge le réseau et le serveur nfs, c'est donc désactivé par défaut). >> Il n'y a pas de cron foireux, j'ai naturellement vérifié. ypbind tourne >> directement rattaché à init, donc ici à systemd et s'il y a un truc qui >> est stable, c'est bien ypbind. Quand je le lance dans une console, il >> récupère un signal 15 du père (ici systemd) > > Sauf si tu fais des trucs spécifique, en lançant ypbind dans une > console, c'est elle qui est parent de ypbind. À moins que ypbind se > détache mais dans ce cas tu ne devrais plus avoir de stdout/stderr. Je ne fais rien de spécifique (ypbind -dn). >> et c'est pour cela qu'il s'arrête. Ça peut mettre deux ou trois jours, >> plus encore, mais ce signal 15 du père finit TOUJOURS par >> arriver. Quand il est lancé en daemon, il n'y a strictement rien comme >> information pertinente dans les logs. Mais vu qu'il s'arrête en >> interactif sur un signal 15, je te file mon billet que c'est >> exactement la même chose lorsqu'il est en tâche de fond. La question >> est de savoir pourquoi systemd envoie un signal au processus en >> question. Dernière chose, j'ai installé Devuan avec le même ypbind sur >> un vieux portable dans la même configuration nis (mais avec un init >> SysV qui fonctionne et qui fait juste ce qu'on lui demande). Aucun >> problème. Ce n'est donc pas ypserv qui est en faute mais le père de >> ypbind (sinon, ypbind se baugerait aussi sur le portable en >> question). Je te l'accorde, c'est peut-être une interaction de systemd >> avec tout autre chose qui fait que la conséquence est un arrêt de >> ypbind. Mais ce quelque chose ne laisse dans ce cas aucune trace dans >> les logs. > > Et systemd est plutôt verbeux, donc c'est peu probable que ça soit lui > tout seul. > >> On est bien d'accord que ypbind n'a aucune raison de se prendre un >> signal 15 si X se bauge lui-même vu que ypbind n'est pas lancé dans la >> session X. On est bien d'accord que ce n'est pas ypbind qui s'envoie à >> lui-même un signal 15. >> >> Reste le problème des shells tournant dans des xterm. La session X est >> tuée, certes, mais tous les shells entrent dans un état bizarre >> lorsqu'ils sont rattachés à... systemd (parce que, là encore, j'ai >> vérifié les PPID). Et, naturellement, ce n'est pas un bug non plus. >> C'est juste un comportement non maîtrisé. Chose surprenante, le fait que >> les xterms soient tués par la fin de la session X ne tue pas les shells >> dépendants (?!). > > Bon, déjà tu as totalement mis de côté ma solution à base > d'enable-linger pour creuser. > > Ensuite, tu peux aussi installer auditd, et tracker tous les syscalls > dont les signaux envoyés. Ça te permettrait de savoir qui envoie de > SIGTERM. Voir plus loin pourquoi c'est inapplicable (encore une fois, je ne t'ai pas attendu, ça fait de
Re: Grosse fatigue
Salut, BERTRAND Joël wrote on 26/09/2022 at 09:44:54+0200: > Pierre-Elliott Bécue a écrit : >> >> BERTRAND Joël wrote on 23/09/2022 at >> 10:31:52+0200: >>> [snip] >> >> Ok, donc systemd ne tue pas X. systemd met un terme à la session de >> root. La raison est que systemd détermine au moment où il le fait que le >> dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) >> a terminé, et par défaut dans ce cas, il clos la session, et termine >> donc tout programme lancé depuis cette session (logique, ça évite que >> des trucs traînent ad-vitam comme résidus d'une session interactive). >> >> Dans la mesure où tu as a priori une session graphique qui tourne, c'est >> effectivement surprenant, mais il est possible (vu que tu ne postes que >> les logs qui t'intéressent, qui ne sont pas forcément les logs >> pertinents) que ta session utilisateur meure pour une raison ou une >> autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun >> programme interactif qui tourne. > > Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de > me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en > veille) pour constater une fois de plus que la session avait été tuée et > que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans > deux jours de logs pour trouver toujours le même message après des > lignes tout à fait normales. > > Au passage, ça m'a fait exactement la même chose sur la machine de ma > femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu > tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne > peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent qui tourne ? As-tu un needrestart d'installé qui redémarrerait des services agressivement en cas d'upgrade via un unattended-upgrades like? >> Il y a une façon d'éviter que systemd ferme une session en cas de fin de >> tous les programmes interactifs d'un utilisateur, via "loginctl >> enable-linger $username". Ici ça ressemble à du scotch sur une jambe de >> bois car cela ne t'aidera pas à comprendre ce qu'il se passe >> derrière. >> >> Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait >> sans doute plus pertinent, voire activer certains debugs sur certains >> progs. Après l'enable-linger peut aider à voir ce qu'il se passe et >> trouver le nœud du problème si c'est effectivement un programme qui >> meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas >> buté). > > Figure-toi qu'avant de poster ici, j'ai un peu creusé, parce que ça > fait plusieurs mois que le problème dure. J'utilise Debian depuis Potato > et, avant, j'utilisais RedHat. Je sais où chercher et où creuser. > > J'ai tout d'abord cru que c'était wdm le fautif, mais avec xdm ou gdm, > le résultat est strictement identique. J'ai mis la chose sur le dos de > wmaker, j'ai essayé xfce. Idem. KDE, itou. Gnome, je ne peux pas, je > suis allergique. Quand je dis que le résultat est identique, c'est une > fermeture de la session comme si j'avais normalement quitté la session > (jamais de crash violent), mais avec les shells restant actifs, > rattachés à systemd et qui passent dans un état bizarre (utilisation CPU > maximale). J'ai mis ça sur le dos de la carte graphique. J'ai changé la > carte AMD par une NVidia avec le même résultat. > > J'ai même réinstallé le système en totalité (sans soft proprétaire, que > du Debian pour commencer) parce que mon installation datait un petit > peu. Même résultat. Et ce ne sont pas des programmes aléatoires qui sont > arrêtés, mais la session X ou ypbind (jamais autre chose, lorsque > d'autres daemons sont arrêtés, c'est parce que ypbind est stoppé au > préalable, n'est pas redémarré par systemd et que le daemon en question > crashe parce qu'il n'a plus accès aux tables NIS). Tu vois, j'ai un peu > creusé le sujet. > > Il n'y a pas de cron foireux, j'ai naturellement vérifié. ypbind tourne > directement rattaché à init, donc ici à systemd et s'il y a un truc qui > est stable, c'est bien ypbind. Quand je le lance dans une console, il > récupère un signal 15 du père (ici systemd) Sauf si tu fais des trucs spécifique, en lançant ypbind dans une console, c'est elle qui est parent de ypbind. À moins que ypbind se détache mais dans ce cas tu ne devrais plus avoir de stdout/stderr. > et c'est pour cela qu'il s'arrête. Ça peut mettre deux ou trois jours, > plus encore, mais ce signal 15 du père finit TOUJOURS par > arriver. Quand il est lancé en daemon, il n'y a strictement rien comme > information pertinente dans les logs. Mais vu qu'il s'arrête en > interactif sur un signal 15, je te file mon billet que c'est > exactement la même chose lorsqu'il est en tâche de fond. La question > est de savoir pourquoi systemd envoie un signal au processus en > question. Dernière chose, j'ai installé Devuan avec
Re: Grosse fatigue
raphael.rign...@gmail.com a écrit :
> Basile Starynkevitch a écrit :
>>
>> On 23/09/2022 09:41, BERTRAND Joël wrote:
>>> Bonjour à tous,
> Bonjour
>>>
>>> Ce matin, une fois de plus, systemd a cru bon tuer X et,
>>> incidemment, toutes les applications en cours (me contraignant à
>>> repartir de la sauvegarde de la nuit, je n'ai heureusement perdu
>>> qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne
>>> s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les
>>> terminaux de contrôles dépendants de X :
>>
>>
>> Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon
>> https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.
>> c
>
> Merci, j'ai déjà ce qu'il faut, donc au pire, je perds quelques heures
> de boulot. Ce qui m'énerve surtout, c'est que durant 25 ans, je considérais
> Linux en général et Debian en particulier comme un OS stable, robuste et
> qu'on pouvait utiliser dans des configurations spéciales. Ce n'est plus le
> cas aujourd'hui et c'est bien dommage.
> ---
> Je suis d'accord, les évolutions mettent nos vieux neurones à rude épreuve.
> Je me suis moi-même cassé les dents sur une Ubuntu 22.04 en desktop pour des
> étudiants qui font un peu de dev python avec Spyder et de la bdd Mysql
> workbench. Le premier ne fonctionne même pas car le python système 3.10 est
> en avance sur le package de spyder compatible avec 3.9, et pour le deuxième,
> le paquet issu du site officiel d'Oracle plante avec wayland. Même Firefox en
> version snap n'est pas compatible avec des home directory en NFS en dehors du
> /home. J'ai donc viré snap et wayland et d'autres bidouilles pour contourner
> les problèmes sans être certain d'une bonne stabilité. Pour du LTS je
> m'attendait à mieux, c'est usant...
>
> Pour en revenir à Debian et tes problèmes avec systemd, soit continuer à
> lutter soit passer sur devuan.org. Ce fork n'a pas été créé sans raison, tu
> n'es donc pas seul dans cette galère.
Je sais bien. Toutes mes nouvelles installations sont faites sur Devuan
(quand il faut du Linux) ou carrément sur des NetBSD (serveurs) ou
FreeBSD (postes de travail), mais je gère aussi un historique existant
et des prérequis. Si j'ai encore ma machine de dev sous Debian, c'est
parce que j'utilise un soft propriétaire à peu près supporté sous
Debian. J'appelle (trop) régulièrement le support, si je leur dis
d'emblée que j'utilise autre chose que Debian ou RedHat, je connais déjà
leur réponse ("démerdez-vous !"). On peut le déplorer, mais c'est comme
ça, malheureusement.
Sinon, on ne va pas parler de Wayland tellement il y aurait de choses à
dire... On se demande si ce truc a été sérieusement testé, mais là n'est
pas le sujet du fil.
En fait, je ne suis pas contre les évolutions, mais les évolutions pour
les évolutions, surtout quand elles sont forcées et qu'elles apportent
leur lot de régressions dont un paquet est parfaitement connu,
m'énervent au plus haut point. C'est le cas de systemd, mais c'est aussi
le cas d'usrmerge et de wayland qui sont des bouts de code conçus et
poussés par des gens certainement très compétents dans leurs domaines
respectifs, mais qui n'ont jamais été confrontés à certains problèmes
que l'on vit tous les jours dans l'embarqué. Ou qui pour des raisons
politiques, ne veulent surtout pas les voir. Aujourd'hui, il y a 1710
"issues" ouvertes sur systemd dont certaines particulièrement cocasses !
Ça fait beaucoup pour un système d'init imposé.
RE: Grosse fatigue
Basile Starynkevitch a écrit : > > On 23/09/2022 09:41, BERTRAND Joël wrote: >> Bonjour à tous, Bonjour >> >> Ce matin, une fois de plus, systemd a cru bon tuer X et, >> incidemment, toutes les applications en cours (me contraignant à >> repartir de la sauvegarde de la nuit, je n'ai heureusement perdu >> qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne >> s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les >> terminaux de contrôles dépendants de X : > > > Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon > https://github.com/bstarynk/misc-basile/blob/master/sync-periodically. > c Merci, j'ai déjà ce qu'il faut, donc au pire, je perds quelques heures de boulot. Ce qui m'énerve surtout, c'est que durant 25 ans, je considérais Linux en général et Debian en particulier comme un OS stable, robuste et qu'on pouvait utiliser dans des configurations spéciales. Ce n'est plus le cas aujourd'hui et c'est bien dommage. --- Je suis d'accord, les évolutions mettent nos vieux neurones à rude épreuve. Je me suis moi-même cassé les dents sur une Ubuntu 22.04 en desktop pour des étudiants qui font un peu de dev python avec Spyder et de la bdd Mysql workbench. Le premier ne fonctionne même pas car le python système 3.10 est en avance sur le package de spyder compatible avec 3.9, et pour le deuxième, le paquet issu du site officiel d'Oracle plante avec wayland. Même Firefox en version snap n'est pas compatible avec des home directory en NFS en dehors du /home. J'ai donc viré snap et wayland et d'autres bidouilles pour contourner les problèmes sans être certain d'une bonne stabilité. Pour du LTS je m'attendait à mieux, c'est usant... Pour en revenir à Debian et tes problèmes avec systemd, soit continuer à lutter soit passer sur devuan.org. Ce fork n'a pas été créé sans raison, tu n'es donc pas seul dans cette galère. Bon courage. RaphR
Re: Grosse fatigue
Pierre-Elliott Bécue a écrit : > > BERTRAND Joël wrote on 23/09/2022 at > 10:31:52+0200: > >> Pierre-Elliott Bécue a écrit : >>> Une ligne de log, quelque chose qui montre que systemd a bien tué X >>> et éventuellement pourquoi, ou bien on est juste sur yet another >>> mail de baseless FUD? >> >> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... >> Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit >> the Session... >> Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core >> Session Slice. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets. >> Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus >> Socket. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network >> certificate management daemon. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch >> DrKonqi for a systemd-coredump crash. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper. >> Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon. >> ... >> Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown. >> Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session. >> Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session. >> Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated >> successfully. >> Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0. >> Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory >> /run/user/0... >> Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated >> successfully. >> Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service: >> Deactivated successfully. >> Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory >> /run/user/0. >> Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0. >> ... > > Ok, donc systemd ne tue pas X. systemd met un terme à la session de > root. La raison est que systemd détermine au moment où il le fait que le > dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) > a terminé, et par défaut dans ce cas, il clos la session, et termine > donc tout programme lancé depuis cette session (logique, ça évite que > des trucs traînent ad-vitam comme résidus d'une session interactive). > > Dans la mesure où tu as a priori une session graphique qui tourne, c'est > effectivement surprenant, mais il est possible (vu que tu ne postes que > les logs qui t'intéressent, qui ne sont pas forcément les logs > pertinents) que ta session utilisateur meure pour une raison ou une > autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun > programme interactif qui tourne. Il n'y a rien d'autre anormal avant cela, mais tu n'es pas contraint de me croire. Ce matin, d'ailleurs, je réveille ma machine (écrans en veille) pour constater une fois de plus que la session avait été tuée et que wdm n'était même plus actif. J'ai la flemme d'aller rechercher dans deux jours de logs pour trouver toujours le même message après des lignes tout à fait normales. Au passage, ça m'a fait exactement la même chose sur la machine de ma femme (dans la même configuration diskless) jusqu'au jour où j'en ai eu tellement marre que je lui ai installé un FreeBSD. Sauf que moi, je ne peux pas, j'ai un bout de soft propriétaire qui ne tourne que sous Linux. > Il y a une façon d'éviter que systemd ferme une session en cas de fin de > tous les programmes interactifs d'un utilisateur, via "loginctl > enable-linger $username". Ici ça ressemble à du scotch sur une jambe de > bois car cela ne t'aidera pas à comprendre ce qu'il se passe > derrière. > > Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait > sans doute plus pertinent, voire activer certains debugs sur certains > progs. Après l'enable-linger peut aider à voir ce qu'il se passe et > trouver le nœud du problème si c'est effectivement un programme qui > meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas > buté). Figure-toi qu'avant de poster ici, j'ai un peu creusé, parce que ça fait plusieurs mois que le problème dure. J'utilise Debian depuis Potato et, avant, j'utilisais RedHat. Je sais où chercher et où creuser. J'ai tout d'abord cru que c'était wdm le fautif, mais avec xdm ou gdm, le résultat est strictement identique. J'ai mis la chose sur le dos de wmaker, j'ai essayé xfce. Idem. KDE, itou. Gnome, je ne peux pas, je suis allergique. Quand je dis que le résultat est identique, c'est une fermeture de la session comme si j'avais normalement quitté la session (jamais de crash violent), mais avec les shells restant actifs, rattachés à systemd
Re: Grosse fatigue
Basile Starynkevitch a écrit : > > On 23/09/2022 09:41, BERTRAND Joël wrote: >> Bonjour à tous, >> >> Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, >> toutes les applications en cours (me contraignant à repartir de la >> sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de >> travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au >> milieu du chemin, tuant X mais surtout pas les terminaux de contrôles >> dépendants de X : > > > Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon > https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c Merci, j'ai déjà ce qu'il faut, donc au pire, je perds quelques heures de boulot. Ce qui m'énerve surtout, c'est que durant 25 ans, je considérais Linux en général et Debian en particulier comme un OS stable, robuste et qu'on pouvait utiliser dans des configurations spéciales. Ce n'est plus le cas aujourd'hui et c'est bien dommage.
Re: Grosse fatigue
BERTRAND Joël wrote on 23/09/2022 at 10:31:52+0200: > Pierre-Elliott Bécue a écrit : >> Une ligne de log, quelque chose qui montre que systemd a bien tué X >> et éventuellement pourquoi, ou bien on est juste sur yet another >> mail de baseless FUD? > > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... > Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit > the Session... > Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core > Session Slice. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets. > Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers. > Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus > Socket. > Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network > certificate management daemon. > Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch > DrKonqi for a systemd-coredump crash. > Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper. > Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon. > ... > Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown. > Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session. > Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session. > Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated > successfully. > Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0. > Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory > /run/user/0... > Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated > successfully. > Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service: > Deactivated successfully. > Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory > /run/user/0. > Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0. > ... Ok, donc systemd ne tue pas X. systemd met un terme à la session de root. La raison est que systemd détermine au moment où il le fait que le dernier processus interactif (c'est-à-dire contrôlé par un utilisateur) a terminé, et par défaut dans ce cas, il clos la session, et termine donc tout programme lancé depuis cette session (logique, ça évite que des trucs traînent ad-vitam comme résidus d'une session interactive). Dans la mesure où tu as a priori une session graphique qui tourne, c'est effectivement surprenant, mais il est possible (vu que tu ne postes que les logs qui t'intéressent, qui ne sont pas forcément les logs pertinents) que ta session utilisateur meure pour une raison ou une autre et qu'en conséquence, systemd considère qu'il n'y a plus aucun programme interactif qui tourne. Il y a une façon d'éviter que systemd ferme une session en cas de fin de tous les programmes interactifs d'un utilisateur, via "loginctl enable-linger $username". Ici ça ressemble à du scotch sur une jambe de bois car cela ne t'aidera pas à comprendre ce qu'il se passe derrière. Creuser les logs (un cron qui se lance? ton wm qui meurt/crashe?) serait sans doute plus pertinent, voire activer certains debugs sur certains progs. Après l'enable-linger peut aider à voir ce qu'il se passe et trouver le nœud du problème si c'est effectivement un programme qui meurt (puisque dans ce cas il mourra toujours mais le reste ne sera pas buté). > Au passage, systemd va jusqu'à tuer ypbind : > > Sep 23 08:49:46 hilbert systemd[1]: ypbind.service: Main process > exited Non, systemd constate juste que ypbind a terminé, il ne le tue pas, et n'a rien à voir avec son arrêt. C'est bien de critiquer, c'est mieux de lire les lignes de logs que tu colles. > On se demande bien pourquoi. > > Et il relance le tout comme si rien ne s'était passé (enfin, là, > parce que par moment il tue ypbind sans le redémarrer, ce qui pose des > problèmes amusants sur une machine diskless en NIS/NFS). Il le relance parce qu'en cas d'arrêt inopiné, c'est ce que le service est supposé faire. > De toute façon, la question n'est pas là. systemd décide pour une > raison inconnue de clôturer la session. Naturellement, il n'y a AUCUNE > erreur avant la première ligne de log. Je veux donc me séparer à la > fois de cette saleté qui est une brique pour essuyer les plâtres et > d'usrmerge. Feel free to go elsewhere, mais ici le souci c'est avant tout que tu as décidé que c'était un bug ou un comportement inexplicable plutôt que d'essayer de comprendre ce qu'il se passe. Tu auras donc d'autres problèmes sur d'autres systèmes, et tu trouveras un autre outil à blâmer. > Je précise que ce genre de chose arrive tous les deux ou trois jours > et que c'est gavant. C'est sûr que ça doit l'être, mais c'est pas pour autant qu'il faut devenir fainéant et juste rentrer dans le FUD. :) -- PEB signature.asc
Re: Grosse fatigue
On 23/09/2022 09:41, BERTRAND Joël wrote: Bonjour à tous, Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, toutes les applications en cours (me contraignant à repartir de la sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au milieu du chemin, tuant X mais surtout pas les terminaux de contrôles dépendants de X : Une suggestion en rapport est peut-être d'utiliser et d'améliorer mon https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c Par ailleurs, je cherche des partenaires intéressés par http://refpersys.org/ - contactez moi alors aussi sur mon mél professionnel (au CEA, LIST): basile.starynkevi...@cea.fr -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Grosse fatigue
Bonjour, Le 23/09/2022 à 14:24, Haricophile a écrit : Le Fri, 23 Sep 2022 12:42:41 +0200, "antoine.valmer" a écrit : eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant. Le nouveau nommage est explicite aussi, c'est juste pas fait pour les humains. Ce que je reproche n'est pas la logique du truc, mais ce fait qui effectivement rend complexe ce qui était simple du point de vue de l'humain et du contrôle de ce qu'on fait. Je suppose que ça va avec les automatisations, le branchement à chaud, les gros parcs et toussa, mais il y a une perte de l'idée qu'on doit contrôler sa machine et pas l'inverse. On se simplifie la vie en rendant les choses plus complexes. C'est un paradoxe. l'ordre eth0, eth1... était fonction de la façon dont étaient détectées les cartes par le kernel lors du boot (ordre de chargement des modules). Pour que cela soit stable c'est à l'aide des règles udev que se faisait l'association nom/@MAC à la première détection de la carte. En cas de changement de carte réseau fallait supprimer la règle dans /etc/udev/rules.d/70-persistent-net.rules pour retrouver eth0 disponible. C'était un peu galère pour affecter des noms spécifiques en fonction de la position des cartes dans un PC (déploiement d'images). Le nouveau nommage fait ça tout seul. C'est plus stable et pas nécessairement plus complexe (source https://debian-facile.org/viewtopic.php?pid=264958#p264958) : wl = WireLess en= EtherNet p1 = bus PCI n° 1 (non présent si contrôleur sur la carte mère) s0 = Slot n° 0 f0 = Fonction n° 0 (quand le périphérique contient plusieurs fonctions) Pour retourner aux anciens noms, modifier le fichier /etc/default/grub et ajouter les options net.ifnames=0 et biosdevname=0 à la ligne GRUB_CMDLINE_LINUX=(https://memo-linux.com/debian-9-retrouver-les-noms-des-interfaces-reseaux-eth/). Puis update-grub en root devrait le faire. Bonne soirée, Luc.
Re: Grosse fatigue
Le Fri, 23 Sep 2022 12:42:41 +0200, "antoine.valmer" a écrit : > eth0, wlan0... c'est explicite, et pratique pour réparer un réseau > défaillant. Le nouveau nommage est explicite aussi, c'est juste pas fait pour les humains. Ce que je reproche n'est pas la logique du truc, mais ce fait qui effectivement rend complexe ce qui était simple du point de vue de l'humain et du contrôle de ce qu'on fait. Je suppose que ça va avec les automatisations, le branchement à chaud, les gros parcs et toussa, mais il y a une perte de l'idée qu'on doit contrôler sa machine et pas l'inverse. On se simplifie la vie en rendant les choses plus complexes. C'est un paradoxe.
Re: Grosse fatigue
Le 23/09/2022 à 12:42, antoine.valmer a écrit : On Friday 23 September 2022 12:34:01 BERTRAND Joël wrote: Attention, les ports sont renommés automatiquement sauf s'il y a des règles udev spécifiques. Cela fut rigolo au passage de l'ancien système au nouveau (et si j'ai pu récupérer eth1 et eth2, eth0 n'a rien voulu savoir et se retrouve lan0). Hello, on peut tout à fait modifier le nom des ports eth, wlan..., que ces noms abscons non explicites (ens...) attribués d'office par Debian et Ubuntu : https://waytolearnx.com/2019/05/renommer-linterface-par-defaut-ens33-a-lancienne-eth0-sur-ubuntu-16-04.html eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant. Bonne journée. Et au moins ça change pas sur une mise à jour de udev/systemd comme ça m'est arrivé.
Re: Grosse fatigue
On Friday 23 September 2022 12:34:01 BERTRAND Joël wrote: > Attention, les ports sont renommés automatiquement sauf s'il y a des > règles udev spécifiques. Cela fut rigolo au passage de l'ancien système > au nouveau (et si j'ai pu récupérer eth1 et eth2, eth0 n'a rien voulu > savoir et se retrouve lan0). Hello, on peut tout à fait modifier le nom des ports eth, wlan..., que ces noms abscons non explicites (ens...) attribués d'office par Debian et Ubuntu : https://waytolearnx.com/2019/05/renommer-linterface-par-defaut-ens33-a-lancienne-eth0-sur-ubuntu-16-04.html eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant. Bonne journée.
Re: Grosse fatigue
Erwann Le Bras a écrit : > > > >> Bonjour >> >> Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : >> [...] >>> chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à >>> l'installer. >>> J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer >>> >>> Je suis en Debian stable (11.5). >> >> Si tu as fait un upgrade d'une version antérieure, pas d'usrmerge. >> Installation fraîche: usrmerge installé. > > > ah bah voilà. Ça doit être comme mes ports réseaux qui s'appellent > encore "lo0", "eth0" et "eth1" sur mon serveur. > > sur le serveur c'est la même install depuis Debian 8, qui a changé de > disques et de machine. Attention, les ports sont renommés automatiquement sauf s'il y a des règles udev spécifiques. Cela fut rigolo au passage de l'ancien système au nouveau (et si j'ai pu récupérer eth1 et eth2, eth0 n'a rien voulu savoir et se retrouve lan0).
Re: Grosse fatigue
Bonjour Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : [...] chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à l'installer. J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer Je suis en Debian stable (11.5). Si tu as fait un upgrade d'une version antérieure, pas d'usrmerge. Installation fraîche: usrmerge installé. ah bah voilà. Ça doit être comme mes ports réseaux qui s'appellent encore "lo0", "eth0" et "eth1" sur mon serveur. sur le serveur c'est la même install depuis Debian 8, qui a changé de disques et de machine. amitiés, -- Erwann
Re: Grosse fatigue
Bonjour Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : [...] chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à l'installer. J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer Je suis en Debian stable (11.5). Si tu as fait un upgrade d'une version antérieure, pas d'usrmerge. Installation fraîche: usrmerge installé. -- Daniel
Re: Grosse fatigue
Bonjour, Erwann Le Bras a écrit : > chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à > l'installer. > J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer C'est ce matin que j'ai constaté qu'il était autoritairement poussé dans testing. Jusqu'ici, je m'en suis fort bien passé. Personnellement, je n'ai jamais compris qu'il faille les regrouper, surtout dans l'embarqué où l'on aime bien avoir une partition / minimale en ro. Là, une corruption de /usr met le système par terre (et dans l'embarqué, une telle corruption peut arriver assez vite).
Re: Grosse fatigue
Le 23/09/2022 à 10:31, Erwann Le Bras a écrit : [...] chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à l'installer. J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer Je suis en Debian stable (11.5). [...] Bonjour, De ce que je comprends, ce sera problématique en Stable à partir de Debian 12 Bookworm: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636 et en Unstable Sid, le support a déjà été abandonné ces jours derniers: https://lists.debian.org/debian-devel-announce/2022/09/msg1.html
Re: Grosse fatigue
Michel Memeteau a écrit : > Bonjour , > > > Je pensais que Systemd-OOM était désactivé sur debian ? Je préférerais que ce soit un truc comme ça, mais non. Dans les logs, j'ai juste systemd qui tue la session, comme ça, presque gratuitement. Et concernant la session, c'est une sortie propre, comme si je la quittais normalement (avec les programmes qui se ferment les uns après les autres). Seuls les bash restent orphelins et consomment du temps CPU. Il n'y a pas de problème de mémoire. La machine embarque 64 Go de mémoire (et 96 Go de swap) et ça doit pouvoir faire fonctionner FreeCAD sans se bauger. Ce n'est pas une histoire de carte graphique non plus (la carte embarque 8 Go de mémoire). Mais ça m'arrive aussi en utilisant firefox sans que la mémoire ne soit occupée plus que ça. Le pire, c'est qu'il me tue la session sans aller jusqu'au bout. Mais de temps en temps, il me tue aussi les répliques de base PostgreSQL, ou ypbind... Ça pue l'accès réseau non maîtrisé de systemd. J'ai déjà fait un rapport d'erreur il y a de longs mois sans obtenir de correctif.
Re: Grosse fatigue
Pierre-Elliott Bécue a écrit : > Une ligne de log, quelque chose qui montre que systemd a bien tué X > et éventuellement pourquoi, ou bien on est juste sur yet another > mail de baseless FUD? Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... Sep 23 08:49:31 hilbert systemd[577146]: Activating special unit Exit the Session... Sep 23 08:49:31 hilbert systemd[577146]: Removed slice User Core Session Slice. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Main User Target. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Basic System. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Paths. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Sockets. Sep 23 08:49:31 hilbert systemd[577146]: Stopped target Timers. Sep 23 08:49:31 hilbert systemd[577146]: Closed D-Bus User Message Bus Socket. Sep 23 08:49:31 hilbert systemd[577146]: Closed GnuPG network certificate management daemon. Sep 23 08:49:31 hilbert systemd[577146]: Closed Socket to launch DrKonqi for a systemd-coredump crash. Sep 23 08:49:31 hilbert systemd[577146]: Closed GCR ssh-agent wrapper. Sep 23 08:49:31 hilbert systemd[577146]: Closed GNOME Keyring daemon. ... Sep 23 08:49:31 hilbert systemd[577146]: Reached target Shutdown. Sep 23 08:49:31 hilbert systemd[577146]: Finished Exit the Session. Sep 23 08:49:31 hilbert systemd[577146]: Reached target Exit the Session. Sep 23 08:49:31 hilbert systemd[1]: user@0.service: Deactivated successfully. Sep 23 08:49:31 hilbert systemd[1]: Stopped User Manager for UID 0. Sep 23 08:49:31 hilbert systemd[1]: Stopping User Runtime Directory /run/user/0... Sep 23 08:49:31 hilbert systemd[1]: run-user-0.mount: Deactivated successfully. Sep 23 08:49:31 hilbert systemd[1]: user-runtime-dir@0.service: Deactivated successfully. Sep 23 08:49:31 hilbert systemd[1]: Stopped User Runtime Directory /run/user/0. Sep 23 08:49:31 hilbert systemd[1]: Removed slice User Slice of UID 0. ... Au passage, systemd va jusqu'à tuer ypbind : Sep 23 08:49:46 hilbert systemd[1]: ypbind.service: Main process exited On se demande bien pourquoi. Et il relance le tout comme si rien ne s'était passé (enfin, là, parce que par moment il tue ypbind sans le redémarrer, ce qui pose des problèmes amusants sur une machine diskless en NIS/NFS). De toute façon, la question n'est pas là. systemd décide pour une raison inconnue de clôturer la session. Naturellement, il n'y a AUCUNE erreur avant la première ligne de log. Je veux donc me séparer à la fois de cette saleté qui est une brique pour essuyer les plâtres et d'usrmerge. Je précise que ce genre de chose arrive tous les deux ou trois jours et que c'est gavant.
Re: Grosse fatigue
bonjour
je n'ai jamais constaté ce comportement :
sur mon ordi il arrive -rarement, mais je ne sais pas pourquoi- que
lightdm parte en vrille et je dois le redémarrer par 'systemctl restart
lightdm' depuis la console locale en root.
Ma session utilisateur est fermée, et les les processus correctement
stoppés.
("ps -fu //" ne retourne rien, rien de suspect dans
l'activité CPU/RAM au bout d'un instant)
Je peux me reconnecter sans soucis et relancer mes applis.
Certes, je perds le travail non sauvegardé mais je me suis habitué à
sauvegarder souvent mon travail.
chez moi usrmerge n'est pas installé et Debian ne m'a jamais obligé à
l'installer.
J'ai /usr dans /, je n'ai jamais vu l'intéret de les séparer
Je suis en Debian stable (11.5).
Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment,
toutes les applications en cours (me contraignant à repartir de la
sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de
travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au
milieu du chemin, tuant X mais surtout pas les terminaux de contrôles
dépendants de X :
amitiés,
--
Erwann
Re: Grosse fatigue
Bonjour , Je pensais que Systemd-OOM était désactivé sur debian ? Le 23/09/2022 à 09:41, BERTRAND Joël a écrit : Bonjour à tous, Ce matin, une fois de plus, systemd a cru bon tuer X et, -- -- Michel Memeteau Ekimia ( https://ekimia.fr ) Directeur tel:+33(0)624808051 Address : 620 avenue de la roche fourcade 13400 Aubagne France
Re: Grosse fatigue
BERTRAND Joël wrote on 23/09/2022 at 09:41:24+0200: > Bonjour à tous, > > Ce matin, une fois de plus, systemd a cru bon tuer X et, incidemment, > toutes les applications en cours (me contraignant à repartir de la > sauvegarde de la nuit, je n'ai heureusement perdu qu'une heure de > travail). Ce ne serait encore pas trop grave s'il ne s'arrêtait pas au > milieu du chemin, tuant X mais surtout pas les terminaux de contrôles > dépendants de X : > > top - 09:03:05 up 3 days, 53 min, 19 users, load average: 48,54, 25,93, > 14,15 > ... > KiB Mem : 65562712 total, 5298100 libr, 24405232 util, 3078024 tamp/cache > KiB Éch : 10066329+total, 71624128 libr, 29039160 util. 7755600 dispo Mem > ... > 76791 bertrand 20 0 10108 2468 1660 R 76,2 0,0 13:08.04 > bash >2418 bertrand 20 09988 1792 1648 R 75,2 0,0 13:06.32 > bash > 79309 bertrand 20 09988 2432 1640 R 75,2 0,0 13:30.25 > bash > 307331 bertrand 20 09988 2604 1812 R 75,2 0,0 13:06.87 > bash > 422686 bertrand 20 0 10104 2564 1768 D 75,2 0,0 13:08.79 > bash > 475927 bertrand 20 0 10252 2508 1688 R 75,2 0,0 13:08.96 > bash > 477249 bertrand 20 0 10172 2460 1652 R 75,2 0,0 13:29.82 > bash >2114 bertrand 20 0 10108 2016 1680 R 74,3 0,0 13:09.14 > bash >2122 bertrand 20 0 10108 2056 1716 D 74,3 0,0 13:09.67 > bash >3684 bertrand 20 09988 1808 1672 R 74,3 0,0 13:02.70 > bash >4944 bertrand 20 09988 1892 1732 R 74,3 0,0 13:02.49 > bash > 77325 bertrand 20 09988 2580 1780 R 74,3 0,0 13:10.73 > bash > 103189 bertrand 20 0 10808 3064 1712 R 74,3 0,0 13:02.45 > bash > 309027 bertrand 20 09988 2496 1708 R 74,3 0,0 12:59.61 > bash > 429272 bertrand 20 0 10104 2532 1736 R 74,3 0,0 13:08.76 > bash > > en laissant des zombies partout, des fichiers à moitié ouverts et > corrompus ! Je ne vous ai pas mis toute la liste, la charge est > uniquement due aux bash qui tournent la poignée dans le coin sans rien > faire puisqu'ils ne sont plus associés à un terminal. Le swap de s'est > rempli qu'_après_ que X a été tué par systemd. > > Cette machine n'a aucun problème matériel. Je l'ai testée en long, en > large et en travers. > > J'avoue que ça commence sérieusement à me fatiguer. systemd se permet > de tuer la session X sans aucune raison (rien dans les logs sinon un > truc du style systemd: kill X). Je tourne en testing à jour pour tout un > tas de raisons que je n'expliciterai pas ici. > > Sur ces entrefaites, je passe ne console texte et je m'aperçois que > trois paquets ne peuvent s'installer. Comment ça ? Pour mémoire, > "unattented-upgrade" _N_'est _PAS_ configuré parce que j'ai une version > de KiCAD et une autre de FreeCAD en rolling releases (et > qu'accessoirement lorsque le truc décide de mettre à jour LaTeX, le > réseau rame durant plusieurs heures parce que la station de travail est > diskless). La seule chose qui est faite, c'est un apt update la nuit. > Les mises à jour automatique mettent un bazar là-dedans et je préfère > toujours les passer à la main quand je sais que je ne dérangerai personne. > > Je tente donc un apt dist-upgrade et là, je vois que le truc veut > m'installer usrmerge. Mais pour tout un tas de raisons, JE NE VEUX PAS > DE CETTE SALETÉ. Pourquoi ? Toute mon installation est diskless et/ou > embarqué et usrmerge met un bazar incommensurable là-dedans. Pour une > installation diskless, ça multiplie les latences (regardez un peu le > trafic sur un NFS/TCP, c'est effarant) et dans l'embarqué où / et /usr > ne sont pas sur les mêmes partitions, ça oblige à des contorsions pour > espérer démarrer correctement jusqu'au bout. > > Est-il possible de refuser usrmerge ? Ou faut-il que j'envisage de > réinstaller cette machine sous autre chose, autre chose qui n'utilise ni > systemd vus les dysfonctionnements du truc ni usrmerge ? D'ailleurs > existe-t-il encore une distribution Linux sans usrmerge ? > > À titre personnel, je ne comprends toujours pas que Debian cherche à > imposer systemd vue la fiabilité de la chose dès lors qu'on n'est plus > sur un poste de travail avec un disque en local (la gestion des timeouts > réseau ou des accès réseau concurrents au sens large est... rigologène > pour rester poli et surtout non reproductible d'une version à l'autre). > Quant à ursmerge, dans l'embarqué, on préférerais avoir un répertoire > /rescue à la NetBSD et un /usr séparé pour toujours pouvoir démarrer un > système minimal même lorsque la partition /usr est plantée (/ pouvant > rester en lecture seule). Là, si /usr est corrompue pour une raison ou > pour une autre, on n'est même pas sûr de réussir à démarrer le système > (sauf à se retrouver dans un shell embarqué dans le fumeux initramfs). > > Merci pour toutes vos suggestions, > > JKB Une ligne de log,
Re: Grosse fatigue en fin de compilation de noyau :)
On Fri, Jan 04, 2002 at 11:33:29PM +0100, spear wrote: Je recompile mon noyau ... make menuconfig, make dep, make bzImage, make mrproper ... je rebootais, suivant le kernel howto, afin de faire le make modules ... j'obtenais le message suivant pendant le démarrage, la sequence a taper est make menuconfig make dep clean bzImage modules puis (en tant que root): make modules_install make mrproper te nettoie, comme le nom l'indique, toute ton arborescence et (attention!) te supprime egalement ta '.config', si bien que tu serais reparti pour un 'make menuconfig'. make proper n'est utile que si tu veux repartir a zero. - Dois-je faire le make modules avant le mrproper, et sans redémarrer ? oui. et surtout relis /usr/src/kernel-/README pour ne rien oublier ensuite. en bref: - copier le noyau au bon endroit - evtl. editer /etc/lilo.conf - lancer 'lilo' - redemarrer. Il paraitrait que le tout serait plus simple et facile a faire avec le paquet kernel-package. Je ne l'ai pas encore utilise pour ma part, donc voir la doc respective et les debian-guides. Je n'avais pas installé les Kernel-headers, je l'ai fait, j'ai réessayé, même message au démarrage jusqu'au login ... Je n'ai jamais eu besoin des paquets kernel-headers pour compiler un noyau. Il est tard et je suis HS, alors, si vous voulez bien me dire quoi :) hth, -- Camille
Re: Grosse fatigue en fin de compilation de noyau :)
On Sun, Jan 06, 2002 at 10:48:07AM +0100, Camille Dominique wrote: Il paraitrait que le tout serait plus simple et facile a faire avec le paquet kernel-package. Je ne l'ai pas encore utilise pour ma part, donc voir la doc respective et les debian-guides. plus exactement, dans la newbiedoc (newbiedoc, section kernel-pkg), ou en ligne en francais: http://nicolaxx.free.fr/docs/noyau/noyau.html ou http://nicolaxx.free.fr/docs/noyau/noyau.htm (long) (trouves sur http://dpt.tuxfamily.org) -- Camille
Re: Grosse fatigue en fin de compilation de noyau :)
Je crois que compiler ton noyau à la debian avec make-kpkg est la manière la plus simple d'éviter de genre de désagréments, car debian fait beaucoup de boulot pour toi... Voir le howto de Nicolas Boos, déjà cité http://nicolaxx.free.fr/docs/noyau/noyau.htm http://dpt.tuxfamily.org/ Olivier
Re: Grosse fatigue en fin de compilation de noyau :)
Où as-tu lu ça ??? Pourtant, c'était dans le kernel-howto :( Avec plaisir. re - merci ;) Thomas -- BOFH excuse #201: RPC_PMAP_FAILURE
Re: Grosse fatigue en fin de compilation de noyau :)
Le 04.01.02, spear a tapoté : | Bon ! | | Je recompile mon noyau ... make menuconfig, make dep, make bzImage, make | mrproper ... je rebootais, suivant le kernel howto, afin de faire le | make modules ... j'obtenais le message suivant pendant le démarrage, Où as-tu lu ça ??? Il ne faut pas rebooter avant d'avoir totalement reconstruit ton nouveau noyau ! cd /usr/src/linux su - make menuconfig make dep clean bzlilo modules modules_install reboot et puis basta. Pour le HOWTO : ftp://ftp.lip6.fr/pub/linux/french/docs/HOWTO/a-jour/text/Kernel-HOWTO.gz | modprobe : modprobe: Can't open module dependencies file | /lib/modules/2.2.19/modules.dep (no such file or directory) Normal. | ce message défilait, puis finalement j'arrivais à me logger, j'allais | dans le /usr/src/kernel... et quand je tapais make modules , il me | disait que le support des modules n'était pas activé. Ah bin ça, si on veut pouvoir utiliser les modules, il faut activer le support des modules lors de la configuration du noyau. | - Dois-je faire le make modules avant le mrproper, et sans redémarrer ? Heu... Je ne vois pas trop ce que tu veux faire. Si tu veux simplement pouvoir compiler tes modules, il te faut reprendre la procédure de compilation du noyau étant donné que tu sembles ne pas avoir intégré leur support. | Je n'avais pas installé les Kernel-headers, je l'ai fait, j'ai réessayé, | même message au démarrage jusqu'au login ... Pas nécessaire si tu installes les sources du noyau. | Merci de votre aide ! Avec plaisir. Thomas -- BOFH excuse #201: RPC_PMAP_FAILURE
Re: [CLX] Re: Grosse fatigue en fin de compilation de noyau :)
En fait, j'avais suivi à la lettre le HOWTO, le chapitre ne précisant pas (d'après ce que j'ai compris) qu'il fallait faire le make_modules avant de rebooter ... j'avais donc suivi les chapitres les un après les autres ... ce serait bien de le préciser dans le Howto, tiens ! Mathias Ci dessous, quelques extraits commentés aux endroits clés dans ce cas : The Linux Kernel HOWTO Brian Ward [EMAIL PROTECTED] v3.1, 07 Nov 2001 This is a detailed guide to kernel configuration, compilation, upgrades, and troubleshooting for ix86-based systems. [ ... ] 8. After bzImage is successful, copy the kernel image to /boot directory. You must copy the new kernel image to /boot directory, otherwise the new kernel MAY NOT boot. And then read the manual page on lilo (see also http://www.linuxdoc.org/HOWTO/LILO-crash- rescue-HOWTO.html) and see the ``sample lilo.conf'' file. Always give a date extension to the filename, because it tells you when you built the kernel, as shown below: [ ... ] 9. Now give [ ... ] -- Ici, on dit de rebooter la machine -- 10. Reboot the machine and at lilo press tab key and type 'myker' If it boots then you did a good job! Otherwise at lilo select your old kernel, boot and re-try all over again. Your old kernel is still INTACT and SAFE at say /boot/vmlinuz-2.0.34-0.6 11. If your new kernel 'myker' boots and works properly, you can create the boot disk. Insert a blank floppy into floppy drive and - ___ bash# cd /usr/src/linux bash# make bzdisk See also mkbootdisk - bash# rpm -i mkbootdisk*.rpm bash# man mkbootdisk ___ - Et ici, de s'occuper des modules - 12. LOADABLE MODULES: This step is required ONLY if you had enabled Loadable module support in step 3 above. Loadable module are located in /lib/modules. You MUST do this step if you enabled or disabled any modules, otherwise you will get 'unresolved symbols' errors during or after kernel boot. Check for insmod command which is extensively used for loading the modules. ___ bash# cd /usr/src/linux bash# make modules bash# make modules_install ___ This will copy the modules to /lib/modules directory. For example to load the module /lib/modules/2.4.2-2/ker nel/drivers/block/loop.o, you would do : __ bash# man insmod bash# modproble loop bash# insmod loop bash# lsmod __ [CLX] Re: Grosse fatigue en fin de compilation de noyau :) You can set PATH the insmod searches in /etc/modules.conf
Re: [CLX] Re: Grosse fatigue en fin de compilation de noyau :)
On Sun, Jan 06, 2002 at 01:44:24AM +0100, spear wrote: En fait, j'avais suivi à la lettre le HOWTO, le chapitre ne précisant pas (d'après ce que j'ai compris) qu'il fallait faire le make_modules avant de rebooter ... j'avais donc suivi les chapitres les un après les autres ... ce serait bien de le préciser dans le Howto, tiens ! Ci dessous, quelques extraits commentés aux endroits clés dans ce cas : The Linux Kernel HOWTO Brian Ward [EMAIL PROTECTED] v3.1, 07 Nov 2001 [...] 10. Reboot the machine and at lilo press tab key and type 'myker' If it boots then you did a good job! Otherwise at lilo select your old kernel, boot and re-try all over again. Your old kernel is still INTACT and SAFE at say /boot/vmlinuz-2.0.34-0.6 [...] 12. LOADABLE MODULES: This step is required ONLY if you had enabled [...] ___ bash# cd /usr/src/linux bash# make modules bash# make modules_install ___ Ce que tu nous cites sont les Quick Steps du chapitre 2 d'un HOWTO qui en comporte * 14 * ! Je pense que l'auteur ne les a pas ecrit rien que pour gonfler son HOWTO ;-) Lire au moins *tous* les Quick Steps du chapitre 2 et survoler le chapitre 5. Compiling the kernel avant de se lancer dans l'aventure n'eut pas ete du luxe, surtout si c'est la premiere fois que tu compiles un noyau. Sans oublier le /usr/src/linux/README qui nous indique (en plus court que dans le Kernel-HOWTO) la marche a suivre (et dans l'ordre ;-). -- Camille
