Orphans And Zombies - Learning Module

Loading content...

0/227

Adoption by init: The Universal Foster Parent

The Orphanage at PID 1

When a child process is orphaned, the operating system faces a critical decision: who should become its new parent? Left without a parent, a process would become a permanent resource leak when it eventually terminates—no process would be responsible for collecting its exit status, and its zombie remains would persist indefinitely.

The Unix solution is elegant: init, the first process started by the kernel and assigned PID 1, serves as the universal foster parent. Every orphan in the system is automatically adopted by init, ensuring that even abandoned processes have a responsible parent waiting to clean up after them. This mechanism is fundamental to Unix system stability and has influenced operating system design for over 50 years.

What You Will Learn

By the end of this page, you will understand: (1) The unique role of init/PID 1 in Unix systems, (2) The mechanics of how orphan adoption works at the kernel level, (3) How init handles its adopted children, (4) Modern implementations with systemd, subreaping, and containers, and (5) The design philosophy behind this approach.

The Special Role of PID 1

PID 1 occupies a unique and privileged position in Unix/Linux systems. It's not just the first process; it has special properties that no other process possesses.

Unique Properties of PID 1 (init)

•First Process — Started directly by the kernel during boot. It is the ancestor of all user-space processes.
•Cannot Be Killed Normally — Signals are handled specially. SIGKILL and SIGSTOP are ignored unless init explicitly sets up handlers for them. This prevents accidental system death.
•Orphan Adopter — Automatically becomes the parent of all orphaned processes. This is hardcoded in the kernel.
•Zombie Reaper — Responsible for calling wait() on adopted children to prevent zombie accumulation.
•System Death on Exit — If PID 1 terminates, the kernel panics. There's no recovery—the system halts.
•Signal Handler of Last Resort — Must handle SIGCHLD to reap adopted children's exit statuses.

The Special Signal Handling

The kernel treats signals to PID 1 differently than to other processes. SIGKILL and SIGSTOP do nothing unless init has explicitly registered handlers for them. This protection ensures that a misguided 'kill -9 1' doesn't bring down the system. The kernel enforces: 'init must survive'.

Converting Mermaid diagram...

Historical Context: The Name "init"

The name "init" comes from "initialization" — it's the process responsible for initializing the system. In traditional Unix:

The kernel boots and mounts the root filesystem
The kernel executes /sbin/init (or similar path)
init reads configuration (historically /etc/inittab)
init spawns getty processes for terminals
init spawns system services
init waits for SIGCHLD to reap adopted children

This pattern has persisted for decades, though modern implementations like systemd have expanded init's capabilities significantly.

The Adoption Mechanism

When a process exits, the kernel must ensure its children have a valid parent. The adoption mechanism is implemented directly in the kernel's process exit path.

Converting Mermaid diagram...

kernel_reparenting.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
/**
 * Kernel orphan reparenting logic (simplified from kernel/exit.c)
 * This runs in the context of the dying parent process
 */
 
void exit_notify(struct task_struct *tsk, int group_dead)
{
    struct task_struct *reaper;
    
    /* Find the reaper for this dying process's children */
    reaper = find_child_reaper(tsk);
    
    /* If we have children, they need new parents */
    if (!list_empty(&tsk->children)) {
        forget_original_parent(tsk, reaper);
    }
    
    /* ... continue with exit processing ... */
}
 
struct task_struct *find_child_reaper(struct task_struct *father)
{
    struct task_struct *reaper;
    
    /*
     * Priority 1: Another live thread in the same thread group
     * This keeps children "in the family" if possible
     */
    reaper = find_alive_thread(father);
    if (reaper != father)
        return reaper;
    
    /*
     * Priority 2: The child_reaper for this PID namespace
     * In the root namespace, this is init (PID 1)
     * In a container, this is the container's init
     */
    return father->nsproxy->pid_ns_for_children->child_reaper;
}
 
void forget_original_parent(struct task_struct *father, 
                           struct task_struct *reaper)
{
    struct task_struct *child;
    
    /* Iterate through all children */
    list_for_each_entry(child, &father->children, sibling) {
        /* Change the parent pointers */
        child->real_parent = reaper;
        child->parent = reaper;
        
        /* Move to new parent's child list */
        list_move_tail(&child->sibling, &reaper->children);
        
        /* If child is already dead (zombie), notify new parent */
        if (child->exit_state == EXIT_ZOMBIE)
            send_sigchld_to_reaper(reaper, child);
    }
}

Key Points About the Kernel Implementation:

