Logs, exec, and the container lifecycle

Seeing inside a running container

A detached container from lesson 2-2 runs silently in the background. Two commands make it observable:

docker logs web        # everything the container has printed
docker logs -f web     # keep following new output live (Ctrl-C to stop)

Containers do not write log files you go hunting for. Whatever the program prints to standard output becomes docker logs. You know stdout from the terminal course, and it is the whole logging story here.

When logs aren't enough, get a shell inside the container:

docker exec -it web bash

• exec: run an extra command inside an already-running container
• -it: interactive with a terminal, same as in lesson 2-1
• web bash: container name, then the command, here a bash shell

Now ls, cat, and ps show you the container's private world. Type exit to leave. The container keeps running.

The lifecycle

Every container moves through the same states:

docker run -d --name web nginx   # created + running
docker stop web                  # running -> stopped (politely, then forced)
docker start web                 # stopped -> running again
docker rm web                    # stopped -> gone (rm -f skips the stop)

A stopped container still exists: its writable layer, its name, its settings all remain, which is why docker ps -a from lesson 2-1 shows exited containers. docker rm is what actually deletes it.

The habit to build: never hand-repair a container. Any fix you apply with exec lives only in that container's writable layer, is recorded nowhere, and dies with the container, so the next machine (or the next deploy) has the bug again. Put the fix in the Dockerfile or config instead and recreate: stop, rm, run a fresh one from the image. Ops people compress this into "cattle, not pets": individual containers get no special care. exec is for diagnosing, not for repairing.