J'essaie de télécharger un très gros fichier (1 gigo et des brouettes)
avec wget et il plante parfois en cours de route.
Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou
killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
n.
Noyau 2.4.26-1-k7
Sarge à jour
PS : les programmes à base de xine plantent au démarrage sans
explication (dans la console), il n'y a aucun rapport mais c'est relou.
Qui a une idée ?
--
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
Sylvain
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote :
Bonjour,
Salut,
J'essaie de télécharger un très gros fichier (1 gigo et des brouettes) avec wget et il plante parfois en cours de route. Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou killall -9 ne marchent pas, que je sois root ou pas.
Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut que tu recupere le PID du père avec ps auxf, les processes seront sous forme d'arborescence, tu remonte a la racine et tu as le papa :)
C'est un bugue du noyau ou quoi ? Qui a une idée ?
je ne pense pas ...
n.
Noyau 2.4.26-1-k7 Sarge à jour
PS : les programmes à base de xine plantent au démarrage sans explication (dans la console), il n'y a aucun rapport mais c'est relou. Qui a une idée ?
? nope :)
Sylvain -- Gravity is a myth, the Earth sucks.
-- 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
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote :
Bonjour,
Salut,
J'essaie de télécharger un très gros fichier (1 gigo et des brouettes)
avec wget et il plante parfois en cours de route.
Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou
killall -9 ne marchent pas, que je sois root ou pas.
Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut
que tu recupere le PID du père avec ps auxf, les processes seront sous
forme d'arborescence, tu remonte a la racine et tu as le papa :)
C'est un bugue du noyau ou quoi ? Qui a une idée ?
je ne pense pas ...
n.
Noyau 2.4.26-1-k7
Sarge à jour
PS : les programmes à base de xine plantent au démarrage sans
explication (dans la console), il n'y a aucun rapport mais c'est relou.
Qui a une idée ?
? nope :)
Sylvain
--
Gravity is a myth, the Earth sucks.
--
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
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote :
Bonjour,
Salut,
J'essaie de télécharger un très gros fichier (1 gigo et des brouettes) avec wget et il plante parfois en cours de route. Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou killall -9 ne marchent pas, que je sois root ou pas.
Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut que tu recupere le PID du père avec ps auxf, les processes seront sous forme d'arborescence, tu remonte a la racine et tu as le papa :)
C'est un bugue du noyau ou quoi ? Qui a une idée ?
je ne pense pas ...
n.
Noyau 2.4.26-1-k7 Sarge à jour
PS : les programmes à base de xine plantent au démarrage sans explication (dans la console), il n'y a aucun rapport mais c'est relou. Qui a une idée ?
? nope :)
Sylvain -- Gravity is a myth, the Earth sucks.
-- 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
François Boisson
On Tue, 06 Jul 2004 18:19:08 +0200 nicolas wrote:
Bonjour,
J'essaie de télécharger un très gros fichier (1 gigo et des brouett es) avec wget et il plante parfois en cours de route. Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
Le seul exemple de processus intuable que j'ai rencontré est lorsque le processus n'arrive pas a fermer ses flux d'entrées/sorties, il est dans un état "D" mais toujours apparent tant que les entrées sorties sont toujo urs ouvertes, le processus lui même ne tourne plus. L'exemple typique est le cas d'une clé USB gelée et un sync lancé derrière.
François Boisson
On Tue, 06 Jul 2004 18:19:08 +0200
nicolas <nicolas.patrois@online.fr> wrote:
Bonjour,
J'essaie de télécharger un très gros fichier (1 gigo et des brouett es)
avec wget et il plante parfois en cours de route.
Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9
ou killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
Le seul exemple de processus intuable que j'ai rencontré est lorsque le
processus n'arrive pas a fermer ses flux d'entrées/sorties, il est dans un
état "D" mais toujours apparent tant que les entrées sorties sont toujo urs
ouvertes, le processus lui même ne tourne plus. L'exemple typique est le
cas d'une clé USB gelée et un sync lancé derrière.
J'essaie de télécharger un très gros fichier (1 gigo et des brouett es) avec wget et il plante parfois en cours de route. Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
Le seul exemple de processus intuable que j'ai rencontré est lorsque le processus n'arrive pas a fermer ses flux d'entrées/sorties, il est dans un état "D" mais toujours apparent tant que les entrées sorties sont toujo urs ouvertes, le processus lui même ne tourne plus. L'exemple typique est le cas d'une clé USB gelée et un sync lancé derrière.
François Boisson
fra-duf-no-spam
Le 12605ième jour après Epoch, François Boisson écrivait:
On Tue, 06 Jul 2004 18:19:08 +0200 nicolas wrote:
Bonjour,
J'essaie de télécharger un très gros fichier (1 gigo et des brouettes) avec wget et il plante parfois en cours de route. Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
Le seul exemple de processus intuable que j'ai rencontré est lorsque le processus n'arrive pas a fermer ses flux d'entrées/sorties, il est dans un état "D" mais toujours apparent tant que les entrées sorties sont toujours ouvertes, le processus lui même ne tourne plus. L'exemple typique est le cas d'une clé USB gelée et un sync lancé derrière.
Effectivement. Le principe est qu'un process qui est dans une action noyau (read, write, etc.) ne peut pas disparaître tant que l'I/O n'est pas terminée.
Il ne reste quand même que l'entrée dans la table des processes, donc ça prends pas de place (sauf dans la table en question bien sûr).
C'est pas trop grave, en général. Sauf si les processes sont nombreux à faire ce genre d'erreurs.
-- 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
Le 12605ième jour après Epoch,
François Boisson écrivait:
On Tue, 06 Jul 2004 18:19:08 +0200
nicolas <nicolas.patrois@online.fr> wrote:
Bonjour,
J'essaie de télécharger un très gros fichier (1 gigo et des brouettes)
avec wget et il plante parfois en cours de route.
Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9
ou killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
Le seul exemple de processus intuable que j'ai rencontré est lorsque le
processus n'arrive pas a fermer ses flux d'entrées/sorties, il est dans un
état "D" mais toujours apparent tant que les entrées sorties sont toujours
ouvertes, le processus lui même ne tourne plus. L'exemple typique est le
cas d'une clé USB gelée et un sync lancé derrière.
Effectivement. Le principe est qu'un process qui est dans une action
noyau (read, write, etc.) ne peut pas disparaître tant que l'I/O n'est
pas terminée.
Il ne reste quand même que l'entrée dans la table des processes, donc
ça prends pas de place (sauf dans la table en question bien sûr).
C'est pas trop grave, en général. Sauf si les processes sont nombreux
à faire ce genre d'erreurs.
--
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
Le 12605ième jour après Epoch, François Boisson écrivait:
On Tue, 06 Jul 2004 18:19:08 +0200 nicolas wrote:
Bonjour,
J'essaie de télécharger un très gros fichier (1 gigo et des brouettes) avec wget et il plante parfois en cours de route. Il vient de planter cet après-midi et je ne peux plus le tuer. kill -9 ou killall -9 ne marchent pas, que je sois root ou pas.
C'est un bugue du noyau ou quoi ? Qui a une idée ?
Le seul exemple de processus intuable que j'ai rencontré est lorsque le processus n'arrive pas a fermer ses flux d'entrées/sorties, il est dans un état "D" mais toujours apparent tant que les entrées sorties sont toujours ouvertes, le processus lui même ne tourne plus. L'exemple typique est le cas d'une clé USB gelée et un sync lancé derrière.
Effectivement. Le principe est qu'un process qui est dans une action noyau (read, write, etc.) ne peut pas disparaître tant que l'I/O n'est pas terminée.
Il ne reste quand même que l'entrée dans la table des processes, donc ça prends pas de place (sauf dans la table en question bien sûr).
C'est pas trop grave, en général. Sauf si les processes sont nombreux à faire ce genre d'erreurs.
-- 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
Gurvan Huiban
On Tuesday 06 July 2004 17:26, François TOURDE wrote:
> Le seul exemple de processus intuable que j'ai rencontré est lorsque le > processus n'arrive pas a fermer ses flux d'entrées/sorties, il est da ns > un état "D" mais toujours apparent tant que les entrées sorties sont > toujours ouvertes, le processus lui même ne tourne plus. L'exemple > typique est le cas d'une clé USB gelée et un sync lancé derrièr e.
Effectivement. Le principe est qu'un process qui est dans une action noyau (read, write, etc.) ne peut pas disparaître tant que l'I/O n'est pas terminée.
Il ne reste quand même que l'entrée dans la table des processes, donc ça prends pas de place (sauf dans la table en question bien sûr).
C'est pas trop grave, en général. Sauf si les processes sont nombreux à faire ce genre d'erreurs.
Ça reste quand même parfois pénible; par exemple quand c'est du a un CD foireux qui continue de tourner jusqu'a la fin de l'éternité (bruit + b loquer le lecteur CD + je ne crois pas que ce soit très bon pour le lecteur ou m ême pour le CD).
Ou, en d'autres termes, existe-t-il un moyen de "tuer" (fermer?) l'I/O d'un processus?
"What about a nice cup of coffee?" (self-citation)
On Tuesday 06 July 2004 17:26, François TOURDE wrote:
> Le seul exemple de processus intuable que j'ai rencontré est lorsque le
> processus n'arrive pas a fermer ses flux d'entrées/sorties, il est da ns
> un état "D" mais toujours apparent tant que les entrées sorties sont
> toujours ouvertes, le processus lui même ne tourne plus. L'exemple
> typique est le cas d'une clé USB gelée et un sync lancé derrièr e.
Effectivement. Le principe est qu'un process qui est dans une action
noyau (read, write, etc.) ne peut pas disparaître tant que l'I/O n'est
pas terminée.
Il ne reste quand même que l'entrée dans la table des processes, donc
ça prends pas de place (sauf dans la table en question bien sûr).
C'est pas trop grave, en général. Sauf si les processes sont nombreux
à faire ce genre d'erreurs.
Ça reste quand même parfois pénible; par exemple quand c'est du a un CD
foireux qui continue de tourner jusqu'a la fin de l'éternité (bruit + b loquer
le lecteur CD + je ne crois pas que ce soit très bon pour le lecteur ou m ême
pour le CD).
Ou, en d'autres termes, existe-t-il un moyen de "tuer" (fermer?) l'I/O d'un
processus?
On Tuesday 06 July 2004 17:26, François TOURDE wrote:
> Le seul exemple de processus intuable que j'ai rencontré est lorsque le > processus n'arrive pas a fermer ses flux d'entrées/sorties, il est da ns > un état "D" mais toujours apparent tant que les entrées sorties sont > toujours ouvertes, le processus lui même ne tourne plus. L'exemple > typique est le cas d'une clé USB gelée et un sync lancé derrièr e.
Effectivement. Le principe est qu'un process qui est dans une action noyau (read, write, etc.) ne peut pas disparaître tant que l'I/O n'est pas terminée.
Il ne reste quand même que l'entrée dans la table des processes, donc ça prends pas de place (sauf dans la table en question bien sûr).
C'est pas trop grave, en général. Sauf si les processes sont nombreux à faire ce genre d'erreurs.
Ça reste quand même parfois pénible; par exemple quand c'est du a un CD foireux qui continue de tourner jusqu'a la fin de l'éternité (bruit + b loquer le lecteur CD + je ne crois pas que ce soit très bon pour le lecteur ou m ême pour le CD).
Ou, en d'autres termes, existe-t-il un moyen de "tuer" (fermer?) l'I/O d'un processus?
"What about a nice cup of coffee?" (self-citation)
fra-duf-no-spam
Le 12606ième jour après Epoch, Gurvan Huiban écrivait:
On Tuesday 06 July 2004 17:26, François TOURDE wrote:
C'est pas trop grave, en général. Sauf si les processes sont nombreux à faire ce genre d'erreurs.
Ça reste quand même parfois pénible; par exemple quand c'est du a un CD foireux qui continue de tourner jusqu'a la fin de l'éternité (bruit + bloquer le lecteur CD + je ne crois pas que ce soit très bon pour le lecteur ou même pour le CD).
C'est clair. J'ai dû faire un power-off brutal lors de ma dernière tentative d'overburn sur CD, et j'avoue que ça m'a un peu gonflé. Mais je ne pense pas qu'il y ait de solution propre. Si il y a, je suis preneur :)
Ce genre de blocage de process m'arrive une fois par décénie, mais quand ça arrive c'est au pire moment ;)
-- "I'd love to go out with you, but there are important world issues that need worrying about."
-- 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
Le 12606ième jour après Epoch,
Gurvan Huiban écrivait:
On Tuesday 06 July 2004 17:26, François TOURDE wrote:
C'est pas trop grave, en général. Sauf si les processes sont nombreux
à faire ce genre d'erreurs.
Ça reste quand même parfois pénible; par exemple quand c'est du a un CD
foireux qui continue de tourner jusqu'a la fin de l'éternité (bruit + bloquer
le lecteur CD + je ne crois pas que ce soit très bon pour le lecteur ou même
pour le CD).
C'est clair. J'ai dû faire un power-off brutal lors de ma dernière
tentative d'overburn sur CD, et j'avoue que ça m'a un peu gonflé. Mais
je ne pense pas qu'il y ait de solution propre. Si il y a, je suis
preneur :)
Ce genre de blocage de process m'arrive une fois par décénie, mais
quand ça arrive c'est au pire moment ;)
--
"I'd love to go out with you, but there are important world issues that
need worrying about."
--
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
Le 12606ième jour après Epoch, Gurvan Huiban écrivait:
On Tuesday 06 July 2004 17:26, François TOURDE wrote:
C'est pas trop grave, en général. Sauf si les processes sont nombreux à faire ce genre d'erreurs.
Ça reste quand même parfois pénible; par exemple quand c'est du a un CD foireux qui continue de tourner jusqu'a la fin de l'éternité (bruit + bloquer le lecteur CD + je ne crois pas que ce soit très bon pour le lecteur ou même pour le CD).
C'est clair. J'ai dû faire un power-off brutal lors de ma dernière tentative d'overburn sur CD, et j'avoue que ça m'a un peu gonflé. Mais je ne pense pas qu'il y ait de solution propre. Si il y a, je suis preneur :)
Ce genre de blocage de process m'arrive une fois par décénie, mais quand ça arrive c'est au pire moment ;)
-- "I'd love to go out with you, but there are important world issues that need worrying about."
-- 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
nicolas
Le Tue, 06 Jul 2004 20:40:14 +0200, Sylvain a écrit :
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote : Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut que tu recupere le PID du père avec ps auxf, les processes seront sous forme d'arborescence, tu remonte a la racine et tu as le papa :)
Le processus père est init. :-)
n.
-- 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
Le Tue, 06 Jul 2004 20:40:14 +0200, Sylvain a écrit :
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote :
Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut
que tu recupere le PID du père avec ps auxf, les processes seront sous
forme d'arborescence, tu remonte a la racine et tu as le papa :)
Le processus père est init. :-)
n.
--
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
Le Tue, 06 Jul 2004 20:40:14 +0200, Sylvain a écrit :
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote : Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut que tu recupere le PID du père avec ps auxf, les processes seront sous forme d'arborescence, tu remonte a la racine et tu as le papa :)
Le processus père est init. :-)
n.
-- 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
fra-duf-no-spam
Le 12606ième jour après Epoch, écrivait:
Le Tue, 06 Jul 2004 20:40:14 +0200, Sylvain a écrit :
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote : Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut que tu recupere le PID du père avec ps auxf, les processes seront sous forme d'arborescence, tu remonte a la racine et tu as le papa :)
Le processus père est init. :-)
Alors tant mieux :)
Le gentil init récupère la paternité des processes orphelins (une vraie mère poule, cet init), de façon à pouvoir débarasser le noyau des traces pouvant rester après l'arrêt du programme.
Dans ce cas, il ne restera plus de zombies. Par contre, le programme *doit* se terminer. Si il reste bloqué sur une IO, alors il y a problème. Il faut attendre que l'IO finisse en timeout. Un read bloquant sur un pipe ou un fichier peut poser le problème. Dans ce cas, il faut utiliser des trucs comme lsof ou regarder dans /proc/<pid>/fd pour prendre les mesures nécessaires.
-- "Here comes Mr. Bill's dog." -- Narrator, Saturday Night Live
-- 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
Le 12606ième jour après Epoch,
nicolas.patrois@online.fr écrivait:
Le Tue, 06 Jul 2004 20:40:14 +0200, Sylvain a écrit :
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote :
Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut
que tu recupere le PID du père avec ps auxf, les processes seront sous
forme d'arborescence, tu remonte a la racine et tu as le papa :)
Le processus père est init. :-)
Alors tant mieux :)
Le gentil init récupère la paternité des processes orphelins (une
vraie mère poule, cet init), de façon à pouvoir débarasser le noyau
des traces pouvant rester après l'arrêt du programme.
Dans ce cas, il ne restera plus de zombies. Par contre, le programme
*doit* se terminer. Si il reste bloqué sur une IO, alors il y a
problème. Il faut attendre que l'IO finisse en timeout. Un read
bloquant sur un pipe ou un fichier peut poser le problème. Dans ce
cas, il faut utiliser des trucs comme lsof ou regarder dans
/proc/<pid>/fd pour prendre les mesures nécessaires.
--
"Here comes Mr. Bill's dog."
-- Narrator, Saturday Night Live
--
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
Le Tue, 06 Jul 2004 20:40:14 +0200, Sylvain a écrit :
On Tue, Jul 06, 2004 at 06:19:08PM +0200, nicolas wrote : Generalement, le fait de tuer le processus 'père' fonctionne. Donc il faut que tu recupere le PID du père avec ps auxf, les processes seront sous forme d'arborescence, tu remonte a la racine et tu as le papa :)
Le processus père est init. :-)
Alors tant mieux :)
Le gentil init récupère la paternité des processes orphelins (une vraie mère poule, cet init), de façon à pouvoir débarasser le noyau des traces pouvant rester après l'arrêt du programme.
Dans ce cas, il ne restera plus de zombies. Par contre, le programme *doit* se terminer. Si il reste bloqué sur une IO, alors il y a problème. Il faut attendre que l'IO finisse en timeout. Un read bloquant sur un pipe ou un fichier peut poser le problème. Dans ce cas, il faut utiliser des trucs comme lsof ou regarder dans /proc/<pid>/fd pour prendre les mesures nécessaires.
-- "Here comes Mr. Bill's dog." -- Narrator, Saturday Night Live
-- 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