Atomic Operation: The reparenting happens atomically as part of the parent's exit sequence. There's no window where a child has an invalid parent.
Thread Group Preference: If the dying process is part of a multi-threaded group, siblings take priority as the new parent. This preserves locality and is important for threaded applications.
Namespace Awareness: Each PID namespace has its own child_reaper. This is crucial for containers—orphans stay within their namespace.
Zombie Notification: If adopted children are already zombies, SIGCHLD is immediately sent to init so it can reap them.

How init Handles Adopted Children

For adoption to work correctly, init must actively participate. It's not enough to just receive orphans—init must reap them when they terminate. This is one of the core responsibilities of any init implementation.

minimal_init.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/**
 * A minimal init that demonstrates the core requirements
 * Real inits (systemd, SysV init, runit) are far more complex
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <sys/wait.h>
#include <errno.h>
 
/* Flag set by SIGCHLD handler */
volatile sig_atomic_t child_died = 0;
 
/* SIGCHLD handler - just set flag, reap in main loop */
void sigchld_handler(int sig) {
    child_died = 1;
}
 
/* Reap all terminated children */
void reap_children(void) {
    pid_t pid;
    int status;
    
    /*
     * Use WNOHANG to avoid blocking - there may be multiple
     * children to reap, and we reap them all in one pass
     */
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        /* Log the reaped process */
        if (WIFEXITED(status)) {
            fprintf(stderr, "[init] Reaped PID %d, exit code %d\n",
                    pid, WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            fprintf(stderr, "[init] Reaped PID %d, killed by signal %d\n",
                    pid, WTERMSIG(status));
        }
    }
}
 
int main(void) {
    struct sigaction sa;
    
    /* Verify we are PID 1 */
    if (getpid() != 1) {
        fprintf(stderr, "This program must run as init (PID 1)\n");
        return 1;
    }
    
    /* Set up SIGCHLD handler */
    sa.sa_handler = sigchld_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_NOCLDSTOP;  /* Don't notify for stopped children */
    sigaction(SIGCHLD, &sa, NULL);
    
    /* Start system services (simplified) */
    if (fork() == 0) {
        execl("/sbin/getty", "getty", "tty1", "38400", NULL);
        _exit(127);
    }
    
    fprintf(stderr, "[init] System started, waiting for children\n");
    
    /* Main loop - init runs forever */
    while (1) {
        /* Wait for signals */
        pause();
        
        /* Reap any dead children (natural or adopted) */
        if (child_died) {
            child_died = 0;
            reap_children();
        }
    }
    
    /* Never reached - init never exits */
    return 0;
}

The Reaping Loop

Notice the while loop with waitpid() and WNOHANG. This pattern is essential because: (1) Multiple children may die between SIGCHLD signals (signals aren't queued per-child), (2) WNOHANG prevents blocking if no more children are ready, and (3) Checking in a loop ensures no zombies are left behind.

Why Must init Reap Continuously?

Unlike regular parents who wait() for specific children they spawned, init must reap any child that terminates. This includes:

Natural children: Services init spawns directly
Adopted children: Orphaned processes whose original parents died
Unknown children: Processes init didn't spawn but inherited through deep adoption chains

Init has no idea who most of its adopted children are—it didn't create them. It simply receives SIGCHLD and calls wait() to collect exit statuses. This "blind reaping" is fundamental to the design.

systemd's Enhanced Orphan Handling

systemd, the modern init system used by most Linux distributions, enhances the traditional adoption model with additional features for tracking and managing processes.

Traditional init vs systemd Orphan Handling
Feature	Traditional init	systemd
Basic reaping	✓ Reaps all zombies	✓ Reaps all zombies
Logging	Minimal or none	Full journal logging with process details
Tracking	No process tracking	cgroups track all descendants
Resource limits	None	Per-service resource limits apply
Orphan attribution	Unknown origin	Associated with original service unit
Restart handling	Manual intervention	Automatic service restart if configured
Subreaper delegation	Not available	Supports PR_SET_CHILD_SUBREAPER

cgroup-Based Tracking:

systemd uses control groups (cgroups) to track all processes belonging to a service, regardless of how many times they fork. This means when a service's main process dies, systemd knows about all the orphans it created:

systemd_orphan_tracking.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# View processes in a service's cgroup
$ systemctl status myservice
● myservice.service - My Service
   Loaded: loaded (/etc/systemd/system/myservice.service; enabled)
   Active: active (running) since ...
   CGroup: /system.slice/myservice.service
           ├─12345 /usr/bin/myservice --daemon
           ├─12346 worker-process-1
           ├─12347 worker-process-2
           └─12348 adopted-orphan  # <-- Visible even if orphaned!
 
# When service stops, all processes in cgroup are visible
$ systemctl stop myservice
# systemd can terminate all descendants, including orphans
 
# View cgroup contents directly
$ cat /sys/fs/cgroup/system.slice/myservice.service/cgroup.procs
12345
12346
12347
12348
 
# systemd journal captures orphan reaping
$ journalctl -u myservice
systemd[1]: myservice.service: Orphan process 12348 reaped (exit: 0)

The Reaper Problem in Traditional init

Traditional init has no way to know which service an orphan came from. If nginx spawns a worker that gets orphaned, init just sees 'some process died'. systemd, through cgroups, knows 'nginx.service spawned this process, it should be counted against nginx's resource limits and killed when nginx stops'.

Subreaper: Delegated Orphan Adoption

Linux 3.4 introduced the PR_SET_CHILD_SUBREAPER flag, which allows processes other than init to adopt orphans. This powerful feature enables intermediate process managers to handle their descendants' orphans without burdening init.

subreaper_example.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
/**
 * Demonstrates the subreaper capability
 * A subreaper becomes the parent of orphans in its subtree
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/prctl.h>
#include <sys/wait.h>
 
void reap_orphans(void) {
    pid_t pid;
    int status;
    
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        printf("[Subreaper] Reaped orphan PID %d\n", pid);
    }
}
 
int main(void) {
    pid_t child, grandchild;
    
    /*
     * Mark ourselves as a subreaper
     * Orphans in our subtree will be reparented to us, not init
     */
    if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
        perror("Failed to set subreaper");
        return 1;
    }
    printf("[Subreaper] PID %d marked as subreaper\n", getpid());
    
    /* Create child */
    child = fork();
    if (child == 0) {
        /* Child creates grandchild then exits */
        grandchild = fork();
        if (grandchild == 0) {
            /* Grandchild: will become orphan when parent exits */
            printf("[Grandchild] PID %d, PPID %d\n", 
                   getpid(), getppid());
            sleep(2);  /* Wait for parent to die */
            printf("[Grandchild] After parent death, PPID = %d\n",
                   getppid());  /* Should be subreaper, not init! */
            exit(0);
        }
        
        /* Parent exits, orphaning grandchild */
        printf("[Child] PID %d exiting, orphaning %d\n", 
               getpid(), grandchild);
        exit(0);
    }
    
    /* Subreaper loop: reap both child and grandchild */
    for (int i = 0; i < 5; i++) {
        sleep(1);
        reap_orphans();
    }
    
    printf("[Subreaper] Done\n");
    return 0;
}

