0.4Lifecycle: run, ps, stop, rm, logs
The essentials in 30 seconds
- run creates AND starts (pull + create + start): -d for background, --rm for self-removed disposable trials.
- ps sees, logs reads, exec enters: ps the living (ps -a all), logs -f follows journals, exec -it opens a shell inside.
- stop stops politely, rm removes the husk: prefer stop to kill, and purge exited containers with prune.
Running mini-case — Idir runs a clean end-to-end demo
Idir, junior DevOps in Algiers, must show nginx to his team: instead of leaving -d ghosts behind, he plays the full cycle. He launches with docker run -d --name demo nginx:1.27, displays with docker ps, reads with docker logs demo, enters with docker exec -it demo sh then exits with exit, stops with docker stop demo, removes with docker rm demo, and checks with docker ps -a that everything is gone. Six commands, zero forgotten exited containers: 80% of his daily usage is covered.
Self-contained case for this section: it returns in the lesson, diagram, script and 48h challenge of section 0.4.
1. Being born: run = pull + create + start
docker run -d --name demo nginx:1.27 does three things: download the image if needed, create the container, start it in the background (-d). Without -d, the terminal stays attached; with --rm, the container self-removes on stop (perfect for trials). Idir always names (--name) to aim right afterwards.
2. Living: see, follow, enter
docker ps lists the living, ps -a adds the dead. docker logs -f demo follows the journals, docker exec -it demo sh opens a shell inside the living container. Remember: logs to see, exec to enter. Idir reads the logs first before entering: most diagnoses stop there.
3. Dying cleanly: stop then rm
docker stop demo sends a polite stop (SIGTERM then SIGKILL), docker rm demo removes the husk. docker rm -f forces both at once. Stopped, unremoved containers clutter: a regular docker container prune cleans up. Idir prefers stop to kill to let apps finish cleanly.
🔎 Concrete example — 🔎 Concrete example — A clean end-to-end demo
Idir chains the full cycle on demo, then checks nothing remains.
docker run -d --name demo nginx:1.27
docker ps
docker logs demo
docker stop demo
docker rm demo
docker ps -aReading: we see the living container, read its logs, stop it, remove it, check it is gone.
Lesson: this six-command cycle is 80% of your daily usage.
Section vocabulary
- run
- Create + start a container from an image.
Simple example: Idir types docker run -d --name demo nginx:1.27: pull + create + start.
What it is not: the simple list of containers.
Reflex: always --name to aim right afterwards.
- ps
- List containers (living, or all with -a).
Simple example: Idir sees living demo with ps, then gone with ps -a after rm.
What it is not: the image list.
Reflex: lost? ps -a also shows the dead.
- exec
- Run a command inside a living container.
Simple example: Idir opens a shell with docker exec -it demo sh then exit.
What it is not: starting a new container.
Reflex: diagnosis: logs first, exec after.
- stop / rm
- Stop politely / remove the husk.
Simple example: Idir stops demo (SIGTERM) then removes its husk with rm.
What it is not: removing the image (rmi).
Reflex: stop before rm, never close the terminal.
- --rm
- Automatically remove the container when it stops.
Simple example: Idir adds it to all his disposable trials: zero exited ghosts.
What it is not: background detaching (-d).
Reflex: disposable trial → systematic --rm.
In practice — In practice — Bringing a container to life
- Launch a named nginx with -d, like Idir (docker run -d --name demo nginx:1.27).
- Display it (ps), read its logs.
- Enter it with exec -it … sh, then exit (exit).
- Stop it, remove it, check with ps -a.
Step-by-step script — Idir's demo cycle in 6 commands (5 min)
1) Type docker run -d --name demo nginx:1.27: background birth. 2) Type docker ps then docker logs demo: the living one and its journals. 3) Type docker exec -it demo sh, look, then type exit: entering and leaving. 4) Type docker stop demo then docker rm demo: polite stop then removal. 5) Type docker ps -a: like Idir, check demo is gone — otherwise, docker container prune to purge exited containers.
For a simple disposable trial, add --rm to run: no step 4 to forget.
Copy-paste template — my lifecycle memo
docker run -d --name demo nginx:1.27 # being born (pull + create + start)
docker ps # seeing the living (ps -a = all)
docker logs demo # reading (logs -f = following)
docker exec -it demo sh # entering (exit = leaving)
docker stop demo # polite stop (SIGTERM then SIGKILL)
docker rm demo # removing the husk
docker ps -a # checking it is goneDisposable trial
Idir tests an unknown image with --rm: the container self-removes on stop, no exited container.
Express debugging
Silent service: Idir reads docker logs demo first, then enters with exec -it demo sh if needed.
Polite stop
In production, Idir prefers stop (SIGTERM, clean finish) to kill (instant death).
Big cleanup
Dozens of forgotten exited containers: Idir purges with docker container prune and restarts clean.
✓ Best practices
- Name (--name) to aim right afterwards.
- Use --rm for all disposable trials.
- Prefer stop to kill: apps finish cleanly.
✗ Common pitfalls
- Leaving dozens of exited containers (forgotten prune).
- Mixing up rm (container) and rmi (image).
- Closing the terminal instead of stopping (-d ghosts).
Key takeaways
- run creates AND starts.
- ps sees, logs reads, exec enters.
- stop stops, rm removes.
- --rm and prune keep the machine clean.
48h challenge — apply tomorrow
Play Idir's demo cycle without cheating: named run -d, ps, logs, exec + exit, stop, rm — then ps -a to prove nothing remains.
- I can play the run → ps → logs → exec → stop → rm cycle unaided.
- I can read living and dead with ps and ps -a.
- My machine stays clean (--rm for trials, prune against exited).
Frequently asked questions
Difference between stop and kill?
stop sends SIGTERM (the app ends cleanly) then SIGKILL after a delay; kill kills immediately. In production, prefer stop — Idir's reflex for apps.
Where do logs go?
The daemon captures them (json-file by default). docker logs rereads them; think about rotation for long-lived services.
You test a disposable image. Which option avoids forgetting cleanup?