Pourquoi Docker Kill ne parvient-il parfois pas à tuer les conteneurs en cours d'exécution ?

Processus principal Docker Kill

1. Le moteur Docker utilise SIGKILL pour envoyer au conteneur le processus principal via containersd. Un message de sortie est reçu de containersd, Ensuite, le conteneur Kill est réussi.

2. Si le délai d'attente expire à l'étape précédente, le moteur Docker ignorera Containerd et enverra le signal SIGKILL au processus principal du conteneur via l'appel système kill. Si l'appel système kill indique que le processus principal n'existe pas à ce moment-là, alors le kill de Docker réussit. Sinon, le moteur restera mort jusqu'à ce que containersd dépasse le moteur et que le conteneur sorte.

Lorsqu'un problème survient, un grand nombre de processus de stress (en fait des processus de conteneur) se trouvent sur la machine hôte comme étant à l'état D, et la réponse du système ralentit. Le problème peut être expliqué comme suit :

1. Après que Docker kill envoie indirectement le signal SIGKill au processus principal du conteneur via containersd, en raison de la réponse lente du système, le sous-processus interne (stress) du conteneur est dans l'état D, alors pendant le délai d'attente, Containerd n'a pas signalé la sortie du conteneur. Docker kill a atteint le stade de l'envoi direct de Sigkill

2 Avant cette étape, le processus principal à l'intérieur du conteneur est terminé, donc l'appel système kill pour envoyer SIGKILL retournera bientôt que le. le processus n’existe pas. Le moteur pense avoir tué le conteneur et Docker kill revient avec succès.

3. Après un certain temps, les sous-processus du conteneur récupèrent de l'état D, containersd signale la sortie du conteneur et le moteur nettoie les ressources. ps voit que le conteneur est dans l'état de sortie.

Le processus principal/enfant du conteneur est dans l'état D

L'état D du processus signifie que le processus est dans un état de veille ininterrompue, en attente généralement de ressources d'E/S. Bien sûr, parfois, s'il y a un problème avec les E/S du système, il y aura un grand nombre de processus dans l'état D. Dans cet état, le signal ne peut pas réveiller le processus ; il peut seulement attendre que le processus revienne de l’état D. Et dans le noyau conventionnel, si un processus était dans l'état D, il n'y a théoriquement aucun moyen de le récupérer depuis D, sauf en redémarrant le système.

Pour plus de tutoriels connexes, veuillez faire attention à la colonne Tutoriel Docker sur le site Web PHP chinois.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!