Expected Output:

[Subreaper] PID 1000 marked as subreaper
[Child] PID 1001 exiting, orphaning 1002
[Grandchild] PID 1002, PPID 1001
[Subreaper] Reaped orphan PID 1001
[Grandchild] After parent death, PPID = 1000  <- Adopted by subreaper, not init!
[Subreaper] Reaped orphan PID 1002
[Subreaper] Done

Notice that the grandchild's PPID becomes 1000 (the subreaper), not 1 (init).

Subreaper Use Cases

•Process Managers — Tools like supervisord, runit's runsv, or custom job controllers use subreaper to adopt orphans from their supervised processes.
•Container Runtimes — Docker, containerd, and other container runtimes use subreaper to ensure orphans stay within the container's process hierarchy.
•Session Managers — systemd --user uses subreaper to manage user session processes.
•Test Harnesses — Testing frameworks use subreaper to ensure all spawned processes are cleaned up after tests.
•CI/CD Runners — Jenkins, GitLab Runner, and similar tools prevent orphan escape from build jobs.

Containers: Namespace-Private init

Linux containers use PID namespaces to create isolated process trees. Each container has its own PID 1, which handles orphan adoption within that container. This is fundamental to container isolation.

Converting Mermaid diagram...

Key Points About Container PID 1:

Local Orphan Adoption: Orphans in Container A are adopted by Container A's PID 1, not the host's init. They cannot "escape" to the host.
Same Responsibilities: The container's PID 1 must reap zombies just like the host init. If it doesn't, zombies accumulate inside the container.
Signal Handling: Container PID 1 has the same signal protections—SIGKILL won't work unless the process handles it.
The "Not a Real Init" Problem: Many containers run application processes as PID 1, which weren't designed for init responsibilities.

The Container Zombie Problem

When an application that doesn't reap children runs as container PID 1, zombies accumulate. The application never calls wait(), so adopted orphans become zombies forever. Solutions include: (1) Use a proper init like tini or dumb-init, (2) Use Docker's --init flag, (3) Ensure application handles SIGCHLD properly.

container_init.dockerfile
Dockerfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# Problem: Application as PID 1 without zombie reaping
FROM ubuntu:22.04
CMD ["/usr/bin/myapp"]
# myapp doesn't reap children -> zombies accumulate
 
# Solution 1: Use tini as init
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y tini
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["/usr/bin/myapp"]
# tini reaps zombies, signals propagate correctly
 
