Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3186 connectés 

  FORUM HardWare.fr
  Programmation
  C

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

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

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

n°897499
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 14:16:21  profilanswer
 

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)
mood
Publicité
Posté le 13-11-2004 à 14:16:21  profilanswer
 

n°897509
Diody
Posté le 13-11-2004 à 14:32:45  profilanswer
 

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
n°897512
Taz
bisounours-codeur
Posté le 13-11-2004 à 14:34:42  profilanswer
 

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 ?

n°897518
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 14:49:13  profilanswer
 

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)
n°897522
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 14:54:50  profilanswer
 

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)
n°897527
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 14:57:19  profilanswer
 

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


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
n°897531
Diody
Posté le 13-11-2004 à 15:03:31  profilanswer
 

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
n°897536
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 15:09:45  profilanswer
 

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


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
n°897538
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 15:11:51  profilanswer
 

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)
n°897542
Taz
bisounours-codeur
Posté le 13-11-2004 à 15:16:07  profilanswer
 

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

mood
Publicité
Posté le 13-11-2004 à 15:16:07  profilanswer
 

n°897567
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 16:02:43  profilanswer
 

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)
n°897572
Master_Jul
Posté le 13-11-2004 à 16:07:45  profilanswer
 

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".
n°897602
udok
La racaille des barbus ©clémen
Posté le 13-11-2004 à 17:28:05  profilanswer
 

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)

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

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

 

Sujets relatifs
Possible d'éviter l'apparition de messages d'erreur?[Serveur en C ] pb de processus zombies
éviter le LEFT JOIN (performance)[Java] Eviter qu'un dessin s'efface si la fenetre est recouverte...?
Eviter l'affichage des fichiers d'un repertoire? [résolu][SQL] Comment éviter une division par 0 (zéro) --> résolu par DECODE()
[PHP] Comment éviter les Warning ?[CSS] Comment éviter de tel chose si horrible ?! [Résolu]
comment éviter d'afficher des résultats doubles ?[JSP] Eviter l'interpretation d'html dans un fomulaire
Plus de sujets relatifs à : [ Defunct ] Comment éviter les zombies après un *fork -> execl*

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.062 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR