Programmation systeme en C et les signaux

Version imprimable

Bonjour,

Je dois creer un processus avec fork() et capter les signaux ainsi que les status.

J'ai un petit programme pour essayer de comprendre le fonctionnement, mais ça ne fonctionne pas.

Pouvez-vous me dire comment faire pour obtenir le status du processus ???

Selon la documentation sur ce site, je devrais pouvoir obtenir le status:

http://www.opengroup.org/onlinepubs/...ions/wait.html

IF(WIFSIGNALED(status)).. devrait être exécuté selon moi, mais ce n'est pas le cas. Alors comment faire pour obtenir le status de terminaison du processus?

Faites le test avec une interruption "ctrl_c" qui est supposer lancer le signal SIGINT. Ça ne fonctionne pas. wait retourne -1 et le status est 0.

Merci de me donner vos commentaires
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 #include <fcntl.h> #include <sys/stat.h> int main(){ pid_t child_pid, wpid; int status; child_pid = fork(); if (child_pid == -1) { /* fork() failed */ perror("fork"); exit(EXIT_FAILURE); } if (child_pid == 0) { /* This is the child */ while(1); } else { /* This is the parent */ wpid = wait(&status); if (wpid == -1) { perror("waitpid"); printf("\n ***** La fonction wait() a retourné : %d et le status est: %d ******\n\n",wpid, status); exit(EXIT_FAILURE); } if (WIFEXITED(status)) { printf("child exited, status=%d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("child killed (signal %d)\n", WTERMSIG(status)); } else if (WIFSTOPPED(status)) { printf("child stopped (signal %d)\n", WSTOPSIG(status)); } } }

01/02/2007, 23h35
souviron34

tu es sur quelle plateforme stp ?

Si tu es sur Linux ou Unix, les signaux ne sont pas WIFEXITED ou ...

Va voir les tutoriels C .....
02/02/2007, 12h55
igor24

bonjour,

Pour attendre la fin d'un processus, on utilise les fonctions de la famille wait()

pid_t wait(int * status) : renvoit le pid du fils terminé. si le pointeur status n'est pas NULL, on est renseigné sur les circonstances de terminaison du processus.

le contenu de status est opaque, on doit donc faire appel à quelques macro pour s'informer des circonstances de trminaison

la macro WIFEXITED(status) : renvoie vrai si le processus s'est terminé en invoquant exit(), ou en revenant de main.
on récupère le code de retour avec WEXITSTATUS(status).

bon courage
03/02/2007, 16h46
Traboulidon

D'accord. Oui, je suis sou linux.

J'étais au courant de ces macros. J'ai d'ailleurs voulu les tester. Je me suis rendu compte que le ctrl-c(SIGINT #2) ne fait pas la même chose que l'orsque l'on lance le signal avec kill -INT pid (#2). Alors j'essayais d'interrompre le programme avec ctrl-c et ça ne fonctionnait pas.

Je ne comprends toujours pas pourquoi le ctrl-c n'envoie pas de signal comme le kill -INT pid, c'est pourtant le même signal.

Anyway.
04/02/2007, 15h16
souviron34

non ça n'est pas le même signal...

Ctrl-c c'est "à l'intérieur" du progamme, kill à l'extérieur...

Signaux SIGQUIT et SIGKILL
04/02/2007, 15h19
Médinoc

Ce n'est pas plutôt SIGTERM ?
04/02/2007, 15h41
souviron34

NON..

En fait SIGTERM est un SIGKILL qui peut être capturé (et donc ignoré).. Ce qui doit se faire pas mal sous Windows (au vu du nbes de fois ou tu restes suspendu sans pouvoir terminer un programme..)..

SIGKILL ne te demande pas ton avis.. :mouarf: ... L'intérêt est de prévoir une action à prendre..

SIGQUIT est ce qui est envoyé par ctrl-c

http://en.wikipedia.org/wiki/SIGTERM

http://en.wikipedia.org/wiki/SIGKILL

http://en.wikipedia.org/wiki/SIGQUIT
04/02/2007, 19h52
Traboulidon

