Debugging and observing running containers

A container's isolation (its own filesystem view, its own process namespace) doesn't mean it's a black box to the host it's running on — a small set of Docker commands can inspect a running container's state, resource usage, and logs without needing the application itself to expose any special debugging endpoint.

The container's stdout/stderr, captured by Docker regardless of whether the application writes to a file. This is the starting point for almost every investigation — and its absence of useful output (an OOM-killed process leaves nothing here, exactly as the resource-limits lesson described) is itself a diagnostic signal, not a dead end.

This runs a new process inside the container's existing namespaces — not a separate container, the same isolated environment the application is actually running in. From here, ordinary tools (checking environment variables, testing DNS resolution to another service, confirming a config file's actual contents on disk) work exactly as they would debugging any Linux process, just scoped to what that container can see. A minimal or distroless image (from the image-security lesson) has no shell at all, trading this convenience away for a smaller attack surface — worth knowing before reaching for exec on one and getting nothing back.

This is the direct, live view into whether a container is actually hitting the resource limits described in the previous lesson — a memory percentage sitting near 100% is a container about to be OOM-killed, and CPU usage pinned near its --cpus ceiling is a container being throttled, both confirmable here before (or instead of) guessing from application symptoms alone.

inspect returns a container's complete metadata — its exact resource limits, environment variables, mounted volumes, network settings, and detailed exit/health state — as structured JSON, filterable with --format to pull out exactly one field instead of scrolling a large dump. This is precisely the command the common-bugs lesson uses to confirm OOMKilled: true as a specific, checkable fact rather than an inference from symptoms.

Lists the processes running inside a container's process namespace, directly from the host — useful for confirming a container's PID 1 is actually the application process and not an unexpected shell wrapper (the SIGTERM-ignored bug from the common-bugs lesson traces to exactly this kind of mismatch), or for spotting an unexpected zombie or runaway process without needing a shell inside the container at all.

Rather than guessing which of the common-bugs lesson's five scenarios applies, this sequence — logs, then inspect, then stats or exec depending on what inspect reveals — turns "something's wrong" into a specific, evidence-backed diagnosis in a handful of commands, before touching any application code at all.