WEBVTT 00:05.030 --> 00:11.040 Donc, les gars, allons de l'avant, ensuite, discutons des signaux bien connus de Linux. 00:11.060 --> 00:16.370 Le nombre total de signaux pris en charge par le système d'exploitation Linux est donc d'environ 30. 00:16.520 --> 00:22.730 Nous allons examiner ici quelques-uns des signaux les plus couramment utilisés et les plus couramment observés 00:22.730 --> 00:23.780 dans Linux. 00:24.410 --> 00:27.650 Le premier signal est donc le signal sig int. 00:27.920 --> 00:34.850 Ce signal est généré par le système d'exploitation et transmis au processus lorsque l'utilisateur appuie 00:34.850 --> 00:35.930 sur Ctrl C. 00:36.140 --> 00:41.640 Vous avez donc dû mettre fin à certaines applications sous Linux en utilisant uniquement la touche Ctrl C. 00:41.660 --> 00:49.640 Ainsi, dès que vous appuyez sur la touche Ctrl C, le signal de type sig int est transmis au processus. 00:50.780 --> 00:52.820 par le système d'exploitation sous-jacent. 00:54.980 --> 00:58.280 Ce signal est donc également appelé signal d'interruption. 00:58.490 --> 01:03.320 Le comportement par défaut du signal est donc de mettre fin à l'application. 01:04.100 --> 01:07.130 Toutefois, vous pouvez modifier le comportement par défaut du signal. 01:07.130 --> 01:12.380 En d'autres termes, votre processus peut effectuer un traitement personnalisé lorsque la touche de contrôle est enfoncée. 01:12.710 --> 01:13.400 C'est vrai. 01:13.400 --> 01:17.090 Nous verrons donc plus tard comment cela est possible. 01:18.060 --> 01:23.650 Le deuxième type de signaux est celui qui est réservé à l'usage de l'utilisateur. 01:23.670 --> 01:29.220 Les deuxième et troisième signaux nous indiquent donc SR un et SR deux. 01:29.370 --> 01:32.070 Ce type de signaux est envoyé par le processus. 01:32.100 --> 01:33.360 P1 au processus. 01:33.390 --> 01:39.150 P2 Et lorsque le processus P2 reçoit ce type de signaux, nous pouvons le définir. 01:39.150 --> 01:44.610 Qu'est-ce que le processus P2 est censé faire lorsqu'il reçoit ces signaux, n'est-ce pas ? 01:44.610 --> 01:50.490 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, 01:50.880 --> 01:51.690 n'est-ce pas ? 01:51.840 --> 01:53.820 Linux n'a pas défini cela. 01:53.820 --> 01:58.140 Que doit faire le processus par défaut lorsqu'il reçoit le signal ? 01:59.860 --> 02:03.130 Le troisième signal est du type sigkill. 02:03.340 --> 02:04.120 C'est vrai. 02:04.120 --> 02:09.880 Ce signal est donc généré par le système d'exploitation et transmis au processus qui s'exécute dans l'espace 02:09.880 --> 02:11.120 utilisateur. 02:11.140 --> 02:16.670 Lorsque le processus reçoit ce signal, il est immédiatement interrompu. 02:16.690 --> 02:17.350 C'est vrai. 02:17.350 --> 02:23.480 Ce signal ne peut pas être capté par le processus pour effectuer son propre traitement personnalisé. 02:23.500 --> 02:24.070 C'est vrai. 02:24.070 --> 02:25.780 Ce signal est donc agressif. 02:25.780 --> 02:26.290 Le signal ? 02:26.290 --> 02:26.710 Pourquoi ? 02:26.740 --> 02:27.670 Parce que. 02:27.670 --> 02:34.240 Parce que le processus ne peut pas couper ce signal pour effectuer son propre traitement personnalisé. 02:34.480 --> 02:35.140 C'est vrai. 02:35.140 --> 02:37.090 Et comment ce signal est généré. 02:37.120 --> 02:41.140 Ce signal est généré par la commande kill minus nine. 02:41.890 --> 02:45.700 Prenons un exemple du fonctionnement de sigkill. 02:45.940 --> 02:51.790 Disons que dans ma fenêtre, je lance un nouveau processus, disons RPD, n'est-ce pas ? 02:51.820 --> 02:56.800 Je dois maintenant trouver l'ID du processus qui est attribué à ce processus. 02:57.460 --> 03:03.550 Dans l'autre fenêtre, vous pouvez donc simplement exécuter la commande PS hyphen grep RPD. 03:03.880 --> 03:08.590 Cette commande vous donnera l'identifiant du processus qui est assigné à ce processus. 03:08.740 --> 03:13.120 Je veux maintenant envoyer un signal Sigkill à ce processus. 03:13.120 --> 03:20.680 Pour ce faire, je vais exécuter la commande kill minus nine et spécifier l'identifiant du processus auquel vous 03:20.680 --> 03:22.840 souhaitez envoyer le signal. 03:23.020 --> 03:23.740 C'est vrai. 03:23.770 --> 03:30.760 Maintenant, par définition de ce signal, au moment où j'exécute cette commande, le processus 03:30.760 --> 03:34.180 qui a l'ID 11912 sera tué immédiatement. 03:35.120 --> 03:35.690 C'est vrai. 03:35.690 --> 03:42.920 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 03:42.920 --> 03:44.330 le système d'exploitation. 03:44.330 --> 03:44.990 C'est vrai. 03:44.990 --> 03:47.810 Et le processus n'est plus en cours d'exécution. 03:48.540 --> 03:49.080 C'est vrai. 03:49.080 --> 03:56.250 La théorie derrière la commande kill minus nine est que lorsque vous exécutez la commande kill minus nine et contre 03:56.250 --> 04:01.410 cette commande, vous fournissez l'ID du processus en tant qu'argument. 04:01.440 --> 04:06.150 Ce processus reçoit alors le signal sigkill. 04:06.150 --> 04:13.800 Le comportement par défaut de ce signal est que le processus se termine immédiatement et que ce signal ne peut pas être 04:13.800 --> 04:18.620 écrasé par le processus pour effectuer un traitement personnalisé. 04:18.630 --> 04:21.960 Le signal suivant est le signal d'abandon de Sig. 04:21.990 --> 04:26.340 Ce signal est émis par un appel système spécial appelé Abort. 04:26.340 --> 04:32.940 Ainsi, chaque fois qu'un processus exécute cet appel système, un signal est envoyé par le système d'exploitation au processus 04:32.940 --> 04:34.740 qui a invoqué le système. 04:34.740 --> 04:36.180 Appeler à droite. 04:36.210 --> 04:38.820 Ce signal ne peut pas être bloqué. 04:38.820 --> 04:44.190 En d'autres termes, ce signal ne peut pas être capté par le processus pour effectuer son propre traitement personnalisé. 04:44.190 --> 04:49.240 Dès que le processus reçoit ce signal, il se termine. 04:50.340 --> 04:56.100 Nous discuterons donc de l'utilisation de cet appel système d'abandon, lorsque nous aborderons la mise en œuvre 04:56.100 --> 04:57.930 de cet appel système d'abandon. 04:59.160 --> 05:02.100 Le signal suivant est le signal sigterm. 05:02.100 --> 05:06.220 Ce signal n'est donc pas très différent de celui de Sigkill. 05:06.240 --> 05:13.380 La seule différence est que le signal Sigterm peut être capté par le processus et que ce dernier peut choisir d'effectuer 05:13.380 --> 05:19.350 son propre traitement personnalisé en réponse à la réception du signal Sigterm. 05:20.570 --> 05:21.140 C'est vrai. 05:21.140 --> 05:26.360 Alors que le signal de Sigkill était en fait un signal agressif qui ne pouvait pas être capté. 05:27.020 --> 05:27.620 C'est vrai. 05:27.620 --> 05:33.830 Ainsi, le comportement par défaut de la réception du signal sigterm est que la réception de ce signal. 05:33.860 --> 05:35.720 Le processus est interrompu. 05:36.920 --> 05:42.350 Ce signal est transmis par le système d'exploitation au processus à l'aide de la commande kill. 05:42.380 --> 05:45.900 Il n'est pas nécessaire de spécifier moins neuf avec cette commande. 05:45.920 --> 05:53.120 Ainsi, si vous spécifiez simplement kill et juste vous, et si vous spécifiez simplement l'ID du processus, le système 05:53.120 --> 06:00.530 d'exploitation émettra un signal sigterm au processus dont l'ID est spécifié en tant qu'argument de la commande kill. 06:02.150 --> 06:05.540 Le signal suivant est le signal sigsegv. 06:05.900 --> 06:12.140 Si vous avez déjà écrit et exécuté un programme C, vous avez dû voir cette erreur de segmentation. 06:12.350 --> 06:17.090 Vous saurez maintenant pourquoi l'erreur de segmentation se produit. 06:17.930 --> 06:24.230 Ainsi, chaque fois qu'un processus exécute une mémoire illégale, c'est-à-dire chaque fois qu'un processus 06:24.230 --> 06:30.910 tente d'accéder à la mémoire qui se trouve en dehors de l'espace d'adressage virtuel d'un processus, le système 06:31.040 --> 06:38.660 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. 06:38.810 --> 06:39.410 C'est vrai ? 06:39.410 --> 06:46.040 Ainsi, chaque fois qu'un processus reçoit ce signal, il se termine et affiche un message d'erreur de 06:46.040 --> 06:48.200 segmentation sur la console. 06:48.710 --> 06:54.530 Là encore, il s'agit d'un signal agressif qui ne peut être capté par le processus. 06:55.010 --> 07:02.600 Ainsi, chaque fois que votre processus tente d'accéder à la mémoire illégale, le système d'exploitation envoie un signal à votre 07:02.600 --> 07:03.440 processus. 07:03.440 --> 07:08.270 Chaque fois que votre processus reçoit ce signal, il s'arrête, en signalant une erreur de 07:08.270 --> 07:09.230 segmentation. 07:11.780 --> 07:14.930 Un autre signal est celui de l'enfant malade. 07:14.930 --> 07:17.120 Ainsi, chaque fois qu'un enfant s'éteint. 07:17.140 --> 07:20.750 Ici, enfant signifie un processus enfant d'un processus. 07:20.750 --> 07:25.730 Vous avez donc un processus P qui s'exécute sur le système et qui utilise l'appel système fork. 07:26.090 --> 07:33.470 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 07:33.470 --> 07:35.120 processus P1 est créé. 07:35.120 --> 07:38.630 Ce processus P1 est considéré comme le processus fils du processus. 07:38.660 --> 07:38.960 P. 07:40.130 --> 07:46.250 À l'heure actuelle, il est possible que le processus P1 ait terminé sa tâche et qu'il ait choisi 07:46.250 --> 07:47.480 de s'arrêter. 07:47.720 --> 07:53.570 Ainsi, chaque fois qu'un processus enfant se termine avant le processus parent, le signal est envoyé par le système d'exploitation 07:53.570 --> 07:55.130 au processus parent. 07:55.840 --> 07:57.640 Ce signal est malade. 07:57.640 --> 07:58.660 Signal de l'enfant. 08:00.670 --> 08:01.210 C'est vrai. 08:01.210 --> 08:06.310 Ainsi, six signaux enfants sont des signaux délivrés au processus P par le système d'exploitation. 08:06.310 --> 08:10.540 Chaque fois que le processus enfant du processus parent se termine. 08:11.600 --> 08:18.560 À la réception du signal, le parent doit exécuter l'appel système wait pour connaître l'état de l'enfant. 08:18.590 --> 08:25.680 Il s'agit là de quelque chose de profond que vous n'êtes pas censé comprendre dans le cadre de ce cours. 08:25.700 --> 08:32.090 Si vous allez explorer le système de fourche, faire appel à la profondeur, alors seule cette ligne est pertinente 08:32.090 --> 08:32.720 pour vous. 08:33.200 --> 08:38.510 Pour l'instant, il suffit de comprendre qu'à chaque fois qu'un processus enfant se termine, le système d'exploitation envoie 08:38.510 --> 08:40.010 six signaux enfant au processus. 08:40.040 --> 08:40.530 P. 08:42.260 --> 08:45.830 Voici donc les différents signaux célèbres dont nous avons parlé. 08:46.070 --> 08:49.110 Il existe bien sûr d'autres types de signaux. 08:49.140 --> 08:54.560 Je vous laisse le soin de naviguer sur Internet et de découvrir quels sont les autres signaux fournis par le 08:54.560 --> 08:58.150 système d'exploitation Linux et quelles sont leurs utilisations. 08:58.160 --> 09:02.630 Mais les signaux les plus couramment utilisés sont ceux dont nous avons déjà parlé.