>_SecOpsLog_
CoursesDocker for beginnersInspect, logs & exec

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).

A running container is like a washing machine locked in the utility room. It is working away, you can hear it, but you cannot see the drum, and you would rather not switch it off at the wall only to find out what cycle it is on. Docker gives you three ways to check on a live container without stopping it. You can read the notes it keeps pushing under the door. You can open the door and step inside. Or you can read the metal spec plate bolted to its side. Those three moves are docker logs, docker exec, and docker inspect. Try them in that order, because nine times out of ten the answer is already sitting in the logs.

Get a real container running first, so you have something to check on. The command below starts nginx, a very common web server, which is a program whose whole job is handing out web pages when a browser asks for one. Three flags do the work. -d means detached: run it in the background and give me my prompt back. --name web sticks the label web on the container so you never have to type its long ID. And -p 8080:80 wires port 8080 on your own machine through to port 80 inside the container. A port is a numbered door that network traffic goes through, so that flag is you propping open door 8080 on your laptop and running a corridor from it to door 80 inside.

terminal
$ docker run -d --name web -p 8080:80 nginx:1.27
Unable to find image 'nginx:1.27' locally
1.27: Pulling from library/nginx
Digest: sha256:287ff8...9e
Status: Downloaded newer image for nginx:1.27
3f8a1c9d4e2b7a6f0c5d8e1b2a3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c
$ docker ps
CONTAINER ID   IMAGE        STATUS         PORTS                  NAMES
3f8a1c9d4e2b   nginx:1.27   Up 3 seconds   0.0.0.0:8080->80/tcp   web

Read what it printed: docker logs

Every program chatters while it runs. nginx prints a short startup banner, then one line for every request it answers. That text goes out on two streams with formal names: standard output and standard error, usually shortened to stdout and stderr. Treat them as the program talking out loud. Docker sits there recording both, word for word, and keeps the recording. That is why docker logs can play it back at any time, even long after the container has stopped. Add -f to follow the log live, so new lines land on your screen as they happen (press Ctrl+C when you want to stop watching). Add --tail to see only the last few lines instead of the whole history. In the example below I use curl, a small command-line tool that fetches a web page the way a browser would, to hit the server once so nginx has a request to log.

