The Container State Machine

Look, if you've ever dealt with this in production, you know exactly what the problem is. You know how to build Images and run them. Now, we dive into what happens while the container is alive. A Docker container is fundamentally a State Machine. It transitions between specific states: Created, Running, Paused, Stopped (Exited), and Dead. Understanding exactly how a container moves between these states is critical for operating production workloads and debugging failures. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. Why does a container transition from 'Running' to 'Exited'? The answer lies in the 'PID 1 Rule'. Every container has a primary process (defined by the CMD instruction in the Dockerfile). This primary process is assigned Process ID 1 inside the container. If PID 1 is running, the container is running. The exact millisecond that PID 1 finishes, crashes, or terminates, the Docker Daemon immediately powers off the entire container. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. If a container powers off when the process crashes, what happens to your production web server if it encounters an unhandled exception at 3:00 AM? Without intervention, your website stays offline until you wake up. To fix this, Docker provides 'Restart Policies'. By passing the --restart=always flag, you command the Docker Daemon to act as a watchdog. If the container crashes, the Daemon will automatically reboot it instantly. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

The Container State Machine. You know how to build Images and run them. Now, we dive into what happens while the container is alive. A Docker container is fundamentally a State Machine. It transitions between specific states: Created, Running, Paused, Stopped (Exited), and Dead. Understanding exactly how a container moves between these states is critical for operating production workloads and debugging failures.

The PID 1 Rule. Why does a container transition from 'Running' to 'Exited'? The answer lies in the 'PID 1 Rule'. Every container has a primary process (defined by the CMD instruction in the Dockerfile). This primary process is assigned Process ID 1 inside the container. If PID 1 is running, the container is running. The exact millisecond that PID 1 finishes, crashes, or terminates, the Docker Daemon immediately powers off the entire container.

You write a Dockerfile for a database migration script. The script connects to the database, updates the tables, and finishes successfully. What happens to the Docker container immediately after the script finishes?

• →The container immediately enters the 'Exited' (Stopped) state. Because the primary process (PID 1) finished its task, the container shuts down.
• →The container stays Running, idling forever waiting for more commands.

Restart Policies. If a container powers off when the process crashes, what happens to your production web server if it encounters an unhandled exception at 3:00 AM? Without intervention, your website stays offline until you wake up. To fix this, Docker provides 'Restart Policies'. By passing the --restart=always flag, you command the Docker Daemon to act as a watchdog. If the container crashes, the Daemon will automatically reboot it instantly.

on-failure vs always. There are multiple restart policies. --restart=always means Docker will reboot the container no matter what (even if you explicitly restart the server hardware). However, --restart=on-failure is smarter for batch jobs. If a script finishes successfully (Exit Code 0), Docker leaves it stopped. But if the script crashes due to an error (Exit Code 1), Docker will reboot it. This prevents successful tasks from infinitely looping.

You have a data-processing container that takes 10 minutes to run, processes files, and exits cleanly. You want it to automatically retry if the network drops and it crashes, but you DO NOT want it to run again if it succeeds. Which policy is correct?

• →--restart=always
• →--restart=on-failure

Resilience Mastered. You now understand the Container State Machine. You know that a container's life is inextricably linked to PID 1, and that you must architect your Dockerfiles so the main process never exits. More importantly, you have learned how to configure the Docker Daemon as an automated watchdog, ensuring your applications self-heal from catastrophic crashes. Next, we will learn how to actively debug a running container.