Process

Linux hub

A process is a running instance of a program. Linux gives each process a unique PID, its own memory space, and a set of open file descriptors. Every process has a parent — except PID 1 (systemd) — forming a tree of all running processes.

What Is a Process in Simple Terms

A program is a file on disk — instructions waiting to be run. A process is what that program becomes when it is actually running: the instructions loaded into memory, executing one by one, with its own private memory, open files, and state.

The difference matters for DevOps work. When nginx is installed, it is a program. When systemctl start nginx runs, nginx becomes a process (actually several: a master and workers). When you troubleshoot a hung service, you are working with processes — inspecting their state, reading their memory usage, and sending them signals.

How It Works

When Linux creates a new process, it uses fork() to copy the parent process, then exec() to replace the copy with the new program. The new process inherits the parent's environment, open file descriptors, and user context — then replaces the program image with the new executable.

◈ DIAGRAM

PID 1 (systemd) -- the root of all processes
|
+-- sshd (PID 892)       -- SSH daemon
|   |
|   +-- bash (PID 1203)  -- your login shell
|       |
|       +-- vim (PID 1247)  -- editor you opened
|
+-- nginx (PID 1100)     -- master process
|   +-- nginx worker (PID 1101)
|   +-- nginx worker (PID 1102)
|
+-- postgres (PID 1350)  -- database master
    +-- postgres (PID 1351)  -- worker
    +-- postgres (PID 1352)  -- worker

Process memory layout:

◈ DIAGRAM

High memory addresses
+---------------------------+
| Stack (grows down)        |  Local variables, function calls
+---------------------------+
| ...gap...                 |
+---------------------------+
| Heap (grows up)           |  Dynamic memory allocation (malloc)
+---------------------------+
| BSS segment               |  Uninitialised global variables
+---------------------------+
| Data segment              |  Initialised global variables
+---------------------------+
| Text segment              |  Program code (read-only)
Low memory addresses

Process states:

TEXT

R  Running or runnable -- on CPU or waiting for CPU
S  Sleeping (interruptible) -- waiting for event, can be woken
D  Sleeping (uninterruptible) -- waiting for I/O, cannot be killed
T  Stopped -- received SIGSTOP or SIGTSTP
Z  Zombie -- finished but parent has not read exit status yet
 
D state (uninterruptible sleep) is important:
- Process is waiting for disk I/O or network I/O
- Cannot be killed with SIGKILL while in D state
- High D-state process count = I/O bottleneck
- Contributes to load average even though CPU is idle

Practical Commands

Bash

## Show all running processes
ps aux
## USER  PID  %CPU %MEM  VSZ   RSS   STAT  START  TIME  COMMAND
## root    1   0.0  0.1  168MB  13MB  Ss    Jan01  0:05  /sbin/init
 
## Show as tree
ps --forest aux
pstree -p  ## more visual tree
 
## Show specific process
ps aux | grep nginx
 
## Show process with all threads
ps -eLf | grep nginx
 
## Live view sorted by CPU
top
htop  ## more user-friendly
 
## Sort top by memory: press M
## Sort top by CPU: press P
## Kill a process from top: press k, enter PID
 
## Read process info from /proc
cat /proc/1234/status  ## detailed process status
cat /proc/1234/cmdline | tr '\0' ' '  ## command line
ls -la /proc/1234/fd  ## open file descriptors
cat /proc/1234/environ | tr '\0' '\n'  ## environment variables

Troubleshooting

Symptom	Command	What to Look For
Server is slow, unknown cause	`top` or `htop`	Process consuming most CPU or memory
Cannot kill a process	`ps aux	grep proc`
Zombie processes accumulating	`ps aux	grep Z`
Process using wrong user	`ps aux	grep process`

Tip
The D (uninterruptible sleep) state cannot be killed. It means the process is stuck waiting for kernel I/O — usually disk or NFS. If you have many D-state processes, the problem is at the I/O layer, not the process layer. Check iostat -x and dmesg for disk errors.

Remember
ps aux shows a snapshot in time. top and htop show live updates every 3 seconds. For troubleshooting a process that is intermittently high CPU, top is more useful because you can watch the values change in real time.

Security
A process running as root that was started by a non-root user is a privilege escalation indicator. Always check the USER column in ps aux for any unexpected root processes. Service processes should run as their dedicated service accounts, never as root.

Frequently Asked Questions

What happens to a process's children when the process itself dies unexpectedly?

Orphaned child processes get automatically reparented to PID 1 (systemd, or init), which adopts them and is responsible for reaping their exit status when they eventually terminate. This matters in containers: many base images run an application directly as PID 1, and that process often doesn't handle reaping duties correctly, leading to zombie processes accumulating inside the container — which is why tools like tini or dumb-init are commonly added as a lightweight PID 1.

What's the practical difference between killing a process with SIGTERM vs SIGKILL?

SIGTERM (the default for `kill`) is a polite request the process can catch, ignore, or handle to clean up — close file handles, flush buffers, finish in-flight requests — before exiting. SIGKILL (`kill -9`) is enforced directly by the kernel and cannot be caught or ignored; the process is terminated immediately with no cleanup. Always try SIGTERM first and only escalate to SIGKILL if the process doesn't exit within a reasonable timeout, since -9 can leave corrupted state or orphaned locks behind.