Container Lifecycle & Runtime Management
A Docker container is a stateful process bound by the Linux kernel. To maintain high availability in production, DevOps teams must control the full container state machine, diagnose exit codes (such as OOMKilled), configure automated recovery policies, and enforce hard CPU, memory, and PID quotas using cgroups v2.
1. The Container Process State Machine
Containers traverse deterministic state transitions throughout their operational life cycle:
| State | Kernel & Engine Mechanics | Transition Command |
|---|---|---|
| Created | Namespaces, rootfs overlay, and network veth pairs allocated. PID 1 not yet spawned. | docker create <image> |
| Running | PID 1 executing inside kernel namespaces. Standard I/O streams active. | docker start <id> or docker run |
| Paused | Kernel uses cgroup.freeze to suspend all process threads. Memory state preserved in RAM; 0% CPU consumption. | docker pause <id> (resume with docker unpause) |
| Restarting | Container process crashed or terminated, and the daemon is executing recovery based on restart policy. | Automatic via daemon monitor |
| Exited / Stopped | PID 1 terminated. Network interfaces torn down. Writable container layer preserved on disk. | docker stop <id> or self-exit |
| Deleted | Writable container layer and overlay2 mount points purged from host storage. | docker rm <id> |
Diagnostic Exit Codes
When inspecting an exited container (docker inspect -f '{{.State.ExitCode}}' <id>):
- 0: Success / Clean intentional termination.
- 1: Application-level exception or uncaught code error.
- 137 (128 + 9): OOMKilled or SIGKILL. The Linux Out-Of-Memory killer terminated the container for exceeding
--memorylimits, ordocker killwas issued. - 143 (128 + 15): SIGTERM. Container stopped gracefully via
docker stop.
2. Automated Recovery: Restart Policies
Restart policies govern whether the Docker daemon restarts your container upon process failure or host system reboot:
| Policy | Behavior upon Application Crash | Behavior upon Host Daemon Reboot | Recommended Use Case |
|---|---|---|---|
no | Does not restart. | Remains stopped. | Batch jobs, database migrations, CI runners. |
on-failure[:max] | Restarts only if exit code != 0 (up to max attempts). | Remains stopped. | Transient workers with failure recovery. |
always | Restarts unconditionally. | Always starts on boot, even if manually stopped. | Critical infrastructure daemons. |
unless-stopped | Restarts unconditionally. | Starts on boot unless explicitly stopped by a human prior to reboot. | Production Standard for Web Apps & APIs. |
# Production best practice: unless-stopped
docker run -d --name payment-service --restart unless-stopped payment-api:v23. Resource Quotas with cgroups v2
Without resource limits, a memory leak or infinite CPU loop inside one container can starve the host OS kernel and cause server crashes. Always enforce hard boundaries:
docker run -d \
--name web-app \
--memory="1024m" \
--memory-swap="2048m" \
--cpus="2.5" \
--pids-limit="200" \
my-app:latestMemory Limit (--memory)
Sets the maximum RAM ceiling. If the application allocates beyond 1024 MB, the Linux kernel invokes the OOM killer.
CPU Quota (--cpus)
Allocates Fractional CPU compute time. --cpus=2.5 guarantees the container can access at most 2.5 cores per scheduling period.
PIDs Limit (--pids-limit)
Prevents catastrophic fork-bomb exploits or thread leaks by limiting the maximum concurrent processes inside that container's PID namespace.
4. Dynamic Container Healthchecks
A container may be in the running state while its internal web application is deadlocked or throwing 500 errors. Native health checks probe internal HTTP endpoints:
docker run -d \
--name api-server \
--health-cmd="curl -f http://localhost:8080/health || exit 1" \
--health-interval=15s \
--health-timeout=3s \
--health-retries=3 \
--health-start-period=10s \
my-api:v1During the first 10 seconds (start-period), failures do not mark the container as unhealthy. Once 3 consecutive retries fail, Docker marks the container status as (unhealthy), alerting orchestrators like Docker Compose to restart it.
Next Up: Docker Volumes & Persistent Storage
In Chapter 9, master stateful database persistence using Named Volumes, Bind Mounts, and in-memory tmpfs mounts.
Chapter 09: Docker Volumes & Persistence →
