Qu'est-ce qui cause l'envoi de divers signaux ?

Je suis parfois un peu confus par tous les signaux qu'un processus peut recevoir. Si je comprends bien, un processus a un gestionnaire par défaut (disposition du signal ) pour chacun de ces signaux, mais il peut fournir son propre gestionnaire en appelant sigaction() .

Voici donc ma question :qu'est-ce qui cause l'envoi de chacun des signaux ? Je me rends compte que vous pouvez envoyer manuellement des signaux aux processus en cours d'exécution via le -s paramètre pour kill , mais quels sont les naturels circonstances dans lesquelles ces signaux sont envoyés ? Par exemple, quand est-ce que SIGINT être envoyé ?

Existe-t-il également des restrictions sur les signaux pouvant être traités ? Peut même SIGSEGV les signaux seront-ils traités et le contrôle rendu à l'application ?

Réponse acceptée :

En plus des processus appelant kill(2) , certains signaux sont envoyés par le noyau (ou parfois par le processus lui-même) dans diverses circonstances :

• Les pilotes de terminaux envoient des signaux correspondant à divers événements :
  • Notifications d'appui sur les touches :SIGINT (veuillez revenir à la boucle principale) sur Ctrl +C , SIGQUIT (veuillez quitter immédiatement) sur Ctrl + , SIGTSTP (veuillez suspendre) sur Ctrl +Z . Les clés peuvent être changées avec le stty commande.
  • SIGTTIN et SIGTTOU sont envoyés lorsqu'un processus d'arrière-plan essaie de lire ou d'écrire sur son terminal de contrôle.
  • SIGWINCH est envoyé pour signaler que la taille de la fenêtre du terminal a changé.
  • SIGHUP est envoyé pour signaler que le terminal a disparu (historiquement car votre modem avait h ung vers le haut , de nos jours généralement parce que vous avez fermé la fenêtre de l'émulateur de terminal).
• Certains déroutements de processeur peuvent générer un signal. Les détails dépendent de l'architecture et du système ; voici des exemples typiques :
  • SIGBUS pour une mémoire à accès non aligné ;
  • SIGSEGV pour un accès à une page non mappée ;
  • SIGILL pour une instruction illégale (mauvais opcode);
  • SIGFPE pour une instruction en virgule flottante avec de mauvais arguments (par exemple sqrt(-1) ).
• Un certain nombre de signaux informent le processus cible qu'un événement système s'est produit :
  • SIGALRM notifie qu'un temporisateur défini par le processus a expiré. Les minuteries peuvent être réglées avec alarm , setitimer et autres.
  • SIGCHLD notifie un processus que l'un de ses enfants est décédé.
  • SIGPIPE est généré lorsqu'un processus essaie d'écrire dans un tube lorsque la fin de lecture a été fermée (l'idée est que si vous exécutez foo | bar et bar sort, foo se fait tuer par un SIGPIPE ).
  • SIGPOLL (aussi appelé SIGIO ) notifie le processus qu'un événement pollable s'est produit. POSIX spécifie les événements pollables enregistrés via le I_SETSIG ioctl . De nombreux systèmes autorisent les événements pollables sur n'importe quel descripteur de fichier, défini via le O_ASYNC fcntl drapeau. Un signal associé est SIGURG , qui notifie les données urgentes sur un appareil (enregistré via le I_SETSIG ioctl ) ou socket.
  • Sur certains systèmes, SIGPWR est envoyé à tous les processus lorsque l'onduleur signale qu'une panne de courant est imminente.

Connexes :Linux - Montage Union sur Linux ?

Ces listes ne sont pas exhaustives. Les signaux standards sont définis dans signal.h .

La plupart des signaux peuvent être capturés et traités (ou ignorés) par l'application. Les deux seuls signaux portables qui ne peuvent pas être capturés sont SIGKILL (juste mourir) et STOP (arrêter l'exécution).

SIGSEGV (défaut de segmentation) et son cousin SIGBUS (erreur de bus) peut être attrapé, mais c'est une mauvaise idée à moins que vous ne sachiez vraiment ce que vous faites. Une application courante pour les intercepter consiste à imprimer une trace de pile ou d'autres informations de débogage. Une application plus avancée consiste à implémenter une sorte de gestion de la mémoire in-process ou à piéger les mauvaises instructions dans les moteurs de machines virtuelles.

Enfin, permettez-moi de mentionner quelque chose qui n'est pas un signal. Lorsque vous appuyez sur Ctrl +D au début d'une ligne dans un programme qui lit l'entrée du terminal, cela indique au programme que la fin du fichier d'entrée est atteinte. Ce n'est pas un signal :il est transmis via l'API d'entrée/sortie. Comme Ctrl +C et amis, la clé peut être configurée avec stty .