# Solution 2: Use Docker's built-in init
# docker run --init myimage
# Injects tini automatically
 
# Solution 3: Use dumb-init
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y dumb-init
ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["/usr/bin/myapp"]
 
# Solution 4: s6-overlay for complex init needs
FROM ubuntu:22.04
ADD https://github.com/just-containers/s6-overlay/.../s6-overlay.tar.gz /tmp/
RUN tar xzf /tmp/s6-overlay.tar.gz -C /
ENTRYPOINT ["/init"]
CMD ["/usr/bin/myapp"]

Design Philosophy: Why This Approach?

The init adoption mechanism reflects deep Unix design philosophy. Understanding the "why" helps appreciate the elegance of this solution.

Design Principles Behind Adoption

•No Process Without Parent: Unix requires every process to have a parent. This invariant simplifies the process model—you can always traverse up to find an ancestor.
•Single Point of Responsibility: Having one process (init) responsible for orphans means no coordination is needed. Any orphan, anywhere, has a defined handler.
•Simplicity Over Complexity: Rather than complex orphan tracking, the kernel simply reassigns the parent pointer. The logic is trivial and foolproof.
•Fail-Safe Resource Cleanup: Even if every other process misbehaves, init will reap zombies. The system eventually reaches a consistent state.
•Process Hierarchy Preservation: Orphans get a new parent but keep their identity, resources, and execution context. The adoption is minimally invasive.
•Layered Responsibility: The kernel handles detection and reparenting; init handles reaping. Each layer has a clear, limited responsibility.

The Elegance of Simplicity

The adoption mechanism is elegant precisely because it's simple. No registration, no complex state machines, no distributed coordination. Just: 'parent dies → children point to init → init reaps when they die.' This simplicity has allowed the same mechanism to work correctly for 50+ years across countless Unix variants.

Alternative Designs Considered (and rejected):

Alternative	Why Rejected
Kill orphans immediately	Too aggressive; legitimate daemons would be killed
Leave orphan parentless	Breaks process model; prevents zombie cleanup
Complex orphan registry	Over-engineering; single point of failure
Let orphans appoint own parent	Security nightmare; could manipulate parent
Cascade to grandparent	May also be dead; complex chain resolution

The init adoption model is the simplest solution that works reliably in all cases.

Verifying Adoption in Practice

Let's see the adoption mechanism in action with practical demonstrations you can run on any Linux system.

verify_adoption.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
/**
 * Complete demonstration of orphan adoption
 * Compile: gcc -o verify_adoption verify_adoption.c
 * Run: ./verify_adoption
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
 
int main(void) {
    pid_t child_pid, grandchild_pid;
    
    printf("=== Orphan Adoption Demonstration ===\n\n");
    printf("Main Process: PID=%d, PPID=%d\n", getpid(), getppid());
    
    child_pid = fork();
    
    if (child_pid == 0) {
        /* Child process */
        printf("\nChild: PID=%d, PPID=%d\n", getpid(), getppid());
        
        grandchild_pid = fork();
        
        if (grandchild_pid == 0) {
            /* Grandchild process */
            printf("\nGrandchild: PID=%d, PPID=%d (original parent)\n",
                   getpid(), getppid());
            
            printf("Grandchild: Waiting 3 seconds for parent to exit...\n");
            sleep(3);
            
            printf("\nGrandchild: After parent exit:\n");
            printf("  PID=%d, PPID=%d (adopted by init/subreaper)\n",
                   getpid(), getppid());
            
            /* Read /proc to show more details */
            char path[64];
            snprintf(path, sizeof(path), "/proc/%d/stat", getpid());
            FILE *f = fopen(path, "r");
            if (f) {
                int pid, ppid;
                char comm[256], state;
                fscanf(f, "%d %s %c %d", &pid, comm, &state, &ppid);
                printf("  From /proc: PID=%d, PPID=%d\n", pid, ppid);
                fclose(f);
            }
            
            printf("\nGrandchild: Exiting (init will reap me)\n");
            exit(0);
        } else {
            /* Child exits immediately, orphaning grandchild */
            printf("Child: Grandchild PID=%d created\n", grandchild_pid);
            printf("Child: Exiting NOW (orphaning grandchild)...\n");
            exit(0);
        }
    } else {
        /* Main process */
        printf("Main: Child PID=%d created\n", child_pid);
        
        /* Wait for child (not grandchild) */
        waitpid(child_pid, NULL, 0);
        printf("\nMain: Child has exited\n");
        
        /* Give grandchild time to report */
        sleep(5);
        printf("\nMain: Demonstration complete\n");
    }
    
    return 0;
}

Verifying with Shell Commands:

# Watch adoption in real-time
# Terminal 1: 
$ ./verify_adoption &

# Terminal 2: 
$ watch -n 1 'ps -eo pid,ppid,stat,cmd | grep -E "^\s*(PID|verify|sleep)"'

# You'll see the grandchild's PPID change from child's PID to 1

# Check if a specific process was adopted
$ ps -o pid,ppid,cmd -p <PID>
  PID  PPID CMD
12345     1 /usr/bin/orphaned_process  # PPID=1 confirms adoption

# View adoption in the process tree
$ pstree -psa $$

Summary: The Adoption Mechanism

Key Takeaways

•PID 1 is Special — Init has unique properties: first process, cannot be killed easily, adopts all orphans, reaps all zombies.
•Adoption is Automatic — The kernel reparents orphans during the parent's exit processing. No userspace action required.
•Init Must Reap — Any process running as PID 1 must call wait() to reap adopted children, or zombies accumulate.
•Subreaper Enables Delegation — PR_SET_CHILD_SUBREAPER allows process managers to adopt orphans within their subtree.
•Containers Have Local init — Each PID namespace has its own child_reaper that handles orphans within that namespace.
•Design is Elegant — The mechanism is simple, reliable, and has worked unchanged for decades.

What's Next:

Now that we understand orphan processes and their adoption, we turn to the other side of the coin: zombie processes. While orphans are running processes that lost their parent, zombies are terminated processes whose parent hasn't collected their exit status. Understanding zombies completes the picture of process lifecycle anomalies.

Page Complete

You now understand how the Unix adoption mechanism ensures every process has a parent and prevents orphans from becoming unmanageable. The key insight: init serves as the universal safety net, and modern systems (systemd, containers) build upon this foundation with enhanced tracking and delegation capabilities.

Adoption by init: The Universal Foster Parent

The Orphanage at PID 1

What You Will Learn

The Special Role of PID 1

PID 1 occupies a unique and privileged position in Unix/Linux systems. It's not just the first process; it has special properties that no other process possesses.

Unique Properties of PID 1 (init)

•First Process — Started directly by the kernel during boot. It is the ancestor of all user-space processes.
•Cannot Be Killed Normally — Signals are handled specially. SIGKILL and SIGSTOP are ignored unless init explicitly sets up handlers for them. This prevents accidental system death.
•Orphan Adopter — Automatically becomes the parent of all orphaned processes. This is hardcoded in the kernel.
•Zombie Reaper — Responsible for calling wait() on adopted children to prevent zombie accumulation.
•System Death on Exit — If PID 1 terminates, the kernel panics. There's no recovery—the system halts.
•Signal Handler of Last Resort — Must handle SIGCHLD to reap adopted children's exit statuses.

The Special Signal Handling

Converting Mermaid diagram...

Historical Context: The Name "init"

The name "init" comes from "initialization" — it's the process responsible for initializing the system. In traditional Unix:

The kernel boots and mounts the root filesystem
The kernel executes /sbin/init (or similar path)
init reads configuration (historically /etc/inittab)
init spawns getty processes for terminals
init spawns system services
init waits for SIGCHLD to reap adopted children

This pattern has persisted for decades, though modern implementations like systemd have expanded init's capabilities significantly.

The Adoption Mechanism

When a process exits, the kernel must ensure its children have a valid parent. The adoption mechanism is implemented directly in the kernel's process exit path.

Converting Mermaid diagram...

kernel_reparenting.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
/**
 * Kernel orphan reparenting logic (simplified from kernel/exit.c)
 * This runs in the context of the dying parent process
 */
 
void exit_notify(struct task_struct *tsk, int group_dead)
{
    struct task_struct *reaper;
    
    /* Find the reaper for this dying process's children */
    reaper = find_child_reaper(tsk);
    
    /* If we have children, they need new parents */
    if (!list_empty(&tsk->children)) {
        forget_original_parent(tsk, reaper);
    }
    
    /* ... continue with exit processing ... */
}
 
struct task_struct *find_child_reaper(struct task_struct *father)
{
    struct task_struct *reaper;
    
    /*
     * Priority 1: Another live thread in the same thread group
     * This keeps children "in the family" if possible
     */
    reaper = find_alive_thread(father);
    if (reaper != father)
        return reaper;
    
    /*
     * Priority 2: The child_reaper for this PID namespace
     * In the root namespace, this is init (PID 1)
     * In a container, this is the container's init
     */
    return father->nsproxy->pid_ns_for_children->child_reaper;
}
 
void forget_original_parent(struct task_struct *father, 
                           struct task_struct *reaper)
{
    struct task_struct *child;
    