D'après les tests que j'ai fait, "kill -INT pid" envoie un sigal #2 qui est le SIGINT et qui est le même que CTRL-C.

C'est exactement ce qui est dit ici.
http://en.wikipedia.org/wiki/SIGINT_%28POSIX%29

CTRL-C, peut-être ignoré. S,il ne l'est pas, il termine l'application et le parent ne reçoit aucun signal. Par contre, pour le "kill -INT pid", le parent reçoit le signal. Je me demande juste pourquoi ils ne réagissent pas de la même façon puisque c'est le même signal.

Je ne peux pas répondre pour tout, mais je sais que sur ma distrib Linux (Redhat 6), ça a toujours donné 2, je crois aussi (si je me souviens.. Plus testé la valeur du retour depuis ... 5 ou 6 ans au moins). Et je crois que c'est bug ?? feature ?? wrapping ?? du code...

Dans tous les cas, ce que je mets par précaution (puisque ça marche très bien dans tous les cas, et que sur d'autres systèmes Unix (HPUX, SGI mips) les signaux étaient effectivement différents) est :
Code:

1 2 3 4 5 6 7 8 if ( (sig == SIGKILL) || (sig == SIGTERM) || (sig == SIGQUIT) || (sig == SIGPIPE) || (sig == SIGSTOP) ) { fprintf(stderr,"Signal de terminaison reçu \n"); End_Of_Session(); }
Mais peut-être d'autres ont-ils eu d'autres résultats...

05/02/2007, 09h06
zooro

Citation:

Envoyé par souviron34

En fait SIGTERM est un SIGKILL qui peut être capturé (et donc ignoré).. Ce qui doit se faire pas mal sous Windows (au vu du nbes de fois ou tu restes suspendu sans pouvoir terminer un programme..)..

SIGKILL ne te demande pas ton avis.. :mouarf: ... L'intérêt est de prévoir une action à prendre..

SIGKILL ne peut pas être intercepté ni traité dans le programme.
Pour une liste des signaux et de leurs actions par défaut : http://www.opengroup.org/onlinepubs/.../signal.h.html

Un "Ctrl-C" envoie un SIGINT. Donc pour l'ignorer, tu peux faire :

Code:

signal(SIGINT, SIG_IGN);

Et pour traiter un signal, il faut mettre en place un gestionnaire autre que celui par défaut, avec la fonction signal, ou mieux, avec la famille de fonctions sigaction.
Sinon, c'est l'action par défaut qui est exécutée (souvent la mort du processus).
05/02/2007, 12h14
souviron34

Citation:

SIGKILL ne peut pas être intercepté ni traité dans le programme.
Pour une liste des signaux et de leurs actions par défaut : http://www.opengroup.org/onlinepubs/.../signal.h.html

Pas tout à fait vrai... Vrai pour le programme concerné. Mais imagines le cas par exemple d'un serveur et d'un client.

Si les 2 ont une action sur le signal SIGKILL, celui qui n'est pas tué le recoit et peut le traiter.... Je sais, je l'ai implanté et ça marche opérationnelemnt depuis 10 ans...

exemple :

client demande service => serveur/service se clone et le clone devient attaché au client.

Si serveur a : if ( SIGKILL ) exit
Si client a : if ( SIGKILL ) redemarre serveur

Si tu tues le client le serveur sort
Si tu tues le serveur le client redemande service.....

:mrgreen:
05/02/2007, 12h27
zooro

Citation:

Envoyé par souviron34

Pas tout à fait vrai... Vrai pour le programme concerné. Mais imagines le cas par exemple d'un serveur et d'un client.

Si les 2 ont une action sur le signal SIGKILL, celui qui n'est pas tué le recoit et peut le traiter.... Je sais, je l'ai implanté et ça marche opérationnelemnt depuis 10 ans...

exemple :

client demande service => serveur/service se clone et le clone devient attaché au client.

Si serveur a : if ( SIGKILL ) exit
Si client a : if ( SIGKILL ) redemarre serveur

Si tu tues le client le serveur sort
Si tu tues le serveur le client redemande service.....

:mrgreen:

Euh... Seul le programme à qui le SIGKILL est envoyé le reçoit. Et il en meure systématiquement sans le savoir (essaie de faire un "kill -9", pour voir).
Par contre, comme tu le dis, son père peut effectivement être prévenu de sa mort, et agir en conséquence. Mais il ne reçoit pas lui-même le signal, il est simplement informé du fait que son fils PID xxx est mort anormalement, suite à la réception d'un signal SIGKILL.
05/02/2007, 13h17
souviron34

pas tout à fait..

Je suis d'accord avec toi pour

le programme qui est tué ne reçoit rien..

Mais je ne parlait pas seulement du père (qui est averti par un SIGCHILD et non SIGKILL)..

Je dis si un CLIENT a enregistré d'être averti d'un SIGKILL (par ioctl, signal, ou autre), il le reçoit et peut le traiter.... et il reçoit bien sig 9...
05/02/2007, 13h28
zooro

Citation:

Envoyé par souviron34

Je suis d'accord avec toi pour le programme qui est tué ne reçoit rien.
(...)
si un CLIENT a enregistré d'être averti d'un SIGKILL (par ioctl, signal, ou autre), il le reçoit et peut le traiter.... et il reçoit bien sig 9...

Ce que tu dis n'est pas clair.
Par ailleurs, le man de signal dit bien qu'il est impossible d'intercepter un SIGKILL :

Citation:

Envoyé par man

Utiliser une fonction comme gestionnaire de signal est appelé "intercepter - ou capturer - le signal". Les signaux SIGKILL et SIGSTOP ne peuvent ni être ignorés, ni être interceptés.

Le père d'un processus peut être averti (via un SIGCHLD) de la mort d'un de ses fils, mais il ne peut récupérer que des informations sur ce qui a tué son fils (le numéro du signal en l'occurrence), et non le SIGKILL en lui-même.
Lors d'une communication (socket, pipe, ou autres), le processus qui n'a pas été tué est prévenu de la rupture du lien (BROKEN PIPE) mais ne reçoit pas de SIGKILL.
05/02/2007, 14h06
souviron34

la réponse est dans la question ;)

Citation:

Lors d'une communication (socket, pipe, ou autres), le processus qui n'a pas été tué est prévenu de la rupture du lien (BROKEN PIPE) mais ne reçoit pas de SIGKILL

Il reçoit SIGPIPE quand c'est un pipe (si mes souvenirs très lointains sont bons).. Quand c'est un socket il reçoit SIGKILL.. Essaye et regarde le numéro du signal reçu.....
05/02/2007, 14h50
zooro

Citation:

Envoyé par souviron34

la réponse est dans la question ;)

