Le dump envoie sa sortie vers gzip à travers un pipe. Impossible
de tuer ces processus même avec kill -KILL. Si j'ai bien compris,
c'est normal car ils sont en attente au niveau I/O, état qui
est censé durer très peu de temps et pendant lequel un processus
ne fait strictement rien à part attendre et il n'écoute aucun
signal (et mes kill n'aboutissent pas).
Ok. Il faut donc que je dégage le volume logique blogs-2-disk-clone
(qui est un volume temporaire en principe donc pas de souci s'il
faut le zigouiller). Du coup, je tente :
~# lvremove -f /dev/vg1/blogs-2-disk-clone
Can't remove open logical volume "blogs-2-disk-clone"
C'est logique, il me dit que mon lv est ouvert etc. alors
impossible de le zigouiller.
Du coup, j'ai un peu l'impression que c'est la quadrature du
cercle ce machin avec d'un côté des processus dans l'attente d'un
device en continu et de l'autre un device que je ne peux pas
virer car il me dit qu'il est ouvert pas des processus.
Y a-t-il un moyen d'éviter le reboot du système ?
(j'aimerais bien ;-))
Merci pour votre aide.
PS : oui le processus parent des commandes dump est init,
mais ce n'était pas le cas au départ et c'est peut-être là
où j'ai merdé. Lorsque j'ai tué le processus initial (ie le
script qui lance les backups) j'ai fait un :
kill -TERM <LE-PID-SCRIPT>
alors que j'aurais sûrement dû faire :
kill -TERM -<LE-PID-SCRIPT> # avec un « - » devant le pid
car ça aurait tué tout le groupe et ça m'aurait évité mon
problème actuel. Je me trompe ?
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 viens de voir qu'il existe un autre outil qui ne nécessite pas de rebooter : memtester
Someone else stole your IP address, call the Internet detectives!
Salut,
Francois Lafont a tapoté, le 04/11/2013 23:24:
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 viens de voir qu'il existe un autre outil qui ne nécessite pas de
rebooter : memtester
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 viens de voir qu'il existe un autre outil qui ne nécessite pas de rebooter : memtester
Someone else stole your IP address, call the Internet detectives!
JKB
Le Tue, 05 Nov 2013 10:16:05 +0100, yamo' écrivait :
Salut,
Francois Lafont a tapoté, le 04/11/2013 23:24:
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 viens de voir qu'il existe un autre outil qui ne nécessite pas de rebooter : memtester
Cela ne testera pas tout. En particulier, cela ne testera pas la mémoire du noyau (et ton 0000 me fait penser à un problème de mémoire dans la zone du noyau).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Tue, 05 Nov 2013 10:16:05 +0100,
yamo' <yamo@beurdin.invalid> écrivait :
Salut,
Francois Lafont a tapoté, le 04/11/2013 23:24:
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 viens de voir qu'il existe un autre outil qui ne nécessite pas de
rebooter : memtester
Cela ne testera pas tout. En particulier, cela ne testera pas la
mémoire du noyau (et ton 0000 me fait penser à un problème de
mémoire dans la zone du noyau).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Tue, 05 Nov 2013 10:16:05 +0100, yamo' écrivait :
Salut,
Francois Lafont a tapoté, le 04/11/2013 23:24:
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 viens de voir qu'il existe un autre outil qui ne nécessite pas de rebooter : memtester
Cela ne testera pas tout. En particulier, cela ne testera pas la mémoire du noyau (et ton 0000 me fait penser à un problème de mémoire dans la zone du noyau).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Francois Lafont
Bonsoir,
Juste pour info, j'ai fini par me débarrasser de mes processus bloqués dans l'état D via un redémarrage. Mais même un banal redémarrage n'a pas été simple car avec un
reboot ou même reboot -f
le serveur ne voulait même pas rebooter ! Ma connexion ssh se coupait, mais le serveur continuait à tourner : je pouvais m'y reconnecter par ssh, les VMs Xen étaient parfaitement ok etc. Bref, à part me couper ma connexion ssh, ça ne faisait rien du tout. C'est bizarre tout de même, j'avais encore jamais vu ça. Il a fallu que j'éteigne proprement les domUs une à une puis, via le port IPMI du serveur, que je provoque un extinction électrique puis que je le rallume. Ensuite, tout est rentré dans l'ordre et les backups se font bien à nouveau, comme c'était déjà le cas depuis longtemps... jusqu'à ce petit « oops » du 8 octobre. ;-)
Pour le memtest ça va être compliqué car je ne peux pas stopper le serveur si longtemps. C'est un vieux coucou et, de toute façon, il est en fin de vie.
-- François Lafont
Bonsoir,
Juste pour info, j'ai fini par me débarrasser de mes
processus bloqués dans l'état D via un redémarrage. Mais
même un banal redémarrage n'a pas été simple car avec un
reboot ou même reboot -f
le serveur ne voulait même pas rebooter ! Ma connexion
ssh se coupait, mais le serveur continuait à tourner :
je pouvais m'y reconnecter par ssh, les VMs Xen étaient
parfaitement ok etc. Bref, à part me couper ma connexion
ssh, ça ne faisait rien du tout. C'est bizarre tout de même,
j'avais encore jamais vu ça. Il a fallu que j'éteigne
proprement les domUs une à une puis, via le port IPMI
du serveur, que je provoque un extinction électrique
puis que je le rallume. Ensuite, tout est rentré dans
l'ordre et les backups se font bien à nouveau, comme
c'était déjà le cas depuis longtemps... jusqu'à ce
petit « oops » du 8 octobre. ;-)
Pour le memtest ça va être compliqué car je ne peux
pas stopper le serveur si longtemps. C'est un vieux
coucou et, de toute façon, il est en fin de vie.
Juste pour info, j'ai fini par me débarrasser de mes processus bloqués dans l'état D via un redémarrage. Mais même un banal redémarrage n'a pas été simple car avec un
reboot ou même reboot -f
le serveur ne voulait même pas rebooter ! Ma connexion ssh se coupait, mais le serveur continuait à tourner : je pouvais m'y reconnecter par ssh, les VMs Xen étaient parfaitement ok etc. Bref, à part me couper ma connexion ssh, ça ne faisait rien du tout. C'est bizarre tout de même, j'avais encore jamais vu ça. Il a fallu que j'éteigne proprement les domUs une à une puis, via le port IPMI du serveur, que je provoque un extinction électrique puis que je le rallume. Ensuite, tout est rentré dans l'ordre et les backups se font bien à nouveau, comme c'était déjà le cas depuis longtemps... jusqu'à ce petit « oops » du 8 octobre. ;-)
Pour le memtest ça va être compliqué car je ne peux pas stopper le serveur si longtemps. C'est un vieux coucou et, de toute façon, il est en fin de vie.
