In Unix/Linux, process creation is split into two distinct operations: fork() to create a new process, and exec() to replace a process's program image with a different program. This separation is a fundamental Unix design philosophy that provides extraordinary flexibility.

fork() -- Clone the Current Process

The fork() system call creates a child process that is an almost exact copy of the parent:

• The child gets a new PID but inherits the parent's code, data, heap, stack, open file descriptors, signal handlers, and environment variables.
• Return value is the key to distinguishing parent from child: fork() returns the child's PID to the parent (a positive integer), and 0 to the child. On failure, it returns -1 to the parent (no child is created).

pid_t pid = fork();
if (pid == 0) {
    // Child process executes here
} else if (pid > 0) {
    // Parent process executes here (pid = child's PID)
} else {
    // fork() failed
}

After fork(), both parent and child execute concurrently from the same point in the code (the instruction after fork). They have independent address spaces -- changes in one do not affect the other (thanks to copy-on-write, covered in the next tutorial).

exec() -- Replace the Program Image

The exec() family of functions (execl, execv, execvp, execve, etc.) replaces the current process's code, data, heap, and stack with a new program loaded from an executable file. The PID stays the same -- it is the same process running a different program.

After exec(), the old program is gone entirely. exec() does not return on success (there is nothing to return to -- the old code no longer exists). It only returns on failure (e.g., file not found).

The fork+exec Pattern

The canonical way to run a new program in Unix:

1. The parent calls fork() to create a child.
2. The child calls exec() to replace itself with the desired program.
3. The parent calls waitpid() to wait for the child to finish.

This pattern is how shells work: when you type ls -la, the shell forks, the child execs /bin/ls, and the shell waits for it to complete.

Orphan and Zombie Processes

Orphan process: A child whose parent exits first. The child is adopted by the init process (PID 1) or systemd, which becomes its new parent and will reap it when it exits.

Zombie process: A child that has exited but whose parent has not yet called wait() or waitpid() to read its exit status. The process has released all its resources (memory, open files), but its PCB entry remains in the process table so the exit status is preserved for the parent. Zombies consume a PID and a small amount of kernel memory. A parent that never calls wait() accumulates zombies.

waitpid() -- Reap the Child

waitpid(pid, &status, options) blocks the parent until the specified child exits (or returns immediately with WNOHANG). It fills status with the child's exit code and frees the zombie PCB entry. Properly reaping children prevents zombie accumulation.