Este team de redactores ha pasado horas investigando la respuesta a tus búsquedas, te ofrecemos la respuesta por esto nuestro objetivo es servirte de gran ayuda.
Solución:
¿Es que docker stop intenta detener la ejecución del proceso dentro del contenedor de la manera correcta, mientras que docker kill enviará una señal de finalización?
Básicamente sí, la diferencia es sutil, pero se describe en la referencia de la línea de comandos:
- parada de la ventana acoplable: Detener un contenedor en ejecución (enviar SIGTERM, y luego SIGKILL después del período de gracia) […] El proceso principal dentro del contenedor recibirá SIGTERM y, después de un período de gracia, SIGKILL. [emphasis mine]
- Docker matar: Matar un contenedor en ejecución (enviar SIGKILL, o señal especificada) […] El proceso principal dentro del contenedor se enviará SIGKILL, o cualquier señal especificada con la opción –signal. [emphasis mine]
Entonces stop intenta activar un apagado correcto enviando la señal POSIX estándar SIGTERMmientras que killsimplemente elimina el proceso de forma predeterminada (pero también permite enviar cualquier otra señal):
La señal SIGTERM se envía a un proceso para solicitar su terminación. A diferencia de la señal SIGKILL, el proceso puede captarla e interpretarla o ignorarla. Esto permite que el proceso realice una buena terminación, liberando recursos y guardando el estado, si corresponde. Cabe señalar que SIGINT es casi idéntico a SIGTERM.
Si bien no se aplica de ninguna manera, generalmente se espera que los procesos manejen SIGTERM con gracia y hacer lo correcto según sus responsabilidades; esto puede fallar fácilmente debido a que el intento de apagado correcto toma más tiempo que el período de gracia, lo cual es algo a considerar si la integridad de los datos es primordial (por ejemplo, para las bases de datos); véase, por ejemplo, SIGTERM vs. SIGKILL del mayor Hayden para obtener una explicación más detallada:
La aplicación puede determinar qué quiere hacer una vez que se recibe un SIGTERM. Si bien la mayoría de las aplicaciones limpiarán sus recursos y se detendrán, es posible que algunas no lo hagan. Una aplicación puede configurarse para hacer algo completamente diferente cuando se recibe un SIGTERM. Además, si la aplicación está en mal estado, como esperando la E/S del disco, es posible que no pueda actuar sobre la señal que se envió.
docker kill detendrá abruptamente el proceso/programa del punto de entrada principal
docker stop tratará de detenerlo con gracia (preguntará cortésmente: P)
en ambos casos, los cambios en el sistema de archivos persistirán (en el momento de detener o eliminar), por lo que si docker start entonces continuará desde allí.
Y además de las respuestas agregadas anteriormente
corriendo docker events después docker stop muestra eventos
- matar (señal 15): donde señal 15 = SIGTERM
- morir
- detener
corriendo docker events después docker kill muestra eventos
- matar (señal 9): donde señal 9 = SIGKILL
- Muere (Código de salida 137)
docker stop tiene un tiempo de espera antes de matar el proceso. El valor predeterminado es 10 segundos.
Esta tabla tiene aún más detalles.
Nos puedes añadir valor a nuestro contenido informacional tributando tu veteranía en las anotaciones.