Chapter 56: Creating Processes: The fork() System Call

Chapter Objectives

Upon completing this chapter, you will be able to:

• Understand the concept of a process in the Linux operating system, including its memory layout and key attributes.
• Explain the mechanics of the fork() system call and how it creates a new child process.
• Describe the Copy-on-Write (CoW) optimization and analyze its role in making process creation efficient.
• Implement C programs that use fork() to create and manage child processes on a Raspberry Pi 5.
• Differentiate between the parent and child process execution paths based on the return value of fork().
• Debug common issues related to process creation, such as zombie processes and race conditions.

Introduction

In the world of modern operating systems, the process is the fundamental unit of execution. The ability to create, manage, and terminate processes is what allows a system, from a massive server to a tiny embedded device, to perform multiple tasks concurrently. For an embedded Linux system like the Raspberry Pi 5, effective process management is not just a feature—it is the cornerstone of building responsive, robust, and modular applications. Whether it’s a web server handling multiple client requests, a robotics controller managing separate motor and sensor tasks, or a data logger processing information while maintaining a user interface, the creation of new processes is an essential operation.

This chapter delves into the primary mechanism for process creation in Linux and other UNIX-like systems: the fork() system call. At first glance, its behavior can seem peculiar. It is a function that is called once but returns twice—once in the original (parent) process and once in a newly created (child) process. This elegant, if unusual, design is the foundation for multitasking in Linux. We will explore the intricate details of how fork() works, from duplicating the parent’s address space to the clever optimization known as Copy-on-Write (CoW), which makes this operation remarkably fast. By the end of this chapter, you will not only understand the theory behind fork() but will have used it to write practical C programs on your Raspberry Pi 5, gaining a foundational skill for any advanced embedded Linux developer.

Technical Background

To truly appreciate the fork() system call, one must first have a solid understanding of what a process is from the perspective of the Linux kernel. A process is far more than just a running program; it is an active, isolated environment that encapsulates all the resources needed for execution. The kernel maintains a detailed record for every active process in a C structure known as the Process Control Block (PCB), or task_struct in the Linux source code. This structure is the kernel’s single source of truth for a process, containing vital information such as the process ID (PID), the process state (e.g., running, sleeping, zombie), CPU scheduling information, memory management details, and a list of open file descriptors.

The Process Address Space

A key concept tied to a process is its virtual address space. This is a private, isolated memory map that the kernel provides to each process. From the process’s point of view, it has a large, contiguous block of memory all to itself, starting from address 0. This is, of course, a virtual abstraction; the kernel maps these virtual addresses to physical RAM addresses behind the scenes. This virtualization prevents processes from interfering with each other’s memory, which is a critical security and stability feature.

The virtual address space is typically organized into several distinct segments. The text segment contains the compiled, executable machine code of the program. It is read-only to prevent a process from accidentally or maliciously modifying its own instructions. The data segment stores initialized global and static variables, while the BSS segment (named for an old assembler operator, “Block Started by Symbol”) holds uninitialized global and static variables, which are all set to zero by default. The heap is the region for dynamic memory allocation, managed by functions like malloc() and free(). It grows upwards from the BSS segment. Finally, the stack is used for local variables, function parameters, and return addresses. It grows downwards from the highest memory address.

The fork() System Call: Cloning a Process

With this understanding of a process, we can now explore fork(). The purpose of fork() is to create a new process, and it does so in the most direct way imaginable: it creates a nearly exact clone of the calling process. When a process (the parent) calls fork(), the kernel performs the following actions:

1. It creates a new, unique process ID (PID) for the new process (the child).
2. It allocates a new task_struct (PCB) for the child.
3. It copies most of the values from the parent’s task_struct to the child’s task_struct. This means the child inherits the parent’s user and group IDs, signal handling settings, and current working directory.
4. It duplicates the parent’s virtual address space for the child.
5. It duplicates the parent’s set of open file descriptors.