Il reçoit SIGPIPE quand c'est un pipe (si mes souvenirs très lointains sont bons).. Quand c'est un socket il reçoit SIGKILL.. Essaye et regarde le numéro du signal reçu.....

Ce n'était pas une question.
Et le processus reçoit toujours SIGPIPE, que ce soit une socket ou non.
cf. man send :

Citation:

Voici les erreurs standards engendrés par la couche socket. (...)
EPIPE
L'écriture est impossible (correspondant absent). Dans ce cas le processus recevra également un signal SIGPIPE sauf s'il a activée l'option MSG_NOSIGNAL.
05/02/2007, 15h03
souviron34

Primo man n'est pas la pancée (voir la documentation réelle du standard)

Secondo l'exemple que tu donnes tu fais un send...

Mais si tu es en train de RIEN faire ? attendre un interrupt par exemple ??

Je te le répète... teste, imprime la valeur du sig, et on en reparle après....
05/02/2007, 15h52
zooro

Citation:

Envoyé par souviron34

Primo man n'est pas la pancée (voir la documentation réelle du standard)

C'est vrai, mais dans ce cas précis, le comportement étant le même sur toutes les versions de Linux...

Citation:

Envoyé par souviron34

Secondo l'exemple que tu donnes tu fais un send...
Mais si tu es en train de RIEN faire ? attendre un interrupt par exemple ??

Tu recevras le SIGPIPE quand tu tenteras d'accéder à la socket en question.

Citation:

Envoyé par souviron34

