🐳 Reading Docker Runtime Errors

Container names must be unique — Docker will not silently reuse or rename one for you.

Every container gets a name (explicit via --name, or a random one like great_hopper if you don't set one). Docker keeps stopped containers around until you explicitly delete them, so re-running the same docker run --name web ... command a second time hits this conflict even if the first "web" container already exited.

The fix: docker rm web to delete the old container, or docker rm -f web if it's still running, or add --rm to future docker run commands so the container is auto-deleted on exit.

How to describe this to a colleague: "It's not a real crash — there's already a stopped container called web from a previous run. I just need to remove it first." This distinguishes a naming conflict (harmless, easy fix) from an actual application failure — useful vocabulary when triaging in a channel.

Port 8080 on the host is already taken — by another container, or another process entirely.

The -p 8080:80 flag maps host port 8080 to the container's port 80. "Bind" here means the host OS reserving that port for this container's use; if anything else already holds it, the bind fails. This is an OS-level networking conflict, not a Docker or application bug.

How to check what's using the port:

• docker ps — is another container already publishing 8080?
• lsof -i :8080 (macOS/Linux) or netstat -ano | findstr 8080 (Windows) — is a non-Docker process using it?

The fix: stop whatever is using 8080, or map to a different host port, e.g. -p 8081:80.

How to describe this to a colleague: "Container won't start — port 8080's already in use on my machine, probably from a container I forgot to stop." EADDRINUSE is the equivalent error you'd see directly from an application (e.g. Node.js) trying to bind the same port.

exec format error almost always means an architecture mismatch.

The image tag here (myapp:build-arm64) hints strongly at this: it was likely built on an Apple Silicon (arm64) machine, then someone tried to run it on an amd64/x86_64 server (or a CI runner) without emulation. The kernel tries to execute the container's entrypoint binary and fails because the binary's machine code is for a different processor architecture entirely — the OS can't even start interpreting it.

How to confirm: docker image inspect myapp:build-arm64 --format '{{.Architecture}}' and compare it to docker version --format '{{.Server.Arch}}' on the host.

The fix: build (or pull) a multi-architecture image using docker buildx build --platform linux/amd64,linux/arm64 ..., or explicitly specify the platform when running: docker run --platform linux/amd64 myapp:latest.

How to describe this to a colleague: "It's not a code bug — this looks like an arch mismatch, the image was probably built on an M-series Mac and we're trying to run it on an x86 server." Precise vocabulary here (architecture, arm64, amd64/x86_64, multi-arch) avoids a long debugging detour into "the code" when the real issue is the build target.

OOMKilled — the container used more memory than it was allowed and the kernel killed it with SIGKILL.

Exit code 137 is not an application-chosen code — Unix convention is 128 + signal number, and 137 = 128 + 9, where signal 9 is SIGKILL (an immediate, un-catchable kill). When a container is started with a memory limit (docker run -m 512m ...) or is on a host that ran out of memory, the kernel's OOM killer targets the offending process and sends SIGKILL — the container gets no chance to shut down gracefully.

docker inspect --format '{{.State.OOMKilled}}' is the definitive way to confirm this was memory-related rather than a crash or manual stop — docker ps alone only shows the exit code, which could theoretically mean other things.

The fix: raise the container's memory limit if the workload genuinely needs it, or profile the application for memory leaks / unbounded caches / large in-memory batches.

How to describe this to a colleague: "It's not crashing on its own — docker inspect confirms OOMKilled, so it's hitting the memory limit. Either bump the limit or we've got a leak." This exact vocabulary (exit 137, OOMKilled, SIGKILL, memory limit) carries over directly to Kubernetes, where the same signal and exit code appear in kubectl describe pod output.