Why Init or Systemd Is the Ancestor Process in Linux

In the Linux operating system, the initial process launched by the kernel—traditionally known as init and modernly implemented by systemd—is designated as Process ID 1 (PID 1). This process serves as the direct or indirect ancestor of every other process running in user space. By exploring the Linux boot sequence, the hierarchical process creation model, and the critical role of orphan process adoption, this article explains how PID 1 sits at the root of the entire operating system's process tree and maintains system stability.

The Boot Hand-off: From Kernel to User Space

When a computer boots a Linux-based operating system, the BIOS or UEFI initializes the hardware and transfers execution to the bootloader, which in turn loads the Linux kernel into memory. The kernel configures hardware, sets up memory management, and mounts the root filesystem.

Once the kernel has initialized its internal subsystems, it exits kernel space and starts the very first user-space program. It searches for specific binaries, historically /sbin/init or modern symlinks targeting /lib/systemd/systemd. Because this program is the first to be executed in user space, the kernel assigns it PID 1. If the kernel fails to execute this initial binary, the system halts with a "kernel panic," demonstrating that user-space execution cannot exist without it.

The Process Hierarchy: Fork and Exec

Linux manages processes in a strict hierarchical tree structure. With the exception of PID 1, no process can simply appear out of nowhere. Instead, processes are created using two primary system calls:

  1. fork(): An existing process clones itself, creating a child process with a new PID that inherits the execution state, file descriptors, and memory space of the parent.
  2. execve(): The child process replaces its own memory image with a new executable program.

Because every new process requires an existing parent to execute fork(), tracing any process backward through its parent PID (PPID) eventually leads to the original root of the tree: PID 1. When systemd or init starts, it reads its configuration files to spawn foundational daemons, terminal emulators, display managers, and network services. Those services, in turn, spawn background tasks, worker threads, and user shells.

Adopting Orphaned Processes and Preventing Zombies

Beyond starting initial services, PID 1 has an essential maintenance role embedded in the POSIX standard: adopting orphaned processes.

When a parent process terminates before its child process finishes executing, that child process becomes an "orphan." Without a living parent to collect its exit status via the wait() system call, the child process would remain in the process table as a "zombie" upon termination, indefinitely consuming system resources.

The Linux kernel resolves this by automatically reparenting orphan processes to PID 1. Modern systemd or classic init constantly runs a loop executing wait() to collect the termination statuses of these adopted children. By reaping terminated orphans, PID 1 ensures that the system's process table does not fill up with unmanageable zombie entries.

How Modern Systemd Manages the Root

While traditional SysVinit executed shell scripts sequentially to launch services, modern systemd manages PID 1 by leveraging Linux control groups (cgroups) and parallel socket activation.

Despite these architectural enhancements, systemd retains the core duty of PID 1: it handles signal traps (such as shutdown and reboot requests from the kernel), tracks service dependencies, captures orphan terminations, and supervises the entire lifecycle of the operating system from boot to poweroff.