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 0 9988 1792 1648 R 75,2 0,0 13:06.32
bash
79309 bertrand 20 0 9988 2432 1640 R 75,2 0,0 13:30.25
bash
307331 bertrand 20 0 9988 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 0 9988 1808 1672 R 74,3 0,0 13:02.70
bash
4944 bertrand 20 0 9988 1892 1732 R 74,3 0,0 13:02.49
bash
77325 bertrand 20 0 9988 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 0 9988 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
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
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 :
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).
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
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é.
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.
eth0, wlan0... c'est explicite, et pratique pour réparer un réseau défaillant.
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 :
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]: [email protected]e: 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]: [email protected]e:
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.
On 23/09/2022 09:41, BERTRAND Joël wrote:Bonjour
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
Pierre-Elliott Bécue a écrit :
BERTRAND Joël <[email protected]> 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.
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.
BERTRAND Joël <[email protected]> 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".
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.
Thomas Parmelan a écrit :
Le mardi 27 septembre 2022 à 18:23, d'après
BERTRAND Joël <[email protected]> :
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).Sep 23 08:49:31 hilbert systemd[1]: Stopping User Manager for UID 0... >>
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.
Pierre-Elliott Bécue a écrit :
Salut,
BERTRAND Joël <[email protected]> wrote on 26/09/2022 at 09:44:54+0200:
Pierre-Elliott Bécue a écrit :Très bien, mais as-tu, par exemple, unattended-upgrades ou équivalent
BERTRAND Joël <[email protected]> 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. >>
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.
J'ai bien compris que tu es convaincu d'avoir trouvé le coupable. Tu asDe 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. >>
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.
Ç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, pourTu 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. >>
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.
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.
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 !
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 154:02:01 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,674 |