🔄 Lifecycle & Debug

Lifecycle & Debug: A container's life is like a hotel guest's stay: docker ps is the reception desk listing who is currently checked in, stop/start is stepping out and returning

A container's life is like a hotel guest's stay: docker ps is the reception desk listing who is currently checked in, stop/start is stepping out and returning to the room, rm is checking out for good — and logs/exec are the room's security camera and the master key that lets you walk in while the guest is still inside. Why do stop and rm exist as two separate steps instead of one 'kill it' command? For the same reason Java separates close() from letting the object be garbage-collected: a stopped container keeps its filesystem — invaluable evidence — while rm destroys it permanently. In real QA work this order matters: when a test container crashes in CI at 3 AM, the engineer who ran 'docker logs' BEFORE 'docker rm' has the stack trace; the one who cleaned up first has nothing to attach to the bug report.

Why Does the Difference Between docker ps and docker ps -a Matter?

docker ps lists ONLY the containers…

`docker ps` lists ONLY currently RUNNING containers — a stopped container does NOT appear at all, which can look like it was deleted.

docker ps -a shows STOPPED and…

`docker ps -a` shows ALL containers including STOPPED ones and ones NEVER started — "where did my container go?" is USUALLY answered by this command first.

The "Exited (1)" text in the STATUS…

The "Exited (1)" text in the STATUS column shows the container EXITED with a NON-ZERO error code — any number other than 0 is an ALARM for QA.

Type docker ps in the sandbox — this completes mission 3 and shows you a live table of running containers right in the terminal.

Lifecycle — stop, start, restart

Why Does docker stop NOT Kill the Container INSTANTLY?

docker stop FIRST sends a SIGTERM…

`docker stop` FIRST sends a SIGTERM signal — a POLITE way of saying "get READY to shut down, CLEAN UP open connections".

If the app does not exit within 10…