CoursesDocker for beginnersWorking with containers

Inspect, logs & exec

Look inside a running container.

Beginner10 min · lesson 7 of 16
In plain terms
Three ways to check on a running container, like checking on a room: read the diary it’s writing (logs), step inside and look around (exec), or read the full spec sheet taped to the door (inspect).

When something is wrong, three commands let you see inside a running container without stopping it: logs to read what it printed, exec to get a shell inside it, and inspect to dump its full configuration. Reach for them in that order most of the time — the answer is usually in the logs.

terminal
$ docker logs web # everything the container wrote to stdout/stderr
$ docker logs -f web # -f follows, like tail -f
$ docker logs --tail 20 web # just the last 20 lines

Exec into a container

docker exec runs a new command inside an already-running container; with -it (interactive + a terminal) it gives you a shell to look around. This is different from docker run, which starts a new container — exec attaches to one that is already up. It is the everyday way to poke at a live container: check a file, run a quick command, see what the process sees.

terminal
$ docker exec -it web sh # a shell inside the running container
/ # ls /etc/nginx
conf.d nginx.conf ...
/ # exit # leaves the shell; the container keeps running

Inspect the details

docker inspect prints a container’s complete state as JSON — its IP address, mounts, environment, restart policy, and more. It is verbose, so use -f with a Go template to pull out just the field you want. This is where you go when you need a fact about the container that the logs will not tell you, like which IP it got or exactly which volumes are mounted.

terminal
$ docker inspect -f '{{ .NetworkSettings.IPAddress }}' web
172.17.0.2
$ docker inspect -f '{{ .State.Status }} ({{ .State.ExitCode }})' web
running (0)
exec needs a shell in the image
docker exec -it web sh only works if the image actually contains a shell. Small, hardened images (distroless, scratch) ship without one on purpose — which frustrates attackers but also means exec fails. That is a feature you will meet later; for now, know that “no such file: sh” means the image is minimal, not broken.