Process Creation

In operating systems, processes are not created in isolation—they emerge from existing processes through a carefully orchestrated mechanism that establishes a parent-child relationship. This hierarchical model is not merely an organizational convenience; it is a fundamental architectural decision that shapes resource management, privilege inheritance, termination semantics, and the very identity of every running program on a system.

When you launch a web browser, execute a terminal command, or start a background service, you are witnessing the instantiation of this relationship. The shell that interprets your command becomes the parent, and the newly created browser or program becomes its child. This relationship carries profound implications for how processes share resources, communicate, and ultimately cease to exist.

The parent-child paradigm for process creation arose from a fundamental insight in operating system design: creation implies responsibility. When a process creates another process, the creator naturally assumes oversight responsibilities—managing the child's lifecycle, collecting its termination status, and ensuring proper cleanup when the child concludes execution.

Why Not Create Processes Independently?

One might question why processes need parents at all. Couldn't an operating system simply create processes as independent entities? Theoretically, yes—but this approach creates significant practical problems:

1. Resource Accounting: Without a parent, who is responsible for the resources a process consumes? Who reclaims memory if the process crashes?

2. Termination Status: When a process completes, its exit status (success, failure, error code) needs to be delivered somewhere. Without a parent, this information is lost.

3. Privilege Boundaries: A newly created process needs some initial set of permissions. Inheriting from a parent provides a natural, auditable source of these privileges.

4. Process Group Organization: Processes often need to work together. Parent-child relationships provide a natural grouping mechanism.

The Creation Moment

When a parent process creates a child, several critical operations occur atomically from the perspective of the participating processes:

What the Parent Does:

• Requests process creation from the operating system kernel
• Provides initial parameters (program to execute, arguments, environment)
• Receives a Process ID (PID) representing the new child
• May optionally wait for the child's completion

What the Kernel Does:

• Allocates a new Process Control Block (PCB)
• Assigns a unique PID
• Establishes the parent-child link in process tables
• Initializes the child's execution context (address space, registers, file descriptors)
• Schedules the child for execution

What the Child Receives:

• A copy of (or shared access to) the parent's execution context
• The parent's PID stored as its Parent PID (PPID)
• Inherited file descriptors, environment variables, and permissions
• Its own unique PID

The output demonstrates the core relationship:

Before fork(): Process 1234
Parent Process:
  My PID: 1234
  My Child's PID: 1235
  fork() returned to me: 1235
Child Process:
  My PID: 1235
  My Parent's PID (PPID): 1234
  fork() returned to me: 0

Notice how both processes execute the same code after fork(), but the return value differentiates them. The parent receives the child's PID, enabling it to track and manage the child. The child receives 0, indicating it is the newly created process.

Every process in a running system possesses two essential identifiers that define its existence within the process hierarchy:

Process ID (PID)

The Process ID (PID) is a non-negative integer that uniquely identifies a process within the operating system. PIDs are assigned by the kernel at process creation time and are guaranteed to be unique among all currently running processes.

Critical Properties of PIDs:

Parent Process ID (PPID)

The Parent Process ID (PPID) is the PID of the process that created the current process. This single link creates the chain that forms the entire process hierarchy.

Semantics of PPID:

1. Set at Creation: PPID is established when a process is created via fork() or equivalent

2. Immutable Under Normal Circumstances: A process's parent remains constant throughout its lifetime—with one critical exception

3. Orphan Reparenting: If a parent terminates before its child, the child becomes an orphan, and its PPID changes to that of the init process (PID 1) or a designated subreaper

4. Queryable: Any process can retrieve its PPID via getppid() system call

Special Process IDs

Certain PIDs carry special significance in operating systems:

The Init Process (PID 1)

PID 1 occupies a singular position in the operating system hierarchy:

1. First User Process: Created directly by the kernel during boot
2. Universal Ancestor: All user processes ultimately trace their lineage to PID 1
3. Orphan Adoption: When a parent dies, its children are reparented to PID 1
4. System Shutdown Orchestration: PID 1 coordinates graceful shutdown
5. Immortal (Almost): The kernel prevents PID 1 from being killed by normal means; its death triggers kernel panic

When a child process is created, it inherits a rich set of attributes from its parent. Understanding precisely what is inherited, what is copied, and what is reset is essential for writing correct concurrent programs.

Categories of Inheritance

Process attributes at creation time fall into three categories:

1. Inherited (Shared or Copied): Attributes that pass from parent to child
2. Unique to Child: Attributes that are fresh for each new process
3. Reset to Defaults: Attributes that revert to system defaults

Let's examine each attribute category in detail:

Environment Variable Inheritance

Environment variables represent another critical inherited attribute. They form a simple key-value store that configures program behavior:

