MidLinux

What is the difference between SIGTERM and SIGKILL, and why does it matter for containers?

What they are really testing: Whether you understand graceful shutdown, which is the mechanism behind dropped requests during deploys. Also whether you know the PID 1 signal-handling trap in containers.

A real interview question

What is the difference between SIGTERM and SIGKILL, and why does it matter for containers?

What most people say

drag me

SIGTERM asks nicely and SIGKILL forces it. You use SIGKILL when SIGTERM does not work.

It is technically correct and stops before everything that matters operationally: the grace period, what the application should do in it, and the reason a container often ignores SIGTERM entirely despite handling it correctly in code.

The follow-ups they ask next

  • Every pod takes exactly 30 seconds to terminate. What does that tell you?

    It is not handling SIGTERM, so it is waiting out the grace period and dying by SIGKILL. Check for a PID 1 handler and whether a shell entrypoint is swallowing the signal.

  • Requests still fail during shutdown despite correct handling. Why?

    A race: endpoint removal propagates asynchronously, so traffic can still arrive just after SIGTERM. A preStop hook with a short sleep lets removal propagate before shutdown begins.

What the interviewer is listening for

  • Describes the full orchestrator sequence
  • Knows the PID 1 signal trap
  • Raises the endpoint removal race

What sinks the answer

  • Only defines the two signals
  • Unaware of grace periods
  • No idea why a container might ignore SIGTERM

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

SIGTERM [can be caught so the process can finish work], SIGKILL [cannot]. Kubernetes [removes the endpoint, sends SIGTERM, waits the 30 second grace period, then SIGKILL]. The app should [stop accepting new work, finish in-flight, close connections, exit]. The trap is [PID 1 gets no default handlers, and a shell entrypoint may not forward the signal].

Keep going with linux

All 87 devops engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free