Debugging containers

In plain English

docker logs prints the stdout and stderr of a container, which is usually where an application reports why it crashed. docker exec runs a new command inside an already running container, so you can open a shell with docker exec -it web sh and poke around. docker inspect returns a large JSON description of a container, including its exit code, mounts, environment and network settings. An exit code tells you how the process ended: 0 means clean success, a non-zero code usually signals an error, and 137 often means the process was killed, commonly by an out-of-memory kill. Networking and DNS problems are frequent, and they usually come down to containers being on different networks or a service name that the embedded DNS cannot resolve.

Step by step

1. 1Stream a container log with docker logs -f web.
2. 2Open a shell inside a running container with docker exec -it web sh.
3. 3Inspect a container with docker inspect to read its exit code and settings.
4. 4List all containers, including stopped ones, with docker ps -a.
5. 5Confirm two services share a network with docker network ls and docker network inspect.

docker logs -f web
docker exec -it web sh
docker inspect web
docker ps -a
docker network ls

Common mistakes

• Assuming a container is fine because it started is wrong; a crashed process may have already exited.
• Reading docker ps only shows running containers, so stopped crashes stay invisible until you add -a.
• Calling a service by name from a different network fails, because DNS resolution is scoped to the shared network.
• Treating every non-zero exit code as the same error hides the difference between a crash and a kill.