Process Management & Observability

The Process Tree & PID 1

A program is a static file resting on a disk. A process is the active, executing instance of that program loaded into memory.

In Linux, every process is assigned a unique Process ID (PID) and is hierarchically linked to the process that created it, known as the Parent Process ID (PPID). When a Linux kernel boots, the very first User Space process it starts is assigned PID 1 (traditionally init, but nearly universally systemd in modern distributions). Every single process running on the system is a descendant of PID 1.

The Fork/Exec Model

Linux creates new processes using an elegant, two-step architectural pattern: fork() and exec().

1. fork(): A parent process calls fork() to create an exact clone of itself. The kernel copies the parent’s memory state, file descriptors, and environment variables into a new child process. The only difference is that the child is assigned a new PID.
2. exec(): The child process immediately calls an exec() family function. This system call replaces the child’s entire memory space with a brand new program loaded from disk.

Signals & Process Control

Processes in Linux communicate state changes primarily through Signals. When you press Ctrl+C in a terminal, you are not closing the program; you are instructing the terminal to send a SIGINT (Interrupt) signal to the foreground process.

Understanding how to terminate misbehaving processes safely is critical for system stability:

• SIGTERM (15): The standard, graceful termination signal (sent by default when you run kill <PID>). The program is notified, allowing it to close database connections and flush buffers before exiting.
• SIGKILL (9): The absolute kill switch (kill -9 <PID>). The kernel immediately destroys the process. The program cannot catch, block, or ignore this signal, meaning it will leave temporary files and corrupted data streams behind.

System Observability

When an engineer inherits an unfamiliar or failing system, they cannot rely on application logs alone. They must observe the OS-level state using standard telemetry tools.

• top / htop: Provides a real-time, dynamic view of all running processes, ordered by CPU or memory consumption. Essential for identifying runaway processes.
• dmesg: Prints the kernel ring buffer. This is the first place to look if hardware is failing, a network driver crashes, or the Out-Of-Memory (OOM) killer destroys a process.
• journalctl: Queries the unified systemd journal, capturing logs from all services and the kernel in a centralized, queryable format.
• strace: Traces system calls. If a process is frozen but using 0% CPU, attaching strace -p <PID> will show exactly which system call (often a network read or a file lock) the process is infinitely waiting for.

Test Your Understanding

Further Exploration

• The Linux fork() System Call Manual
• Brendan Gregg’s Linux Performance Observability Tools