Re: Grosse fatigue
Pierre-Elliott Bécue a écrit :
>
> BERTRAND Joël <joel.bertrand@systella.fr> 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 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) 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.
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 (?!).
>> 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.
>> 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.
> 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.
Reply to: