TP 5 - Signaux

• lab05-refcard.pdf

• Génération de signaux
• Soumission et recevoir des signaux
• Types standard de signaux
• Les messages décrivant des signaux
• Masques de signalisation. Verrouillage du signal
• Traitement du signal
• Rapport de processus
• En attente d'un signal
• Timers sous Linux

Dans le monde réel, un processus peut découvrir une variété de contingences qui affectent le flux normal de l'exécution. Si le processus ne peut pas gérer, ils sont passés plus loin, le système d'exploitation. Quel système d'exploitation ne sait pas si le processus peut continuer à exécuter normalement sans effets secondaires indésirables est nécessaire pour terminer le processus de force. Une solution à ce problème est les signaux.

• En règle générale l'action par défaut est processus d'achèvement.

• Si un processus veut ignorer un signal, le système d'exploitation ne sera pas envoyer ce processus de signal.

• Si un processus spécifique qui veut signal de bloc, le système d'exploitation ne sera plus envoyer des signaux à traiter ce type en question, mais enregistrera seulement le premier signal de ce type, le reste est perdu. Lorsque le processus décide qu'il veut recevoir des signaux à nouveau de ce type, en cas de signal en attente, il sera envoyé.

L'ensemble de ces signaux est terminé; OS conserve pour chaque processus, une table des actions choisie pour chaque type de signal. A chaque fois que ces actions sont bien définies. Lors du démarrage de la table de processus est initialisé avec l'action par défaut. Le signal de traitement est déterminé par le processus de réception du signal, mais est choisi automatiquement de la table. Les signaux sont flux d'exécution synchrone / asynchrone du processus qui reçoit le signal si l'événement provoquant le signal d'envoi est exécution synchrone / asynchrone des flux de processus.

• Un événement est flux synchrone de l'exécution du processus qui se produit chaque fois que le programme en cours d'exécution au même point dans le flot d'exécution. Des exemples tentent d'accéder à un emplacement mémoire invalide ou permis, division par zéro, etc.

