Salut, BERTRAND Joël <joel.bertrand@systella.fr> wrote on 26/09/2022 at 09:44:54+0200: > Pierre-Elliott Bécue a écrit : >> >> BERTRAND Joël <joel.bertrand@systella.fr> 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 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. >>> 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. > > Sauf que dans le cas de ypbind, ça ne fonctionne pas. Il n'est JAMAIS > relancé. C'est d'ailleurs amusant, c'est souvent comme cela qu'à > distance je m'en rends compte parce que je ne plus faire de ssh sur la > machine en question. Si j'ai un shell ouvert, je peux encore récupérer > la situation, mais dans le cas contraire, c'est mort. Dans le cas de X, > ça fonctionne une fois sur deux. Tu dis l'inverse (que systemd tente de relancer des trucs dont ypbind) dans ton mail précédent qui est cité. Faut savoir. Après si tu perds ton système (mort de ypbind), ça ne m'étonne qu'à moitié que le relancement ne se fasse pas bien. >>> 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. > > Ça fait des mois que je bissecte le truc dans tous les sens, que j'y ai > passé un paquet d'heures, tu ne m'ôteras de l'esprit que c'est un bug > systemd parce que tout le reste, pris séparément, fonctionne > parfaitement. Ça pue une utilisation un peu spéciale des disques qui, > dans le cas d'un nfsroot, peuvent mettre un peu de temps à répondre, > voire se prendre un "nfs server not responding" durant quelques secondes. J'ai bien compris que tu es convaincu d'avoir trouvé le coupable. Tu as peut-être raison, cependant, me prétendre que tu sais où chercher et comment quand tu n'as utilisé aucun outil pour débugger ledit systemd, ni auditd qui te permettrait de savoir qui sigterm quoi quand, c'est pas donner l'impression que tu te donnes les moyens de valider ta théorie. Et du coup, oui, ça ressemble à du FUD. Bref, tu fais ce que tu veux, mais à ta place vu que tu as des signaux envoyés, tu sais qu'il y a des syscalls faits juste avant, et un syscall, c'est facile à tracer, sous Linux. À toi de voir. >> Tu auras donc d'autres problèmes sur d'autres systèmes, et tu trouveras >> un autre outil à blâmer. > > Bon, je vais être clair, je considère pour avoir un beau parc de > machines embarquées dans la nature que systemd est un nid à ennui. Et je > pèse mes mots. Son comportement n'est pas reproductif d'une version à la > suivante. Pas plus tard qu'il y a un mois, en plein été, il m'a fallu > remplacer à la volée des clauses Require par After alors qu'il n'y avait > aucune raison valable. Heureusement que je teste avant de déployer ! Je > pense que même les concepteurs du bousin ne savent plus trop comment ça > fonctionne. Donc lorsque tu es dans une configuration standard (disques > locaux, pas de configuration réseau bizarre), ça fonctionne. Mais dès > que tu es dans un truc pas trop prévu ou pas testé par les concepteurs, > ça merdoie dans les grandes largeurs et il y a des effets de bord partout. Ça, ça ressemble essentiellement à du FUD, et je n'ai pas le temps pour ça. En revanche, je suis ravi d'en prendre, si tu le souhaites, pour essayer de comprendre l'enchaînement d'événements qui détruis ta session utilisateur ou ton ypbind. Cf auditd. Bien à toi. -- PEB
Attachment:
signature.asc
Description: PGP signature