Why Do Docker Containers Exit Instantly? Understanding PID 1 and Init

Many Docker beginners encounter containers that stop immediately after launch, with no error logs. The cause is not a mistake in the Dockerfile but the way Docker handles the main process: when the foreground command exits, the container stops.

Using the official nginx Dockerfile as an example, the CMD instruction runs nginx -g 'daemon off;' instead of systemctl nginx start or /etc/init.d/nginx start. Running nginx as a daemon would cause the start command to finish, making the container exit.

To understand why a finished command ends the container, we need to look at the Linux kernel. After boot, the kernel starts the init process (PID 1), which becomes the parent of all user‑space processes. Important concepts include:

Process table entry : each process has a record in the kernel’s process table, storing state, file descriptors, etc.

Zombie process : a process that has terminated but whose exit status has not yet been collected by its parent via wait / waitpid.

Orphan process : a process whose parent has exited; it is adopted by the init process (PID 1) which then reaps it.

In a Docker container, there is no separate init process. The process designated by CMD or ENTRYPOINT becomes PID 1 inside the container because Docker uses Linux PID namespaces to present that process as the root of its own process tree.

When you run docker run -d nginx, the nginx process started by the Dockerfile is PID 1 in the container. Killing that process on the host terminates the container, which explains why the container exits as soon as the command finishes.

Inside the container, ps shows the parent PID as 0. This is because the container’s process tree is a branch of the host’s tree; the host process containerd‑shim (PID 0 from the container’s view) is the actual parent.

The container creation flow is:

docker‑containerd‑shim

runC (the OCI reference implementation)

entrypoint process

runC sets up cgroups and namespaces, then exits after the container is started, which is why you do not see a persistent runC process.

Understanding these details helps you keep the main process in the foreground, preventing the container from exiting immediately.