• Un événement est asynchrone si il est pas synchronisé. Des exemples d'événements asynchrones: un signal envoyé par un autre processus (terminaison de signal d'un processus enfant), ou une demande de terminaison externe (utilisateur veut réinitialiser l'ordinateur).

Un signal reçu par un processus peut être généré:

• Soit directement système d'exploitation - où il signale diverses erreurs;

• ou un processus - qui peut également envoyer ses propres signaux (le signal passera également par le système d'exploitation).

Dans certains cas, il faut savoir, sûrement, qui a envoyé un signal pour atteindre sa destination et donc, le processus lui répondre (faire une des actions possibles). Le système d'exploitation fournit un autre moyen d'envoyer un signal, qui garantit si le signal a atteint sa destination, si cette action a échoué. Ceci est accompli en créant une pile de signaux d'une certaine capacité (il doit être fini, ne pas provoquer des situations de débordement). Envoi d'un signal, le système d'exploitation vérifie si la pile est pleine. Dans ce cas, l'application échoue, l'autre signal est placé sur la pile et l'opération se termine avec succès.

Le signal terme est utilisé pour indiquer alternativement être une sorte d'objets ou réels signaux de ce type.

En général, les événements générant des signaux se répartissent en trois catégories principales:

• Une “erreur” indique qu'un programme a effectué une opération non autorisée et ne peut pas continuer son exécution. Cependant, tous les types d'erreur ne génèrent pas de signaux (en fait, la plupart ne le font pas). Par exemple, ouvrir un fichier inexistant est une erreur, mais cela ne génère pas de signal. Au lieu de cela, l'appel système ouvert renvoie -1 indiquant que l'appel s'est terminé avec une erreur. Généralement, les erreurs associées à certaines bibliothèques sont signalées en renvoyant une valeur spéciale. Les erreurs qui génèrent des signaux sont celles qui peuvent apparaître n'importe où dans le programme, pas seulement dans les appels des bibliothèques. Ils incluent la remise à zéro et l'accès invalide à la mémoire.

• Un “événement externe” est généralement lié aux E / S et à d'autres processus. Exemples: nouvelle entrée de données, expiration du temporisateur, achèvement d'un processus enfant.

• La demande explicite indique l'utilisation d'un appel système, tel que kill, pour générer un signal.

Les signaux peuvent être synchrones ou asynchrones:

• Un signal “synchrone” fait référence à une action spécifique du programme et est envoyé (s'il n'est pas bloqué) au cours de cette action. La plupart des erreurs génèrent des signaux synchrones. Les signaux peuvent également être générés de manière synchrone et par des demandes explicites envoyées par un processus lui-même. Sur certains ordinateurs, certains types d’erreurs matérielles (généralement des exceptions en virgule flottante) ne sont pas signalés comme étant complètement synchroniques et ils peuvent obtenir certaines instructions ultérieurement.

• Les signaux asynchrones sont générés par des événements incontrôlables par le processus qui les reçoit. Ces signaux arrivent à des moments imprévisibles. Les événements externes génèrent des signaux asynchrones, ainsi que des demandes explicites envoyées par d'autres processus.

Un type de signal donné est synchrone ou asynchrone. Par exemple, les signaux d'erreur sont généralement synchrones car les erreurs génèrent des signaux synchrones. Cependant, tout type de signal peut être généré de manière synchrone ou asynchrone avec une demande explicite.

Lorsqu'un signal est généré, il entre dans un état en attente. Normalement, il reste dans cet état pendant très peu de temps et est ensuite envoyé au processus de destination. Toutefois, si ce type de signal est actuellement bloqué, il peut rester à l'état indéfini jusqu'à ce que les signaux de ce type soient déverrouillés. Une fois que ce type de signal est déverrouillé, il sera envoyé immédiatement. Lorsque le signal a été reçu, immédiatement ou avec retard, l'action spécifiée pour ce signal est exécutée. Pour certains signaux, tels que «SIGKILL» et «SIGSTOP», l'action est fixée (le processus est terminé), mais pour la plupart des signaux, le programme peut choisir de:

• ignorer le signal
• spécifie une fonction gestionnaire
• accepte l'action par défaut pour ce type de signal.

Le programme spécifie votre choix en utilisant des fonctionnalités telles que signal ou sigaction . Lorsque le gestionnaire est en cours d'exécution, ce type de signal est normalement verrouillé (le déverrouillage sera effectué par une demande explicite du gestionnaire qui gère le signal).

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
 
pid_t child1, child2;
int child1_pid;
 
 
void signal_handler(int signum)
{
 
    switch(signum) {
        case SIGINT:
            printf("CTRL+C received in %d Exiting\n", getpid());
            exit(EXIT_SUCCESS);
        case SIGUSR1:
            printf("SIGUSR1 received. Continuing execution\n");
    }
}
 
int main(void)
{
 
    printf("Process %d started\n", getpid());
 
    /* Semnale ca SIGKILL sau SIGSTOP nu pot fi prinse */
    if (signal(SIGKILL, signal_handler) == SIG_ERR)
        printf("\nYou shall not catch SIGKILL\n");
 
    if(signal(SIGINT, signal_handler) == SIG_ERR) {
        printf("Unable to catch SIGINT");
        exit(EXIT_FAILURE);
    }
 
    if(signal(SIGUSR1, signal_handler) == SIG_ERR) {
        printf("Unable to catch SIGUSR1");
        exit(EXIT_FAILURE);
    }
 
 
    printf("Press CTRL+C to stop us\n");
 
    while(1) {
        sleep(1);
    }
 
    return 0;
}

Si l'action spécifiée pour un type de signal est de ignorer , alors tout signal de ce type généré pour le processus en question est ignoré. La même chose se produit si le signal est bloqué à ce moment-là. Un signal négligé dans ce mode ne sera jamais reçu, ou si le programme spécifie ensuite une action différente pour ce type de signal, puis le déverrouille. Si un signal est reçu pour lequel aucun type d'action n'a été spécifié, l'action par défaut est exécutée. Chaque type de signal a sa propre action par défaut. Pour la plupart des signaux, l'action par défaut est mettant fin au processus . Pour certains types de signaux, qui sont des événements sans conséquences majeures, l'action par défaut consiste à ne rien faire.

Lorsqu'un signal force un processus à se terminer, le processus parent peut déterminer la cause de la terminaison en examinant le code de terminaison signalé par les fonctions 'wait' et 'waitpid'. Les informations pouvant être obtenues incluent le fait que le processus s'est terminé par un signal ainsi que le type de signal. Si un programme que vous exécutez à partir de la ligne de commande est terminé par un signal, le shell affiche généralement des messages d'erreur. Les signaux qui représentent normalement des erreurs de programme ont une propriété spéciale: lorsqu'un de ces signaux termine le processus, il écrit également un fichier core dump qui enregistre le statut du processus à la fin. Vous pouvez examiner le fichier avec un débogueur pour déterminer la cause de l'erreur. Si vous générez un signal, qui est une erreur de programme, par une requête explicite et que le processus se termine, le fichier est généré comme si le signal avait été généré par une erreur.

Cette section répertorie les noms de différents types de signaux standard et décrit le type d’événements qu’il indique.

$ kill -l
 
     1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
     5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE
     9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2
    13) SIGPIPE     14) SIGALRM     15) SIGTERM     17) SIGCHLD
    18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN
    22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
    26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO
    30) SIGPWR      31) SIGSYS      33) SIGRTMIN    34) SIGRTMIN+1
    35) SIGRTMIN+2  36) SIGRTMIN+3  37) SIGRTMIN+4  38) SIGRTMIN+5
    39) SIGRTMIN+6  40) SIGRTMIN+7  41) SIGRTMIN+8  42) SIGRTMIN+9
    43) SIGRTMIN+10 44) SIGRTMIN+11 45) SIGRTMIN+12 46) SIGRTMIN+13
    47) SIGRTMIN+14 48) SIGRTMIN+15 49) SIGRTMAX-15 50) SIGRTMAX-14
    51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10
    55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7  58) SIGRTMAX-6
    59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
    63) SIGRTMAX-1  64) SIGRTMAX

