Next, a #container is a #cgroup of processes running in their own PID namespace. This cgroup is cleaned up when the container is stopped. Any zombies that are in a container are removed on stop. They don't reach the hosts init.
10/n
Next, a #container is a #cgroup of processes running in their own PID namespace. This cgroup is cleaned up when the container is stopped. Any zombies that are in a container are removed on stop. They don't reach the hosts init.
10/n
Third is the different ways containers are used. Most run one main process and nothing else. If there is another process spawned it is usually a child of that main process. So until the parent exits, the zombie will exist. Then see point 2 (the zombies will be cleared on #container exit).
11/n
The other role an #init process can provide is to install signal handlers so signals sent from the host can be passed onto the container process. PID 1 is a bit special as it requires the process to listen for a signal for it to be received.
If you can install a SIGINT and SIGTERM signal handler in your PID 1 process then an init process doesn't add much here.
!!! Those explanations come from this superb article in #stackoverflow
https://stackoverflow.com/questions/49162358/docker-init-zombies-why-does-it-matter !!!
12/n
The solution to avoid #zombie in the #container is to use an #init process. This is included by default in #docker thanks to #tini
https://github.com/krallin/tini
13/n
The syntaxe in #DockerCompose is:
init: true
What is advantage of #tini ? https://github.com/krallin/tini/issues/8
14/n