Linux Curriculum
Process Management
System Monitoring
Service Management
Scheduling Tasks
Disk and Storage Management
On this page
Subtopic•Process Management

Processes Overview

1. What is a Process?

In Linux, a process is an instance of an executing program in memory, along with all the system resources allocated to it by the kernel (CPU time, memory address space, file descriptors, network sockets, environment variables, and security security contexts).

A program stored on a solid-state disk or hard drive is merely a static file containing executable machine code. When that program is executed, the kernel loads the binary into virtual memory, allocates process data structures, and schedules its execution threads across CPU cores.

+--------------------------------------------------------------------------+
|                       Program vs. Process Architecture                   |
+--------------------------------------------------------------------------+
|  Static on Disk (Program)           Dynamic in RAM (Process)             |
|  +--------------------+             +----------------------------------+ |
|  | /usr/bin/nginx     |  execve()   | Process ID (PID: 1420)           | |
|  | - ELF Binary Code  | ----------> | - Virtual Memory Address Space   | |
|  | - Static Assets    |             |   - Stack (Local variables)      | |
|  | - Dynamic Libraries|             |   - Heap (Dynamic malloc memory) | |
|  +--------------------+             |   - BSS & Data (Global variables)| |
|                                     |   - Text (Executable Code)       | |
|                                     | - File Descriptors (0, 1, 2, ...) | |
|                                     | - Security Credentials (UID/GID) | |
|                                     | - Environment Variables          | |
|                                     +----------------------------------+ |
+--------------------------------------------------------------------------+

2. Process Identification and Hierarchy

Every process in a Linux system is uniquely identified by numeric integers managed by the kernel:

IdentifierNameMeaning
PIDProcess IDUnique numerical identifier assigned to the process by the kernel.
PPIDParent Process IDThe PID of the process that created (forked) this process.
UID / GIDUser / Group IDIdentifies the security credentials and file access rights of the process.
TIDThread IDIdentifier for individual lightweight execution threads within a process.

The Process Tree (Inheritance)

Processes do not exist in isolation; they form an inverted tree structure originating from a single root ancestor: PID 1 (systemd or legacy init).

                              [ systemd (PID: 1) ]
                                       |
          +----------------------------+----------------------------+
          |                            |                            |
          v                            v                            v
   [ sshd (PID: 980) ]        [ containerd (PID: 1102) ]   [ crond (PID: 850) ]
          |                            |
          v                            v
   [ sshd: devops ]            [ dockerd-shim ]
          |                            |
          v                            v
   [ bash (PID: 2314) ]        [ nginx (PID: 3410) ]
          |
          v
   [ ps aux (PID: 4120) ]

When a process creates a child, it invokes the fork() or clone() system call, which duplicates the parent's memory pages using Copy-on-Write (CoW), followed by execve() to load the new binary.


3. Process Lifecycle and States

A Linux process transitions through well-defined lifecycle states between initialization and termination:

        +----------------+     fork() / clone()
        |   Created      | -----------------------+
        +----------------+                        |
                                                  v
                     schedule()           +----------------+
        +-------------------------------- |   Runnable (R) | <----------------+
        |                                 | (Ready in RunQ)|                  |
        v                                 +----------------+                  |
+----------------+                                                            |
|  Running (R)   |                                                            |
| (On CPU Core)  |                                                            |
+-------+--------+                                                            |
        |                                                                     |
        |-- Waiting for I/O / Event ---> +-----------------------------+      |
        |                                | Interruptible Sleep (S)     | -----+ Event occurs
        |                                +-----------------------------+
        |
        |-- Blocked on Disk / Hardware ->+-----------------------------+
        |                                | Uninterruptible Sleep (D)   | -----+ Hardware ready
        |                                +-----------------------------+
        |
        |-- Received SIGSTOP / Ctrl+Z -> +-----------------------------+
        |                                | Stopped / Traced (T)        | -----+ Received SIGCONT
        |                                +-----------------------------+
        |
        v exit() / kill
+----------------+
|   Zombie (Z)   |
| (Dead; pending |
| parent wait()) |
+-------+--------+
        |
        | Parent calls waitpid()
        v
+----------------+
|   Terminated   | (PID freed to pool)
+----------------+

State Indicators:

  • R (Running / Runnable): Either currently executing on a CPU core or waiting in the kernel runqueue.
  • S (Interruptible Sleep): Waiting for an external event (network socket data, timer, keyboard input). Can be awakened by OS signals.
  • D (Uninterruptible Sleep): Blocked waiting for synchronous hardware/disk I/O. Cannot be killed with kill -9 until hardware responds.
  • T (Stopped / Traced): Suspended via user signal (SIGSTOP, Ctrl+Z) or under gdb debugger tracing.
  • Z (Zombie / Defunct): Process has completed execution (exit()), but its entry remains in the process table because the parent process has not yet read its exit status code via wait() or waitpid().

4. Special Process Conditions: Zombies and Orphans

Zombie Processes (Z)

A zombie consumes zero CPU and zero memory address space, but it occupies an entry in the kernel's finite process table (/proc/sys/kernel/pid_max). If a buggy parent process continuously spawns child processes that exit without calling wait(), the PID table can become exhausted, preventing any new processes (including administrative shells) from launching!

[!TIP] You cannot kill a zombie with kill -9 because it is already dead. To clear a zombie, send SIGHUP or SIGTERM to the parent process (PPID), or terminate the parent. When the parent dies, the zombie is adopted by systemd (PID 1), which immediately harvests its exit code.

Orphan Processes

When a parent process terminates before its children, the children become orphans. The Linux kernel automatically reparents orphan processes to systemd (PID 1), which assumes responsibility for reaping them upon completion.


5. Summary Takeaways

  • A process is an active, executing program instance managed via a unique Process ID (PID).
  • All processes descend from PID 1 (systemd).
  • Process states include Running (R), Interruptible Sleep (S), Uninterruptible Disk Sleep (D), Stopped (T), and Zombie (Z).
  • Uninterruptible sleep (D) processes cannot be terminated by signals until I/O concludes.
  • Zombie processes consume no memory, but hoard kernel PIDs; resolve them by terminating the parent process.
←Previous ModuleNetworking and Security