Je te le répète... teste, imprime la valeur du sig, et on en reparle après....

Tu ne pourras jamais imprimer "j'ai reçu un SIGKILL", puisque le SIGKILL tue immédiatement le processus et ne peut pas être intercepté (sinon, il y aurait des processus que root ne pourrait pas tuer !).
05/02/2007, 16h22
souviron34

je me répète, mais je ne te parles PAS du processus qui EST tué, mais de celui qui est connecté avec..

Lui reçoit le SIGKILL ..... et tu pourras imprimer "j'ai reçu le sig kill"....
05/02/2007, 16h56
Médinoc
Le problème, c'est que:
1. SIGKILL signifie tuer, et rien d'autre. Tout processus qui "reçoit" SIGKILL est tué.
2. Si quelqu'un avait programmé le système autrement, ce ne serait pas logique et ça aurait été corrigé depuis longtemps, et ce serait marqué dans toutes les aides.
3. Montre-nous un peu comment tu affiches ton "J'ai reçu SIGKILL".

Citation:

Montre-nous un peu comment tu affiches ton "J'ai reçu SIGKILL".

Facile.... :mouarf:

Je ne mettrais ni le code complet (2 modules de 20 000 lignes), ni la création/ouverture des sockets, juste ce qu'il faut...

Tu fais une routine :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 
 
/*
*  Parametres : 
*       <requete>        : numero du descripteur de fichier 
*       <fonction>       : fonction appelee lors de la reception du signal systeme
*
*
*   Retour : 0 si tout va bien
*            < 0 il y a eu erreur
*            > 0 : il y a deja des caracteres a lire sur le socket.  Dans ce
*	          cas, on retourne le nobre de caracteres disponibles sans 
*		  passer en mode asynchrone.
*/
 
int InitialiserSocketAsynchrone(int requete,void (*fonction)()  )
{
   pid_t pid;
   int retour;
   int bidon;
 
 
   /*
    *On passe en asynchrone
    *Obtenir le numero de ce processus pour pouvoir le refiler
    *a ioctl afin d'etre avise de tout changement sur le socket
    */
 
   pid =getpid();
 
   bidon = (int) pid;
#ifndef LINUX
   retour = ioctl(requete,SIOCSPGRP,&bidon);
#else
   retour = fcntl(requete,F_SETOWN,(long)bidon);
#endif
   if ( retour < 0 )
     return retour ;
 
   /*
    *Initialiser l'option asynchrone pour le socket
    */
 
#ifndef LINUX
   bidon = 1;
   retour = ioctl(requete,FIOASYNC,&bidon);
#else
   bidon = O_ASYNC ;
   retour = fcntl(requete,F_SETFL,(long)bidon);
#endif
 
   if ( retour < 0 )
       return retour ;
   else
     {
       signal(SIGIO,fonction);
       return (0);
     }
}

Dans une bibliothèque c'est mieux :-)

Et ensuite, ET dans le client ET dans le serveur tu mets :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
 
{
.....
int iret, canal_in ;
 
....
 
/* A l'endroit ou on va écouter le socket et attendre les évènements */
 
     iret = InitialiserSocketAsynchrone( Canal_in, &Received_New_Request );
.......
 
}
 
 
/*
 * R e c e i v e d _ N e w _ R e q u e s t
 *
 */
static void  Received_New_Request ( int sig )
{
   /* Si dans serveur */
      fprintf (stderr, "\n\nInterrupt %d received from client",sig);
 
    /* Si dans client */
      fprintf (stderr, "\n\nInterrupt %d received from server",sig);
 
 
/*
--- Go get the number of the server concerned by this signal
*/
   /* --- If interrupt provoked by temination of either ends, exits ---*/
   if ( (sig == SIGKILL) || (sig == SIGTERM) || (sig == SIGQUIT)  || 
        (sig == SIGPIPE) || (sig == SIGSTOP) || (NumServer == -9999) )
     {
       if ( DEBUG )
	 fprintf(stderr,"ONE TERMINATION SIGNAL WAS RECEIVED \n");
 
       End_Of_Session(2);
     }
}

