Understanding Processes
A process is a running instance of a program: the operating system's abstraction for a program in execution, complete with its own memory space, open file descriptors, and execution state, all tracked by the kernel. A single program on disk (like /bin/bash) can be the source of many simultaneously running processes, each with an independent PID (process ID) and its own memory — running bash in three different terminals creates three distinct processes from the same executable file. Understanding processes — how they're created, identified, and related to one another — is foundational to almost every other Linux administration and shell scripting topic, from job control to systemd service management.
Cricket analogy: Like a single coaching manual being used simultaneously by three different net-practice sessions, each with its own players, equipment, and score, running bash in three terminals spawns three distinct processes from the same executable just as three nets run independently.
PIDs, PPIDs, and the process tree
Every process has a unique PID assigned by the kernel when it's created, and (except for the very first process) a PPID (parent process ID) identifying the process that spawned it. Processes are created almost exclusively via fork(), which duplicates an existing (parent) process into a new (child) process, typically followed by exec() to replace the child's memory image with a different program. This fork-then-exec pattern is how your shell launches every command you type: it forks itself, and the child then execs the requested program. The very first process, PID 1 (traditionally init, now systemd on most modern distributions), has no parent and is responsible for eventually adopting any 'orphaned' processes whose original parent has exited.
Cricket analogy: Like a senior player sending a substitute onto the field who's initially a clone of the team's style before adopting a specialized role like a pinch-hitter, the team manager with no parent is responsible for absorbing any player left without a mentor if their senior leaves.
# Show your current shell's PID and its parent's PID
echo "My PID: $$"
ps -o pid,ppid,comm -p $$
# Visualize the process tree
pstree -p
# See a process's ancestry chain
ps -o pid,ppid,comm --ppid 1
# Show PID 1's identity (systemd on most modern distros)
ps -p 1 -o pid,commProcess states
At any moment, a process is in one of several states tracked by the kernel scheduler. Running (R) means it's actually executing on a CPU or ready to. Sleeping — split into interruptible sleep (S, waiting for an event like I/O or a timer, and can be woken by a signal) and uninterruptible sleep (D, typically waiting on disk/device I/O and cannot be interrupted even by SIGKILL, which is why processes 'stuck' in D state are notoriously hard to kill) — covers most idle time. Stopped (T) means execution is paused (e.g. by Ctrl+Z or SIGSTOP). Zombie (Z) is a process that has finished executing but whose exit status hasn't yet been collected (reaped) by its parent via wait() — it holds almost no resources beyond its PID and an entry in the process table, but a large accumulation of zombies usually signals a parent process that's failing to reap its children.
Cricket analogy: Like a batsman actively facing the bowler, one resting in the pavilion waiting to be called back in, one stuck in a rain-delay review that can't be interrupted even by the umpire's whistle, one paused mid-over by an injury timeout, and a retired player whose final scorecard was never officially signed off.
# See process states in the STAT column
ps aux | awk '{print $8, $11}' | sort | uniq -c | sort -rn | head
# Find any zombie processes system-wide
ps aux | awk '$8 ~ /Z/'
# Inspect detailed live state via /proc for a specific PID
cat /proc/1234/status | grep -E 'State|PPid|Threads'The /proc virtual filesystem exposes a live, machine-readable view of every running process as a directory named after its PID (e.g. /proc/1234/), containing files like status, cmdline, environ, and fd/ (open file descriptors). Tools like ps, top, and pstree don't use any special kernel API to gather their information — they simply parse files under /proc, which means you can inspect a lot of process detail yourself with nothing more than cat and grep.
A process stuck in uninterruptible sleep (D state), usually waiting on unresponsive disk or network-mounted storage, cannot be terminated even with kill -9 (SIGKILL) — SIGKILL itself must be delivered and acted upon by the process, which can't happen while it's blocked in that kernel-level wait. The only reliable fixes are resolving the underlying I/O issue (e.g. a hung NFS mount) or, in the worst case, rebooting the machine.
- A process is a running instance of a program, with its own PID, memory space, and open file descriptors tracked by the kernel.
- Processes are created via fork() (duplicate the parent) followed typically by exec() (replace the child's program image) — the pattern your shell uses to launch every command.
- Every process has a PPID linking it to its parent, forming a tree rooted at PID 1 (systemd on most modern distros), which adopts orphaned processes.
- Key process states: R (running), S (interruptible sleep), D (uninterruptible sleep, often disk I/O), T (stopped), and Z (zombie, exited but not yet reaped).
- A zombie process holds almost no resources but signals its parent hasn't called wait() to collect its exit status; many zombies indicate a bug in the parent.
- The /proc filesystem exposes live process information as plain files, which is how tools like ps, top, and pstree gather their data.
Practice what you learned
1. What kernel mechanism does a shell typically use to launch a new command you type?
2. Why can't `kill -9` terminate a process in uninterruptible sleep (D state)?
3. What is a zombie process?
4. Which process, by convention, has no parent and is responsible for adopting orphaned processes?
5. What is /proc, and how do tools like ps and top use it?
Was this page helpful?
You May Also Like
Monitoring Processes with ps and top
Learn to inspect running processes with ps snapshots and the interactive top monitor, reading CPU, memory, and state columns to diagnose system load.
Killing and Signaling Processes
Understand Unix signals and the kill, killall, and pkill commands to gracefully terminate or forcibly stop misbehaving processes.
Background Jobs and nohup
Learn to run and manage background jobs with &, jobs, bg/fg, and disown, and keep long-running processes alive after logout using nohup and disown.
systemd and Managing Services
Learn how systemd manages services, sockets, and timers as units, and how to start, stop, enable, and inspect them with systemctl and journalctl.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics