Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
Le 31-10-2013, Francois Lafont a écrit :Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
De par mon expérience, oui. J'avais eu le cas avec un CD, et le même
problème de process en état D.
Seule solution efficace: reboot.
Le 31-10-2013, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
De par mon expérience, oui. J'avais eu le cas avec un CD, et le même
problème de process en état D.
Seule solution efficace: reboot.
Le 31-10-2013, Francois Lafont a écrit :Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
De par mon expérience, oui. J'avais eu le cas avec un CD, et le même
problème de process en état D.
Seule solution efficace: reboot.
Le 31/10/2013 06:19, Kevin Denis a écrit :Le 31-10-2013, Francois Lafont a écrit :Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
De par mon expérience, oui. J'avais eu le cas avec un CD, et le même
problème de process en état D.
Seule solution efficace: reboot.
Ok, merci de ta réponse.
C'est quand même fou qu'il existe un état (l'état D donc) dans lequel un
processus ne réagisse à aucun signal envoyé par kill. Ça devrait pas
exister un machin comme ça. ;-)
Perso, j'ai déjà vu des processus dans l'état D finir par disparaître
mais ça passait par la destruction du device responsable du « blocage ».
Ici, impossible de le flinguer ce device (le volume logique LVM).
Ah... tant pis, je me fendrai d'un reboot alors.
Le 31/10/2013 06:19, Kevin Denis a écrit :
Le 31-10-2013, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
De par mon expérience, oui. J'avais eu le cas avec un CD, et le même
problème de process en état D.
Seule solution efficace: reboot.
Ok, merci de ta réponse.
C'est quand même fou qu'il existe un état (l'état D donc) dans lequel un
processus ne réagisse à aucun signal envoyé par kill. Ça devrait pas
exister un machin comme ça. ;-)
Perso, j'ai déjà vu des processus dans l'état D finir par disparaître
mais ça passait par la destruction du device responsable du « blocage ».
Ici, impossible de le flinguer ce device (le volume logique LVM).
Ah... tant pis, je me fendrai d'un reboot alors.
Le 31/10/2013 06:19, Kevin Denis a écrit :Le 31-10-2013, Francois Lafont a écrit :Pouvez-vous me confirmer (ou pas ;-)) que je n'ai pas d'autre choix
que le reboot ?
De par mon expérience, oui. J'avais eu le cas avec un CD, et le même
problème de process en état D.
Seule solution efficace: reboot.
Ok, merci de ta réponse.
C'est quand même fou qu'il existe un état (l'état D donc) dans lequel un
processus ne réagisse à aucun signal envoyé par kill. Ça devrait pas
exister un machin comme ça. ;-)
Perso, j'ai déjà vu des processus dans l'état D finir par disparaître
mais ça passait par la destruction du device responsable du « blocage ».
Ici, impossible de le flinguer ce device (le volume logique LVM).
Ah... tant pis, je me fendrai d'un reboot alors.
Ça me semble bizarre, ton histoire. À chaque fois que j'ai vu des
processus dans l'état D, il y avait de bonnes raisons à cela (style
I/O sur un périphérique qui ne répond plus).
Ne faudrait-il pas
plutôt regarder du côté des sources du problème ? L'état D n'est
qu'une conséquence.
Ça me semble bizarre, ton histoire. À chaque fois que j'ai vu des
processus dans l'état D, il y avait de bonnes raisons à cela (style
I/O sur un périphérique qui ne répond plus).
Ne faudrait-il pas
plutôt regarder du côté des sources du problème ? L'état D n'est
qu'une conséquence.
Ça me semble bizarre, ton histoire. À chaque fois que j'ai vu des
processus dans l'état D, il y avait de bonnes raisons à cela (style
I/O sur un périphérique qui ne répond plus).
Ne faudrait-il pas
plutôt regarder du côté des sources du problème ? L'état D n'est
qu'une conséquence.
Le 31/10/2013 13:46, JKB a écrit :Ça me semble bizarre, ton histoire. À chaque fois que j'ai vu des
processus dans l'état D, il y avait de bonnes raisons à cela (style
I/O sur un périphérique qui ne répond plus).
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
Ne faudrait-il pas
plutôt regarder du côté des sources du problème ? L'état D n'est
qu'une conséquence.
Sans doute. Personnellement je n'ai pas trop d'idée, mais je peux fournir
quelques éléments ci-dessous.
Ça se passe sur un serveur Xen où les disques des VMs sont des lv.
Tous les soirs à 1h00, pour chaque VM, un snapshot du lv
(logical volume) du disque est fait. Par exemple :
lvcreate --snapshot -L6272M -n blogs-2-disk-clone /dev/vg1/blogs-2-disk
et un dump de ce snapshot est fait :
dump -f - /dev/vg1/blogs-2-disk-clone | gzip > $BACKUP_PATH/blogs-2-disk-clone.dump.gz
Et quand c'est fini, le snapshot est détruit :
lvremove -f /dev/vg1/blogs-2-disk-clone
Ce cron fonctionnait bien a priori depuis pas mal de temps. Pour des
raisons que j'ignore un jour ça a bloqué au niveau du dump sur le snapshot
mais je ne m'en suis pas rendu compte tout de suite. Ensuite, au fur et à
mesure que les crons se sont succédés, des processus dans l'état D
(ceux associés à la commande dump) se sont accumulés et là je me
suis aperçu du problème.
Dans un premier temps, je voudrais nettoyer un peu tout ça, ie tuer
les processus et virer le lv /dev/vg1/blogs-2-disk-clone. Encore une
fois, le cron fonctionnait très bien depuis fort longtemps et donc
ceci me laisse penser que le blocage initial est un « impondérable ».
Maintenant, une fois la situation remise « à zéro », je n'ai pas la
certitude non plus que le cron va à nouveau fonctionner correctement
comme avant.
Le 31/10/2013 13:46, JKB a écrit :
Ça me semble bizarre, ton histoire. À chaque fois que j'ai vu des
processus dans l'état D, il y avait de bonnes raisons à cela (style
I/O sur un périphérique qui ne répond plus).
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
Ne faudrait-il pas
plutôt regarder du côté des sources du problème ? L'état D n'est
qu'une conséquence.
Sans doute. Personnellement je n'ai pas trop d'idée, mais je peux fournir
quelques éléments ci-dessous.
Ça se passe sur un serveur Xen où les disques des VMs sont des lv.
Tous les soirs à 1h00, pour chaque VM, un snapshot du lv
(logical volume) du disque est fait. Par exemple :
lvcreate --snapshot -L6272M -n blogs-2-disk-clone /dev/vg1/blogs-2-disk
et un dump de ce snapshot est fait :
dump -f - /dev/vg1/blogs-2-disk-clone | gzip > $BACKUP_PATH/blogs-2-disk-clone.dump.gz
Et quand c'est fini, le snapshot est détruit :
lvremove -f /dev/vg1/blogs-2-disk-clone
Ce cron fonctionnait bien a priori depuis pas mal de temps. Pour des
raisons que j'ignore un jour ça a bloqué au niveau du dump sur le snapshot
mais je ne m'en suis pas rendu compte tout de suite. Ensuite, au fur et à
mesure que les crons se sont succédés, des processus dans l'état D
(ceux associés à la commande dump) se sont accumulés et là je me
suis aperçu du problème.
Dans un premier temps, je voudrais nettoyer un peu tout ça, ie tuer
les processus et virer le lv /dev/vg1/blogs-2-disk-clone. Encore une
fois, le cron fonctionnait très bien depuis fort longtemps et donc
ceci me laisse penser que le blocage initial est un « impondérable ».
Maintenant, une fois la situation remise « à zéro », je n'ai pas la
certitude non plus que le cron va à nouveau fonctionner correctement
comme avant.
Le 31/10/2013 13:46, JKB a écrit :Ça me semble bizarre, ton histoire. À chaque fois que j'ai vu des
processus dans l'état D, il y avait de bonnes raisons à cela (style
I/O sur un périphérique qui ne répond plus).
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
Ne faudrait-il pas
plutôt regarder du côté des sources du problème ? L'état D n'est
qu'une conséquence.
Sans doute. Personnellement je n'ai pas trop d'idée, mais je peux fournir
quelques éléments ci-dessous.
Ça se passe sur un serveur Xen où les disques des VMs sont des lv.
Tous les soirs à 1h00, pour chaque VM, un snapshot du lv
(logical volume) du disque est fait. Par exemple :
lvcreate --snapshot -L6272M -n blogs-2-disk-clone /dev/vg1/blogs-2-disk
et un dump de ce snapshot est fait :
dump -f - /dev/vg1/blogs-2-disk-clone | gzip > $BACKUP_PATH/blogs-2-disk-clone.dump.gz
Et quand c'est fini, le snapshot est détruit :
lvremove -f /dev/vg1/blogs-2-disk-clone
Ce cron fonctionnait bien a priori depuis pas mal de temps. Pour des
raisons que j'ignore un jour ça a bloqué au niveau du dump sur le snapshot
mais je ne m'en suis pas rendu compte tout de suite. Ensuite, au fur et à
mesure que les crons se sont succédés, des processus dans l'état D
(ceux associés à la commande dump) se sont accumulés et là je me
suis aperçu du problème.
Dans un premier temps, je voudrais nettoyer un peu tout ça, ie tuer
les processus et virer le lv /dev/vg1/blogs-2-disk-clone. Encore une
fois, le cron fonctionnait très bien depuis fort longtemps et donc
ceci me laisse penser que le blocage initial est un « impondérable ».
Maintenant, une fois la situation remise « à zéro », je n'ai pas la
certitude non plus que le cron va à nouveau fonctionner correctement
comme avant.
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
S'il ne répond plus, il doit y avoir un message quelque par dans les
logs qui explique pourquoi il ne répond plus.
Ça pourrait être une tentative de démontage sauvage de
/dev/vg1/blogs-2-disk-clone ou un script tellement long que celui de
la veille n'est pas terminé lorsque celui du jour reprend.
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
S'il ne répond plus, il doit y avoir un message quelque par dans les
logs qui explique pourquoi il ne répond plus.
Ça pourrait être une tentative de démontage sauvage de
/dev/vg1/blogs-2-disk-clone ou un script tellement long que celui de
la veille n'est pas terminé lorsque celui du jour reprend.
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
S'il ne répond plus, il doit y avoir un message quelque par dans les
logs qui explique pourquoi il ne répond plus.
Ça pourrait être une tentative de démontage sauvage de
/dev/vg1/blogs-2-disk-clone ou un script tellement long que celui de
la veille n'est pas terminé lorsque celui du jour reprend.
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
Le 31/10/2013 14:32, JKB a écrit :Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
S'il ne répond plus, il doit y avoir un message quelque par dans les
logs qui explique pourquoi il ne répond plus.
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Ça pourrait être une tentative de démontage sauvage de
/dev/vg1/blogs-2-disk-clone ou un script tellement long que celui de
la veille n'est pas terminé lorsque celui du jour reprend.
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Le 31/10/2013 14:32, JKB a écrit :
Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
S'il ne répond plus, il doit y avoir un message quelque par dans les
logs qui explique pourquoi il ne répond plus.
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Ça pourrait être une tentative de démontage sauvage de
/dev/vg1/blogs-2-disk-clone ou un script tellement long que celui de
la veille n'est pas terminé lorsque celui du jour reprend.
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Le 31/10/2013 14:32, JKB a écrit :Et c'est bien le cas ici. J'ai un lv (logical volume) qui ne répond plus.
Mais impossible de le supprimer celui-là malheureusement.
S'il ne répond plus, il doit y avoir un message quelque par dans les
logs qui explique pourquoi il ne répond plus.
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Ça pourrait être une tentative de démontage sauvage de
/dev/vg1/blogs-2-disk-clone ou un script tellement long que celui de
la veille n'est pas terminé lorsque celui du jour reprend.
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Je vois un oops sur un RPC le 8 octobre (avec un invalid opcode 0000).
Ne cherche pas plus loin. Un coup de memtest pour voir l'état de la
mémoire ?
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Ça, de toute façon, c'est le minimum ;-)
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Je vois un oops sur un RPC le 8 octobre (avec un invalid opcode 0000).
Ne cherche pas plus loin. Un coup de memtest pour voir l'état de la
mémoire ?
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Ça, de toute façon, c'est le minimum ;-)
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Je vois un oops sur un RPC le 8 octobre (avec un invalid opcode 0000).
Ne cherche pas plus loin. Un coup de memtest pour voir l'état de la
mémoire ?
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Ça, de toute façon, c'est le minimum ;-)
Bonsoir,
Le 04/11/2013 14:05, JKB a écrit :Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Je vois un oops sur un RPC le 8 octobre (avec un invalid opcode 0000).
Ne cherche pas plus loin. Un coup de memtest pour voir l'état de la
mémoire ?
J'ai voulu tester sur une VM (en Lenny tout comme le serveur) avec un petit
coup de « apt-get install memtest86+ && update-grub », si j'ai bien compris
ensuite :
1) il faut rebooter le choix memtest86+ via le menu Grub;
2) ça peut prendre un certain temps.
Je n'ai pas un accès physique au serveur (du moins pas facilement) du coup
1) me pose un peu de souci. Certes on a un port IPMI mais il reste ensuite
le point 2) qui me gêne. Est-il possible de mettre en place un memtest86+
un peu light et rapide ?
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Ça, de toute façon, c'est le minimum ;-)
Ça c'est fait (via la méthode à l'ancienne).
Bonsoir,
Le 04/11/2013 14:05, JKB a écrit :
Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Je vois un oops sur un RPC le 8 octobre (avec un invalid opcode 0000).
Ne cherche pas plus loin. Un coup de memtest pour voir l'état de la
mémoire ?
J'ai voulu tester sur une VM (en Lenny tout comme le serveur) avec un petit
coup de « apt-get install memtest86+ && update-grub », si j'ai bien compris
ensuite :
1) il faut rebooter le choix memtest86+ via le menu Grub;
2) ça peut prendre un certain temps.
Je n'ai pas un accès physique au serveur (du moins pas facilement) du coup
1) me pose un peu de souci. Certes on a un port IPMI mais il reste ensuite
le point 2) qui me gêne. Est-il possible de mettre en place un memtest86+
un peu light et rapide ?
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Ça, de toute façon, c'est le minimum ;-)
Ça c'est fait (via la méthode à l'ancienne).
Bonsoir,
Le 04/11/2013 14:05, JKB a écrit :Le blocage initial a eu lieu le 8 ou le 9 octobre (j'ai un petit doute).
J'ai rien dans syslog qui remonte aussi loin et en fait j'ai même absolument
rien dans syslog sur ce problème de device même pour les crons plus récents.
Je vois un oops sur un RPC le 8 octobre (avec un invalid opcode 0000).
Ne cherche pas plus loin. Un coup de memtest pour voir l'état de la
mémoire ?
J'ai voulu tester sur une VM (en Lenny tout comme le serveur) avec un petit
coup de « apt-get install memtest86+ && update-grub », si j'ai bien compris
ensuite :
1) il faut rebooter le choix memtest86+ via le menu Grub;
2) ça peut prendre un certain temps.
Je n'ai pas un accès physique au serveur (du moins pas facilement) du coup
1) me pose un peu de souci. Certes on a un port IPMI mais il reste ensuite
le point 2) qui me gêne. Est-il possible de mettre en place un memtest86+
un peu light et rapide ?
Je commencerais par mettre un mutex sur la chose. Soit à l'ancienne
(avec un touch lock) si le script n'est lancé que par un seul cron,
soit un vrai mutex POSIX.
C'est vrai que ça serait une amélioration à faire au niveau du cron.
Ça, de toute façon, c'est le minimum ;-)
Ça c'est fait (via la méthode à l'ancienne).