Docker · Containers in practice
How do you debug a container that is failing?
Short answer
Start with exit codes, logs and inspect output, then reproduce interactively with a shell or an ephemeral debug container. Check configuration, mounts, networking and resource limits before changing the image.
A container that exits immediately has usually failed at startup, so docker logs is the first place to look. If the image has no shell, use an ephemeral debug container that shares its namespaces, or run the image with an overridden entrypoint.
docker ps -a
docker logs --tail 100 api-1
docker inspect api-1
docker exec -it api-1 sh
docker run --rm -it --network container:api-1 --pid container:api-1 nicolaka/netshootA practical order
- Check the exit code: 127 means a missing command, 137 often means OOM or SIGKILL
- Read logs from the start, not only the last lines
- Inspect environment, mounts, entrypoint and network settings
- Test name resolution and connectivity from inside the network namespace
- Compare the run command with a working environment
If the image is minimal, do not rebuild it just to get a shell. Override the entrypoint with a debug command, or attach a debug container. That keeps the artifact under test unchanged.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What does exit code 127 usually mean?
- 2How do you debug a distroless image with no shell?
- 3How can you test DNS from inside a container?
- 4What is the difference between an exited container and an unhealthy one?
Say it in the interview
I start with the exit code, the full logs and docker inspect, because most failures are startup configuration or a missing dependency. If the image has no shell I attach an ephemeral debug container or override the entrypoint instead of rebuilding. Then I check mounts, environment, DNS and resource limits before changing anything.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Docker mock interview and get scored feedback on depth, clarity and confidence.