TL;DR: SIGTERM is a request the process can catch, block or ignore; SIGKILL forces termination without a userspace handler, though uninterruptible kernel work can delay completion. Containers ignore SIGTERM most often because the app is PID 1, and PID 1 has no default action for catchable signals, so an unhandled SIGTERM is silently discarded.
How to approach it
Answer in two layers: what the kernel does with each signal, then why a container specifically is a place where the first layer surprises people. Do not start with docker stop. The interviewer is checking whether you understand the mechanism or the command.
A strong answer
SIGTERM (15) is delivered to the process, which gets to decide. It can install a handler, flush buffers, drain connections, and exit on its own terms. It can also block or ignore it entirely, which is the whole point of a polite signal.
SIGKILL (9) is a signal whose disposition cannot be changed. The kernel forces task termination when it can act on the signal; an uninterruptible wait can delay teardown. No handler runs, no destructor fires, no buffer flushes, no defer executes. Anything the process was writing at that moment is whatever the page cache happened to hold. SIGKILL cannot be caught, blocked or ignored, which is exactly why it is the last resort rather than the default.
Now the container part. When you ENTRYPOINT your app directly, it runs as PID 1 in its namespace, and PID 1 is special: the kernel does not apply default actions for catchable signals to it. For any other process, SIGTERM with no handler means terminate. For PID 1, SIGTERM with no handler means nothing at all. The signal is delivered and discarded, and the process keeps running until the grace period expires and the runtime sends SIGKILL.
The second common cause is a shell in the way. ENTRYPOINT ["sh", "-c", "myapp"] puts sh at PID 1, and it does not forward signals to its child. Your app never sees SIGTERM even though the signal was sent correctly. exec myapp or the exec-form entrypoint fixes it.
In Kubernetes the visible symptom is that every pod takes exactly terminationGracePeriodSeconds to disappear, usually 30 seconds, and dropped connections during every rollout. If deleting a pod always takes precisely the grace period, inspect signal handling, preStop duration and application shutdown. Matching the grace period is a clue, not proof that no signal arrived.
# signals reach the app: exec form, app is PID 1 and handles SIGTERM
ENTRYPOINT ["/app/server"]
# signals die at the shell: sh is PID 1, does not forward
ENTRYPOINT /app/server
What interviewers probe next
"How would you confirm the app is receiving the signal?" Run kill -TERM 1 inside the container and watch whether it exits before the grace period, or check that /proc/1/status shows SIGTERM in SigCgt rather than only SigIgn.
"What is the correct graceful shutdown sequence for a Kubernetes pod?" The endpoint removal and the SIGTERM race, so you want a preStop sleep of a few seconds to let kube-proxy and the ingress stop sending traffic, then handle SIGTERM to drain in-flight requests, and finish inside the grace period.
"When would you deliberately use SIGKILL?" When the process is wedged in a state it cannot exit from, and you have accepted that anything unflushed is lost. Never as the routine path for a stateful service.
Common mistakes
Saying "SIGTERM is graceful and SIGKILL is forceful" and stopping there. That is a definition, not an answer, and the follow-up will find the gap immediately.
Blaming a slow shutdown on the application when every pod takes exactly the same number of seconds. Identical timing can mean the grace deadline was exhausted, including by a slow hook or handler.
Adding an init process such as tini as the fix without saying what it fixes. It reaps zombies and forwards signals, and running the application as a non-PID-1 child restores ordinary default SIGTERM termination even without a custom handler. Graceful application cleanup still needs its own support.
References