• PATH: Search path for executables
• HOME: User's home directory
• USER: Current username
• SHELL: Default shell
• LD_LIBRARY_PATH: Dynamic library search path
• Custom Variables: Application-specific configuration

Importantly, the child receives a copy of the environment at fork time. Subsequent modifications by either parent or child do not affect the other.

// Parent sets environment before fork
setenv("MY_CONFIG", "parent_value", 1);

pid_t pid = fork();

if (pid == 0) {
    // Child can read parent's value
    printf("Child sees: %s
", getenv("MY_CONFIG")); // "parent_value"
    
    // Child modifies - parent unaffected
    setenv("MY_CONFIG", "child_modified", 1);
} else {
    sleep(1);
    // Parent still sees original value
    printf("Parent sees: %s
", getenv("MY_CONFIG")); // "parent_value"
}

The parent-child relationship is not merely structural—it carries obligations. A parent process has responsibilities toward its children that, if neglected, lead to system-level problems.

The Wait Obligation

When a child process terminates, it does not simply vanish. Instead, it enters a zombie state, where it remains in the process table with its exit status preserved, waiting for its parent to collect this information.

The Zombie Problem:

1. Child process exits (calls exit() or returns from main())
2. Kernel preserves minimal state: PID, exit status, resource usage statistics
3. Child becomes a zombie (defunct) process
4. Parent must call wait() or waitpid() to collect exit status
5. Only then is the child's process table entry released

If the parent never waits:

• Zombie accumulates in process table
• PID remains allocated (cannot be reused)
• System eventually runs out of available PIDs
• Fork calls fail with EAGAIN

Orphan Adoption

What happens when a parent terminates before its child? The child becomes an orphan, but the operating system does not leave it unmanaged.

The Reparenting Mechanism:

1. Parent process terminates (voluntarily or involuntarily)
2. Kernel identifies all children of the terminated parent
3. Each child's PPID is changed to PID 1 (init/systemd)
4. Init process becomes the adoptive parent
5. Init's job includes periodically calling wait() to reap adopted children

This mechanism ensures that:

• No child process is left without a parent
• Exit statuses of orphaned children are properly collected
• Zombies from orphaned children don't accumulate

Subreaper Processes (Linux 3.4+):

Modern Linux allows any process to mark itself as a "subreaper" using prctl(PR_SET_CHILD_SUBREAPER, 1). When a process's parent terminates, instead of being adopted by init, it's adopted by the nearest subreaper ancestor. This is useful for container init processes and service managers.

The parent-child relationship intersects with two other critical process management mechanisms: signals and process groups. Understanding these interactions is essential for building robust process hierarchies.

Process Groups

A process group is a collection of processes that can receive signals together. By default:

• A newly forked child inherits its parent's process group ID (PGID)
• All processes in a group can be signaled with a single operation
• Process groups enable job control (foreground/background jobs)

Job Control Scenario:

parent_shell (PGID=1000)
  ├── child1 (PGID=1000)  
  ├── child2 (PGID=1000)
  └── child3 (PGID=1000)

When you press Ctrl+C in a terminal, SIGINT is sent to the entire foreground process group—all four processes receive it, not just the shell.

Signal Propagation Rules

Signals interact with parent-child relationships in specific ways:

The SIGCHLD Signal

SIGCHLD is the primary mechanism for asynchronous child management. When a child:

• Terminates (exits)
• Is stopped (via SIGSTOP)
• Is continued (via SIGCONT)

The kernel sends SIGCHLD to the parent. This enables non-blocking child reaping:

While the parent-child paradigm is universal, its implementation varies across operating systems. Understanding these differences is crucial for writing portable code and for appreciating different design philosophies.

Windows Process Creation

Windows takes a fundamentally different approach than Unix. Instead of fork-and-exec, Windows uses CreateProcess(), which creates a new process and loads a new program in one operation.

Real-Time Operating Systems (RTOS)

Real-time operating systems often have simplified process models focused on determinism:

Example: FreeRTOS Task Creation

// FreeRTOS uses tasks, not processes
// No parent-child hierarchy; tasks are peers
xTaskCreate(
    vTaskFunction,     // Task function
    "TaskName",        // Name
    STACK_SIZE,        // Stack size
    NULL,              // Parameters
    PRIORITY,          // Priority
    &taskHandle        // Handle (output)
);

We have explored the foundational concept of parent-child relationships in process creation—a model that underpins virtually all modern operating systems. Let's consolidate the essential knowledge:

What's Next:

The parent-child relationship creates a structure; the next page explores how these structures form complete process trees—the hierarchical arrangement of all processes in a running system. We'll examine how to visualize, traverse, and manage these trees, and understand the implications of tree structure for system administration and process control.