[ Defunct ] Comment éviter les zombies après un *fork -> execl*

Comment éviter les zombies après un *fork -> execl* [ Defunct ] - C - Programmation

Marsh Posté le 13-11-2004 à 14:16:21    

J'ai ça dans mon code :

Code :
  1. if (!fork())
  2.              if ( execl( "/bin/mount", "mount", chemin, NULL ) ) warn("Erreur lors du montage" );
  3.              else wait(&status);


 
une fois le montage effectué, le mount devient zombie et ne meurt donc pas tant que je ne tue pas le père ... il me semblait qu'un wait était suffisant, j'ai oublié quelque chose ?
le tout sous linux, je vois donc le defunct avec ps


Message édité par udok le 13-11-2004 à 14:17:45

---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 14:16:21   

Reply

Marsh Posté le 13-11-2004 à 14:32:45    

Je suis pas certain de moi, mais il me semble que quand un processus passe à l'état zombie, il y a émission d'un signal SIGCHLD.
 
Normalement si t'arme le signal SIGCHLD dans le processus père et que tu met un wait(NULL) dans le handler ca devrait marcher


Message édité par Diody le 13-11-2004 à 14:33:29
Reply

Marsh Posté le 13-11-2004 à 14:34:42    

pourquoi tu fais ça en C ?
s'il est defunct, c'est qu'il est mort, y a pas de quoi s'inquiéter ... t'es sur d'avoir besoin du fork au moins ? t'as regardé le status ? est-ce que tu fais plusieur fork dans ton père ?

Reply

Marsh Posté le 13-11-2004 à 14:49:13    

Diody a écrit :

Je suis pas certain de moi, mais il me semble que quand un processus passe à l'état zombie, il y a émission d'un signal SIGCHLD.
 
Normalement si t'arme le signal SIGCHLD dans le processus père et que tu met un wait(NULL) dans le handler ca devrait marcher


 
pour la premier phrase je sais, j'ai lu le man de fork()
pour la deuxieme phrase j'ai pas tout compris [:cupra]
qu'entends tu par armer le sigchild
c'est quoi le handler
pourquoi ce que j'ai fait ne suffit pas ?


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 14:54:50    

Taz a écrit :

pourquoi tu fais ça en C ?


parce qu'il n'y a pas que ça dans mon programme :
http://forum.hardware.fr/hardwaref [...] tm#t589003
(comme ça tu as tous les éléments en main :o)
 

Taz a écrit :

s'il est defunct, c'est qu'il est mort, y a pas de quoi s'inquiéter ...


ouai m'enfin c'est pas top propre quoi [:spamafote]
 

Taz a écrit :

t'es sur d'avoir besoin du fork au moins ?


oui parce que si je fais que l'execl, il va remplacer le père en mémoire et donc tout va s'arreter quand le montage serait effectif ce qui n'est pas le but recherché
 

Taz a écrit :

t'as regardé le status ? est-ce que tu fais plusieur fork dans ton père ?


non j'ai pas regardé le status (j'imagine qu'il va me dire un truc du genre, je suis zonbi maintenant ?  [:anathema] )
et j'ai qu'un fork comme tu peux le constater dans le code


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 14:57:19    

bon j'ai dit une bétise pour le status, je vais le vérifier


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 15:03:31    

Code :
  1. // Handler du signal
  2. void HandlerFinFils (int sig)
  3. {
  4.   wait(NULL);
  5.   return;
  6. }
  7. ...
  9. struct sigaction Action;
  10. sigemptyset(&Action.sa_mask);
  11. Action.sa_flags = 0;
  12. Action.sa_handler = HandlerFinFils;
  14. // armement du signal
  15. if (sigaction(SIGCHLD,&Action,NULL) == -1)
  16. {
  17.   // erreur
  18. }
  20. // ton fork


 
Voilà, ca fait longtemps que je touche plus a ce genre de truc, j'ai retrouvé ca dans un vieux prog mais y me semble que ca fonctionnait correctement.
Tu devras surmement pas mettre la meme chose pour le sigemptyset si t utilise déjà d'autre signaux mais bon l'idée est la.
 
De plus avec ca tu peux le faire en asynchrone et pas attendre dans ton else


Message édité par Diody le 13-11-2004 à 15:06:23
Reply

Marsh Posté le 13-11-2004 à 15:09:45    

c'est bien compliqué tout ça [:mlc2]


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 15:11:51    

j'ai rajouté ça après le fork :

Code :
  1. if (WIFEXITED(status)) fprintf(stderr,"terminaison anormale : %d",WEXITSTATUS(status));
  2.    if (WIFSIGNALED(status)) fprintf(stderr,"termisaison à cause d'un signal : %d",WTERMSIG(status));


et ça me dit maintenant "terminsaison à cause du signal 43" :o
ou qu'on trouve la correspondance des signaux déjà ?
 
 
EDIT :
ok, kill -l me donne :
43) SIGRTMIN+10
connais pas :/


Message édité par udok le 13-11-2004 à 15:13:06

---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 15:16:07    

t'es sur que c'est le bon fils ? t'as essayé avec waitpid ?

Reply

Marsh Posté le 13-11-2004 à 15:16:07   

Reply

Marsh Posté le 13-11-2004 à 16:02:43    

Taz a écrit :

t'es sur que c'est le bon fils ? t'as essayé avec waitpid ?


 
non juste wait, mais il ne peut y avoir qu'un fils à la fois


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 13-11-2004 à 16:07:45    

udok a écrit :

c'est bien compliqué tout ça [:mlc2]


 
Diody a pourtant raison, il faut un handler qui fait un wait(NULL) à la réception d'un SIGCHLD. Je suis en train de programmer un mini shell et on a fait tout un cours sur la gestion des processus. Edit : C'est pas indispensable en fait le handler dans ce cas.
 
Et encore, ce n'est pas la solution parfaite si c'est multi fils, mais puisque tu dis qu'il n'y en a qu'un.
 
Voilà la syntaxe pour la version "mono fils" que l'on utilise :
 

Code :
  1. pid_t pid_fils;
  3. switch(pid_fils=fork())
  4. {
  5. case 0:
  6.       execl( "/bin/mount", "mount", chemin, NULL );
  7.       perror("exec impossible" );
  8.       exit(1);
  9. case -1:
  10.       perror("fork impossible" );
  11.       exit(1);
  12. default:
  13.       waitpid(pid_fils,NULL,0);
  14.       exit(0);
  15. }


Message édité par Master_Jul le 13-11-2004 à 16:14:55

---------------
En français, on écrit "connexion", pas "connection".
Reply

Marsh Posté le 13-11-2004 à 17:28:05    

hmm, ta version ressemble bcp à la mienne
si ce n'est que tu utilises waitpid mais étant donné que je n'ai qu'un fils *à la fois*, je pense pas que ça soit super util
enfin je vais jeter un coup d'oeil du coté du handler avec sigaction pour voir ce que ça donne
merci en tout cas, je vous tiens au courant


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed