PR_SET_PDEATHSIG Binds a Child Notification to Parent Thread Exit

PR_SET_PDEATHSIG lets a Linux process request a signal when the thread that created it terminates. The mechanism is narrow: it is a kernel-delivered notification tied to a parental relationship, not a general process-lifetime contract and not a guarantee that two processes terminate together.

That distinction matters in supervisors, launchers, and helper processes. A child can react to loss of its creator without polling a PID, but the exact parent identity, setup timing, inheritance rules, and credential transitions define where the mechanism stops.

The setting belongs to the calling process

The request is installed with prctl():

if (prctl(PR_SET_PDEATHSIG, SIGTERM) == -1) {
    perror("prctl");
    exit(EXIT_FAILURE);
}

The signal argument may be a valid signal number or zero to clear the setting. When the relevant parent terminates later, the kernel generates the configured signal for the child. The signal is process-directed, so normal signal disposition and masking rules still govern its delivery and handling.

With a SA_SIGINFO handler, siginfo_t.si_pid identifies the terminating parent process. This can be useful when reparenting through subreapers causes more than one qualifying ancestor termination during the child’s lifetime.

PR_SET_PDEATHSIG does not create a new signal class. It arranges for an ordinary Linux signal to be generated at a specific lifecycle event.

Parent means the thread that created the process

The most important boundary appears in multithreaded parents. For this interface, the relevant parent is the thread that created the child, not the parent process considered only as a thread group.

If that creating thread exits with pthread_exit(), the configured signal can be generated even while other threads in the parent process continue running. Software that treats the setting as equivalent to “notify me when the entire parent process disappears” can therefore attach the wrong lifecycle meaning to the event.

This thread-level rule follows the kernel relationship used by the interface. A launcher that creates children from worker threads must account for worker-thread lifetime separately from the lifetime of the launcher’s process.

Setup has a race boundary

The notification applies to subsequent parent termination. If the parent thread has already terminated before the child installs PR_SET_PDEATHSIG, the kernel does not retroactively generate the signal merely because the setting is added later.

A child that needs to close this race can record its parent PID before installing the setting, call prctl(), then check the parent relationship again. That check is application coordination around the interface; PR_SET_PDEATHSIG itself does not make the setup sequence atomic with process creation.

The distinction is especially relevant when the parent can exit immediately after fork(). A successful prctl() call says the setting was installed, not that the parent was still alive at every earlier point in the child’s startup.

fork clears the setting in the new child

The parent-death signal setting is not inherited unchanged through fork(). A newly created child starts with this setting cleared.

This prevents a descendant from silently inheriting a lifecycle signal that referred to its parent’s own creator. Code that forks again and expects the next generation to receive a parent-death signal must install its own setting in that process.

Across execve(), the setting is normally preserved, but there are security-sensitive exceptions. Executing a set-user-ID or set-group-ID program, or a program with associated file capabilities, clears the setting under the documented Linux rules. Changes to effective or filesystem user and group IDs can also clear it.

Those boundaries make the attribute unsuitable as an invisible assumption across arbitrary privilege transitions. A program that depends on the notification after changing credentials must verify the state appropriate to that transition.

Subreapers extend the sequence of qualifying exits

Linux subreapers alter orphan reparenting. When a process is reparented to an ancestor subreaper, subsequent termination of that subreaper can also trigger the configured parent-death signal.

This means the mechanism can describe more than a single original-parent event over a process lifetime. A service manager acting as a subreaper may become the new parent for descendants whose immediate parents exit, and the kernel’s parent-death notification follows that reparenting behavior.

The signal remains a notification. It does not reap children, transfer exit status, or replace wait() semantics. Subreaper responsibilities and parent-death signaling solve different lifecycle problems even when they meet in the same process tree.

The mechanism is a lifecycle edge, not a kill guarantee

A common use is to request SIGTERM or another signal so a helper can react when its creator disappears. The resulting action still depends on signal semantics. A blocked signal can remain pending, a caught signal invokes its handler, and an ignored signal has no terminating effect.

For a strict containment policy, other Linux mechanisms may be needed alongside this one, depending on the process model. PR_SET_PDEATHSIG contributes one precise edge: a configured signal is generated when the relevant parent thread or later qualifying subreaper terminates.

Its value comes from keeping that edge explicit. It avoids PID polling and ties notification to kernel-maintained parentage, while leaving process termination policy, signal handling, privilege transitions, and broader supervision to separate mechanisms.