sequenceDiagram
    participant P as Parent Process (PID: 2345)
    participant K as Linux Kernel
    participant C as Child Process (PID: 2346)

    P->>+K: fork()
    Note over K: 1. Create new task_struct for Child
    Note over K: 2. Copy Parent's context (memory map, FDs)
    Note over K: 3. Assign new PID (2346)
    
    K-->>-P: return 2346 (Child's PID)
    K-->>+C: return 0
    
    Note over P,C: Both processes now execute independently
    
    par
        P->>P: Continue execution...
    and
        C->>C: Start execution from fork() return
    end

The result is two processes that are, at the moment of creation, virtually identical. They are executing the same code at the same instruction, they have identical memory contents, and they have access to the same open files. The most significant difference is the value that fork() returns in each process. In the parent process, fork() returns the PID of the newly created child. In the child process, fork() returns 0. If the fork() call fails (for example, if the system has reached its process limit), it returns -1 in the parent, and no child process is created. This simple return value distinction is the critical mechanism that allows the programmer to introduce different behaviors in the parent and child, enabling them to diverge and perform separate tasks.

The Power of Copy-on-Write (CoW)

One might look at the description above and think that duplicating the entire address space of a process would be incredibly slow and memory-intensive, especially for large applications. If a parent process is using hundreds of megabytes of RAM, does the kernel really copy all of that data just to create a new process? In the early days of UNIX, it did, which made process creation an expensive operation. Modern systems, however, employ a powerful optimization called Copy-on-Write (CoW).

Copy-on-Write is a resource management technique that dramatically improves the efficiency of fork(). Instead of immediately duplicating all the memory pages of the parent process, the kernel performs a clever trick. It lets the parent and child share the same physical memory pages, but it marks them as read-only. Both processes can read from these shared pages without issue. However, the moment either the parent or the child attempts to write to a shared memory page, the CPU triggers a page-fault exception, which transfers control to the kernel.

The kernel recognizes this as a CoW fault. It then transparently allocates a new physical memory page, copies the contents of the original page to the new one, and updates the page table of the writing process to point to this new private copy. The new page is marked as read-write. The original page remains shared with the other process (or becomes a private copy for it as well, if it’s the last one sharing it). The kernel then resumes the process, which completes its write operation, completely unaware of the intricate page shuffling that just occurred.

graph LR



    
    subgraph "Stage 3: After Child Writes"
        direction TB
        Parent3(Parent Process)
        Child3(Child Process)
        PhysMemOrig("Original Memory Page<br><i>(Read-Only)</i>")
        PhysMemNew("<b>New Private Page</b><br><i>(Read-Write)</i>")
        
        Child3 -- "Write attempt triggers fault" --> PhysMemOrig
        subgraph Kernel Action
            direction LR
            A(1- Trap to Kernel) --> B(2- Allocate New Page);
            B --> C(3- Copy Data);
            C --> D(4- Update Child's<br>Page Table);
        end
        D -. "maps to" .-> PhysMemNew
        Parent3 -- "Still points to" --> PhysMemOrig
        Child3 -.->|Now points to| PhysMemNew
    end

    subgraph "Stage 2: Immediately After fork()"
        direction TB
        Parent2(Parent Process)
        Child2(Child Process)
        PhysMemShared("Physical Memory Pages<br><i>(Shared, Read-Only)</i>")
        Parent2 -- "Points to" --> PhysMemShared
        Child2 -- "Points to" --> PhysMemShared
    end

        subgraph "Stage 1: Before fork()"
        direction LR
        Parent1(Parent Process)
        PhysMem1(Physical<br>Memory Pages)
        Parent1 -- "Virtual Address Space<br>maps to" --> PhysMem1
    end



    %% Styling
    classDef default fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#1f2937;
    classDef parentStyle fill:#1e3a8a,stroke:#1e3a8a,stroke-width:2px,color:#ffffff;
    classDef childStyle fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff;
    classDef memStyle fill:#8b5cf6,stroke:#8b5cf6,stroke-width:1px,color:#ffffff;
    classDef actionStyle fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff;

    class Parent1,Parent2,Parent3 parentStyle;
    class Child2,Child3 childStyle;
    class PhysMem1,PhysMemShared,PhysMemOrig,PhysMemNew memStyle;
    class A,B,C,D actionStyle;

This approach is profoundly efficient. In the common scenario where fork() is immediately followed by a call to one of the exec() family of functions (which replaces the current process image with a new program), there is no need to copy the parent’s address space at all. The child process simply discards the shared address space and loads the new program’s code and data. CoW ensures that the overhead of fork() is minimal, paying the price of a memory copy only when it is absolutely necessary.

Inheritance: What the Child Gets

The child process is a clone, but not everything is identical. It’s crucial to understand what is inherited and what is unique.

What is inherited and shared:

• Virtual Address Space (with CoW): As discussed, the memory content is identical at the time of the fork.
• Open File Descriptors: This is a particularly important feature. If the parent has a file open, the child gets a duplicate of the file descriptor. Both descriptors point to the same underlying file table entry in the kernel. This entry contains the current file offset and status flags. This means that if the child reads from the file, it advances the file offset for the parent as well, and vice-versa. This shared offset is a powerful tool for cooperation but can also be a source of confusion if not handled carefully.
• User and Group IDs: The child runs with the same credentials as the parent.
• Environment Variables: The child receives a copy of the parent’s environment.
• Current Working Directory: Both processes start in the same directory.

What is unique to the child:

• Process ID (PID): The child has its own unique PID.
• Parent PID (PPID): The child’s PPID is set to the parent’s PID.
• Resource Utilization: The child’s resource usage counters (e.g., CPU time) are reset to zero.
• Pending Signals: The child does not inherit the parent’s set of pending signals.
• File Locks: Locks set by the parent on files are not inherited by the child.

Understanding these distinctions is key to writing correct, predictable multi-process programs. The fork() system call, combined with the efficiency of Copy-on-Write, provides a simple yet powerful primitive for building complex applications, forming the very backbone of process management in Linux.

Practical Examples

The best way to understand fork() is to see it in action. The following examples are designed to be compiled and run on a Raspberry Pi 5 running Raspberry Pi OS or a similar Debian-based distribution. You will need the gcc compiler, which is typically installed by default.

flowchart TD
    A("Start: Process P1 calls fork()")
    B{"pid = fork()"}
    A --> B
    
    subgraph "In Parent Process (P1)"
        C{"pid > 0 ?"}
        D[Success! pid is the Child's Process ID]
        E["Parent continues its execution path.<br>Often calls wait() to reap the child."]
    end

    subgraph "In Child Process (P2)"
        F{"pid == 0 ?"}
        G[Success! This is the new child process.]
        H["Child is a clone of the parent.<br>Executes its own logic, often an exec() call."]
    end

    subgraph "Error Condition"
        I{"pid < 0 ?"}
        J["<b>fork() Failed!</b><br>No child process was created."]
        K[Handle error: Check errno,<br>log a message, and exit gracefully.]
    end
    
    B -- "Returns Child's PID to Parent" --> C
    B -- "Returns 0 to Child" --> F
    B -- "Returns -1 to Parent on Failure" --> I
    
    C -- "Yes" --> D --> E
    F -- "Yes" --> G --> H
    I -- "Yes" --> J --> K

    %% Styling
    classDef startNode fill:#1e3a8a,stroke:#1e3a8a,stroke-width:2px,color:#ffffff;
    classDef decisionNode fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff;
    classDef processNode fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff;
    classDef successNode fill:#10b981,stroke:#10b981,stroke-width:2px,color:#ffffff;
    classDef errorNode fill:#ef4444,stroke:#ef4444,stroke-width:1px,color:#ffffff;

    class A startNode;
    class B,C,F,I decisionNode;
    class E,H,K processNode;
    class D,G successNode;
    class J errorNode;

Example 1: The Basic fork()

This first example demonstrates the fundamental behavior of fork(). It creates a child process, and both parent and child print their own PID and their parent’s PID (PPID).

Code Snippet

Create a file named basic_fork.c with the following content:

// basic_fork.c
// Demonstrates the fundamental use of the fork() system call.

#include <stdio.h>      // For printf()
#include <unistd.h>     // For fork(), getpid(), getppid()
#include <sys/types.h>  // For pid_t
#include <sys/wait.h>   // For wait()

int main() {
    pid_t pid;

    printf("--- Before fork() ---\n");
    printf("My PID is %d\n\n", getpid());

    // Create a new process
    pid = fork();

    // The return value of fork() determines the execution path.
    if (pid < 0) {
        // Error occurred
        fprintf(stderr, "Fork Failed\n");
        return 1;
    } else if (pid == 0) {
        // This is the child process
        printf("--- Child Process ---\n");
        printf("I am the child!\n");
        printf("My PID is %d, and my parent's PID is %d.\n", getpid(), getppid());
        // The child can do its own work here.
        // For this example, we'll just sleep for a second.
        sleep(1);
        printf("Child process is exiting.\n");
    } else {
        // This is the parent process
        printf("--- Parent Process ---\n");
        printf("I am the parent!\n");
        printf("My PID is %d, and I created a child with PID %d.\n", getpid(), pid);

        // The parent waits for the child to finish.
        // This is crucial to prevent a zombie process.
        printf("Parent is waiting for the child to terminate...\n");
        wait(NULL);
        printf("Child has terminated. Parent is exiting.\n");
    }

    printf("\n--- After fork logic ---\n");
    printf("This line is printed by PID: %d\n", getpid());

    return 0;
}

Build and Execution Steps

1. Open a terminal on your Raspberry Pi 5.
2. Compile the code using gcc:
   gcc -o basic_fork basic_fork.c -Wall
The -o basic_fork flag names the output executable, and -Wall enables all compiler warnings, which is a good practice.
3. Run the executable:
   ./basic_fork

Expected Output and Explanation

The exact PIDs will vary each time you run the program, but the structure of the output will be similar to this:

--- Before fork() ---
My PID is 623558

--- Parent Process ---
I am the parent!
My PID is 623558, and I created a child with PID 623559.
Parent is waiting for the child to terminate...
--- Child Process ---
I am the child!
My PID is 623559, and my parent's PID is 623558.
Child process is exiting.

--- After fork logic ---
This line is printed by PID: 623559
Child has terminated. Parent is exiting.

--- After fork logic ---
This line is printed by PID: 623558

Explanation:

• “Before fork()”: This section is printed once by the original process (PID 2345).
• Divergence: After fork() is called, two processes exist. The kernel’s scheduler decides which one runs first. In this common case, the parent runs first.
• Parent’s Path (pid > 0): The parent receives the child’s PID (2346) from fork(). It prints its message and then calls wait(NULL). The wait() call blocks the parent, pausing its execution until any of its child processes terminate.
• Child’s Path (pid == 0): The child receives 0 from fork(). It prints its messages, including its new PID (2346) and its parent’s PID (2345). After sleeping for a second, it exits.
• Reaping the Child: The child’s termination unblocks the parent’s wait() call. The parent then prints its final message and exits.
• “After fork logic”: Notice this line is printed by both processes. This demonstrates that the child process continues execution from the point where fork() returned, just like the parent.

Example 2: Demonstrating Copy-on-Write (CoW)

This example provides a tangible demonstration of the CoW mechanism. A parent process initializes a variable, forks a child, and then both processes try to modify the variable. We will see that the modification in one process does not affect the other.

Code Snippet

Create a file named cow_demo.c.

// cow_demo.c
// Demonstrates the Copy-on-Write (CoW) mechanism.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main() {
    int data_variable = 100;

    printf("Parent (PID %d): Initial data_variable value: %d\n", getpid(), data_variable);
    printf("Parent (PID %d): Address of data_variable: %p\n\n", getpid(), &data_variable);

    pid_t pid = fork();

    if (pid < 0) {
        fprintf(stderr, "Fork Failed\n");
        return 1;
    } else if (pid == 0) {
        // Child process
        printf("Child  (PID %d): Inherited data_variable value: %d\n", getpid(), data_variable);
        printf("Child  (PID %d): Inherited address of data_variable: %p\n", getpid(), &data_variable);

        // Child modifies the variable. This triggers Copy-on-Write.
        printf("Child  (PID %d): Modifying data_variable to 200.\n", getpid());
        data_variable = 200;

        printf("Child  (PID %d): New data_variable value: %d\n", getpid(), data_variable);
        printf("Child  (PID %d): New address of data_variable: %p\n", getpid(), &data_variable);
        printf("Child exiting.\n");
    } else {
        // Parent process
        // Wait for the child to complete so the output is clean.
        wait(NULL);
        
        printf("\nParent (PID %d): Back in parent process after child finished.\n", getpid());
        printf("Parent (PID %d): data_variable value is UNCHANGED: %d\n", getpid(), data_variable);
        printf("Parent (PID %d): Address of data_variable is UNCHANGED: %p\n", getpid(), &data_variable);
        printf("Parent exiting.\n");
    }

    return 0;
}

Build and Execution Steps

1. Compile the code:gcc -o cow_demo cow_demo.c -Wall
2. Run the executable:./cow_demo

Expected Output and Explanation

Parent (PID 624030): Initial data_variable value: 100
Parent (PID 624030): Address of data_variable: 0x7fffc141bcb8

Child  (PID 624031): Inherited data_variable value: 100
Child  (PID 624031): Inherited address of data_variable: 0x7fffc141bcb8
Child  (PID 624031): Modifying data_variable to 200.
Child  (PID 624031): New data_variable value: 200
Child  (PID 624031): New address of data_variable: 0x7fffc141bcb8
Child exiting.

Parent (PID 624030): Back in parent process after child finished.
Parent (PID 624030): data_variable value is UNCHANGED: 100
Parent (PID 624030): Address of data_variable is UNCHANGED: 0x7fffc141bcb8
Parent exiting.

Explanation:

• Virtual Addresses: The most crucial thing to notice is that the virtual address of data_variable (0x7ffc9a1b2c3c in this example) is the same in both the parent and the child, even after the modification. This is because each process has its own private virtual address space. The addresses are the same, but they map to different physical locations after the write.
• Initial State: Before the modification, both processes see the value 100 at this address. They are sharing the same physical page of RAM.
• The Write: When the child executes data_variable = 200;, the kernel’s CoW mechanism kicks in. It silently creates a new page of physical RAM, copies the original data, and maps the child’s virtual address 0x7ffc9a1b2c3c to this new page. The child’s write operation then modifies this new, private copy.
• Isolation: When the parent process resumes, its data_variable is completely unaffected. Its virtual address still points to the original physical page, which still holds the value 100. This perfectly demonstrates the memory isolation that CoW provides.

Common Mistakes & Troubleshooting

The fork() system call is powerful, but its unique behavior can lead to several common pitfalls. Understanding these issues is key to writing robust multi-process applications.

Exercises

These exercises are designed to reinforce the concepts presented in this chapter. Attempt them on your Raspberry Pi 5.

1. PID and PPID Explorer.
   • Objective: Modify the basic_fork.c program. In the child process, loop five times with a one-second delay (sleep(1)). In each iteration, print the child's PID and its parent's PID. In the parent process, simply print a message and exit immediately without waiting for the child.
   • Verification: Run the program in the background (./your_program &) and then immediately run the ps -f command. Observe the child process's PPID. What happens to the PPID after the parent process terminates? (You should see it get re-parented to PID 1). This demonstrates the concept of orphan processes.
2. Environment Variable Inheritance.
   • Objective: Write a C program that does the following:
     1. In the parent process, use the setenv() function to create a new environment variable (e.g., EMBEDDED_GURU="fork_master") before calling fork().
     2. In the child process, use the getenv() function to retrieve and print the value of this environment variable.
     3. In the parent process, wait for the child to complete and then exit.
   • Verification: The output from the child process should successfully display "fork_master", demonstrating that environment variables are copied to the child.
3. Shared File Offset.
   • Objective: Write a program to demonstrate the shared file offset.
     1. Create a text file named data.txt with the content "ABCDEFGHIJKLMNOPQRSTUVWXYZ".
     2. The parent process should open data.txt for reading.
     3. After opening, call fork().
     4. In the parent process, read and print the first 5 characters, then wait for the child. After the child finishes, read and print the next 5 characters.
     5. In the child process, read and print the first 5 characters, then exit.
   • Verification: Observe the output carefully. You should see that the reads are sequential. For example, if the parent runs first, it reads "ABCDE". Then the child runs and reads "FGHIJ". Finally, the parent resumes and reads "KLMNO". This proves they share a single file offset pointer.
4. Process Chain.
   • Objective: Create a chain of three processes: a grandparent, a parent, and a child. The original process (grandparent) should fork a child (the parent). The parent process should then fork its own child (the grandchild).
   • Guidance: Each process should print its PID and its parent's PID. The grandparent should wait for the parent, and the parent should wait for the grandchild.
   • Verification: The output should clearly show the three-level hierarchy. For example:
     • Grandparent (PID 3001) creates Parent (PID 3002).
     • Parent (PID 3002, PPID 3001) creates Grandchild (PID 3003).
     • Grandchild (PID 3003, PPID 3002) executes and exits.
     • Parent waits for grandchild, then exits.
     • Grandparent waits for parent, then exits.
5. A Tiny Shell with execvp.
   • Objective: Combine fork() with execvp() to create a very simple command shell. The exec family of functions replaces the current process image with a new one.
   • Guidance:
     1. The main process should loop, print a prompt (e.g., > ), and read a command from the user (e.g., ls -l).
     2. Inside the loop, call fork().
     3. The parent process should wait() for the child to finish.
     4. The child process should use execvp() to execute the command entered by the user. execvp is convenient because it searches the PATH environment variable for the command.
   • Verification: You should be able to run simple commands like ls -l, pwd, or uname -a from your tiny shell. This is the fundamental model for how command-line shells work.

Summary

This chapter provided a deep dive into fork(), the fundamental mechanism for process creation in Linux. We have moved from theory to practice, solidifying the core concepts of system programming.

• Process Fundamentals: A process is an instance of a running program with its own isolated virtual address space (text, data, heap, stack) and a kernel data structure (task_struct) that tracks its resources.
• fork() Mechanics: The fork() system call creates a new child process by creating a near-perfect clone of the parent. The key differentiator is the return value: 0 in the child, the child's PID in the parent, and -1 on error.
• Copy-on-Write (CoW): This critical optimization makes fork() highly efficient. Instead of copying all memory pages, the kernel shares them as read-only between the parent and child. A page is only duplicated when one of the processes attempts to write to it.
• Inheritance: The child inherits many attributes from the parent, including the memory image (with CoW), open file descriptors (with a shared offset), credentials, and environment. It gets its own unique PID.
• Process Management: Proper management is crucial. The parent should use wait() or waitpid() to reap terminated children, preventing the creation of zombie processes.

Mastering fork() is a significant step. It is the gateway to understanding concurrency, inter-process communication, and the overall architecture of how Linux manages to do so many things at once.

Further Reading

1. fork(2) Linux Programmer's Manual: The definitive, authoritative reference for the fork() system call. Access it on your system with the command man 2 fork.
2. wait(2) Linux Programmer's Manual: The companion to fork(), explaining how to wait for process termination. Access with man 2 wait.
3. "The Linux Programming Interface" by Michael Kerrisk: Chapters 24, 25, and 26 provide an exhaustive and exceptionally clear explanation of process creation, termination, and monitoring.
4. "Advanced Programming in the UNIX Environment" by W. Richard Stevens and Stephen A. Rago: A classic text. Chapter 8 covers process control in great detail.
5. LWN.net - "The history of fork()": A well-written article on the history and evolution of the fork() system call, providing valuable context. (Search for this title on LWN.net).
6. Raspberry Pi Foundation Documentation: Official hardware and software documentation for the Raspberry Pi platform. (https://www.raspberrypi.com/documentation/)
7. "How Do Fork and Exec Work?" - Julia Evans' Blog (jvns.ca): An accessible, illustrated blog post that provides an excellent high-level overview of the concepts.