Donc, les gars, allons de l'avant, ensuite, discutons des signaux bien connus de Linux.
Le nombre total de signaux pris en charge par le système d'exploitation Linux est donc d'environ 30.
Nous allons examiner ici quelques-uns des signaux les plus couramment utilisés et les plus couramment observés
dans Linux.
Le premier signal est donc le signal sig int.
Ce signal est généré par le système d'exploitation et transmis au processus lorsque l'utilisateur appuie
sur Ctrl C.
Vous avez donc dû mettre fin à certaines applications sous Linux en utilisant uniquement la touche Ctrl C.
Ainsi, dès que vous appuyez sur la touche Ctrl C, le signal de type sig int est transmis au processus.
par le système d'exploitation sous-jacent.
Ce signal est donc également appelé signal d'interruption.
Le comportement par défaut du signal est donc de mettre fin à l'application.
Toutefois, vous pouvez modifier le comportement par défaut du signal.
En d'autres termes, votre processus peut effectuer un traitement personnalisé lorsque la touche de contrôle est enfoncée.
C'est vrai.
Nous verrons donc plus tard comment cela est possible.
Le deuxième type de signaux est celui qui est réservé à l'usage de l'utilisateur.
Les deuxième et troisième signaux nous indiquent donc SR un et SR deux.
Ce type de signaux est envoyé par le processus.
P1 au processus.
P2 Et lorsque le processus P2 reçoit ce type de signaux, nous pouvons le définir.
Qu'est-ce que le processus P2 est censé faire lorsqu'il reçoit ces signaux, n'est-ce pas ?
C'est donc la raison pour laquelle ces signaux sont des signaux définis par l'utilisateur et sont laissés à la disposition de l'utilisateur,
n'est-ce pas ?
Linux n'a pas défini cela.
Que doit faire le processus par défaut lorsqu'il reçoit le signal ?
Le troisième signal est du type sigkill.
C'est vrai.
Ce signal est donc généré par le système d'exploitation et transmis au processus qui s'exécute dans l'espace
utilisateur.
Lorsque le processus reçoit ce signal, il est immédiatement interrompu.
C'est vrai.
Ce signal ne peut pas être capté par le processus pour effectuer son propre traitement personnalisé.
C'est vrai.
Ce signal est donc agressif.
Le signal ?
Pourquoi ?
Parce que.
Parce que le processus ne peut pas couper ce signal pour effectuer son propre traitement personnalisé.
C'est vrai.
Et comment ce signal est généré.
Ce signal est généré par la commande kill minus nine.
Prenons un exemple du fonctionnement de sigkill.
Disons que dans ma fenêtre, je lance un nouveau processus, disons RPD, n'est-ce pas ?
Je dois maintenant trouver l'ID du processus qui est attribué à ce processus.
Dans l'autre fenêtre, vous pouvez donc simplement exécuter la commande PS hyphen grep RPD.
Cette commande vous donnera l'identifiant du processus qui est assigné à ce processus.
Je veux maintenant envoyer un signal Sigkill à ce processus.
Pour ce faire, je vais exécuter la commande kill minus nine et spécifier l'identifiant du processus auquel vous
souhaitez envoyer le signal.
C'est vrai.
Maintenant, par définition de ce signal, au moment où j'exécute cette commande, le processus
qui a l'ID 11912 sera tué immédiatement.
C'est vrai.
Ainsi, si j'appuie sur la touche Entrée, vous pouvez voir dans l'autre fenêtre dans laquelle j'ai démarré le processus, qu'il est simplement tué par
le système d'exploitation.
C'est vrai.
Et le processus n'est plus en cours d'exécution.
C'est vrai.
La théorie derrière la commande kill minus nine est que lorsque vous exécutez la commande kill minus nine et contre
cette commande, vous fournissez l'ID du processus en tant qu'argument.
Ce processus reçoit alors le signal sigkill.
Le comportement par défaut de ce signal est que le processus se termine immédiatement et que ce signal ne peut pas être
écrasé par le processus pour effectuer un traitement personnalisé.
Le signal suivant est le signal d'abandon de Sig.
Ce signal est émis par un appel système spécial appelé Abort.
Ainsi, chaque fois qu'un processus exécute cet appel système, un signal est envoyé par le système d'exploitation au processus
qui a invoqué le système.
Appeler à droite.
Ce signal ne peut pas être bloqué.
En d'autres termes, ce signal ne peut pas être capté par le processus pour effectuer son propre traitement personnalisé.
Dès que le processus reçoit ce signal, il se termine.
Nous discuterons donc de l'utilisation de cet appel système d'abandon, lorsque nous aborderons la mise en œuvre
de cet appel système d'abandon.
Le signal suivant est le signal sigterm.
Ce signal n'est donc pas très différent de celui de Sigkill.
La seule différence est que le signal Sigterm peut être capté par le processus et que ce dernier peut choisir d'effectuer
son propre traitement personnalisé en réponse à la réception du signal Sigterm.
C'est vrai.
Alors que le signal de Sigkill était en fait un signal agressif qui ne pouvait pas être capté.
C'est vrai.
Ainsi, le comportement par défaut de la réception du signal sigterm est que la réception de ce signal.
Le processus est interrompu.
Ce signal est transmis par le système d'exploitation au processus à l'aide de la commande kill.
Il n'est pas nécessaire de spécifier moins neuf avec cette commande.
Ainsi, si vous spécifiez simplement kill et juste vous, et si vous spécifiez simplement l'ID du processus, le système
d'exploitation émettra un signal sigterm au processus dont l'ID est spécifié en tant qu'argument de la commande kill.
Le signal suivant est le signal sigsegv.
Si vous avez déjà écrit et exécuté un programme C, vous avez dû voir cette erreur de segmentation.
Vous saurez maintenant pourquoi l'erreur de segmentation se produit.
Ainsi, chaque fois qu'un processus exécute une mémoire illégale, c'est-à-dire chaque fois qu'un processus
tente d'accéder à la mémoire qui se trouve en dehors de l'espace d'adressage virtuel d'un processus, le système
d'exploitation génère le signal sigsegv et délivre ce signal au processus qui a tenté d'accéder à cette mémoire illégale.
C'est vrai ?
Ainsi, chaque fois qu'un processus reçoit ce signal, il se termine et affiche un message d'erreur de
segmentation sur la console.
Là encore, il s'agit d'un signal agressif qui ne peut être capté par le processus.
Ainsi, chaque fois que votre processus tente d'accéder à la mémoire illégale, le système d'exploitation envoie un signal à votre
processus.
Chaque fois que votre processus reçoit ce signal, il s'arrête, en signalant une erreur de
segmentation.
Un autre signal est celui de l'enfant malade.
Ainsi, chaque fois qu'un enfant s'éteint.
Ici, enfant signifie un processus enfant d'un processus.
Vous avez donc un processus P qui s'exécute sur le système et qui utilise l'appel système fork.
Si vous avez entendu parler de ce système de fourche, chaque fois qu'un processus P invoque un appel au système de fourche, un nouveau
processus P1 est créé.
Ce processus P1 est considéré comme le processus fils du processus.
P.
À l'heure actuelle, il est possible que le processus P1 ait terminé sa tâche et qu'il ait choisi
de s'arrêter.
Ainsi, chaque fois qu'un processus enfant se termine avant le processus parent, le signal est envoyé par le système d'exploitation
au processus parent.
Ce signal est malade.
Signal de l'enfant.
C'est vrai.
Ainsi, six signaux enfants sont des signaux délivrés au processus P par le système d'exploitation.
Chaque fois que le processus enfant du processus parent se termine.
À la réception du signal, le parent doit exécuter l'appel système wait pour connaître l'état de l'enfant.
Il s'agit là de quelque chose de profond que vous n'êtes pas censé comprendre dans le cadre de ce cours.
Si vous allez explorer le système de fourche, faire appel à la profondeur, alors seule cette ligne est pertinente
pour vous.
Pour l'instant, il suffit de comprendre qu'à chaque fois qu'un processus enfant se termine, le système d'exploitation envoie
six signaux enfant au processus.
P.
Voici donc les différents signaux célèbres dont nous avons parlé.
Il existe bien sûr d'autres types de signaux.
Je vous laisse le soin de naviguer sur Internet et de découvrir quels sont les autres signaux fournis par le
système d'exploitation Linux et quelles sont leurs utilisations.
Mais les signaux les plus couramment utilisés sont ceux dont nous avons déjà parlé.