You start a long-running program from an interactive Linux shell with `&`, then the shell process is killed. The program keeps running, but its parent process ID is now 1. What happened to it, and what does that change for the process itself?
answer
- nobody dies when the parent does
- the link is rewritten, not the process
- PID 1 adopts, unless somebody claimed it first
- alive with a new guardian, not dead and unclaimed
- ask in advance if you want telling
basics
~20 sThe program became an orphan and the kernel reparented it to PID 1 (or the nearest ancestor marked as a subreaper). It keeps running unchanged — same PID, same memory, same open files — and its exit status will be collected by its new parent.
solid answer
~50 sLosing a parent does not harm a Linux process. When a parent terminates, the kernel walks its surviving children and reassigns each one to a new parent: PID 1 by default, or the closest ancestor that has called `prctl(PR_SET_CHILD_SUBREAPER, 1)` — which is how a service manager or a container init keeps orphans of its own tree. The child is unaffected: same PID, same address space, same open descriptors, same scheduling. Only its recorded PPID changes, and with it the identity of whoever will eventually reap it — which is exactly why an orphan never becomes a permanent zombie. No signal is sent to the child for this; if it wants to know, it must ask in advance with `prctl(PR_SET_PDEATHSIG, SIGTERM)`. So an orphan is a live process with a new guardian, while a zombie is a dead process with a negligent one.
go deeper
Know that a process whose parent exits keeps running and simply gets PID 1 as its new parent — nothing about the process itself changes, and it is not the same thing as a zombie.
Explain what reparenting actually rewrites, why it guarantees the orphan will be reaped later, and that no signal is sent unless the child asked for one with PR_SET_PDEATHSIG.
Demonstrate the operational consequence: killing a parent does not stop its children, so anything that must not outlive its launcher needs an explicit mechanism, and subreapers exist so a supervisor keeps custody of its own tree.
Frame it as a lifecycle-ownership decision: decide where in the platform the adoption point sits, so that every stray process is attributable to a service that can account for and terminate it, instead of drifting up to PID 1 unowned.
## The event: a parent exits first Every Linux process except PID 1 has a parent, recorded as its PPID. That link exists for one purpose — to say who is entitled to, and responsible for, the child's exit status. When a parent terminates while it still has living children, the kernel cannot simply leave those children pointing at a freed record, and it certainly must not kill them: plenty of legitimate designs rely on a child outliving its parent. So it *reparents* them. ## Who becomes the new parent By default the new parent is PID 1, the system's init process. Since Linux 3.4 a process can intercept that by marking itself a **subreaper**: ```c #include <sys/prctl.h> prctl(PR_SET_CHILD_SUBREAPER, 1, 0, 0, 0); ``` Any orphan whose ancestry passes through that process is reparented to it instead of to PID 1. Service managers and container init processes use this so that a whole process tree's strays stay inside the tree that owns them, rather than escaping to the top of the machine where nobody can associate them with a service any more. The kernel picks the *nearest* such ancestor. If there is none, PID 1 gets the child. ## What actually changes for the orphan Remarkably little: - **PID: unchanged.** A process keeps its PID for life. - **Memory, open file descriptors, current directory, credentials: unchanged.** Reparenting rewrites a link in the kernel's process tree, nothing more. - **Scheduling: unchanged.** It is not paused, deprioritised or restarted. - **PPID: now 1 (or the subreaper).** - **Who reaps it: now the new parent.** This is the substantive consequence, and it is a good one — init sits in a wait loop, so when the orphan eventually exits, its status is collected at once and it does not linger as a zombie. ## No signal announces it A process is not told that it has been orphaned. If it needs to react — a helper that should not outlive the daemon that launched it, say — it must arrange notification *in advance*: ```c prctl(PR_SET_PDEATHSIG, SIGTERM); /* signal me when my parent dies */ ``` This is per-process, set by the child itself (usually right after fork), and it is cleared across a change of credentials. Note the deliberate race: if the parent has already died by the time the child calls this, no signal ever arrives, so careful code re-checks its PPID immediately afterwards. ## Orphan versus zombie — the distinction interviewers are fishing for | | Orphan | Zombie | |---|---|---| | Is it running? | Yes, alive and scheduled | No, already terminated | | Whose fault? | Nobody's — normal | The parent's, for not waiting | | What holds it? | Nothing; it is a normal process | Its status record, awaiting collection | | Cleared by | Exiting normally, later | The parent calling wait() | A process can of course be both in sequence: it is orphaned while alive, then becomes a brief zombie under init when it finally exits — a zombie that init reaps within microseconds. ## The classic use: daemonising The traditional double-fork daemon exploits reparenting deliberately. A process forks, the intermediate parent exits at once, and the grandchild — now an orphan — is adopted by PID 1, deliberately severed from the launching shell and its session. Modern service managers make this unnecessary (they prefer to supervise a foreground process they started themselves), but the mechanism the old idiom relies on is exactly the one in this question. ## The related trap Because an orphan keeps running, "I killed the parent" is never proof that a job stopped. Work that must not outlive its launcher needs an explicit mechanism — `PR_SET_PDEATHSIG`, a supervisor that tracks the whole tree, or a resource-control grouping that can be terminated as a unit. Relying on the parent's death to take children with it is a bug, not a design.
- What does PR_SET_CHILD_SUBREAPER change, and why would a process manager set it?It marks a process as the adoption point for orphans in its own subtree: instead of going to PID 1, an orphaned descendant is reparented to the nearest ancestor carrying that mark. A service manager or container init sets it so strays stay attributable to the service that spawned them, and so it — rather than PID 1 — receives their exit statuses and can act on them.
- Can a process be notified when its own parent dies?Only if it asked beforehand, with `prctl(PR_SET_PDEATHSIG, SIGTERM)` or a similar signal. Reparenting itself sends nothing. The call has a race: if the parent has already exited when it runs, the signal never arrives, so robust code re-reads its PPID straight afterwards and exits if it is already an orphan.
- Is an orphan the same thing as a zombie?No, and conflating them is a common tell. An orphan is alive and running; it merely has a new parent. A zombie has already terminated and persists only as a status record its parent has not collected. An orphan will briefly become a zombie under its new parent when it eventually exits, but that parent is usually init, which reaps immediately.
saying these in an interview costs you the question
- Believes the kernel kills children when the parent exits
- Says the orphan gets a new PID after reparenting
- Assumes the child is signalled when its parent dies
- Uses orphan and zombie as interchangeable words
- Thinks killing the parent reliably stops its children