Programmation systeme en C et les signaux

**Traboulidon** · 01/02/2007, 21h02

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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));
        }
    }
}

**souviron34** · 01/02/2007, 23h35

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 .....

**igor24** · 02/02/2007, 12h55

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

**Traboulidon** · 03/02/2007, 16h46

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.

**souviron34** · 04/02/2007, 15h16

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

**Médinoc** · 04/02/2007, 15h19

Ce n'est pas plutôt SIGTERM ?

**souviron34** · 04/02/2007, 15h41

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..

... 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

**Traboulidon** · 04/02/2007, 19h52

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.

**souviron34** · 05/02/2007, 00h35

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

**zooro** · 05/02/2007, 09h06

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..

... 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

**souviron34** · 05/02/2007, 12h14

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.....

**zooro** · 05/02/2007, 12h27

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.....

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.

**souviron34** · 05/02/2007, 13h17

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...

**zooro** · 05/02/2007, 13h28

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 :

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.

**souviron34** · 05/02/2007, 14h06

la réponse est dans la question

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.....

**zooro** · 05/02/2007, 14h50

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 :

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.

**souviron34** · 05/02/2007, 15h03

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....

**zooro** · 05/02/2007, 15h52

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...

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.

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 !).

**souviron34** · 05/02/2007, 16h22

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"....

**Médinoc** · 05/02/2007, 16h56

Le problème, c'est que:

SIGKILL signifie tuer, et rien d'autre. Tout processus qui "reçoit" SIGKILL est tué.
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.
Montre-nous un peu comment tu affiches ton "J'ai reçu SIGKILL".

Programmation systeme en C et les signaux

Réseau C

Discussions similaires

Partager

Partager