Re: Grosse fatigue
Pierre-Elliott Bécue a écrit :
> 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?
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).
<snip>
>> 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 longs mois que le problème existe.).
>>>> 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.
J'ai écrit que systemd relance les daemons (il tente au moins). Et je
rajoute que, de temps en temps, on ne sait pas pourquoi, la station
reste sur sa console texte et que la moitié des daemons se retrouve en
vrac. J'ai naturellement cherché dans les logs pourquoi certains daemons
ne sont pas relancés, il n'y a rien.
> 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.
Certes, mais ce n'est pas corrélé. Hier matin, ypbind était bien actif,
mais les daemons n'ont pas été relancés. Et tant qu'on est dans les
bizarreries, depuis la dernière mouture de systemd (eh oui, j'ai même un
fichier des dysfonctionnements observés en fonction des versions pour
voir si c'est lié), lorsque firefox buggue et ne rend pas la main, le
fait de le tuer avec un kill -9 tue _aussi_ la session X. C'est nouveau,
ça vient de sortir.
>>>> 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.
Tu crois ce que tu veux.
> 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.
Je ne t'ai pas attendu. Je te rappelle que le problème dure depuis de
trop longs mois (j'en ai déjà parlé ici) et que j'ai utilisé à peu près
tous les moyens disponibles dans la doc pour débugguer. auditd est juste
le genre de truc totalement inutilisable sur une machine diskless,
surtout quand elle sert réellement à travailler. Le nombre d'I/O est
monstrueux et sature le serveur nfs qui est pourtant une bête de course.
Or c'est de ça qu'on parle. Si tu ne me crois pas, tu peux en installer
une pour vérifier.
Reply to: