IEN-007 - Stage 6 — PID 1: The Beginning of User Space At the end of the previous stage, the Linux kernel has successfully mounted the real root filesystem. The temporary initrd environment has completed its job and has been discarded through the switch_root operation. For the first time since the system was powered on, the kernel has access to the complete operating system installed on disk. Yet one question remains: Who starts everything else? The kernel is responsible for managing hardware, memory, scheduling, and system calls, but it does not start services, launch user sessions, or manage applications directly. Instead, it hands control to the first userspace process. That process is known as PID 1 . Everything that happens after this point ultimately begins with PID 1. What Is PID 1? In Linux, every running program is represented as a process . Each process receives a unique Process ID (PID) assigned by the kernel. For example: PID Process 1 init or systemd 247 sshd 831 nginx 1524 mysqld 2765 bash The very first process created by the kernel is always assigned: PID = 1 No exceptions. This process becomes the ancestor of almost every other userspace process running on the system. The Transition from Kernel Space to User Space Until now, everything has been executed in kernel space . This includes: Memory management Interrupt handling Driver initialization Storage discovery Root filesystem mounting Applications do not run here. Instead, once the kernel has finished its initialization, it starts the first userspace program. The transition looks like this: Kernel Space │ ▼ Execute PID 1 │ ▼ User Space Begins This is one of the most important transitions during the entire boot sequence. How Does the Kernel Find PID 1? The kernel looks for a userspace initialization program in a predefined order. Traditionally, it searches for: /sbin/init If that does not exist, it may try: /etc/init or /bin/init or /bin/sh If none of these programs can be executed, the kernel has nowhere to transfer control. The result is typically a panic similar to: Kernel panic - not syncing: No working init found. This is one of the few kernel panic messages where the kernel itself is functioning correctly, but it cannot continue because the first userspace program is missing or unusable. Engineering Insight Many administrators immediately suspect a damaged kernel when they see a kernel panic. However, in the case of "No working init found" , the kernel has already completed most of its initialization successfully. The actual problem is that it cannot execute the first userspace process. Replacing the kernel would not solve the issue if /sbin/init is missing or the root filesystem is corrupted. The Evolution of Linux Initialization Systems The role of PID 1 has remained the same throughout Linux history, but the software implementing it has evolved significantly. SysV init For many years, Linux systems used System V init . This implementation was simple and relied on shell scripts. The boot process followed a sequence similar to: Kernel │ ▼ /sbin/init │ ▼ Runlevel Scripts │ ▼ System Services Service startup was largely sequential, meaning each service waited for the previous one to complete. Upstart As Linux systems became more dynamic, Upstart introduced an event-driven model. Instead of relying solely on predefined runlevels, services could start in response to events such as: Filesystem mounted Network available Device detected Although innovative, Upstart was eventually replaced by systemd in most major distributions. systemd Today, the majority of Linux distributions use systemd as PID 1. Unlike earlier initialization systems, systemd introduces: Parallel service startup Dependency management Socket activation Service supervision Integrated logging (journal) Timers Mount unit management Target-based booting A simplified flow looks like this: Kernel │ ▼ systemd (PID 1) │ ├────────────┬─────────────┬─────────────┐ ▼ ▼ ▼ Networking Logging Device Manager │ │ │ └────────────┴─────────────┘ │ ▼ Remaining Services This architecture enables modern Linux systems to boot faster and manage services more efficiently than traditional SysV init. Runlevels vs Targets Older Linux distributions, including RHEL 5, organize the boot process using runlevels . Common runlevels include: Runlevel Purpose 0 Halt 1 Single-user mode 3 Multi-user (text mode) 5 Multi-user with graphical interface 6 Reboot Modern distributions using systemd replace runlevels with targets . For example: SysV Runlevel systemd Target 1 rescue.target 3 multi-user.target 5 graphical.target Although the terminology differs, the underlying goal is the same: define the desired operating state of the system. The Importance of PID 1 PID 1 has several unique responsibilities that no other process performs. These include: Starting essential system services. Managing service dependencies. Reaping orphaned child processes. Coordinating system shutdown and reboot. Handling service failures. Because of these responsibilities, PID 1 is special. If a normal process crashes, only that application is affected. If PID 1 exits unexpectedly, the operating system can no longer manage its processes correctly. Historically, this often resulted in a kernel panic or an unusable system. Engineering Insight PID 1 is more than "the first process." It acts as the orchestrator of the entire userspace environment. Every service you rely on—networking, SSH, databases, logging, web servers—ultimately exists because PID 1 started or supervised it. Understanding this role helps explain why issues affecting init or systemd can have system-wide consequences. Common PID 1 Failures Although failures at this stage are less common than storage-related issues, they can still occur. Symptom Likely Cause No working init found Missing or corrupted /sbin/init Immediate reboot after mounting root PID 1 crashed Rescue shell instead of normal boot Essential services failed or rescue target entered system hangs after switching root Initialization process could not continue When troubleshooting, it is important to distinguish between: The kernel failing to start PID 1 , and PID 1 starting successfully but encountering problems later while launching services. The second scenario belongs to the next stage of the boot process. Verifying PID 1 On a running system, confirming the identity of PID 1 is straightforward. ps -p 1 Example output: PID TTY TIME CMD 1 ? 00:00:05 systemd or on legacy systems: PID TTY TIME CMD 1 ? 00:00:01 init You can also inspect the executable directly: ls -l /proc/1/exe This symbolic link reveals the actual program running as PID 1. Summary The execution of PID 1 marks the beginning of userspace . Until this point, Linux has been concerned primarily with preparing hardware and mounting the operating system. Now the focus shifts to bringing the operating system to life. Whether implemented as SysV init, Upstart, or systemd, PID 1 serves as the parent of nearly every userspace process and coordinates the initialization of the entire system. Without it, Linux cannot progress beyond a mounted root filesystem into a fully operational environment.