Learn Docker - Deep Dive into Container Lifecycle & State Management

#Introduction

After running our first containers in episode 3 and mastering the CLI fundamentals — docker run, ps, stop, start, rm, exec, logs, and port mapping — in this episode we go deeper: understanding the container lifecycle in full and how to manage its state.

Why does this matter? Because in the production world, containers rarely just "run and finish". Containers get restarted during deployment, paused during maintenance, crash and enter a restart loop, or hang in an unclear status. An engineer who doesn't understand the container state machine will panic at the sight of an Exited container — when it could be perfectly normal. Conversely, an engineer who understands state can read a single line of docker ps and immediately know the condition of the system: which containers are running, which are stuck in a restart loop, and which are truly dead.

Episode 4 is the bridge from "running containers" to "managing a production system". We'll dissect the container state machine (Created, Running, Paused, Stopped, Exited, Dead, and Restarting), the state control commands (create, start, pause, unpause, restart, kill), JSON metadata inspection with docker inspect, real-time monitoring (top, stats, events), the meaning of exit codes, and close with safe system cleanup (system prune, system df).

#Main Discussion

#The Container State Machine

Every container always exists in one of the following states. Understand this like a map: every command you run is a "move" from one point to another.

         create              start
(no) ─────────► Created ───────────► Running
                                       │   │
                              pause/  │   │  stop / (proses keluar)
                              unpause │   │
                                       ▼   ▼
                                   Paused   Stopped / Exited
                                       │          │  rm
                                       └──────────►  (hilang)

Important distinctions to remember:

• Paused vs Stopped. A paused container stays alive — the process is frozen (SIGSTOP signal), memory and network remain allocated, but it doesn't execute anything. A stopped container actually terminates its main process. Think of pause as pressing the pause button on a video player (the tape is still in), stop as taking the tape out.
• Stopped vs Exited. In practice the two are often used interchangeably — docker ps shows Exited for containers that have stopped. The difference is subtle: Stopped is the "official" state resulting from the stop command, while Exited is the final status of a process that has finished (whether intentionally or by crashing).

STATUS          PORTS               NAMES
Up 3 minutes    0.0.0.0:8080->80   my-web
Exited (0) ...                      old-job

#State Control Commands

All the following commands only move the state — they don't create a new image. Memorize the transitions:

docker create --name my-web nginx
docker ps -a --filter "status=created"

docker create stores the container's entire configuration (image, ports, env, mounts) without running the process. Useful for preparing a container in advance and running it at the right time — and for checking the configuration before execution.

docker start my-web
docker pause my-web
docker unpause my-web
docker restart my-web

Note docker restart on the last line — it's a combination of stop + start with a SIGTERM grace period. Meanwhile docker kill below is the opposite of stop: it sends SIGKILL immediately without giving the process a chance to clean up:

docker kill my-web

#Restart Policies: Bringing Containers Back Automatically

The Restarting state above often causes confusion: is it a normal state or a sign of a crash loop? The answer lies in the restart policy — the rule that determines what the daemon does when a container stops. This rule is set when the container is created:

docker run -d --name my-web --restart always nginx
docker inspect my-web | jq '.[0].HostConfig.RestartPolicy'

{
  "Name": "always",
  "MaximumRetryCount": 0
}

#Reading Metadata: docker inspect

docker inspect is the gateway to all of a container's metadata in JSON form — the most important tool for understanding a container's true condition:

docker inspect my-web

The output is long, so get in the habit of filtering it with jq (or --format). The four fields you'll read most often:

docker inspect my-web | jq '.[0].Id'
docker inspect my-web | jq '.[0].State'
docker inspect my-web | jq '.[0].Config.Image'
docker inspect my-web | jq '.[0].Mounts'
docker inspect my-web | jq '.[0].NetworkSettings.IPAddress'

{
  "Status": "running",
  "Running": true,
  "Paused": false,
  "Restarting": false,
  "OOMKilled": false,
  "Dead": false,
  "Pid": 12345,
  "ExitCode": 0,
  ...
}