    /* Iterate through all children */
    list_for_each_entry(child, &father->children, sibling) {
        /* Change the parent pointers */
        child->real_parent = reaper;
        child->parent = reaper;
        
        /* Move to new parent's child list */
        list_move_tail(&child->sibling, &reaper->children);
        
        /* If child is already dead (zombie), notify new parent */
        if (child->exit_state == EXIT_ZOMBIE)
            send_sigchld_to_reaper(reaper, child);
    }
}

Key Points About the Kernel Implementation:

Atomic Operation: The reparenting happens atomically as part of the parent's exit sequence. There's no window where a child has an invalid parent.
Thread Group Preference: If the dying process is part of a multi-threaded group, siblings take priority as the new parent. This preserves locality and is important for threaded applications.
Namespace Awareness: Each PID namespace has its own child_reaper. This is crucial for containers—orphans stay within their namespace.
Zombie Notification: If adopted children are already zombies, SIGCHLD is immediately sent to init so it can reap them.

How init Handles Adopted Children

minimal_init.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/**
 * A minimal init that demonstrates the core requirements
 * Real inits (systemd, SysV init, runit) are far more complex
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <sys/wait.h>
#include <errno.h>
 
/* Flag set by SIGCHLD handler */
volatile sig_atomic_t child_died = 0;
 
/* SIGCHLD handler - just set flag, reap in main loop */
void sigchld_handler(int sig) {
    child_died = 1;
}
 
/* Reap all terminated children */
void reap_children(void) {
    pid_t pid;
    int status;
    
    /*
     * Use WNOHANG to avoid blocking - there may be multiple
     * children to reap, and we reap them all in one pass
     */
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        /* Log the reaped process */
        if (WIFEXITED(status)) {
            fprintf(stderr, "[init] Reaped PID %d, exit code %d\n",
                    pid, WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            fprintf(stderr, "[init] Reaped PID %d, killed by signal %d\n",
                    pid, WTERMSIG(status));
        }
    }
}
 
int main(void) {
    struct sigaction sa;
    
    /* Verify we are PID 1 */
    if (getpid() != 1) {
        fprintf(stderr, "This program must run as init (PID 1)\n");
        return 1;
    }
    
    /* Set up SIGCHLD handler */
    sa.sa_handler = sigchld_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_NOCLDSTOP;  /* Don't notify for stopped children */
    sigaction(SIGCHLD, &sa, NULL);
    
    /* Start system services (simplified) */
    if (fork() == 0) {
        execl("/sbin/getty", "getty", "tty1", "38400", NULL);
        _exit(127);
    }
    
    fprintf(stderr, "[init] System started, waiting for children\n");
    
    /* Main loop - init runs forever */
    while (1) {
        /* Wait for signals */
        pause();
        
        /* Reap any dead children (natural or adopted) */
        if (child_died) {
            child_died = 0;
            reap_children();
        }
    }
    
    /* Never reached - init never exits */
    return 0;
}

The Reaping Loop

Why Must init Reap Continuously?

Unlike regular parents who wait() for specific children they spawned, init must reap any child that terminates. This includes:

Natural children: Services init spawns directly
Adopted children: Orphaned processes whose original parents died
Unknown children: Processes init didn't spawn but inherited through deep adoption chains

Init has no idea who most of its adopted children are—it didn't create them. It simply receives SIGCHLD and calls wait() to collect exit statuses. This "blind reaping" is fundamental to the design.

systemd's Enhanced Orphan Handling

systemd, the modern init system used by most Linux distributions, enhances the traditional adoption model with additional features for tracking and managing processes.

Traditional init vs systemd Orphan Handling
Feature	Traditional init	systemd
Basic reaping	✓ Reaps all zombies	✓ Reaps all zombies
Logging	Minimal or none	Full journal logging with process details
Tracking	No process tracking	cgroups track all descendants
Resource limits	None	Per-service resource limits apply
Orphan attribution	Unknown origin	Associated with original service unit
Restart handling	Manual intervention	Automatic service restart if configured
Subreaper delegation	Not available	Supports PR_SET_CHILD_SUBREAPER

cgroup-Based Tracking:

systemd_orphan_tracking.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# View processes in a service's cgroup
$ systemctl status myservice
● myservice.service - My Service
   Loaded: loaded (/etc/systemd/system/myservice.service; enabled)
   Active: active (running) since ...
   CGroup: /system.slice/myservice.service
           ├─12345 /usr/bin/myservice --daemon
           ├─12346 worker-process-1
           ├─12347 worker-process-2
           └─12348 adopted-orphan  # <-- Visible even if orphaned!
 
# When service stops, all processes in cgroup are visible
$ systemctl stop myservice
# systemd can terminate all descendants, including orphans
 
# View cgroup contents directly
$ cat /sys/fs/cgroup/system.slice/myservice.service/cgroup.procs
12345
12346
12347
12348
 
# systemd journal captures orphan reaping
$ journalctl -u myservice
systemd[1]: myservice.service: Orphan process 12348 reaped (exit: 0)

The Reaper Problem in Traditional init

Subreaper: Delegated Orphan Adoption

subreaper_example.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
/**
 * Demonstrates the subreaper capability
 * A subreaper becomes the parent of orphans in its subtree
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/prctl.h>
#include <sys/wait.h>
 
void reap_orphans(void) {
    pid_t pid;
    int status;
    
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        printf("[Subreaper] Reaped orphan PID %d\n", pid);
    }
}
 
int main(void) {
    pid_t child, grandchild;
    
    /*
     * Mark ourselves as a subreaper
     * Orphans in our subtree will be reparented to us, not init
     */
    if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
        perror("Failed to set subreaper");
        return 1;
    }
    printf("[Subreaper] PID %d marked as subreaper\n", getpid());
    
    /* Create child */
    child = fork();
    if (child == 0) {
        /* Child creates grandchild then exits */
        grandchild = fork();
        if (grandchild == 0) {
            /* Grandchild: will become orphan when parent exits */
            printf("[Grandchild] PID %d, PPID %d\n", 
                   getpid(), getppid());
            sleep(2);  /* Wait for parent to die */
            printf("[Grandchild] After parent death, PPID = %d\n",
                   getppid());  /* Should be subreaper, not init! */
            exit(0);
        }
        
        /* Parent exits, orphaning grandchild */
        printf("[Child] PID %d exiting, orphaning %d\n", 
               getpid(), grandchild);
        exit(0);
    }
    
    /* Subreaper loop: reap both child and grandchild */
    for (int i = 0; i < 5; i++) {
        sleep(1);
        reap_orphans();
    }
    
    printf("[Subreaper] Done\n");
    return 0;
}

Expected Output:

[Subreaper] PID 1000 marked as subreaper
[Child] PID 1001 exiting, orphaning 1002
[Grandchild] PID 1002, PPID 1001
[Subreaper] Reaped orphan PID 1001
[Grandchild] After parent death, PPID = 1000  <- Adopted by subreaper, not init!
[Subreaper] Reaped orphan PID 1002
[Subreaper] Done

Notice that the grandchild's PPID becomes 1000 (the subreaper), not 1 (init).

Subreaper Use Cases

•Process Managers — Tools like supervisord, runit's runsv, or custom job controllers use subreaper to adopt orphans from their supervised processes.
•Container Runtimes — Docker, containerd, and other container runtimes use subreaper to ensure orphans stay within the container's process hierarchy.
•Session Managers — systemd --user uses subreaper to manage user session processes.
•Test Harnesses — Testing frameworks use subreaper to ensure all spawned processes are cleaned up after tests.
•CI/CD Runners — Jenkins, GitLab Runner, and similar tools prevent orphan escape from build jobs.

Containers: Namespace-Private init

Converting Mermaid diagram...

Key Points About Container PID 1:

Local Orphan Adoption: Orphans in Container A are adopted by Container A's PID 1, not the host's init. They cannot "escape" to the host.
Same Responsibilities: The container's PID 1 must reap zombies just like the host init. If it doesn't, zombies accumulate inside the container.
Signal Handling: Container PID 1 has the same signal protections—SIGKILL won't work unless the process handles it.
The "Not a Real Init" Problem: Many containers run application processes as PID 1, which weren't designed for init responsibilities.

The Container Zombie Problem

container_init.dockerfile
Dockerfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# Problem: Application as PID 1 without zombie reaping
FROM ubuntu:22.04
CMD ["/usr/bin/myapp"]
# myapp doesn't reap children -> zombies accumulate
 
# Solution 1: Use tini as init
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y tini
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["/usr/bin/myapp"]
# tini reaps zombies, signals propagate correctly
 
# Solution 2: Use Docker's built-in init
# docker run --init myimage
# Injects tini automatically
 
# Solution 3: Use dumb-init
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y dumb-init
ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["/usr/bin/myapp"]
 
# Solution 4: s6-overlay for complex init needs
FROM ubuntu:22.04
ADD https://github.com/just-containers/s6-overlay/.../s6-overlay.tar.gz /tmp/
RUN tar xzf /tmp/s6-overlay.tar.gz -C /
ENTRYPOINT ["/init"]
CMD ["/usr/bin/myapp"]

Design Philosophy: Why This Approach?

The init adoption mechanism reflects deep Unix design philosophy. Understanding the "why" helps appreciate the elegance of this solution.

Design Principles Behind Adoption

