Depuis que j'ai changé de machine, j'ai des problèmes de freeze
intempestifs. Mais tout n'est pas gelé. Un 'ls' gèle alors que d'autres
processus fonctionne normalement. La souris n'est pas touchée ni le
clavier. Dans les logs, j'ai ça:
J'ai supprimé les détails des call trace ([...]) afin de ne pas faire trop long.
On voit que plusieurs processus bloquent (md1_raid1, md0_raid1, uptimed,
fetchmail, kworker, lpqd et systemd). Je pensais à un disque défectueux
dans une grappe RAID 1, alors je l'ai enlevé, ce qui a eu pour effet de
d'augmenter la durée entre deux freeze. J'ai également essayé avec des
versions de noyaux inférieurs, mais même résultat. J'ai lu quelque part
sur Internet que cela pouvait être dû à une machine lente, mais c'est
loin d'être mon cas.
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! »
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti). Je suis donc repassé sur le driver proprio nvidia… En éteignant la machine, j'ai observé un truc étrange: Failed unmounting /var et /var est monté sur /dev/md0. Je ne sais pas si ça peut corrompre ce système de fichiers si la machine s'éteint avant que cette partition ne soit démontée. Une piste ?
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! »
Mais peut-être qu'il s'agit plutôt de « Oui, le problème se
reproduit avec un noyau non teinté! »
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger
xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Je suis donc repassé sur le driver proprio nvidia…
En éteignant la machine, j'ai observé un truc étrange:
Failed unmounting /var
et /var est monté sur /dev/md0.
Je ne sais pas si ça peut corrompre ce système de fichiers si la machine
s'éteint avant que cette partition ne soit démontée. Une piste ?
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! »
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti). Je suis donc repassé sur le driver proprio nvidia… En éteignant la machine, j'ai observé un truc étrange: Failed unmounting /var et /var est monté sur /dev/md0. Je ne sais pas si ça peut corrompre ce système de fichiers si la machine s'éteint avant que cette partition ne soit démontée. Une piste ?
=c3
Bonjour, Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir un rapport à propos du noyau via reportbug. Si ce comportement est connu d'un mainteneur, alors peut-être qu'il aura une solution, sinon ce sera toujours bien d'en avoir une trace. Steve, au 2019-04-17 :
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas.
J'ai bien peur que non. J'aimerais bien avoir plus d'information dans les différents fichiers journaux mais je ne sais pas trop comment et quoi activer.
Les message relatif au noyau et ses sous-systèmes apparaissent en sortie de la commande `dmesg`. En dehors, je ne vois pas, à part des copies dans les différents agrégateurs de journaux. Il est éventuellement possible d'augmenter la verbosité de certains modules noyau, via des options du type module.debug=1, mais pas certain que ça aide dans votre cas. Je n'exclue pas d'avoir loupé quelque chose moi-même. Dans le doute, la force brute est aussi une solution valide pour chercher une aiguille dans une botte de foin: # rgrep -i 'ext4|raid|md[0-2]' /var/
uname -a Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
4.19.28-2~bpo9+1, ça devrait être bon. :) Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où...
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Ça vient probablement du fichier /etc/X11/xorg.conf, produit par nvidia-xconfig ou nvidia-settings, lors de l'installation et la configuration du pilote respectivement. Avec un peu de chance, le serveur X démarrera si ce fichier n'existe plus, par exemple en le renommant /etc/X11/xorg.conf.nvidia-bck. Si vraiment c'est « nouveau » qui coince, alors il est toujours possible de le replacer en liste noire, le pilote nvidiafb pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu ce pilote coincer méchamment sur carte Quadro, avec la console coincée sur une fonte blanche à fond vert… L'écran vert de la mort ?
En éteignant la machine, j'ai observé un truc étrange: Failed unmounting /var et /var est monté sur /dev/md0. Je ne sais pas si ça peut corrompre ce système de fichiers si la machine s'éteint avant que cette partition ne soit démontée. Une piste ?
À première vue, ça aurait pu expliquer les erreurs corrigées par fsck, que vous avez mentionné un peu plus tôt dans le file de discussion. Toutefois, si le système de fichier ne s'était pas correctement démonté à l'arrêt de la machine, je crois que le fsck aurait dû se déclencher au démarrage suivant.
Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très récemment, ce qui a diminué leur nombre).
L'essentiel est effectivement du bruit, mais c'est bien pensé, le coup de mettre à jour le Bios. Amicalement, -- Étienne Mollier
Bonjour,
Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
un rapport à propos du noyau via reportbug. Si ce comportement
est connu d'un mainteneur, alors peut-être qu'il aura une
solution, sinon ce sera toujours bien d'en avoir une trace.
Steve, au 2019-04-17 :
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
> Toutefois, je ne sais pas si vous vous êtes retrouvé dans la
> situation décrite par le changelog, ni si corruption il y a ;
> je crois qu'il y aurait aussi des erreurs relatives à votre
> système de fichier dans `dmesg` dans ce cas.
J'ai bien peur que non. J'aimerais bien avoir plus d'information dans
les différents fichiers journaux mais je ne sais pas trop comment et
quoi activer.
Les message relatif au noyau et ses sous-systèmes apparaissent
en sortie de la commande `dmesg`. En dehors, je ne vois pas, à
part des copies dans les différents agrégateurs de journaux.
Il est éventuellement possible d'augmenter la verbosité de
certains modules noyau, via des options du type module.debug=1,
mais pas certain que ça aide dans votre cas. Je n'exclue pas
d'avoir loupé quelque chose moi-même.
Dans le doute, la force brute est aussi une solution valide pour
chercher une aiguille dans une botte de foin:
# rgrep -i 'ext4|raid|md[0-2]' /var/
uname -a
Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
4.19.28-2~bpo9+1, ça devrait être bon. :)
Dans le doute, j'ajouterais un incrément dans les backups avant
reconstruction, au cas où...
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger
xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Ça vient probablement du fichier /etc/X11/xorg.conf, produit par
nvidia-xconfig ou nvidia-settings, lors de l'installation et la
configuration du pilote respectivement. Avec un peu de chance,
le serveur X démarrera si ce fichier n'existe plus, par exemple
en le renommant /etc/X11/xorg.conf.nvidia-bck.
Si vraiment c'est « nouveau » qui coince, alors il est toujours
possible de le replacer en liste noire, le pilote nvidiafb
pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu
ce pilote coincer méchamment sur carte Quadro, avec la console
coincée sur une fonte blanche à fond vert… L'écran vert de la
mort ?
En éteignant la machine, j'ai observé un truc étrange:
Failed unmounting /var
et /var est monté sur /dev/md0.
Je ne sais pas si ça peut corrompre ce système de fichiers si la machine
s'éteint avant que cette partition ne soit démontée. Une piste ?
À première vue, ça aurait pu expliquer les erreurs corrigées par
fsck, que vous avez mentionné un peu plus tôt dans le file de
discussion. Toutefois, si le système de fichier ne s'était pas
correctement démonté à l'arrêt de la machine, je crois que le
fsck aurait dû se déclencher au démarrage suivant.
Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très
récemment, ce qui a diminué leur nombre).
L'essentiel est effectivement du bruit, mais c'est bien pensé,
le coup de mettre à jour le Bios.
Bonjour, Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir un rapport à propos du noyau via reportbug. Si ce comportement est connu d'un mainteneur, alors peut-être qu'il aura une solution, sinon ce sera toujours bien d'en avoir une trace. Steve, au 2019-04-17 :
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas.
J'ai bien peur que non. J'aimerais bien avoir plus d'information dans les différents fichiers journaux mais je ne sais pas trop comment et quoi activer.
Les message relatif au noyau et ses sous-systèmes apparaissent en sortie de la commande `dmesg`. En dehors, je ne vois pas, à part des copies dans les différents agrégateurs de journaux. Il est éventuellement possible d'augmenter la verbosité de certains modules noyau, via des options du type module.debug=1, mais pas certain que ça aide dans votre cas. Je n'exclue pas d'avoir loupé quelque chose moi-même. Dans le doute, la force brute est aussi une solution valide pour chercher une aiguille dans une botte de foin: # rgrep -i 'ext4|raid|md[0-2]' /var/
uname -a Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
4.19.28-2~bpo9+1, ça devrait être bon. :) Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où...
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Ça vient probablement du fichier /etc/X11/xorg.conf, produit par nvidia-xconfig ou nvidia-settings, lors de l'installation et la configuration du pilote respectivement. Avec un peu de chance, le serveur X démarrera si ce fichier n'existe plus, par exemple en le renommant /etc/X11/xorg.conf.nvidia-bck. Si vraiment c'est « nouveau » qui coince, alors il est toujours possible de le replacer en liste noire, le pilote nvidiafb pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu ce pilote coincer méchamment sur carte Quadro, avec la console coincée sur une fonte blanche à fond vert… L'écran vert de la mort ?
En éteignant la machine, j'ai observé un truc étrange: Failed unmounting /var et /var est monté sur /dev/md0. Je ne sais pas si ça peut corrompre ce système de fichiers si la machine s'éteint avant que cette partition ne soit démontée. Une piste ?
À première vue, ça aurait pu expliquer les erreurs corrigées par fsck, que vous avez mentionné un peu plus tôt dans le file de discussion. Toutefois, si le système de fichier ne s'était pas correctement démonté à l'arrêt de la machine, je crois que le fsck aurait dû se déclencher au démarrage suivant.
Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très récemment, ce qui a diminué leur nombre).
L'essentiel est effectivement du bruit, mais c'est bien pensé, le coup de mettre à jour le Bios. Amicalement, -- Étienne Mollier
steve
Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit :
Bonjour, Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
Et bien moi je crois que je suis sur une piste :) J'ai trouvé trace de fautes de segmentation de mon agent de transport mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le moment, plus de gel. Je croise les doigts. [...]
Les message relatif au noyau et ses sous-systèmes apparaissent en sortie de la commande `dmesg`.
Ou pour ceux qui aime de journalctl… :)
uname -a Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
4.19.28-2~bpo9+1, ça devrait être bon. :) Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où...
C'est à dire ?
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Ça vient probablement du fichier /etc/X11/xorg.conf, produit par nvidia-xconfig ou nvidia-settings, lors de l'installation et la configuration du pilote respectivement. Avec un peu de chance, le serveur X démarrera si ce fichier n'existe plus, par exemple en le renommant /etc/X11/xorg.conf.nvidia-bck.
C'est vrai que j'ai oublié la possibilité de supprimer ce fichier. En faisant le test, j'ai simplement remplacé nvidia par nouveau pour le driver. Mais honnêtement ces histoires de pilotes de cartes graphiques me gavent, c'est pour cela que j'utilise le pilote proprio nvidia qui, jusqu'à présent, remplissait majoritairement mes besoins. Bien sûr, s'il devient évident qu'il est la cause de mes soucis, j'envisagerais de passer des heures à essayer de faire fonctionner le pilote libre. Mais là j'ai vraiment autre chose à faire.
Si vraiment c'est « nouveau » qui coince, alors il est toujours possible de le replacer en liste noire, le pilote nvidiafb pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu ce pilote coincer méchamment sur carte Quadro, avec la console coincée sur une fonte blanche à fond vert… L'écran vert de la mort ?
:)
En éteignant la machine, j'ai observé un truc étrange: Failed unmounting /var et /var est monté sur /dev/md0. Je ne sais pas si ça peut corrompre ce système de fichiers si la machine s'éteint avant que cette partition ne soit démontée. Une piste ?
À première vue, ça aurait pu expliquer les erreurs corrigées par fsck, que vous avez mentionné un peu plus tôt dans le file de discussion. Toutefois, si le système de fichier ne s'était pas correctement démonté à l'arrêt de la machine, je crois que le fsck aurait dû se déclencher au démarrage suivant.
Ce qu'il ne fait pas me semble-t-il. Quand je l'ai lancé manuellement sur un système live, il m'a indiqué que ça faisait des semaines qu'il n'avait pas été lancé. Ce qui me semble bizarre et qui est une autre ligne dans mon TODO informatique. Dans la même veine, j'ai ça: var.mount: Directory /var to mount over is not empty, mounting anyway. Pareil pour tmp (qui n'est pas en RAID1). Je n'arrive pas à comprendre la raison. Steve
Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit :
Bonjour,
Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
Et bien moi je crois que je suis sur une piste :)
J'ai trouvé trace de fautes de segmentation de mon agent de transport
mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le
moment, plus de gel. Je croise les doigts.
[...]
Les message relatif au noyau et ses sous-systèmes apparaissent
en sortie de la commande `dmesg`.
Ou pour ceux qui aime de journalctl… :)
uname -a
Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
4.19.28-2~bpo9+1, ça devrait être bon. :)
Dans le doute, j'ajouterais un incrément dans les backups avant
reconstruction, au cas où...
C'est à dire ?
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger
xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Ça vient probablement du fichier /etc/X11/xorg.conf, produit par
nvidia-xconfig ou nvidia-settings, lors de l'installation et la
configuration du pilote respectivement. Avec un peu de chance,
le serveur X démarrera si ce fichier n'existe plus, par exemple
en le renommant /etc/X11/xorg.conf.nvidia-bck.
C'est vrai que j'ai oublié la possibilité de supprimer ce fichier. En
faisant le test, j'ai simplement remplacé nvidia par nouveau pour le
driver.
Mais honnêtement ces histoires de pilotes de cartes graphiques me
gavent, c'est pour cela que j'utilise le pilote proprio nvidia qui,
jusqu'à présent, remplissait majoritairement mes besoins. Bien sûr, s'il
devient évident qu'il est la cause de mes soucis, j'envisagerais de
passer des heures à essayer de faire fonctionner le pilote libre. Mais
là j'ai vraiment autre chose à faire.
Si vraiment c'est « nouveau » qui coince, alors il est toujours
possible de le replacer en liste noire, le pilote nvidiafb
pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu
ce pilote coincer méchamment sur carte Quadro, avec la console
coincée sur une fonte blanche à fond vert… L'écran vert de la
mort ?
:)
En éteignant la machine, j'ai observé un truc étrange:
Failed unmounting /var
et /var est monté sur /dev/md0.
Je ne sais pas si ça peut corrompre ce système de fichiers si la machine
s'éteint avant que cette partition ne soit démontée. Une piste ?
À première vue, ça aurait pu expliquer les erreurs corrigées par
fsck, que vous avez mentionné un peu plus tôt dans le file de
discussion. Toutefois, si le système de fichier ne s'était pas
correctement démonté à l'arrêt de la machine, je crois que le
fsck aurait dû se déclencher au démarrage suivant.
Ce qu'il ne fait pas me semble-t-il. Quand je l'ai lancé manuellement
sur un système live, il m'a indiqué que ça faisait des semaines qu'il
n'avait pas été lancé. Ce qui me semble bizarre et qui est une autre
ligne dans mon TODO informatique.
Dans la même veine, j'ai ça:
var.mount: Directory /var to mount over is not empty, mounting anyway.
Pareil pour tmp (qui n'est pas en RAID1). Je n'arrive pas à comprendre
la raison.
Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit :
Bonjour, Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
Et bien moi je crois que je suis sur une piste :) J'ai trouvé trace de fautes de segmentation de mon agent de transport mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le moment, plus de gel. Je croise les doigts. [...]
Les message relatif au noyau et ses sous-systèmes apparaissent en sortie de la commande `dmesg`.
Ou pour ceux qui aime de journalctl… :)
uname -a Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
4.19.28-2~bpo9+1, ça devrait être bon. :) Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où...
C'est à dire ?
Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti).
Ça vient probablement du fichier /etc/X11/xorg.conf, produit par nvidia-xconfig ou nvidia-settings, lors de l'installation et la configuration du pilote respectivement. Avec un peu de chance, le serveur X démarrera si ce fichier n'existe plus, par exemple en le renommant /etc/X11/xorg.conf.nvidia-bck.
C'est vrai que j'ai oublié la possibilité de supprimer ce fichier. En faisant le test, j'ai simplement remplacé nvidia par nouveau pour le driver. Mais honnêtement ces histoires de pilotes de cartes graphiques me gavent, c'est pour cela que j'utilise le pilote proprio nvidia qui, jusqu'à présent, remplissait majoritairement mes besoins. Bien sûr, s'il devient évident qu'il est la cause de mes soucis, j'envisagerais de passer des heures à essayer de faire fonctionner le pilote libre. Mais là j'ai vraiment autre chose à faire.
Si vraiment c'est « nouveau » qui coince, alors il est toujours possible de le replacer en liste noire, le pilote nvidiafb pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu ce pilote coincer méchamment sur carte Quadro, avec la console coincée sur une fonte blanche à fond vert… L'écran vert de la mort ?
:)
En éteignant la machine, j'ai observé un truc étrange: Failed unmounting /var et /var est monté sur /dev/md0. Je ne sais pas si ça peut corrompre ce système de fichiers si la machine s'éteint avant que cette partition ne soit démontée. Une piste ?
À première vue, ça aurait pu expliquer les erreurs corrigées par fsck, que vous avez mentionné un peu plus tôt dans le file de discussion. Toutefois, si le système de fichier ne s'était pas correctement démonté à l'arrêt de la machine, je crois que le fsck aurait dû se déclencher au démarrage suivant.
Ce qu'il ne fait pas me semble-t-il. Quand je l'ai lancé manuellement sur un système live, il m'a indiqué que ça faisait des semaines qu'il n'avait pas été lancé. Ce qui me semble bizarre et qui est une autre ligne dans mon TODO informatique. Dans la même veine, j'ai ça: var.mount: Directory /var to mount over is not empty, mounting anyway. Pareil pour tmp (qui n'est pas en RAID1). Je n'arrive pas à comprendre la raison. Steve
=c3
Steve, au 2019-04-18 :
Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit :
Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
Et bien moi je crois que je suis sur une piste :) J'ai trouvé trace de fautes de segmentation de mon agent de transport mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le moment, plus de gel. Je croise les doigts.
Ça c'est une très bonne nouvelle! :)
Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où...
C'est à dire ?
Faites une sauvegarde avant la manipulation, des fois que…
var.mount: Directory /var to mount over is not empty, mounting anyway.
C'est peut-être du bruit lié à un démarrage sans montage du /var une fois. Et comme les fichiers ne sont pas effacés mais seulement inaccessibles, le message se reproduit à chaque démarrage. Ça pourrait aussi être lié à ce bug si le problème se reproduit après ménage dans le /var de votre partition / (utilisez `mount --bind / /mnt/rescue` pour voir ce qu'il se passe sous les points de montages) : https://github.com/systemd/systemd/issues/4494 Corrigé dans systemd 233, mais je ne suis pas allé vérifier si ça été corrigé dans Stretch ou non. Ou alors un de vos services démarre trop vite et aurait grand besoin de dépendre de var.mount et tmp.mount avant de commencer à tourner ? Amicalement, -- Étienne Mollier
Steve, au 2019-04-18 :
Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit :
> Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
Et bien moi je crois que je suis sur une piste :)
J'ai trouvé trace de fautes de segmentation de mon agent de transport
mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le
moment, plus de gel. Je croise les doigts.
Ça c'est une très bonne nouvelle! :)
> Dans le doute, j'ajouterais un incrément dans les backups avant
> reconstruction, au cas où...
C'est à dire ?
Faites une sauvegarde avant la manipulation, des fois que…
var.mount: Directory /var to mount over is not empty, mounting
anyway.
C'est peut-être du bruit lié à un démarrage sans montage du /var
une fois. Et comme les fichiers ne sont pas effacés mais
seulement inaccessibles, le message se reproduit à chaque
démarrage.
Ça pourrait aussi être lié à ce bug si le problème se reproduit
après ménage dans le /var de votre partition / (utilisez `mount
--bind / /mnt/rescue` pour voir ce qu'il se passe sous les
points de montages) :
https://github.com/systemd/systemd/issues/4494
Corrigé dans systemd 233, mais je ne suis pas allé vérifier si
ça été corrigé dans Stretch ou non.
Ou alors un de vos services démarre trop vite et aurait grand
besoin de dépendre de var.mount et tmp.mount avant de commencer
à tourner ?
Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit :
Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir
Et bien moi je crois que je suis sur une piste :) J'ai trouvé trace de fautes de segmentation de mon agent de transport mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le moment, plus de gel. Je croise les doigts.
Ça c'est une très bonne nouvelle! :)
Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où...
C'est à dire ?
Faites une sauvegarde avant la manipulation, des fois que…
var.mount: Directory /var to mount over is not empty, mounting anyway.
C'est peut-être du bruit lié à un démarrage sans montage du /var une fois. Et comme les fichiers ne sont pas effacés mais seulement inaccessibles, le message se reproduit à chaque démarrage. Ça pourrait aussi être lié à ce bug si le problème se reproduit après ménage dans le /var de votre partition / (utilisez `mount --bind / /mnt/rescue` pour voir ce qu'il se passe sous les points de montages) : https://github.com/systemd/systemd/issues/4494 Corrigé dans systemd 233, mais je ne suis pas allé vérifier si ça été corrigé dans Stretch ou non. Ou alors un de vos services démarre trop vite et aurait grand besoin de dépendre de var.mount et tmp.mount avant de commencer à tourner ? Amicalement, -- Étienne Mollier
