What is the difference between stopping and killing a container?
Understand docker stop vs docker kill: SIGTERM with a grace period for clean shutdown versus an immediate SIGKILL, and when to use each safely.
Expected Interview Answer
docker stop asks the container to shut down gracefully by sending SIGTERM and waiting a grace period (default 10s) before forcing SIGKILL, while docker kill terminates it immediately by sending SIGKILL (or a signal you specify) with no wait.
The distinction is about giving the application a chance to clean up. On docker stop the main process (PID 1) receives SIGTERM so it can flush buffers, close connections, finish in-flight requests, and exit on its own; only if it ignores SIGTERM past the timeout does Docker escalate to SIGKILL. docker kill skips the grace period entirely, which is faster but can cause data loss, corrupted files, or half-finished work. You should handle SIGTERM in your app so graceful stop actually works.
- docker stop enables clean shutdown and data flushing
- docker kill guarantees immediate termination when a container is hung
- Both let you control the exact signal or timeout
- Understanding them prevents accidental data loss
- Correct signal handling improves orchestration rollouts
AI Mentor Explanation
docker stop is the umpire calling 'over' and letting the bowler finish the current delivery and the batters complete their run before play pauses. docker kill is a sudden abandonment for lightning on the field — everyone drops everything instantly, mid-run, mid-ball, with no chance to complete the play in progress.
Step-by-Step Explanation
Step 1
Send graceful signal
docker stop sends SIGTERM to PID 1 of the container, asking it to terminate on its own.
Step 2
Wait the grace period
Docker waits the timeout (default 10s, tunable with -t) for the process to exit cleanly.
Step 3
Escalate if needed
If the process is still alive after the timeout, docker stop sends SIGKILL to force it down.
Step 4
Immediate kill
docker kill skips SIGTERM and the wait, sending SIGKILL (or --signal) right away.
Step 5
Choose based on state
Use stop for stateful apps that must flush; use kill for hung containers or when you deliberately want instant termination.
What Interviewer Expects
- Knowing docker stop uses SIGTERM then SIGKILL
- Knowing docker kill sends SIGKILL immediately by default
- Understanding the configurable grace period (-t)
- Awareness that graceful stop needs app-level signal handling
- Recognising the data-loss risk of an abrupt kill
Common Mistakes
- Thinking docker stop and docker kill are identical
- Believing docker stop only sends SIGKILL
- Not handling SIGTERM in the app, so stop always falls back to SIGKILL
- Assuming SIGKILL can be caught or ignored by the process
- Using kill routinely on stateful services and causing corruption
Best Answer (HR Friendly)
“Stopping a container politely asks it to finish up and shut down cleanly, waiting a few seconds. Killing a container ends it instantly with no warning, which is faster but can lose unsaved work, so you kill only when a container is stuck.”
Code Example
# Graceful: SIGTERM, wait up to 10s, then SIGKILL if still alive
docker stop my-container
# Give the app 30 seconds to clean up before force
docker stop -t 30 my-container
# Immediate: send SIGKILL right now, no grace period
docker kill my-container
# Kill with a specific signal instead of SIGKILL
docker kill --signal=SIGINT my-container// Node.js graceful shutdown on SIGTERM
process.on('SIGTERM', () => {
console.log('SIGTERM received, closing server...')
server.close(() => {
db.disconnect()
process.exit(0)
})
})Follow-up Questions
- What signal does docker stop send first, and what does it fall back to?
- How do you change the grace period for docker stop?
- Why might an app never shut down gracefully even though you use docker stop?
- Can a process catch or ignore SIGKILL? Why or why not?
- How does PID 1 behavior in containers affect signal handling and zombie reaping?
MCQ Practice
1. What sequence of signals does 'docker stop' use by default?
docker stop sends SIGTERM, waits the grace period (default 10s), and only then sends SIGKILL if the process is still running.
2. What does 'docker kill' send by default?
docker kill sends SIGKILL immediately with no grace period, unless you override the signal with --signal.
3. Why might docker stop still end up force-killing a container?
If the app doesn't handle SIGTERM and is still alive after the grace period, Docker escalates to SIGKILL.
Flash Cards
docker stop signal order — SIGTERM, wait grace period (default 10s), then SIGKILL.
docker kill default signal — SIGKILL immediately (override with --signal).
Change stop grace period — docker stop -t <seconds> <container>.
Can SIGKILL be caught? — No — SIGKILL cannot be caught, blocked, or ignored by the process.
When to prefer kill — When a container is hung/unresponsive or you deliberately want instant termination.