A typical scenario: a container stops for no apparent reason. docker inspect will answer — whether OOMKilled: true (out of memory), what the ExitCode is, and what Error is recorded. That's far faster than guessing.

#Understanding Exit Codes

Every container stops with an exit code — the number recorded from its main process. This is the container's "final message":

docker run --name fail alpine sh -c "exit 1"
docker inspect fail | jq '.[0].State.ExitCode'
docker run --name oom-test -m 20m alpine sh -c "tail /dev/zero"

The last example above deliberately runs a container that forces an OOM (reading /dev/zero endlessly with a 20 MB memory limit). Note the exit code 137 — the most common signal that a container was killed for running out of memory. Learning to read exit codes is the first debugging skill that will save you in production.

#Real-Time Monitoring: top, stats, events

docker top my-web

docker top shows the processes running inside the container (from the host's perspective). Compare it with ps aux on the host — the nginx container appears as an nginx process with its host user and PID.

docker stats

docker stats is a live dashboard: CPU %, memory usage/limit, network I/O, and block I/O columns for all active containers — updated every few seconds. An essential tool when figuring out "which container is eating memory".

docker events

docker events streams all daemon events in real time: create, start, stop, die, restart, pause, kill, exec_start, and others. Run this in one terminal, then try docker run -d --rm alpine sleep 60 in another — you'll see the create, start, and die events flowing. It's the purest observation tool for studying the lifecycle we just discussed.

#System Cleanup: system prune and system df

Unused containers, images, volumes, and networks pile up — and fill up the disk at /var/lib/docker. These two commands are your cleanup crew:

docker system df

docker system df reports how much disk is used by images, containers, volumes, and build cache — plus the RECLAIMABLE column (how much can be freed).

docker system prune
docker system prune -a
docker system prune -a --volumes

Understand each option carefully:

• docker system prune — removes stopped containers, unused networks, dangling images, and build cache.
• -a (all) — always asks first and removes all images not used by active containers, not just dangling ones.
• --volumes — removes unused volumes. Volumes contain data — this command is dangerous for data that isn't backed up.

WARNING! This will remove all dangling images...
Are you sure you want to continue? [y/N]

#Common Pitfalls

1. Assuming Exited always means error. A hello-world container that's Exited (0) is normal behavior. Read the exit code before panicking — 0 means it finished successfully.

2. docker rm on a still-running container. The error is "cannot remove running container". Stop it first (stop) or use -f deliberately.

3. Not reading State.Error on crash. docker inspect contains the error message in JSON — often the answer is already there before you start guessing.

4. Skipping docker system df. A full disk on a Docker server usually isn't caused by used images but by accumulated build cache and idle containers/images. Regular audits with system df prevent a disk crisis.

5. Running system prune -a --volumes without thinking. Data that isn't backed up can be lost permanently. Always confirm what's about to be deleted.

#Conclusion

In this episode 4 you've deepened your understanding of the container lifecycle: the state machine from Created → Running → Paused → Stopped/Exited → Dead (plus Restarting), the state control commands (create, start, pause, unpause, restart, kill), reading JSON metadata with docker inspect and jq (the State, Config, Mounts, NetworkSettings fields), real-time monitoring with docker top, docker stats, and docker events, the meaning of exit codes (especially 137 for OOM), and system cleanup with docker system df and docker system prune along with the dangers of the -a --volumes option.

Core takeaways:

• A container is a state machine: every command moves its state, nothing is magical.
• pause freezes the process; stop (SIGTERM) stops cleanly; kill (SIGKILL) force-stops.
• docker inspect + jq are your eyes — State.ExitCode, OOMKilled, and State.Error answer why a container died.
• Exit code 137 = killed (often OOM); 0 = finished normally — read before panicking.
• system df for disk audits; system prune for cleanup; be careful with --volumes.

Now you're no longer just "running containers" — you're managing their lifecycle. In the next episode, episode 5, we'll level up: building custom images with a Dockerfile — understanding layered architecture and the build context, the core instructions FROM, WORKDIR, COPY vs ADD, RUN, EXPOSE, and the fundamental difference between CMD and ENTRYPOINT that will change how you package your own applications. See you in episode 5!