Bonjour,

Est ce que quelqu'un connait un moyen d'attendre (sous linux) la mort d'un processus arbitraire et pas seulement d'un processus fils (car wait et waitpid ne fonctionne qu'avec les processus fils).

Dans mon cas, c'est même plus simple, je veux juste attendre la fin du processus père.

En fait, le processus père fork et fait un exit() aussitôt après. Donc dormir pendant une milliseconde est presque une solution suffisante pour le processus fils. Mais je ne trouve pas cette solution très propre. Est-ce que quelqu'un à une meilleure idée ? (j'ai aussi essayer d'attendre la fermeture d'un FD du processus père, mais exit() les ferme trop tôt manifestement).

merci pour vos réponses.

Tu peux faire un wait dans le père, il attendra la fin du fils. Sinon pour attendre un processus particulier tu fais un wait_pid.

si en plus d'attendre la fermeture du fd, tu lui envoie un SIGKILL juste après, t'es sûr qu'il a fini ses trucs importants, et comme tu le tue, en revenant du kill il devrait être terminé non ? (je suis pas sûr que le kill soit "instantané" du point de vue du processus appelant mais ça vaut le coup d'essayer).

Mais quel est l'intérêt de créer un fils si le père se termine directement?

je ne crois pas qu'il y ai de fonction wait_pid, et waitpid ne permet que d'attendre un processus précis, mais pris dans la liste des processus fils.

Le fd sur lequel j'attends la fermeture est un fd qui est fermé par _exit() donc je n'ai pas besoin d'envoyer de sigkill (de toute manière le père se tue tout seul). Envoyer un signal est une opération qui n'est pas du tout instantané, et en fait même l'appel à exit n'est pas suffisant : j'ai testé et il arrive que après l'appel dans le processus père de la fonction exit() et après que exit() ait fermé les fd du père, le fils reprennent la main, mais avant que le père ne soit réellement mort.

"Mais quel est l'intérêt de créer un fils si le père se termine directement?"

changer le pid du programme par exemple.

ce que je voulais dire par instantané, c'est que comme kill(x, SIGKILL) permet de libérer des ressources, cet appel est relativement important, et du coup il est peut-être implémenté de façon à être entièrement traité par l'appel système (enfin vu que SIGKILL ne nécessite pas d'action du processus qui reçoit le signal mais uniquement de l'os), et du coup du point de vue du processus appelant, après le kill le processus x serait terminé.
un peu comme un voyant qui peut pas savoir que tu va te faire écraser par une voiture en sortant sauf si c'est son complice qui conduit.

Je vois pas le problème avec wait_pid. C'est bien le père qui attend le fils non? Tu enregistre le pid du fils dans une variable et tu fais waitpid dessus.

sauf que là, j'ai besoin d'attendre dans le fils que le père se termine et non pas le contraire.
Mais je viens d'avoir une idée très simple : il suffit de lire getppid() puis de rendre la main jusqu'à ce que le résultat soit 1 ce qui veut dire que l'on a été récupéré par init et donc que le père est mort.

Si le fils attend le père, le père mourra avant et le fils deviendra un processus zombie.

• orphelin pardon.

mince, je ne trouve pas de bonne méthode maintenant pour endormir temporairement le process.

Sous windows on fait Sleep(0), mais sous linux une boucle while(1) sleep(0); va utiliser tout le processeur, ce qui n'est pas ce que l'on veut.
J'ai essayer avec select, et c'est le même résultat (sauf que le temps est consommé au niveau kernel et pas au niveau utilisateur).
Il y a un appel schedule qui est censé faire ce que je veux, mais je crois qu'il n'est disponible que pour les process tournant au niveau kernel, et enfin toujours pami les options du scheduler, il y a pour le contexte du processus une option permettant de définir un signal qui sera envoyé au fils quand le process meurt. Mais pareil ça n'est accessible qu'au niveau kernel donc ça ne me vas pas.

C'est juste que faire un usleep(1) ou nanosleep(0) ne me plait pas.

...

bon, merci à vous, de toute manière je me suis aperçu d'une meilleure méthode pour contourner le bogue que j'ai rencontré.

"Si le fils attend le père, le père mourra avant et le fils deviendra un processus zombie."

non, quand le père meurt, le fils est hérité par le processus init, mais il continu à s'exécuter normalement.

j'ai rien dit ... (pas fait gaffe à ton post suivant).

Mais dans tout les cas, il continue de s'exécuter comme on veut.

Salut,
C'est pas bien evident ta question. je te donne en vrac les infos/idées qui ressortent:
On ne peut pas en POSIX attendre un processus n'importe le quel.
Cependant sous linux, tu peux peut etre utiliser l'interface inotify pour lire /proc/<pid> et te faire reveiller quand il y a un changement. Bon c'est linux specific et c'est a tester, mais ca devrait fonctionner.

Sinon, comme tes processus se connaissent, tu peux les faire communiquer (a travers un pipe, des IPC ou SIGUSR) pour que le pere notify le fils quand il meurt.
Une autre solution serait de faire 3 processus au lieu de deux: 1 pere, 2 fils. Le pere notifie un fils quand l'autre meurt.

Pour info, pourquoi as tu besoin de faire cela ?

Si tu veux juste changer le PID d'un processus, il suffit de forker et de faire un exit sur le pere. Il ne semble pas neccessaire de l'attendre.

oui, la solution à trois processus j'y ai pensé aussi. Mais comme il s'agit d'un outils "bas niveau" je voulais éviter de trop complexifier le problème. Pour la dialogue inter-process ça ne m'allait ps car il fallait que je sois prévenu après que le père soit mort, pas juste quand il va mourrir.

En fait il s'agit d'un bogue que j'ai trouvé dans linux (pas dans le noyau, mais dans un des outils du système), je pensais qu'il provenait d'un appel system mal réalisé, mais après quelques test j'ai vu que la raison pour laquelle ça ne fonctionnait pas n'était pas exactement ce que je croyais et effectivement, il n'y a pas besoin d'attendre que le père meurt (il suffit de forker, mais je n'avais pas remarquer que ce n'était pas toujours fait).

Je ne connaisais pas inotify, ça a l'air très intéressant.

en tout cas, merci de vos réponses.

juste au cas où quelqu'un tomberait sur ce thread en faisant une recherche, j'ai trouvé l'appel système qui me manquait : au niveau noyau, on peut dire au scheduler de nous envoyer un signal quand notre processus meurt.

L'appel système pour faire ça dans le monde utilisateur est :
prctl(PR_SET_PDEATHSIG,signal,0,0,0);
dans "sys/prctl.h" ou signal est le numéro du signal que l'on veut recevoir.

• quand notre processus père meurt.

(le signal est envoyé au processus appelant à la mort de son père).