quelle est la différence entre `docker stop` et` docker kill`?
Quelle est la différence entre docker stop et docker kill?
Afaik, les deux vont arrêter un conteneur en cours d'exécution. Est-ce que docker stop tente d'arrêter le processus exécuté correctement dans le conteneur, alors que docker kill envoie un signal de suppression? Si tel est le cas, comment docker stop saura-t-il arrêter correctement le processus en cours d'exécution? (Puisque cela diffère d'un processus à l'autre)
Est-ce que docker stop tente d'arrêter correctement le processus exécuté dans le conteneur, alors que docker kill enverra un signal de destruction?
En gros, oui, la différence est subtile, mais décrite dans la ligne de commande référence:
- docker stop : arrête un conteneur en cours d'exécution ( envoie SIGTERM, puis SIGKILL après la période de grâce ) [...] Le processus principal à l'intérieur du conteneur recevra SIGTERM, et après un délai de grâce période, SIGKILL. [c'est moi qui souligne]
- docker kill : Tuer un conteneur en cours d'exécution ( envoyer SIGKILL ou un signal spécifié ) [...] Le processus principal à l'intérieur du conteneur sera envoyé à SIGKILL ou tout autre signal spécifié avec l'option --signal. [c'est moi qui souligne]
Donc stop tente de déclencher un arrêt normal en envoyant le signal standard POSIXSIGTERM, alors que killjust tue le processus par défaut (mais permet également d’envoyer tout autre signal):
Le signal SIGTERM est envoyé à un processus pour demander sa terminaison. Contrairement au signal SIGKILL, il peut être capturé et interprété ou ignoré par le processus. Cela permet au processus d'effectuer une terminaison Nice en libérant des ressources et en sauvegardant l'état si nécessaire. Il convient de noter que SIGINT est presque identique à SIGTERM.
Bien qu'ils ne soient pas appliqués de toute façon, les processus sont généralement censés gérer SIGTERM et faire ce qui est bien en fonction de leurs responsabilités - cela peut facilement échouer en raison de la tentative d'arrêt harmonieux prenant plus longtemps que le délai de grâce, ce qui est à prendre en compte si l'intégrité des données est primordial (par exemple pour les bases de données); voir par exemple Major Hayden's SIGTERM vs. SIGKILL pour une explication plus détaillée:
L'application peut déterminer ce qu'elle veut faire une fois qu'un SIGTERM est reçu. Bien que la plupart des applications nettoient leurs ressources et s’arrêtent, certaines ne le peuvent pas. Une application peut être configurée pour faire quelque chose de complètement différent lorsqu’un SIGTERM est reçu. De plus, si l'application est dans un mauvais état, par exemple en attente d'E/S de disque, il est possible qu'elle ne puisse pas agir sur le signal envoyé.
docker kill arrêtera brusquement le processus/programme principal du point d'entrée
docker stop va essayer de l'arrêter gracieusement (demandera poliment: P)
dans les deux cas, les modifications du système de fichiers seront persistées (au moment de l'arrêt ou de la suppression), donc si vous docker start <container>, il continuera à partir de là.
Et en plus des réponses ajoutées plus tôt
docker events après docker stop affiche les événements
- kill (signal 15): où signal 15 = SIGTERM
- mourir
- arrêtez
docker events après docker kill affiche les événements
- kill (signal 9): où signal 9 = SIGKILL
- Die (code de sortie 137)
docker stop a un délai d'expiration avant de tuer le processus. La valeur par défaut est 10 secondes.
Ce tableau a encore plus de détails.
C'est analogue à Retirer la prise du bureau et Arrêter l'ordinateur
De la même manière que tirer sur Plug Off signifie éteindre durement, docker kill signifie le moyen direct de tuer my_container, qui ne tente pas d’arrêter le processus correctement en premier.
Arrêter l'ordinateur signifie envoyer un signal au système d'exploitation pour arrêter tous les processus, où docker stop signifie envoyer un signal SIGTERM au conteneur en cours d'exécution pour arrêter les processus en douceur.