terminal
$ docker logs web
/docker-entrypoint.sh: Configuration complete; ready for start up
2025/07/16 10:11:02 [notice] 1#1: nginx/1.27.4
2025/07/16 10:11:02 [notice] 1#1: start worker processes
$ curl -s localhost:8080 > /dev/null
$ docker logs --tail 1 web
172.17.0.1 - - [16/Jul/2025:10:12:40 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.5.0"

Logs really earn their keep when a container refuses to stay up. Here is the trap beginners fall into over and over: one small typo in the command. You start the container detached, the command dies on the spot, and the container is gone before you have looked back at the screen. You run docker ps and there is nothing there, which feels like the container evaporated. It did not. docker ps lists containers that are still running, and nothing else. Add -a (short for all) and the stopped ones show up too. Then read the logs and find out what happened.

terminal
$ docker run -d --name greeter alpine:3.20 sh -c "ecoh hello"
b4d2e1f09a7c8d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e
$ docker ps --filter name=greeter
CONTAINER ID   IMAGE   COMMAND   STATUS
$ docker ps -a --filter name=greeter
CONTAINER ID   IMAGE         COMMAND                STATUS
b4d2e1f09a7c   alpine:3.20   "sh -c 'ecoh hello'"   Exited (127) 4 seconds ago
$ docker logs greeter
sh: ecoh: not found

Exited (127) is your clue. An exit code is the number a program hands back on its way out, like a contractor leaving a note about how the job went, and 0 always means it went fine. 127 is the shell's way of saying it could not find the command you asked for. The log says the rest out loud: ecoh was meant to be echo. Fix the spelling and the container runs.

Step inside: docker exec

Sometimes the notes under the door are not enough and you want to walk in and look around yourself. docker exec starts a new command inside a container that is already running. Pair it with -it, which stands for interactive plus terminal, and Docker hands you a shell inside the container. A shell is a command prompt, the same kind of thing you type into on your own machine. This is not docker run. docker run would spin up a brand new container. exec joins the one that is already up. Type exit when you are done and the container carries on running without you.

terminal
$ docker exec -it web sh
# whoami
root
# head -3 /etc/nginx/conf.d/default.conf
server {
    listen       80;
    server_name  localhost;
# exit
$
No shell? The image is lean, not broken
docker exec -it web sh works only if the image actually carries a shell program inside it. Some very small, stripped-down images (the kind built on bases called distroless or scratch) leave sh out on purpose, so anyone who breaks in finds no tools lying around to use. If you see 'exec: "sh": executable file not found', the image is minimal by design, not damaged. Try bash instead. If that fails too, fall back to docker logs and docker inspect, which read the container from the outside and work on any image, shell or no shell.

Get a fact: docker inspect

Logs tell you what the container said. exec lets you wander around inside it. Some things are neither, because they are flat facts Docker holds about the container: the address it was handed, which folders from your own machine are shared into it, the exact code it exited with. That address is an IP address (Internet Protocol address), the number that identifies the container on Docker's private network, the way a house number identifies a house on a street. For facts like these, read the spec plate. docker inspect prints the container's whole configuration and live state as JSON (JavaScript Object Notation, a plain-text way of writing structured data). It is long. Nobody reads all of it.

terminal
$ docker inspect web | head -11
[
    {
        "Id": "3f8a1c9d4e2b7a6f0c5d8e1b2a3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c",
        "Created": "2025-07-16T10:11:01.482613814Z",
        "Path": "/docker-entrypoint.sh",
        "Args": [
            "nginx",
            "-g",
            "daemon off;"
        ],
        "State": {

So you pull out the one field you want with -f and a Go template. A Go template is a tiny pattern where a pair of double curly braces means 'print this value right here'. You do not need to know the Go programming language to write one. Find the field in the JSON, wrap its path in braces, and inspect fills in the value. This works on stopped containers too, which is how you confirm that greeter really did exit with 127.

terminal
$ docker inspect -f '{{ .State.Status }}' web
running
$ docker inspect -f '{{ .NetworkSettings.IPAddress }}' web
172.17.0.2
$ docker inspect -f '{{ .State.ExitCode }}' greeter
127
Container acting up: which command do you reach for?
Container acting up: which command do you reach for?
Start with logs. Most answers are already sitting there. Reach for exec and inspect when they are not.

When something breaks, the reflex is to open the Dockerfile and rebuild. Hold off for sixty seconds. The three commands answer three different questions, and asking the right one first saves you a whole build. What did the process say on its way down? That is logs. What does the world look like from inside, right now? That is exec. What does Docker itself believe about this container's configuration, network, mounts and state? That is inspect.

docker logs is your first call after an unexpected exit. Get the name or ID from docker ps -a, then read the last handful of lines, because the reason a process died is nearly always the last thing it printed. For a service that keeps running, docker logs -f leaves the tap open the way tail -f does on an ordinary file. One catch is worth knowing early. If the application writes its own log file inside the container instead of printing to stdout, docker logs will look almost empty. Nothing mysterious is going on. The image was packaged in a way that hides its own output, and that is an application packaging problem to fix.

docker exec -it name sh (or bash, if that is what the image ships) opens a shell in a running container. It is the right tool for a yes-or-no question. Did that config file land where you expected? Does that hostname resolve? Is the package you assumed was there actually there? It is a poor tool for repairs. Anything you install or edit through exec vanishes the moment the container is replaced, and containers get replaced constantly. Use exec to work out what is wrong, then write the fix into the Dockerfile or a mount so it survives.

docker inspect is dense, and that is fine. Pipe it through a format string, or through jq (a command-line tool for picking values out of JSON), when you want one fact: an IP address, the list of environment variables, where the mounts land. Knowing the data is in there beats memorising field names. Practise pulling .State.Status and .NetworkSettings.IPAddress until the braces stop looking strange, and the rest of that tree turns into something you browse instead of a wall of text.

Try this

Start a named nginx, read its logs, exec in to see which processes are running inside it, then pull one structured field back out with inspect. Five commands, about a minute of your time.

terminal
docker run -d --name peek nginx:1.27-alpine
docker logs peek | tail -n 5
docker exec peek ps aux | head -n 5
docker inspect -f "{{.State.Status}} {{.Config.Image}}" peek
docker rm -f peek
output
.../docker-entrypoint.sh: Configuration complete; ready for start up
...
PID   USER     TIME  COMMAND
  1   root      0:00  nginx: master process nginx -g daemon off;
...
running nginx:1.27-alpine

Takeaway

Next time a container disappears on you, type docker ps -a before you touch anything else, then docker logs on the name it shows you. The error line and the exit code are already there waiting. Rebuilding first only means you sit through a build and still do not know why it died.

Quick check
01A container you started with docker run has already exited on its own. Which command tells you why it stopped?
Correct — Docker kept everything the process printed, error message included, and it keeps that recording after the container stops.
Incorrect — exec needs a live process to attach to. There is not one any more, so this fails.
Incorrect — Plain ps lists running containers only, so the exited one will not even appear, never mind explain itself. You would need docker ps -a to see that it existed at all.
Incorrect — rm deletes the container and its logs together, throwing away the exact evidence you were about to read.
02You want the exact IP address Docker handed a running container. Which command is built for pulling one single fact like that out of a container?
Incorrect — Logs replay what the program printed. An IP address is configuration, not something nginx announces to its screen.
Correct — inspect holds the container's configuration as JSON, and -f picks out the one field you named.
Incorrect — That puts you inside for a look around. It is a detour when you want one clean value read from outside.
Incorrect — ps gives you names, images and published ports, but never the container's assigned IP address.
03docker exec -it api sh comes back with: exec: "sh": executable file not found. The container is clearly still up and still serving traffic. What is the likeliest explanation?
Incorrect — It is still answering requests, so it has not crashed. The missing piece is the shell, not the container.
Incorrect — docker run would start a brand new container. exec is the right command for joining one that is already up.
Incorrect — The tool is working fine. The message is about a program that is not inside the image.
Correct — Stripped-down images leave sh out to shrink what an intruder can use, so read the container from outside with logs and inspect.
docker run in depthEnvironment variables

Related

Image layers & internalsDocker in depthNamespaces from first principlesAdvanced container securityDocker CLI cheat sheetCheat sheetDocker vs PodmanComparisonDocker interview questionsInterview prep