Fait un kill sur l'un ou l'autre (kill -9) et regarde le numéro de signal reçu par l'autre....

05/02/2007, 17h52
Médinoc

Le signal intercepté n'est donc pas SIGKILL, mais SIGIO.

Il est possible qu'il soit ENSUITE traduit en un autre signal par un mécanisme sous-jacent, mais le vrai signal reste SIGIO.
05/02/2007, 18h29
souviron34

je ne comprend pas ce que tu veux dire..

Tu fais kill -9 sur l'un et tu obtiens sig=9 sur l'autre.....

et ioctl et sockets utilisent tout deux les défnitions de signal.....
05/02/2007, 21h15
Médinoc

signal() est sur SIGIO.

C'est le mécanisme sous-jacent à ioctl() qui traduit le SIGIO en un autre signal entre le moment où le signal est reçu par le process et celui où le handler est appelé.
La traduction peut être "le signal qui a fait finir le process" ou bien "SIGKILL si le process a été tué, autre chose dans d'autre cas", ou que sais-je.
Toujours est-il que ton process qui surveille ne reçoit pas véritablement un SIGKILL, mais un SIGIO traduit par la suite.

N'oublie pas, les faits sont là : signal() intercepte SIGIO, et le vrai SIGKILL n'est pas interceptable de toute façon.
06/02/2007, 01h34
souviron34

Citation:

Toujours est-il que ton process qui surveille ne reçoit pas véritablement un SIGKILL, mais un SIGIO traduit par la suite.

Explique-moi alors comment il se fait que dans tous les autres cas de communications (sauf bien sûr ctrl-c et SIGHUP) celui qui restera vivant reçoit toujours SIGIO (code 22 sur mon linux, mais 29 sur d'autres Unix, ou une autre valeur > 20 en général), et reçoit systématiquement 9 (SIGKILL) quand tu tues l'autre , quel que soit le système ?
(dans la routine Received_New_Request ci-dessus, donc DIRECTEMENT la routine appelée par signal)

Si le sigkill n'est interceptable par AUCUN process, c'est donc que même ioctl ne peut l'intercepter... Et donc comment, si on suit ton raisonnement, pourrait-t-il le transformer (puisqu'alors il détecterait SIGIO et par quel miracle en déduirait-il SIGKILL...) ?

Il n'est pas interceptable par le processus AUQUEL c'est destiné ça d'accord...

Dans l'exemple présenté ci-dessus :

les 2 (client et serveur) partagent le même socket. L'un est tué et ne peut rien faire , mais l'autre reçoit SIGKILL... Donnes-moi une explication convaincante ;)
06/02/2007, 07h21
Médinoc

Les ioctl ne font partie d'aucun process, mais du kernel.

À mon avis, elles surveillent le process lui-même, et quand le process surveillé tombe, elles envoient (et non détectent) un SIGIO au process surveillant, interceptent le signal handler et lui passent la valeur traduite...

Donc, ce n'est pas le process surveillant qui reçoit SIGKILL, mais seulement le handler dans le process.
06/02/2007, 09h16
zooro

Citation:

Envoyé par souviron34

Donnes-moi une explication convaincante

Quand un processus reçoit un SIGKILL, il meurt immédiatement. A priori, il n'y a pas d'exception.
Donc, le processus survivant ne PEUT PAS avoir reçu le signal SIGKILL (sinon, il n'aurait pas survécu). Il a reçu un autre signal (SIGIO), et ta fonction a obtenu l'INFORMATION que le processus lié est mort suite à la réception d'un signal SIGKILL.
06/02/2007, 10h32
souviron34

Entièrement d'accord avec toi, Médinoc, mais cela signifie en clair que pour un programmeur moyen (qui ne s'intéresse pas au kernel) IL EST POSSIBLE d'imprimer "Reçu SIGKILL" ........ ce qui était le début de notre aparté...

Le mécanisme par lequel ça se fait est ce qu'il est, mais le résultat net est que l'on peut (et doit dans un certains nombre de cas, dont les architectures client-serveur) tenir compte du SIGKILL......

CQFD...:mrgreen: