voilà, j'ai un soucis avec un process qui veux pas se faire descendre.
Ca tombe mal c'est amule.
Bon ça peut se regler par un reboot, mais c'est la premiere fois que
j'arrive pas à en tuer un.
j'ai tester differente methode dont par exemple :
sudo killall -9 amule
ou avec le PID
ou dans tty2
rien a faire.
Avez vous une piste ?
--
France-Irlande
J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande.
C'est une question d'honneur
Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé.
http://www.youtube.com/watch?v=ekxsmPnHWSA
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
Luc.Habert.00__arjf
Amandine Parmesan :
j'ai tester differente methode dont par exemple : sudo killall -9 amule ou avec le PID ou dans tty2
Si tu l'affiches avec ps, tu devrais voir un D dans la troisième colonne. Ça veut dire qu'il a un appel système en cours, qui ne veut pas se terminer. Il n'y a rien à faire. Ça peut être soit un bug du noyau, soit un problème matériel qui fait que le noyau n'arrive pas à exécuter l'appel système et bloque dessus.
Amandine Parmesan :
j'ai tester differente methode dont par exemple :
sudo killall -9 amule
ou avec le PID
ou dans tty2
Si tu l'affiches avec ps, tu devrais voir un D dans la troisième colonne. Ça
veut dire qu'il a un appel système en cours, qui ne veut pas se terminer. Il
n'y a rien à faire. Ça peut être soit un bug du noyau, soit un problème
matériel qui fait que le noyau n'arrive pas à exécuter l'appel système et
bloque dessus.
j'ai tester differente methode dont par exemple : sudo killall -9 amule ou avec le PID ou dans tty2
Si tu l'affiches avec ps, tu devrais voir un D dans la troisième colonne. Ça veut dire qu'il a un appel système en cours, qui ne veut pas se terminer. Il n'y a rien à faire. Ça peut être soit un bug du noyau, soit un problème matériel qui fait que le noyau n'arrive pas à exécuter l'appel système et bloque dessus.
Amandine Parmesan
On Wed, 23 Jun 2010 21:44:38 +0000 (UTC), (Luc Habert) wrote:
Amandine Parmesan :
j'ai tester differente methode dont par exemple : sudo killall -9 amule ou avec le PID ou dans tty2
Si tu l'affiches avec ps, tu devrais voir un D dans la troisième colonne. Ça veut dire qu'il a un appel système en cours, qui ne veut pas se terminer. Il n'y a rien à faire. Ça peut être soit un bug du noyau, soit un problème matériel qui fait que le noyau n'arrive pas à exécuter l'appel système et bloque dessus.
ps aux | grep amule moi 3763 0.0 1.1 339956 47404 pts/1 DN+ Jun23 0:26 amule
-- France-Irlande J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande. C'est une question d'honneur Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé. http://www.youtube.com/watch?v=ekxsmPnHWSA
On Wed, 23 Jun 2010 21:44:38 +0000 (UTC),
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote:
Amandine Parmesan :
j'ai tester differente methode dont par exemple :
sudo killall -9 amule
ou avec le PID
ou dans tty2
Si tu l'affiches avec ps, tu devrais voir un D dans la troisième colonne. Ça
veut dire qu'il a un appel système en cours, qui ne veut pas se terminer. Il
n'y a rien à faire. Ça peut être soit un bug du noyau, soit un problème
matériel qui fait que le noyau n'arrive pas à exécuter l'appel système et
bloque dessus.
ps aux | grep amule
moi 3763 0.0 1.1 339956 47404 pts/1 DN+ Jun23 0:26 amule
--
France-Irlande
J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande.
C'est une question d'honneur
Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé.
http://www.youtube.com/watch?v=ekxsmPnHWSA
On Wed, 23 Jun 2010 21:44:38 +0000 (UTC), (Luc Habert) wrote:
Amandine Parmesan :
j'ai tester differente methode dont par exemple : sudo killall -9 amule ou avec le PID ou dans tty2
Si tu l'affiches avec ps, tu devrais voir un D dans la troisième colonne. Ça veut dire qu'il a un appel système en cours, qui ne veut pas se terminer. Il n'y a rien à faire. Ça peut être soit un bug du noyau, soit un problème matériel qui fait que le noyau n'arrive pas à exécuter l'appel système et bloque dessus.
ps aux | grep amule moi 3763 0.0 1.1 339956 47404 pts/1 DN+ Jun23 0:26 amule
-- France-Irlande J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande. C'est une question d'honneur Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé. http://www.youtube.com/watch?v=ekxsmPnHWSA
Luc.Habert.00__arjf
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as
des options qui changent le format de sortie.
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Amandine Parmesan
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC), (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Ok merci. La prochaine fois je verifierai ca en premier. En attendant, j'ai redemarré la machine.
Et si ca se represente, je fais quoi a part rebooter ?
-- France-Irlande J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande. C'est une question d'honneur Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé. http://www.youtube.com/watch?v=ekxsmPnHWSA
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC),
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as
des options qui changent le format de sortie.
Ok merci.
La prochaine fois je verifierai ca en premier.
En attendant, j'ai redemarré la machine.
Et si ca se represente, je fais quoi a part rebooter ?
--
France-Irlande
J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande.
C'est une question d'honneur
Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé.
http://www.youtube.com/watch?v=ekxsmPnHWSA
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC), (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Ok merci. La prochaine fois je verifierai ca en premier. En attendant, j'ai redemarré la machine.
Et si ca se represente, je fais quoi a part rebooter ?
-- France-Irlande J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande. C'est une question d'honneur Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé. http://www.youtube.com/watch?v=ekxsmPnHWSA
Luc.Habert.00__arjf
Amandine Parmesan :
Et si ca se represente, je fais quoi a part rebooter ?
Je l'ai dit, il n'y a en général rien à faire. Tu peux toujours regarder sur quoi il a des fds ouvert (dans /proc/$pid/fd), ça peut donner une indication sur la cause du blocage.
Amandine Parmesan :
Et si ca se represente, je fais quoi a part rebooter ?
Je l'ai dit, il n'y a en général rien à faire. Tu peux toujours regarder sur
quoi il a des fds ouvert (dans /proc/$pid/fd), ça peut donner une indication
sur la cause du blocage.
Et si ca se represente, je fais quoi a part rebooter ?
Je l'ai dit, il n'y a en général rien à faire. Tu peux toujours regarder sur quoi il a des fds ouvert (dans /proc/$pid/fd), ça peut donner une indication sur la cause du blocage.
xtof pernod
Le 24/06/2010 21:50, Amandine Parmesan a fait rien qu'à écrire:
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC), (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Ok merci. La prochaine fois je verifierai ca en premier. En attendant, j'ai redemarré la machine.
attends, on est pas chez "La souris a bougé, le système doit être redémarré pour refléter les changements" =)
Et si ca se represente, je fais quoi a part rebooter ?
Ca: man 1 ps :
(...) nwchan WCHAN address of the kernel function where the process is sleeping (use wchan if you want the kernel function name). Running tasks will display a dash ('-') in this column.
et la commande qui donc va bien (je sais pas si ca passe en 80 col.):
:/mnt/glih/src/cd# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,wchan,comm STAT EUID RUID TT TPGID SESS PGRP PPID PID %CPU WCHAN COMMAND Ss 0 0 ? -1 1 1 0 1 0.0 poll_s init S 0 0 ? -1 0 0 0 2 0.0 kthrea kthreadd S 0 0 ? -1 0 0 2 3 0.0 migrat migration/0 S 0 0 ? -1 0 0 2 4 0.0 ksofti ksoftirqd/0 (...) S 1000 1000 pts/0 847 1850 24830 24830 26456 0.0 wait sh S 1000 1000 pts/0 847 1850 26457 26456 26457 0.0 wait bash S 1000 1000 pts/0 847 1850 26509 26457 26509 0.0 wait me S 0 0 pts/7 26677 15564 26669 15564 26669 0.0 wait su
ca donne l'appel systeme où le process est bloqué (ex: sh est simplement en attente, vraisemblablement sur un read())
Là, grep est en attente en 0x20f4bc. Bien. Un coup d'oeil sur le fichier /usr/src/linux/System.map correspondant *impérativement* au noyau en cours (certaines distros en posent un dans /boot) :
c020f330 t pipe_release c020f3e0 t pipe_rdwr_release c020f400 t pipe_write_release c020f420 t pipe_read_release c020f440 T free_write_pipe c020f470 T pipe_wait <- grep est en attente par là. c020f4e0 t pipe_write c020fa20 t pipe_read c020fe00 T alloc_pipe_info
Rien d'étonnant étant donné la commande passée.
Avec ça, tu sauras déja *où* il coince. Pour le *pourquoi* ...
-- christophe.
Le 24/06/2010 21:50, Amandine Parmesan a fait rien qu'à écrire:
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC),
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as
des options qui changent le format de sortie.
Ok merci.
La prochaine fois je verifierai ca en premier.
En attendant, j'ai redemarré la machine.
attends, on est pas chez "La souris a bougé, le système doit
être redémarré pour refléter les changements" =)
Et si ca se represente, je fais quoi a part rebooter ?
Ca: man 1 ps :
(...)
nwchan WCHAN address of the kernel function where the process is
sleeping (use wchan if you want the kernel function name).
Running tasks will display a dash ('-') in this column.
et la commande qui donc va bien (je sais pas si ca passe en 80 col.):
root@xtof-iv:/mnt/glih/src/cd# ps axo
stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,wchan,comm
STAT EUID RUID TT TPGID SESS PGRP PPID PID %CPU WCHAN COMMAND
Ss 0 0 ? -1 1 1 0 1 0.0 poll_s init
S 0 0 ? -1 0 0 0 2 0.0 kthrea kthreadd
S 0 0 ? -1 0 0 2 3 0.0 migrat migration/0
S 0 0 ? -1 0 0 2 4 0.0 ksofti ksoftirqd/0
(...)
S 1000 1000 pts/0 847 1850 24830 24830 26456 0.0 wait sh
S 1000 1000 pts/0 847 1850 26457 26456 26457 0.0 wait bash
S 1000 1000 pts/0 847 1850 26509 26457 26509 0.0 wait me
S 0 0 pts/7 26677 15564 26669 15564 26669 0.0 wait su
ca donne l'appel systeme où le process est bloqué (ex: sh est
simplement en attente, vraisemblablement sur un read())
Là, grep est en attente en 0x20f4bc. Bien. Un coup d'oeil sur le
fichier /usr/src/linux/System.map correspondant *impérativement*
au noyau en cours (certaines distros en posent un dans /boot) :
c020f330 t pipe_release
c020f3e0 t pipe_rdwr_release
c020f400 t pipe_write_release
c020f420 t pipe_read_release
c020f440 T free_write_pipe
c020f470 T pipe_wait <- grep est en attente par là.
c020f4e0 t pipe_write
c020fa20 t pipe_read
c020fe00 T alloc_pipe_info
Rien d'étonnant étant donné la commande passée.
Avec ça, tu sauras déja *où* il coince. Pour le *pourquoi* ...
Le 24/06/2010 21:50, Amandine Parmesan a fait rien qu'à écrire:
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC), (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Ok merci. La prochaine fois je verifierai ca en premier. En attendant, j'ai redemarré la machine.
attends, on est pas chez "La souris a bougé, le système doit être redémarré pour refléter les changements" =)
Et si ca se represente, je fais quoi a part rebooter ?
Ca: man 1 ps :
(...) nwchan WCHAN address of the kernel function where the process is sleeping (use wchan if you want the kernel function name). Running tasks will display a dash ('-') in this column.
et la commande qui donc va bien (je sais pas si ca passe en 80 col.):
:/mnt/glih/src/cd# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,wchan,comm STAT EUID RUID TT TPGID SESS PGRP PPID PID %CPU WCHAN COMMAND Ss 0 0 ? -1 1 1 0 1 0.0 poll_s init S 0 0 ? -1 0 0 0 2 0.0 kthrea kthreadd S 0 0 ? -1 0 0 2 3 0.0 migrat migration/0 S 0 0 ? -1 0 0 2 4 0.0 ksofti ksoftirqd/0 (...) S 1000 1000 pts/0 847 1850 24830 24830 26456 0.0 wait sh S 1000 1000 pts/0 847 1850 26457 26456 26457 0.0 wait bash S 1000 1000 pts/0 847 1850 26509 26457 26509 0.0 wait me S 0 0 pts/7 26677 15564 26669 15564 26669 0.0 wait su
ca donne l'appel systeme où le process est bloqué (ex: sh est simplement en attente, vraisemblablement sur un read())
Là, grep est en attente en 0x20f4bc. Bien. Un coup d'oeil sur le fichier /usr/src/linux/System.map correspondant *impérativement* au noyau en cours (certaines distros en posent un dans /boot) :
c020f330 t pipe_release c020f3e0 t pipe_rdwr_release c020f400 t pipe_write_release c020f420 t pipe_read_release c020f440 T free_write_pipe c020f470 T pipe_wait <- grep est en attente par là. c020f4e0 t pipe_write c020fa20 t pipe_read c020fe00 T alloc_pipe_info
Rien d'étonnant étant donné la commande passée.
Avec ça, tu sauras déja *où* il coince. Pour le *pourquoi* ...
-- christophe.
Amandine Parmesan
On Fri, 25 Jun 2010 09:21:03 +0200, xtof pernod wrote:
Le 24/06/2010 21:50, Amandine Parmesan a fait rien qu'à écrire:
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC), (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Ok merci. La prochaine fois je verifierai ca en premier. En attendant, j'ai redemarré la machine.
attends, on est pas chez "La souris a bougé, le système doit être redémarré pour refléter les changements" =)
Et si ca se represente, je fais quoi a part rebooter ?
Ca: man 1 ps :
(...) nwchan WCHAN address of the kernel function where the process is sleeping (use wchan if you want the kernel function name). Running tasks will display a dash ('-') in this column.
et la commande qui donc va bien (je sais pas si ca passe en 80 col.):
:/mnt/glih/src/cd# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,wchan,comm STAT EUID RUID TT TPGID SESS PGRP PPID PID %CPU WCHAN COMMAND Ss 0 0 ? -1 1 1 0 1 0.0 poll_s init S 0 0 ? -1 0 0 0 2 0.0 kthrea kthreadd S 0 0 ? -1 0 0 2 3 0.0 migrat migration/0 S 0 0 ? -1 0 0 2 4 0.0 ksofti ksoftirqd/0 (...) S 1000 1000 pts/0 847 1850 24830 24830 26456 0.0 wait sh S 1000 1000 pts/0 847 1850 26457 26456 26457 0.0 wait bash S 1000 1000 pts/0 847 1850 26509 26457 26509 0.0 wait me S 0 0 pts/7 26677 15564 26669 15564 26669 0.0 wait su
ca donne l'appel systeme où le process est bloqué (ex: sh est simplement en attente, vraisemblablement sur un read())
Là, grep est en attente en 0x20f4bc. Bien. Un coup d'oeil sur le fichier /usr/src/linux/System.map correspondant *impérativement* au noyau en cours (certaines distros en posent un dans /boot) :
c020f330 t pipe_release c020f3e0 t pipe_rdwr_release c020f400 t pipe_write_release c020f420 t pipe_read_release c020f440 T free_write_pipe c020f470 T pipe_wait <- grep est en attente par là. c020f4e0 t pipe_write c020fa20 t pipe_read c020fe00 T alloc_pipe_info
Rien d'étonnant étant donné la commande passée.
Avec ça, tu sauras déja *où* il coince. Pour le *pourquoi* ...
Ok, merci. J'archive.
-- France-Irlande J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande. C'est une question d'honneur Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé. http://www.youtube.com/watch?v=ekxsmPnHWSA
On Fri, 25 Jun 2010 09:21:03 +0200, xtof pernod
<xtof.pernod@N0SPAM.free.fr> wrote:
Le 24/06/2010 21:50, Amandine Parmesan a fait rien qu'à écrire:
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC),
Luc.Habert.00__arjf@normalesup.org (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as
des options qui changent le format de sortie.
Ok merci.
La prochaine fois je verifierai ca en premier.
En attendant, j'ai redemarré la machine.
attends, on est pas chez "La souris a bougé, le système doit
être redémarré pour refléter les changements" =)
Et si ca se represente, je fais quoi a part rebooter ?
Ca: man 1 ps :
(...)
nwchan WCHAN address of the kernel function where the process is
sleeping (use wchan if you want the kernel function name).
Running tasks will display a dash ('-') in this column.
et la commande qui donc va bien (je sais pas si ca passe en 80 col.):
root@xtof-iv:/mnt/glih/src/cd# ps axo
stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,wchan,comm
STAT EUID RUID TT TPGID SESS PGRP PPID PID %CPU WCHAN COMMAND
Ss 0 0 ? -1 1 1 0 1 0.0 poll_s init
S 0 0 ? -1 0 0 0 2 0.0 kthrea kthreadd
S 0 0 ? -1 0 0 2 3 0.0 migrat migration/0
S 0 0 ? -1 0 0 2 4 0.0 ksofti ksoftirqd/0
(...)
S 1000 1000 pts/0 847 1850 24830 24830 26456 0.0 wait sh
S 1000 1000 pts/0 847 1850 26457 26456 26457 0.0 wait bash
S 1000 1000 pts/0 847 1850 26509 26457 26509 0.0 wait me
S 0 0 pts/7 26677 15564 26669 15564 26669 0.0 wait su
ca donne l'appel systeme où le process est bloqué (ex: sh est
simplement en attente, vraisemblablement sur un read())
Là, grep est en attente en 0x20f4bc. Bien. Un coup d'oeil sur le
fichier /usr/src/linux/System.map correspondant *impérativement*
au noyau en cours (certaines distros en posent un dans /boot) :
c020f330 t pipe_release
c020f3e0 t pipe_rdwr_release
c020f400 t pipe_write_release
c020f420 t pipe_read_release
c020f440 T free_write_pipe
c020f470 T pipe_wait <- grep est en attente par là.
c020f4e0 t pipe_write
c020fa20 t pipe_read
c020fe00 T alloc_pipe_info
Rien d'étonnant étant donné la commande passée.
Avec ça, tu sauras déja *où* il coince. Pour le *pourquoi* ...
Ok, merci.
J'archive.
--
France-Irlande
J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande.
C'est une question d'honneur
Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé.
http://www.youtube.com/watch?v=ekxsmPnHWSA
On Fri, 25 Jun 2010 09:21:03 +0200, xtof pernod wrote:
Le 24/06/2010 21:50, Amandine Parmesan a fait rien qu'à écrire:
On Thu, 24 Jun 2010 19:31:46 +0000 (UTC), (Luc Habert) wrote:
Tu as bien un « D », pas dans la colonne que j'ai indiquée, parce que tu as des options qui changent le format de sortie.
Ok merci. La prochaine fois je verifierai ca en premier. En attendant, j'ai redemarré la machine.
attends, on est pas chez "La souris a bougé, le système doit être redémarré pour refléter les changements" =)
Et si ca se represente, je fais quoi a part rebooter ?
Ca: man 1 ps :
(...) nwchan WCHAN address of the kernel function where the process is sleeping (use wchan if you want the kernel function name). Running tasks will display a dash ('-') in this column.
et la commande qui donc va bien (je sais pas si ca passe en 80 col.):
:/mnt/glih/src/cd# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,wchan,comm STAT EUID RUID TT TPGID SESS PGRP PPID PID %CPU WCHAN COMMAND Ss 0 0 ? -1 1 1 0 1 0.0 poll_s init S 0 0 ? -1 0 0 0 2 0.0 kthrea kthreadd S 0 0 ? -1 0 0 2 3 0.0 migrat migration/0 S 0 0 ? -1 0 0 2 4 0.0 ksofti ksoftirqd/0 (...) S 1000 1000 pts/0 847 1850 24830 24830 26456 0.0 wait sh S 1000 1000 pts/0 847 1850 26457 26456 26457 0.0 wait bash S 1000 1000 pts/0 847 1850 26509 26457 26509 0.0 wait me S 0 0 pts/7 26677 15564 26669 15564 26669 0.0 wait su
ca donne l'appel systeme où le process est bloqué (ex: sh est simplement en attente, vraisemblablement sur un read())
Là, grep est en attente en 0x20f4bc. Bien. Un coup d'oeil sur le fichier /usr/src/linux/System.map correspondant *impérativement* au noyau en cours (certaines distros en posent un dans /boot) :
c020f330 t pipe_release c020f3e0 t pipe_rdwr_release c020f400 t pipe_write_release c020f420 t pipe_read_release c020f440 T free_write_pipe c020f470 T pipe_wait <- grep est en attente par là. c020f4e0 t pipe_write c020fa20 t pipe_read c020fe00 T alloc_pipe_info
Rien d'étonnant étant donné la commande passée.
Avec ça, tu sauras déja *où* il coince. Pour le *pourquoi* ...
Ok, merci. J'archive.
-- France-Irlande J'ai pas honte d'être francaise, mais j'aimerai être fiere en laissant notre place à l'Irlande. C'est une question d'honneur Mais je ne me fais aucune illusion. J'espère que l'equipe qui a volé le match soit humilié et rentre la tête baissé. http://www.youtube.com/watch?v=ekxsmPnHWSA
