Signals, zombies and PID 1: why a container ignores SIGTERM

What is actually being asked

The ladder is almost always the same, and it rests on a single mechanism even though the questions look unrelated:

1. "What is a zombie process?" — the warm-up that filters out anyone who thinks it means a hung process.
2. "Why is it a problem if the process itself is already gone?" — where the substance starts.
3. "Who becomes the parent of an orphaned process?" — a check on adoption and on subreapers.
4. "Why does a container not stop at once?" — where the tempting answer is "it closes connections slowly": plausible, and past the mechanism.
5. "What does exit code 137 mean?" — whether you know the arithmetic and what the code does not tell you.
6. "Why do people put tini in a container?" — whether you have connected the first five into one thing.

The lesson climbs that ladder in one direction: the rule first, its consequences after. Every number below was produced on one machine by bench/signals/lifecycle.py and bench/signals/practice.py; your process IDs and millisecond timings will differ, while the states, the exit codes and the outcome of SIGTERM for PID 1 will not.

Base: a process, its number, and the message you send it

Before talking about zombies and about the number 1, it is worth naming, in ordinary words, the four things the whole lesson rests on.

A process is a running program. Not the file on disk but its run: the same program started twice is two processes, and they live independently of each other.

A process has a number. The kernel hands it out at startup, and that number is how the process is addressed afterwards: to look at it, to stop it, or to wait for its end.

A signal is a short message to a process. The kernel or another process sends it, and it carries exactly as much meaning as its own number: "finish up nicely", "stop right now", "suspend". No text, no reply: a signal either did something to the process or did nothing at all.

Processes have a parent and a child — the one that did the starting and the one that was started. That link is not a formality: it is the parent that later receives the answer to how the child ended.

The first rung of the ladder follows straight from those last two points. A child has finished; the parent has not yet asked how it ended; the kernel needs somewhere to keep the answer to that future question — and it keeps it. The state "the process is gone but the record of how it ended is still there" is what a zombie is.

And one more thing, without which the second half of the lesson reads as magic: a container has its own space of numbers. Processes inside it are numbered from one, as in a machine that has just booted, while the very same process has a completely different number outside. One process, two numbers: 1 inside, an ordinary one outside. Whoever stops the container lives outside and signals the external number — and the rules that apply to the process are the ones that apply to the number 1.

That is already enough to answer the basic interview question. What follows is about why the same signal acts differently on an ordinary process and on the process numbered 1, who gets the child when its parent dies first, and where the 137 in a report comes from.

Mechanism 1: a process dies twice, not once

Now the same thing in the documentation's words — starting with what does not depend on the distribution or the kernel version.

A process ends in two separate events. First it stops running — it calls exit, takes a fatal signal, crashes. Then somebody collects its status by calling wait. Between those two events the process is gone and the record of it is not.

That record is the zombie, and wait(2) says so directly:

That answers the second rung immediately. A zombie is not dangerous because it "sits in memory": the process's address space is gone, and what remains is the minimal set of information listed in the quotation above. It is dangerous because that record holds a slot in the process table, and the table is finite:

This is a leak with nothing to see on the memory graph. The application runs, memory is flat, and then fork starts failing — in some process that has nothing to do with the one at fault.

Here it is in a run. The child called _exit(7) and was left unwaited:

1. ZOMBIE: the child is gone, the record is not
-----------------------------------------------
  child finished, status not collected       Z (zombie)
  why the kernel keeps the record            so the parent can read the exit code
  state after wait                           no such process
  exit code the record was held for          7

Four lines that read as one story: state Z before wait, nothing after it, and the seven the record was being held for. What removes a zombie is not time and not a collector — it is the question "how did it end", asked by the parent.

Mechanism 2: an orphan gets a new parent, and it is a real one

The mirror case: the parent dies before the child. The child neither dies nor becomes parentless — it is adopted.

The run catches the substitution itself. A grandchild prints its parent twice — right after it starts, and after its father has exited:

2. ORPHAN: the parent died first
--------------------------------
  grandchild: parent right after start    5359
  grandchild: parent after father exits   1

The 5359 will be different on your machine; the 1 will not. And here is what follows for real work: the new parent is the one who will collect the orphan's status, not the lost one. If the new parent knows how, zombies never pile up. If it does not, every orphan piles up at once — which is exactly what happens in a container whose first process is an ordinary application.

The word "subreaper" is not decoration. PR_SET_CHILD_SUBREAPER is how a process tells the kernel: orphans from my subtree come to me, not to PID 1. Session managers and supervision systems use it; a container usually has none, so orphans go straight to PID 1.

Mechanism 3: the PID 1 rule that everything else grows from

Now the important part. A process that received ID 1 in its own namespace handles signals differently, and pid_namespaces(7) writes it down:

From the outside it works the same way, and that is precisely the orchestrator's case: it lives in the ancestor namespace and sends a signal to your first process.

