Debug a running container with the Docker CLI
practical container debugging.
docker inspect for full state and config, docker logs -f to follow output live, docker exec -it <id> sh or bash for an interactive shell.
WHAT THIS TESTS It checks whether you can triage a misbehaving container quickly using the right commands without disrupting its state or killing the main process.
A GOOD ANSWER COVERS Start with state: docker ps for status, ports and health, and docker inspect <container> for the full JSON including environment, mounts, network settings, restart policy, and exit codes. For runtime behavior, docker logs -f <container> follows stdout and stderr live; adding --tail and --since narrows the window. To poke inside, docker exec -it <container> sh opens an interactive shell (use bash if available), letting you check processes, files, and connectivity from within the container's namespaces. A strong answer notes that exec starts a new process, leaving the main process untouched, which is exactly what you want while debugging.
COMMON WRONG ANSWERS Using docker attach, which connects to the container's PID 1 stdio and can terminate it on Ctrl-C. Restarting the container, which erases the failing state. Assuming bash exists in every minimal image. Forgetting -it for an interactive TTY.
LIKELY FOLLOW-UPS How does exec differ from attach? What if the image has no shell at all? How do you copy a file out with docker cp, or check resource use with docker stats?
ONE CONCRETE EXAMPLE An API container returns 500s. docker logs -f api shows repeated database connection refused. docker exec -it api sh lets you run nslookup db and curl the DB port, revealing the service name does not resolve, pointing to a network or compose dependency issue, all without restarting the container.
Interview question
Why is docker exec -it preferred over docker attach when opening a shell to debug a running container?
- a.attach is deprecated and no longer functions
- b.attach cannot show colored output
- c.exec runs on the host rather than inside the container
- d.exec starts a new process, leaving PID 1 untouched, while attach can kill it on Ctrl-CCorrect
Why? this is the answer
exec spawns a separate process so the main process is unaffected, whereas attach connects to PID 1's stdio and Ctrl-C can terminate it; attach is not deprecated and exec does run inside the container.
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
- #docker
- #debugging
- #exec
- #logs
- #inspect
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles