What do `docker top` and `docker diff` show for a container built with no shell?

## Why these commands exist A hardened production image often contains a single static binary and nothing else — no shell, no `ps`, no `ls`. The usual instinct of opening a shell inside it simply fails: there is no shell to execute. `docker top`, `docker diff` and `docker port` all run on the host side, against the daemon's view of the container, so none of them need anything to exist inside the image. ## `docker top` `docker top <container> [ps options]` asks the daemon to run the **host's** `ps` restricted to the processes belonging to that container, and prints the table. Two consequences follow. First, the PIDs you see are **host** PIDs. The process that is PID 1 inside the container appears here with whatever number the host assigned it — often a five-digit number. Candidates who expect to see `1` in the first column have not thought about which side the command runs on. That host PID is genuinely useful: it is the handle other host-side tooling needs to look at the process. Second, because it is the host's `ps`, you can pass ps options through: `docker top worker -eo pid,ppid,rss,etime,args` gives you resident memory and elapsed time per process without anything being installed in the image. It is a point-in-time snapshot; it does not refresh. For a container that should be running one process, `docker top` immediately tells you whether the process tree has grown — a shell wrapper that spawned children, a runtime that forked workers, or zombies accumulating under a PID 1 that does not reap. ## `docker diff` `docker diff <container>` compares the container's filesystem against the image it was created from and prints one line per difference: - `A /path` — added since the image - `C /path` — changed (for a directory, this often means an entry inside it changed) - `D /path` — deleted relative to the image This is a direct reading of the container's **writable layer**, the copy-on-write layer stacked on the image's read-only layers. That defines both its value and its limits. Its value: it answers "what has this container written?" for an image with no tooling. Finding an unexpected `A /app/config.json` explains a container that behaves differently from its image, and a flood of `C` entries under a data directory shows a workload writing into the container instead of into storage that outlives it. Its blind spots, which are the interesting half of the answer: - **Volumes and bind mounts are invisible.** They are mounted over the writable layer, not part of it, so a container writing terabytes into a named volume shows nothing at those paths. "`docker diff` is clean, so the container isn't writing anything" is simply wrong. - **tmpfs mounts are invisible** for the same reason. - **It shows paths, not content.** You learn a file changed, never how. - **It can be slow and noisy** on a container that has written a lot, because it is a filesystem comparison rather than a metadata lookup — the same reason the container's size fields are only computed on request. ## `docker port` `docker port <container>` prints the container's published port mappings, and `docker port <container> 8080/tcp` prints just the host binding for one container port. It is the fastest way to answer "which host port did this actually get?", which matters whenever a port was published without a fixed host port and the engine chose an ephemeral one. The same information exists inside the container record's network settings, but this is one word instead of a template. ## Putting them together For a shell-less container behaving oddly, a compact host-side sweep is: `docker top` for the process tree and its host PIDs, `docker diff` for what it has written into its own layer, `docker port` for where it is reachable, and the container's own record for its configuration and final state. That is often enough to form a hypothesis without modifying the container or rebuilding the image — and where it is not, the host PID from the process table is the handle that lets host-side tooling take over. None of these commands is asked about every day, which is exactly why they differentiate: reaching for them shows you have debugged a container you could not get inside.