•No Process Without Parent: Unix requires every process to have a parent. This invariant simplifies the process model—you can always traverse up to find an ancestor.
•Single Point of Responsibility: Having one process (init) responsible for orphans means no coordination is needed. Any orphan, anywhere, has a defined handler.
•Simplicity Over Complexity: Rather than complex orphan tracking, the kernel simply reassigns the parent pointer. The logic is trivial and foolproof.
•Fail-Safe Resource Cleanup: Even if every other process misbehaves, init will reap zombies. The system eventually reaches a consistent state.
•Process Hierarchy Preservation: Orphans get a new parent but keep their identity, resources, and execution context. The adoption is minimally invasive.
•Layered Responsibility: The kernel handles detection and reparenting; init handles reaping. Each layer has a clear, limited responsibility.

The Elegance of Simplicity

Alternative Designs Considered (and rejected):

Alternative	Why Rejected
Kill orphans immediately	Too aggressive; legitimate daemons would be killed
Leave orphan parentless	Breaks process model; prevents zombie cleanup
Complex orphan registry	Over-engineering; single point of failure
Let orphans appoint own parent	Security nightmare; could manipulate parent
Cascade to grandparent	May also be dead; complex chain resolution

The init adoption model is the simplest solution that works reliably in all cases.

Verifying Adoption in Practice

Let's see the adoption mechanism in action with practical demonstrations you can run on any Linux system.

verify_adoption.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
/**
 * Complete demonstration of orphan adoption
 * Compile: gcc -o verify_adoption verify_adoption.c
 * Run: ./verify_adoption
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
 
int main(void) {
    pid_t child_pid, grandchild_pid;
    
    printf("=== Orphan Adoption Demonstration ===\n\n");
    printf("Main Process: PID=%d, PPID=%d\n", getpid(), getppid());
    
    child_pid = fork();
    
    if (child_pid == 0) {
        /* Child process */
        printf("\nChild: PID=%d, PPID=%d\n", getpid(), getppid());
        
        grandchild_pid = fork();
        
        if (grandchild_pid == 0) {
            /* Grandchild process */
            printf("\nGrandchild: PID=%d, PPID=%d (original parent)\n",
                   getpid(), getppid());
            
            printf("Grandchild: Waiting 3 seconds for parent to exit...\n");
            sleep(3);
            
            printf("\nGrandchild: After parent exit:\n");
            printf("  PID=%d, PPID=%d (adopted by init/subreaper)\n",
                   getpid(), getppid());
            
            /* Read /proc to show more details */
            char path[64];
            snprintf(path, sizeof(path), "/proc/%d/stat", getpid());
            FILE *f = fopen(path, "r");
            if (f) {
                int pid, ppid;
                char comm[256], state;
                fscanf(f, "%d %s %c %d", &pid, comm, &state, &ppid);
                printf("  From /proc: PID=%d, PPID=%d\n", pid, ppid);
                fclose(f);
            }
            
            printf("\nGrandchild: Exiting (init will reap me)\n");
            exit(0);
        } else {
            /* Child exits immediately, orphaning grandchild */
            printf("Child: Grandchild PID=%d created\n", grandchild_pid);
            printf("Child: Exiting NOW (orphaning grandchild)...\n");
            exit(0);
        }
    } else {
        /* Main process */
        printf("Main: Child PID=%d created\n", child_pid);
        
        /* Wait for child (not grandchild) */
        waitpid(child_pid, NULL, 0);
        printf("\nMain: Child has exited\n");
        
        /* Give grandchild time to report */
        sleep(5);
        printf("\nMain: Demonstration complete\n");
    }
    
    return 0;
}

Verifying with Shell Commands:

# Watch adoption in real-time
# Terminal 1: 
$ ./verify_adoption &

# Terminal 2: 
$ watch -n 1 'ps -eo pid,ppid,stat,cmd | grep -E "^\s*(PID|verify|sleep)"'

# You'll see the grandchild's PPID change from child's PID to 1

# Check if a specific process was adopted
$ ps -o pid,ppid,cmd -p <PID>
  PID  PPID CMD
12345     1 /usr/bin/orphaned_process  # PPID=1 confirms adoption

# View adoption in the process tree
$ pstree -psa $$

Summary: The Adoption Mechanism

Key Takeaways

•PID 1 is Special — Init has unique properties: first process, cannot be killed easily, adopts all orphans, reaps all zombies.
•Adoption is Automatic — The kernel reparents orphans during the parent's exit processing. No userspace action required.
•Init Must Reap — Any process running as PID 1 must call wait() to reap adopted children, or zombies accumulate.
•Subreaper Enables Delegation — PR_SET_CHILD_SUBREAPER allows process managers to adopt orphans within their subtree.
•Containers Have Local init — Each PID namespace has its own child_reaper that handles orphans within that namespace.
•Design is Elegant — The mechanism is simple, reliable, and has worked unchanged for decades.

What's Next:

Page Complete