Lesson 19 of 30

Init Systems, PID 1 & Signal Handling

Q: Your team notices in-flight requests get dropped on every deploy, even though the orchestrator waits for old containers to be removed only after new ones are healthy. Walk through why this could still happen and how you'd fix it.

A strong answer covers: Identifies that the orchestrator's rollout mechanics aren't the whole picture — the application's own SIGTERM handling matters independently; Explains the SIGTERM-then-SIGKILL sequence: docker/orchestrator sends SIGTERM, waits a grace period, then SIGKILLs if the process hasn't exited; Connects this to PID 1: without --init/tini or a correct handler, the app may not gracefully stop accepting new work and drain in-flight requests before exiting; Proposes a concrete fix: add a real SIGTERM handler that stops accepting new connections and drains existing ones, and/or use --init or an init: true equivalent.

The first process in a container inherits a job it almost never asked for — and the way it responds (or doesn't) to a stop signal decides whether a deploy is clean or drops requests.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A container's main process runs as PID 1 without `--init` or an equivalent. What responsibility does it silently inherit that most application binaries were never written to handle?

Reaping zombie processes and correctly forwarding signals to childrenAllocating the container's CPU and memory limitsResolving the container's DNS hostname on the network

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Init Systems, PID 1 & Signal Handling

What interviewers actually ask about this, and what a strong answer has to cover.

Your team notices in-flight requests get dropped on every deploy, even though the orchestrator waits for old containers to be removed only after new ones are healthy. Walk through why this could still happen and how you'd fix it.

A strong answer covers

Identifies that the orchestrator's rollout mechanics aren't the whole picture — the application's own SIGTERM handling matters independently
Explains the SIGTERM-then-SIGKILL sequence: docker/orchestrator sends SIGTERM, waits a grace period, then SIGKILLs if the process hasn't exited
Connects this to PID 1: without --init/tini or a correct handler, the app may not gracefully stop accepting new work and drain in-flight requests before exiting
Proposes a concrete fix: add a real SIGTERM handler that stops accepting new connections and drains existing ones, and/or use --init or an init: true equivalent

Likely follow-ups

If graceful shutdown routinely takes longer than the default grace period, what are your actual options — and what's the tradeoff of each?
How would shell-form vs exec-form CMD in the Dockerfile change your diagnosis here?

Practice these with the AI interviewer →

The plain-language idea

Every container runs its main process as PID 1 inside its own PID namespace — the container's version of "process ID 1," the role the kernel's real init plays on a normal machine. On a full OS, PID 1 has two jobs beyond running its own code: reaping zombie processes (cleaning up the exit status of any process whose parent already exited) and correctly forwarding signals to child processes. A real init system is built for that job. Most application binaries — a Node server, a Python script, a compiled Go binary — were never written with it in mind, because on a normal machine they'd run as PID 200-something, not PID 1.

This causes two separate, common problems. First, zombie processes accumulate if your app spawns child processes (a shell script calling other binaries, a process manager forking workers) and never explicitly reaps them — PID 1 is supposed to do that automatically for anything left orphaned, and most application code doesn't. Second, and more visibly: signal handling. When you run docker stop, Docker sends SIGTERM to PID 1, waits a grace period (10 seconds by default), and if the process hasn't exited by then, sends SIGKILL — which cannot be caught or ignored. If PID 1 doesn't have a handler for SIGTERM at all, nothing happens during the grace period, and the container gets hard-killed every single time it's stopped.

See it in a real thing: `docker run --init`

FROM node:20-slim
COPY . .
CMD ["node", "server.js"]

docker run --init myapp

Without --init, node server.js runs as PID 1 directly. --init inserts a tiny real init process (Docker bundles tini) as PID 1 instead, which then execs node server.js as its child. That tiny init does the job a full-blown init system does — reaping zombies, forwarding signals correctly — while your actual application process runs as PID 2 or higher, exactly like it would on a normal machine, with no special PID-1 responsibilities to worry about.

What people usually miss

Watch out

--init (or a bundled tini) is not automatic — it's opt-in. docker run and Compose's init: true both require you to ask for it; plain docker run myapp gives your app PID 1 with zero init behavior for free.
A caught SIGTERM still has to actually finish work, not just acknowledge the signal. A graceful shutdown handler needs to stop accepting new connections, let in-flight requests complete, then exit — a handler that just logs "shutting down" and exits immediately still drops whatever was mid-request.
The grace period is finite and the app doesn't get to negotiate it. If graceful shutdown routinely takes longer than the default grace window, in-flight work gets SIGKILLed anyway — the fix is either shortening actual shutdown time or explicitly configuring a longer grace period, not hoping the default is enough.
This is exactly why zero-downtime deploys depend on more than just the orchestrator. An orchestrator can start new containers and remove old ones cleanly, but if the application doesn't handle SIGTERM gracefully, requests still get dropped on every single deploy regardless of how careful the rollout mechanism is.

Why this matters in interviews

"Why did requests drop during our last deploy even though we use rolling updates?" is a real production question, and "the app never handled SIGTERM" is frequently the actual answer — naming PID 1's role and the SIGTERM-then-SIGKILL sequence precisely is what separates a candidate who's debugged this from one who's only read about orchestration in the abstract.