Debug a running container with the Docker CLI

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.