CodeOath
← All posts
Docker65 min total · 19 parts

Docker Fundamentals: Images, Containers, and Writing a Good Dockerfile

Contents — Part 17 of 19: Debugging a Running Container
  1. 1.Overview
  2. 2.What Problem Docker Actually Solves
  3. 3.Image vs. Container
  4. 4.The Docker Engine's Moving Parts
  5. 5.Images Are Made of Layers, and Layers Are Cached
  6. 6.Dockerfile Instructions, One by One
  7. 7.CMD vs. ENTRYPOINT: The Instruction Everyone Mixes Up
  8. 8.Multi-Stage Builds
  9. 9..dockerignore and the Build Context
  10. 10.Choosing a Base Image
  11. 11.Networking Basics
  12. 12.Volumes, Bind Mounts, and tmpfs
  13. 13.Docker Compose: Running More Than One Container Together
  14. 14.Health Checks and Restart Policies
  15. 15.Environment-Specific Configuration
  16. 16.Security Basics
  17. 17.Debugging a Running Container
  18. 18.Resource Limits
  19. 19.Common Mistakes Worth Remembering
Part 17 of 19 · ~1 min

Debugging a Running Container

The commands that cover the overwhelming majority of "why isn't this container behaving" investigations:

docker ps                          # what's running right now
docker logs -f web                 # follow a container's stdout/stderr
docker exec -it web sh             # get an interactive shell inside a running container
docker inspect web                 # full JSON: mounts, env vars, network settings, restart count
docker stats                       # live CPU/memory/network usage per container
docker top web                     # processes running inside the container, from the host's view

docker exec only works on a container that's already running and has a shell available (not distroless — see the base image section). For a container that keeps crashing before you can exec into it, docker logs on the exited container (it doesn't need to be running for you to read its logs) and docker inspect's .State section (exit code, OOM-killed flag) are usually the first two places to look — an exit code of 137 specifically indicates the container was killed by SIGKILL, very often because it hit a memory limit (see below) and the kernel's OOM killer stepped in.

← Previous
Security Basics
Next →
Resource Limits