et ça quasiment tous les matins. Ce n'est pas toujours le même binaire
des fois c'est apache, des fois c'est exim. A chaque fois, ça plante
vers 3h10 du matin.
Ma question :
Comment savoir ce qui ce passe, comment killer ce process sans rebooter
la machine ? je suis en sarge à jour. kernel debian 2.6.8.
--
Thomas Clavier http://www.tcweb.org
Lille Sans Fil http://www.lillesansfil.org
+33 (0)6 20 81 81 30 JabberID : tom@jabber.tcweb.org
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jonathan ILIAS
Thomas Clavier wrote:
Ma question : Comment savoir ce qui ce passe, comment killer ce process sans rebooter la machine ? je suis en sarge à jour. kernel debian 2.6.8.
Je ne vois qu'une seule raison (mais je ne sais pas tout ;) ) qui puisse rendre impossible de tuer un processus : le fait que celui-ci soit en mode noyau (puisque les signaux sont reçus lorsqu'un processus "sort" d u noyau).
Si c'est bien cela, c'est au niveau du noyau voire plutôt du matériel qu'il faut chercher l'origine du problème. Au pif, je suspecterai la RA M ou un disque dur...
-- Jonathan ILIAS
Thomas Clavier wrote:
Ma question :
Comment savoir ce qui ce passe, comment killer ce process sans rebooter
la machine ? je suis en sarge à jour. kernel debian 2.6.8.
Je ne vois qu'une seule raison (mais je ne sais pas tout ;) ) qui puisse
rendre impossible de tuer un processus : le fait que celui-ci soit en
mode noyau (puisque les signaux sont reçus lorsqu'un processus "sort" d u
noyau).
Si c'est bien cela, c'est au niveau du noyau voire plutôt du matériel
qu'il faut chercher l'origine du problème. Au pif, je suspecterai la RA M
ou un disque dur...
Ma question : Comment savoir ce qui ce passe, comment killer ce process sans rebooter la machine ? je suis en sarge à jour. kernel debian 2.6.8.
Je ne vois qu'une seule raison (mais je ne sais pas tout ;) ) qui puisse rendre impossible de tuer un processus : le fait que celui-ci soit en mode noyau (puisque les signaux sont reçus lorsqu'un processus "sort" d u noyau).
Si c'est bien cela, c'est au niveau du noyau voire plutôt du matériel qu'il faut chercher l'origine du problème. Au pif, je suspecterai la RA M ou un disque dur...
-- Jonathan ILIAS
yoann
Jonathan ILIAS wrote:
Thomas Clavier wrote:
Ma question : Comment savoir ce qui ce passe, comment killer ce process sans rebooter la machine ? je suis en sarge à jour. kernel debian 2.6.8.
Je ne vois qu'une seule raison (mais je ne sais pas tout ;) ) qui puisse rendre impossible de tuer un processus : le fait que celui-ci soit en mode noyau (puisque les signaux sont reçus lorsqu'un processus "sort" du noyau).
Si c'est bien cela, c'est au niveau du noyau voire plutôt du matériel qu'il faut chercher l'origine du problème. Au pif, je suspecterai la RAM ou un disque dur...
regarde au niveau ce cron s'il y a pas un logrotate qui supprime le fichier de log, parce que 3h10 ça correspond au heure par défaut de logrotate il me semble. Ça peut venir du venir du fait que le processus incriminé est en attente d'un accès à un device (file descriptor - fd -sur le fichier de log) qui a surement du être déplacé/compressé par le logrotate. Résultat, le fd pointe null part et ça mets en pannique le processus.
la solution serai soit de supprimé le logrotate sur les services qui posent problème pour voir si ça vient bien de là et ensuite faire des testes et regarder les fd (lsof et netstat sont tes amis je pense) quand ils sont plantés.
au niveau du kill, il me semble (à confirmé) qu'un processus qui est bloqué sur un accès disque ne peut être tuer par un kill -9, les seuls solutions de le tuer à ma connaissance, c'est soit de lui rendre son device pour qu'il sorte du mode noyau, soit rebooter la machine
en espérant que ça éclaire ta lanterne
Yoann
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jonathan ILIAS wrote:
Thomas Clavier wrote:
Ma question :
Comment savoir ce qui ce passe, comment killer ce process sans rebooter
la machine ? je suis en sarge à jour. kernel debian 2.6.8.
Je ne vois qu'une seule raison (mais je ne sais pas tout ;) ) qui puisse
rendre impossible de tuer un processus : le fait que celui-ci soit en
mode noyau (puisque les signaux sont reçus lorsqu'un processus "sort" du
noyau).
Si c'est bien cela, c'est au niveau du noyau voire plutôt du matériel
qu'il faut chercher l'origine du problème. Au pif, je suspecterai la RAM
ou un disque dur...
regarde au niveau ce cron s'il y a pas un logrotate qui supprime le fichier de
log, parce que 3h10 ça correspond au heure par défaut de logrotate il me semble.
Ça peut venir du venir du fait que le processus incriminé est en attente d'un
accès à un device (file descriptor - fd -sur le fichier de log) qui a surement
du être déplacé/compressé par le logrotate. Résultat, le fd pointe null part et
ça mets en pannique le processus.
la solution serai soit de supprimé le logrotate sur les services qui posent
problème pour voir si ça vient bien de là et ensuite faire des testes et
regarder les fd (lsof et netstat sont tes amis je pense) quand ils sont plantés.
au niveau du kill, il me semble (à confirmé) qu'un processus qui est bloqué sur
un accès disque ne peut être tuer par un kill -9, les seuls solutions de le tuer
à ma connaissance, c'est soit de lui rendre son device pour qu'il sorte du mode
noyau, soit rebooter la machine
en espérant que ça éclaire ta lanterne
Yoann
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Ma question : Comment savoir ce qui ce passe, comment killer ce process sans rebooter la machine ? je suis en sarge à jour. kernel debian 2.6.8.
Je ne vois qu'une seule raison (mais je ne sais pas tout ;) ) qui puisse rendre impossible de tuer un processus : le fait que celui-ci soit en mode noyau (puisque les signaux sont reçus lorsqu'un processus "sort" du noyau).
Si c'est bien cela, c'est au niveau du noyau voire plutôt du matériel qu'il faut chercher l'origine du problème. Au pif, je suspecterai la RAM ou un disque dur...
regarde au niveau ce cron s'il y a pas un logrotate qui supprime le fichier de log, parce que 3h10 ça correspond au heure par défaut de logrotate il me semble. Ça peut venir du venir du fait que le processus incriminé est en attente d'un accès à un device (file descriptor - fd -sur le fichier de log) qui a surement du être déplacé/compressé par le logrotate. Résultat, le fd pointe null part et ça mets en pannique le processus.
la solution serai soit de supprimé le logrotate sur les services qui posent problème pour voir si ça vient bien de là et ensuite faire des testes et regarder les fd (lsof et netstat sont tes amis je pense) quand ils sont plantés.
au niveau du kill, il me semble (à confirmé) qu'un processus qui est bloqué sur un accès disque ne peut être tuer par un kill -9, les seuls solutions de le tuer à ma connaissance, c'est soit de lui rendre son device pour qu'il sorte du mode noyau, soit rebooter la machine
en espérant que ça éclaire ta lanterne
Yoann
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Thomas CLavier
yoann a écrit :
regarde au niveau ce cron s'il y a pas un logrotate qui supprime le fic hier de log, parce que 3h10 ça correspond au heure par défaut de logrotate il me semble.
j'y avait pensé, mais comme c'est jamais le même process qui plante, j'avais écarté l'hypothèse.
Je vais retesté ça.
en espérant que ça éclaire ta lanterne
Merci.
-- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
yoann a écrit :
regarde au niveau ce cron s'il y a pas un logrotate qui supprime le fic hier de
log, parce que 3h10 ça correspond au heure par défaut de logrotate il me semble.
j'y avait pensé, mais comme c'est jamais le même process qui plante,
j'avais écarté l'hypothèse.
Je vais retesté ça.
en espérant que ça éclaire ta lanterne
Merci.
--
Thomas Clavier http://www.tcweb.org
Lille Sans Fil http://www.lillesansfil.org
+33 (0)6 20 81 81 30
regarde au niveau ce cron s'il y a pas un logrotate qui supprime le fic hier de log, parce que 3h10 ça correspond au heure par défaut de logrotate il me semble.
j'y avait pensé, mais comme c'est jamais le même process qui plante, j'avais écarté l'hypothèse.
Je vais retesté ça.
en espérant que ça éclaire ta lanterne
Merci.
-- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30
