Linux Process Lifecycle

1. Process Creation: The fork() and clone() System Calls

In Linux, creating a new process is a two-step dance: first, you create a copy of the running process, and second, you optionally replace the copy with a new program. We begin with the first step, fork().

Conceptually, fork() creates a child process that is a near-perfect clone of its parent. They have separate PIDs but initially share almost everything else. The primary way for the code to know whether it's running in the parent or the child is by the return value of fork():

• In the parent, fork() returns the PID of the newly created child.
• In the child, fork() returns 0.

Kernel Implementation of fork()

Now, let's peel back the layers and see what happens inside the kernel.

As the diagram illustrates, user-space calls funnel into a common kernel mechanism. The clone() system call is the fundamental primitive for creating tasks in Linux. Simpler calls like fork() are implemented as wrappers around clone() with specific flags.

The heart of process creation is a function called copy_process().

To summarize the kernel's work during a fork():

1. sys_clone() / sys_fork() is entered.
2. This calls kernel_clone() (previously do_fork), which allocates a new PID.
3. copy_process() is called to do the heavy lifting:
   • dup_task_struct() allocates a new task_struct and kernel stack.
   • It then copies or shares all the parent's resources. A key step here is copy_mm(), which duplicates the page tables for the new process's address space, marking them as read-only to enable CoW.
   • copy_thread() prepares the new task's CPU state (pt_regs) so that when it runs for the first time, it will return to user-space with 0 in its return value register.
4. wake_up_new_task() is called, which makes the new child process TASK_RUNNING and places it on a scheduler run queue, making it eligible to be picked by the scheduler.

2. Process Execution: The execve() System Call

After a fork(), the child process is running the same code as the parent. To run a different program, it must call one of the exec family of functions, with execve() being the underlying system call.

execve() replaces the current process image with a new one. This is a destructive operation: the memory space (code, data, stack, heap) of the old program is completely discarded and replaced by the new program. The PID does not change. There is no return on success; the new program simply starts executing.

Kernel Implementation of execve()

Given your preference for hands-on, deep-level exploration, we're going to trace the execve() call path using a GDB-guided walkthrough. This will demonstrate exactly how the kernel tears down the old process image and sets up the new one.

This walkthrough vividly illustrates the "point of no return" in execve(). Once the kernel starts tearing down the old address space (in load_elf_binary), there's no going back. The start_thread function effectively hijacks the return path of the system call, redirecting it to the entry point of the new executable.

3. Process Termination: exit() and wait()

A process's life ends when it either calls exit() or is terminated by an unhandled signal. This initiates an orderly shutdown sequence within the kernel, orchestrated by the do_exit() function.

Kernel Implementation of exit()

The do_exit() function is responsible for untangling the process from the rest of the system.

The key steps in do_exit() are:

1. Set the PF_EXITING flag in the task_struct to prevent other subsystems from interacting with a dying process.
2. Call a series of exit_* functions (exit_mm, exit_files, etc.) to release the process's resources.
3. Call exit_notify(), which handles two critical tasks:
   • It looks for any child processes and reparents them to another process (typically init/PID 1). These are now orphan processes.
   • It sends a SIGCHLD signal to the process's parent to notify it that a child has terminated.
4. Change the process's state to EXIT_ZOMBIE.
5. Call schedule() to switch to a new process. The dying process will never run again.

Zombie and Orphan Processes

The EXIT_ZOMBIE state is a crucial and often misunderstood part of the lifecycle.

• Zombie Process: A process in the EXIT_ZOMBIE state. It has terminated and released all its resources (memory, files), but its task_struct still remains in the kernel's process list. Why? To hold the process's exit code and resource usage statistics for the parent to collect.
• Reaping: The parent process collects this information (and allows the kernel to finally free the task_struct) by calling one of the wait() family of system calls. This act is called "reaping" the child.
• Orphan Process: If a parent dies before its child, the child becomes an orphan. The kernel automatically reparents the orphan to the init process (PID 1) or a designated subreaper. init's main loop periodically calls wait(), ensuring that all orphans are eventually reaped and don't remain as zombies forever.

4. The Complete Picture

Let's visualize the entire journey. The process transitions between several states, managed by the kernel.

5. Interview Scenario

Your deep understanding of this lifecycle is prime material for a senior-level interview.

Question: "Walk me through what happens at the kernel level when a shell runs a command like ls -l. Then, explain what a zombie process is and why it's a necessary state."

Your Thought Process:

1. Shell runs a command: This is the classic fork() followed by exec().
2. The shell process calls fork(). The kernel executes copy_process(), creating a new child task_struct, duplicating the shell's state (with CoW for memory), and making the child runnable.
3. The child process, now running shell code, immediately calls execve("ls", ["ls", "-l"], ...).
4. The kernel's execve path is triggered. It finds the /bin/ls executable, verifies it's an ELF binary, and calls load_elf_binary.
5. load_elf_binary tears down the child's current memory map (the copy of the shell's) and maps the segments of the ls executable into memory.
6. start_thread modifies the child's pt_regs to set the instruction pointer to the entry point of ls.
7. The system call returns to user-space, but now executes ls code. The ls process runs, prints the directory listing, and calls exit().
8. The ls process's call to exit() triggers do_exit() in the kernel. It releases resources and changes its state to EXIT_ZOMBIE. It also sends SIGCHLD to its parent (the shell).
9. The shell, which was likely waiting via a wait() call, is woken up. The wait() call reaps the zombie ls process, gets its exit status, and allows the kernel to finally free the ls task_struct. The shell then prints a new prompt.
10. Zombie Explanation: A zombie is a terminated process whose task_struct is kept by the kernel solely to provide an exit status to its parent. It consumes no memory or CPU, only a slot in the process table. It's necessary for parent processes to get feedback on how their children terminated. They are cleaned up when the parent calls wait().

Conclusion

Today you've traced the entire life of a Linux process, from creation to execution to termination. This is one of the most fundamental mechanisms in the kernel.

Key Takeaways:

• Process creation is separated into fork() (cloning) and execve() (replacing).
• fork() is implemented via copy_process(), which efficiently duplicates a task using Copy-on-Write (CoW).
• execve() is a destructive operation that replaces the current process's memory image with a new program, orchestrated by functions like load_elf_binary().
• exit() triggers do_exit(), which releases all of a process's resources and transitions it to the EXIT_ZOMBIE state.
• Zombie processes exist so parents can retrieve their exit status via wait(). Orphan processes are adopted by init to ensure they are eventually reaped.

In our next lesson, we will address a critical question: with many processes in the TASK_RUNNING state, how does the kernel decide which one gets to use the CPU? We will dive into the Linux scheduler and describe how the Completely Fair Scheduler (CFS) allocates CPU time using virtual runtime.