Introduction

Child processes are not always terminated automatically when the parent dies. On Unix-like systems, a child often becomes an orphan and is re-parented instead, so if you want parent death to stop the child, you need to implement that behavior deliberately.

Understand the Default Behavior First

Many developers assume parent and child lifetimes are tightly linked because the child was created by the parent. In reality, process creation and process lifetime are separate concerns. On Linux and other Unix-like systems, when a parent exits, the child usually keeps running and is adopted by another process such as init or systemd.

That means "kill the parent, kill the child" is not a built-in guarantee. If your application requires it, you must choose an OS-level mechanism that enforces it.

Linux: Use PR_SET_PDEATHSIG

On Linux, the most direct solution is prctl(PR_SET_PDEATHSIG, ...). The child process asks the kernel to send it a signal if its parent dies.

1#define _GNU_SOURCE
2#include <signal.h>
3#include <stdio.h>
4#include <stdlib.h>
5#include <sys/prctl.h>
6#include <sys/types.h>
7#include <sys/wait.h>
8#include <unistd.h>
9
10int main(void) {
11    pid_t pid = fork();
12
13    if (pid < 0) {
14        perror("fork");
15        return 1;
16    }
17
18    if (pid == 0) {
19        if (prctl(PR_SET_PDEATHSIG, SIGTERM) == -1) {
20            perror("prctl");
21            return 1;
22        }
23
24        if (getppid() == 1) {
25            fprintf(stderr, "parent already died\n");
26            return 1;
27        }
28
29        while (1) {
30            printf("child still alive, parent pid=%d\n", getppid());
31            sleep(1);
32        }
33    }
34
35    printf("parent pid=%d, child pid=%d\n", getpid(), pid);
36    sleep(3);
37    printf("parent exiting now\n");
38    return 0;
39}

Two details matter here. First, prctl is Linux-specific. Second, there is a small race window between fork and the prctl call, so the getppid() check helps detect the case where the parent already exited.

Use Process Groups for Whole Trees

If the goal is to kill not just one child but an entire subtree of related processes, process groups are often a better fit. The idea is to place the child and its descendants in a dedicated process group, then send a signal to the group ID.

1#include <signal.h>
2#include <stdio.h>
3#include <stdlib.h>
4#include <sys/types.h>
5#include <unistd.h>
6
7int main(void) {
8    pid_t pid = fork();
9
10    if (pid == 0) {
11        setpgid(0, 0);
12        execlp("sleep", "sleep", "300", (char *)NULL);
13        perror("execlp");
14        return 1;
15    }
16
17    sleep(2);
18    kill(-pid, SIGTERM);
19    return 0;
20}

The minus sign in kill(-pid, SIGTERM) means "send the signal to the process group whose ID is pid." This is useful when the child may spawn grandchildren.

Shell Scripts Need Explicit Cleanup Too

In shell scripts, background jobs also keep running unless you trap the parent's exit and clean them up.

1#!/usr/bin/env bash
2
3sleep 300 &
4child_pid=$!
5
6cleanup() {
7  kill "$child_pid" 2>/dev/null
8}
9
10trap cleanup EXIT INT TERM
11
12wait "$child_pid"

This is simple, effective, and often enough for wrapper scripts or local tooling.

Windows Uses a Different Model

Windows does not have prctl, so the usual approach there is a Job Object. A process can create a job, assign child processes to it, and configure the job so all assigned processes are terminated when the job handle closes.

The important point is that there is no single cross-platform API that solves this on every operating system. Parent-death handling is fundamentally platform-specific.

Choose the Mechanism That Matches the Requirement

Use PR_SET_PDEATHSIG when:

• you are on Linux
• you need the child to die if the parent dies unexpectedly
• you only need a direct parent-child lifetime link

Use process groups when:

• you need to stop a whole tree of related processes
• you want explicit signal control from the parent
• the child may spawn additional processes

Use shell traps or platform-native job control when:

• you are writing scripts rather than C programs
• you need cleanup behavior in a wrapper process

Common Pitfalls

The biggest misunderstanding is assuming the operating system automatically kills a child when the parent exits. Another common issue is using prctl and forgetting the race between fork and PR_SET_PDEATHSIG. Process groups also trip people up because signaling one PID is not the same as signaling a whole group. Finally, solutions that work on Linux do not automatically translate to Windows, where Job Objects are the closer equivalent.

Summary

• Parent death does not automatically terminate child processes on Unix-like systems.
• On Linux, prctl(PR_SET_PDEATHSIG, SIGTERM) is the most direct parent-death mechanism.
• Process groups are better when you need to kill a whole child tree rather than one process.
• Shell scripts should trap exit and clean up background jobs explicitly.
• Parent-child lifetime control is platform-specific, so choose a mechanism that matches the target OS.