Les noms des signaux sont définis dans l'en-tête signal.h . Généralement, les signaux ont des rôles prédéfinis, mais ils peuvent être écrasés par le programmeur. Les plus communs sont les signaux suivants:

• SIGINT - transmis au toucher de la combinaison CTRL + C ;
• SIGQUIT - transmis en appuyant sur la combinaison de touches CTRL + \ ;
• SIGSEGV - transmis lors de l'accès à un emplacement mémoire invalide, etc.
• SIGKILL - ne peut être ignoré ni écrasé. La transmission de ce signal a pour effet de mettre fin au processus, quel que soit le contexte.

Le meilleur moyen d’afficher une description d’un signal est d’utiliser le strsignal et le psignal. Ces fonctions utilisent un numéro de signal pour spécifier le type de signal à décrire. Vous trouverez ci-dessous un exemple d'utilisation de ces fonctionnalités:

msg_signal.c

#include <stdio.h>
#include <stdlib.h>
 
#define __USE_GNU
#include <string.h>
 
#include <signal.h>
 
int main(void) {
    char *sig_p = strsignal(SIGKILL);
 
    printf("signal %d is %s\n", SIGKILL, sig_p);
 
    psignal(SIGKILL, "death and decay");
 
    return 0;
}

Pour compiler et exécuter la séquence, procédez comme suit:

so@spook$ gcc -Wall -g -o msg_signal msg_signal.c
so@spook$ ./msg_signal 
signal 9 is Killed
death and decay: Killed

Afin de pouvoir effectuer des opérations de blocage / déblocage de signal, nous devons connaître l'état de chaque signal à chaque étape du flux d'exécution. Le système d’exploitation a également besoin de la même chose pour décider du signal à envoyer à un processus (il a besoin de ce type d’informations séparément pour chaque processus). À cette fin, un masque de signaux est utilisé pour chaque processus.

 int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

struct sigaction {
               void     (*sa_handler)(int);
               void     (*sa_sigaction)(int, siginfo_t *, void *);
               sigset_t   sa_mask;
               int        sa_flags;
};

#include <signal.h>
...
 
/* SIGUSR2 handler */
static void usr2_handler(int signum) {
    /* actions that should be taken when the signal signum is received */
    ...
}
 
int main(void) {
    struct sigaction sa;
 
    memset(&sa, 0, sizeof(sa));
 
    sa.sa_flags   = SA_RESETHAND;   /* restore handler to previous state */
    sa.sa_handler = usr2_handler;
    sigaction(SIGUSR2, &sa, NULL);
 
    return 0;
}

siginfo_t {
               int      si_signo;    /* Signal number */
               int      si_errno;    /* An errno value */
               int      si_code;     /* Signal code */
               int      si_trapno;   /* Trap number that caused
                                        hardware-generated signal
                                        (unused on most architectures) */
               pid_t    si_pid;      /* Sending process ID */
               uid_t    si_uid;      /* Real user ID of sending process */
               int      si_status;   /* Exit value or signal */
               clock_t  si_utime;    /* User time consumed */
               clock_t  si_stime;    /* System time consumed */
               sigval_t si_value;    /* Signal value */
               int      si_int;      /* POSIX.1b signal */
               void    *si_ptr;      /* POSIX.1b signal */
               int      si_overrun;  /* Timer overrun count; POSIX.1b timers */
               int      si_timerid;  /* Timer ID; POSIX.1b timers */
               void    *si_addr;     /* Memory location which caused fault */
               long     si_band;     /* Band event (was int in
                                        glibc 2.3.2 and earlier) */
               int      si_fd;       /* File descriptor */
               short    si_addr_lsb; /* Least significant bit of address
                                        (since kernel 2.6.32) */
}