linux - hub - kubernetes
¿Qué sucede con otros procesos cuando sale un PID1 de un contenedor Docker? (1)
De acuerdo, parece que se me han ocurrido pruebas más sólidas de que, de hecho, el núcleo de Linux está terminando. En la página man de clone(2) , hay esta sección útil:
CLONE_NEWPID (desde Linux 2.6.24)
El primer proceso creado en un nuevo espacio de nombres (es decir, el proceso creado utilizando el indicador CLONE_NEWPID) tiene el PID 1, y es el proceso "init" para el espacio de nombres. Los niños que quedan huérfanos dentro del espacio de nombres se volverán a representar en este proceso en lugar de init (8). A diferencia del proceso init tradicional, el proceso "init" de un espacio de nombre PID puede finalizar, y si lo hace, todos los procesos en el espacio de nombres finalizan.
Desafortunadamente, esto todavía es impreciso sobre cómo terminan exactamente los procesos en el espacio de nombres, pero quizás sea porque, a diferencia de una salida de proceso normal, no queda ninguna entrada en la tabla de procesos. Cualquiera que sea el caso, parece claro que:
- El kernel mismo está matando a los otros procesos
- No son asesinados de una manera que les permita hacer una limpieza, lo que lo hace (¿casi?) Idéntico a un SIGKILL
Considere lo siguiente, que ejecuta sleep 60 en segundo plano y luego sale:
$ cat run.sh
sleep 60&
ps
echo Goodbye!!!
$ docker run --rm -v $(pwd)/run.sh:/run.sh ubuntu:16.04 bash /run.sh
PID TTY TIME CMD
1 ? 00:00:00 bash
5 ? 00:00:00 sleep
6 ? 00:00:00 ps
Goodbye!!!
Esto iniciará un contenedor Docker, con bash como PID1. Luego bifurca / ejecuta un proceso de sleep y luego sale bash . Cuando el contenedor Docker muere, el proceso de sleep también muere de alguna manera.
Mi pregunta es: ¿cuál es el mecanismo por el cual se mata el proceso de sleep ? Intenté atrapar SIGTERM en un proceso secundario y parece que no se activó. Mi presunción es que algo (ya sea Docker o el kernel de Linux) está enviando SIGKILL al cerrar el grupo de cgroup que está usando el contenedor, pero no he encontrado ninguna documentación que aclare esto.
EDITAR Lo más cercano que he llegado a una explicación es la siguiente cita de baseimage-docker :
Si su proceso init es su aplicación, probablemente solo se cierre, no todos los demás procesos en el contenedor. El kernel luego matará a la fuerza esos otros procesos, sin darles la oportunidad de cerrar con gracia, lo que podría resultar en corrupción de archivos, archivos temporales obsoletos, etc. Realmente desea cerrar todos sus procesos con elegancia.
Al menos de acuerdo con esto, la implicación es que cuando el contenedor sale, el kernel enviará un SIGKILL a todos los procesos restantes. Pero aún me gustaría tener claridad sobre cómo decide hacerlo (es decir, ¿es una característica de cgroups?), E idealmente una fuente más autorizada sería agradable.