Put in the words worth answering with: for PID 1 the default action of a signal is not carried out. A signal's disposition is what the process does with it: the default action from the signal(7) table (SIGTERM is listed as Term — terminate), ignoring it, or a handler. An ordinary process without a handler gets the first. PID 1 has no first: with a handler the signal works, without one it does nothing.

The same SIGTERM, two processes that differ by one line:

3. PID 1: one SIGTERM, two outcomes
-----------------------------------
  PID inside the namespace (no handler)      1
  SIGTERM from outside, no handler (PID 5362) ALIVE: the signal did nothing
  PID inside the namespace (with handler)    1
  SIGTERM from outside, with handler (PID 5364) exited

Note that the signal is sent from outside and by the external ID (5362), while inside the namespace that process is number 1. The orchestrator does the same: it does not step inside the container, it signals a process that looks ordinary from where it stands.

There is exactly one exception:

So "the container cannot be stopped" is the wrong phrasing. It can always be stopped; the question is whether the orchestrator burns the whole grace period first.

Mechanism 4: what a missing handler costs, and where 143 and 137 come from

Stopping a container is three steps: SIGTERM, a grace period, SIGKILL. The length of that period is set by whoever is doing the stopping and is named in its own settings; what matters for the lesson is not the particular number but that the period is finite and that what follows it cannot be caught. The difference between "stopped in milliseconds" and "stopped after the full period" is exactly the presence of a handler.

The script reproduces that sequence with a two-second period:

stop time, SIGTERM handled           11 ms
stop time, no handler                2009 ms

The second number is not "a slow shutdown". It is the entire grace period plus the time it takes the SIGKILL to land: the process is alive and well throughout, the SIGTERM had no effect on it, and then SIGKILL arrives, which nothing catches.

Then the arithmetic of exit codes. The kernel reports two different things: the code a process exited with, and the number of the signal that killed it. Whoever prints the result is the one who adds them up:

Hence the table people ask about:

4. EXIT CODES: 128 + signal number
----------------------------------
  exited on its own                          3
  SIGTERM, default disposition               -15 (the shell reports 143)
  SIGKILL                                    -9 (the shell reports 137)

143 is 128 + 15, SIGTERM. 137 is 128 + 9, SIGKILL. The minus fifteen is how subprocess returns a signal number: negative, so that it cannot be mistaken for an exit code.

And the most useful part is what 137 does not say. It says the process was killed by SIGKILL. It does not say who sent it. The OOM killer, the orchestrator after the grace period, a human with kill -9 — indistinguishable in that field, and the application log will hold nothing, because SIGKILL runs no line of code. Telling them apart takes other evidence: the kernel message, the orchestrator's event, the timing.

Deeper: why containers ship an init

Now the parts fit together. Your application became PID 1, which means:

• default signal actions are not carried out for it, so SIGTERM without a handler does nothing;
• every orphan in the container is adopted by it, so collecting their statuses is its job too.

An ordinary application does neither: it never expected to be the first process. Hence the two classic failures — a container that only stops on timeout, and a container quietly accumulating zombies from every subprocess it spawns.

Hence the role that small init processes (tini, dumb-init, the docker run --init flag) are written for: take PID 1 and cover both duties — forward signals to the child and reap orphans. The rule about default actions becomes that process's problem rather than yours; what any particular one of them does is stated in its own documentation.

The alternative is not a library but two lines in the application: install a SIGTERM handler and wait for children. If the application spawns no processes, the first line is enough.

How to answer in an interview

Short answer: for the process with ID 1 in its own namespace the default action of a signal is not carried out, so SIGTERM without a handler does nothing to it — the orchestrator waits out the grace period and finishes the job with SIGKILL, leaving exit code 137, that is 128 + 9, in the report. A zombie, meanwhile, is not a process but the record of a death: it is held for the exit code, it occupies a slot in the process table, and what removes it is wait, not time.

That is enough for a correct answer. What follows is what you add when the interviewer digs.

If the interviewer digs deeper

Two things separate a good answer. First, you call the rule a kernel rule rather than a Docker quirk, and you know the exception: SIGKILL and SIGSTOP from an ancestor namespace are delivered forcibly, so stopping always works and only the delay is in question. Second, you say what 137 does not report: who sent the signal. "137 means OOM" turns a piece of evidence into a diagnosis, and those are different things.

Next they ask

Common misconceptions

Practice

Two exercises. Answer first, then check against the real output: in both, the correct answer comes from a script's run rather than from an editor.

pid = os.fork()
if pid == 0:
  os._exit(7)
time.sleep(0.2)
print(state_of(pid))
print(os.waitstatus_to_exitcode(os.waitpid(pid, 0)[1]))
print(orphan_ppid())
print(pid1_state_after_sigterm(SLEEPER))
killed = subprocess.Popen([sys.executable, "-c", "import time; time.sleep(5)"])
time.sleep(0.2)
killed.send_signal(signal.SIGKILL)
print(128 - killed.wait())

Z
7
1
S
137

Z
7
0
S
143

S
7
1
Z
137

Z
0
1
S
143

Knowledge check