What Happens to Other Processes When a Docker Container's Pid1 Exits

What happens to other processes when a Docker container's PID1 exits?

OK, I seem to have come up with some more solid evidence that this is, in fact, the Linux kernel doing the terminating. In the clone(2) man page, there's this useful section:

CLONE_NEWPID (since Linux 2.6.24)

The first process created in a new namespace (i.e., the process
created using the CLONE_NEWPID flag) has the PID 1, and is the
"init" process for the namespace. Children that are orphaned
within the namespace will be reparented to this process rather than
init(8). Unlike the traditional init process, the "init" process of a
PID namespace can terminate, and if it does, all of the processes in
the namespace are terminated.

Unfortunately this is still vague on how exactly the processes in the namespace are terminated, but perhaps that's because, unlike a normal process exit, no entry is left in the process table. Whatever the case is, it seems clear that:

• The kernel itself is killing the other processes
• They are not killed in a way that allows them any chance to do cleanup, making it (almost?) identical to a SIGKILL

how does docker treat child process when we send stop to pid 1

Docker won't do anything here. It just signals PID 1. If PID 1 has children, it is expected to handle signaling them. This is the standard unix model.

For some more info you can read Docker and the PID 1 Zombie Reaping Problem.

When PID 1 exits, the container will exit, so the children will not necessarily exit gracefully. If you want them to exit gracefully you will have to have something hanging around that knows how to do that.

The link above offers one solution, an image from Phusion which has an init-style PID 1 to handle things like this. There are other solutions; that is only one option.

Docker container exits even when run with -it

Compare how long live those 2 containers

1)
docker run -it ubuntu sh -c "echo Hello ; sleep 3"

2)
docker run -it ubuntu sh -c "while true ; do echo Hello ; sleep 3 ; done"

Check the doc for CMD

https://docs.docker.com/engine/reference/builder/#cmd

and ENTRYPOINT

https://docs.docker.com/engine/reference/builder/#entrypoint

When you

docker run -it ubuntu bash

as long as you exit from your bash,your container completes and exits.

check also

What is the difference between CMD and ENTRYPOINT in a Dockerfile?

`

How does a docker container restart work?

A Docker container has one primary process. docker restart does two things:

1. It does the equivalent of docker stop. It sends SIGTERM to its primary process (only); if that doesn't terminate within 10 seconds, it sends SIGKILL. If the primary process still has children, they also get forcibly terminated.
2. It does the equivalent of docker start. In the container that already exists, it runs the container's command, constructed by concatenating its entrypoint and command lists.

Note that both of these focus on one process. If that process is a dedicated process manager like supervisord, the docker stop sequence will hopefully cause the supervisor to gracefully stop every process it's managing and you'll be okay. If it's a shell script that starts a bunch of background processes and ignores them, they'll just get killed with no warning. Similarly, if the main container process knows how to start its children then docker start will cause that to happen again, but if it was an interactive shell and you hand-started background processes, they are lost.

Docker doesn't have any sort of "snapshot" mechanism. The general model is that containers always start from a clean and known state, and can reconstruct whatever they need from there. It fits better with this model to docker rm a stopped container and docker run a new one than to try to docker start it again.

Why does trying to kill a process in Docker container take me out of it?

Every docker container has an ENTRYPOINT that will either be set in the dockerfile, using ENTRYPOINTor CMD declarations, or specified in the run command docker run myimage:tag "entrypoint_command". When the ENTRYPOINT process is killed, I think the container gets killed as well. The docker exec, as I understand it, is kind of like "attaching" command to a container. But if the ENTRYPOINT is down there is no container to attach to.

Kubernetes will restart a container after failure as far as I understand it. Which might be the reason you see the process is back up. I haven't really worked with Kubernetes but I'd try and play around with the way that the replications are scaled to terminate your process.

---

Related Topics