<aside> 🔄
Module 8 — Processes
Everything that happens on Linux happens inside a process — every command you have run since Module 1 was one. This module makes them visible and controllable: watching them, signalling them, running them in the background, and understanding the strange ones (zombies, orphans, daemons) that interviews adore. It is also the module where "why did my program die when I closed the terminal?" finally gets its full answer.
Legend used throughout: 🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start
You need Modules Module 1 — What Linux Is–Module 7 — Text Surgery: sed and awk — especially the environment/child model (Module 5) and pipelines (grep/awk will dissect ps output constantly). Nothing to install; sleep — a command that does nothing for N seconds, then exits successfully — will be our lab rat throughout: harmless, killable, visible.
Goes deeper: this module has two dedicated theory companions in the Operating Systems track — Module 02 — Processes, fork/exec & Process States and Module 04 — Signals, Sessions & Job Control. Read them after this page for the mechanism beneath every command here.
</aside>
<aside> ℹ️
This page uses Mermaid diagram blocks. Notion shows them as code by default — click the block and set it to Preview to see the diagram. This reminder appears once per page.
</aside>
<aside> 📖
Official docs: ps(1) · proc(5)
</aside>
🧠 A program is a file on disk (Module 3's ELF executables). A process is that program running: the kernel's live bookkeeping for one execution — its memory, its open files, its identity (Module 4's UID), and two numbers: the PID (its own process ID) and PPID (its parent's). Every process is created by another — your commands are children of your shell, your shell is a child of the terminal or login machinery — forming one tree, rooted at PID 1: on modern Linux, systemd (historically named init), started by the kernel at boot and ancestor of everything.
The shell tells you its own PID via a special variable: echo $$.
<aside> 🧩
Real-world analogy — the recipe and the cooking
A program is a recipe card; a process is one act of cooking it — pans out, timers running, ingredients half-used. Three cooks can work the same recipe simultaneously: one card, three independent cooking sessions, each with its own mess and its own timer. Three processes, one program.
Where the analogy stops working. A cooking session is the cook's affair. A process is really the kernel's dossier about the cooking — identity, allowances, opened drawers — and the kernel can consult, suspend, or terminate the session from outside at any moment. The cook does not own the kitchen; the kernel does.
</aside>
🧪 Exercise A1.1 — Find yourself in the tree
echo $$ # this shell's PID
ps # processes in THIS terminal session (a short list)
ps -e --forest | head -25 # the whole tree, drawn — look for systemd at the top
<aside> 📖
Official docs: proc(5)
Goes deeper: Module 02 — Processes, fork/exec & Process States — the full mechanism, with experiments.
</aside>
🧠 When you type date, the shell does not "run date" in one step. It forks — asks the kernel to clone itself, producing a child that is a near-copy (same environment: Module 5's snapshot semantics, explained at last) — and the child then execs: replaces its own program with /usr/bin/date, keeping PID and environment. The parent shell waits for the child to exit and collects its exit code — which is exactly the $? you have been reading since Module 5. Fork, exec, wait: three verbs, and every command you have ever run was this trio.
Why you care operationally: it explains environment inheritance (copies at fork), why a child can never alter its parent (separate processes), where exit codes travel (wait), and — in Part D — what happens when the wait step goes missing.
<aside> 🧩
Real-world analogy — the photocopied briefing
Dispatching an errand, the manager photocopies their own briefing folder (fork — the copy is the child's environment), then swaps the top sheet for the errand's instructions (exec), and files the runner's receipt on return (wait — the exit code). Nothing the runner scribbles on their copy reaches the manager's folder.
Where the analogy stops working. A manager dispatches a runner other than themselves. fork is stranger: the shell briefly becomes two identical shells, and one of them transforms into date. There is no hiring — only cloning and metamorphosis. It sounds baroque; it is why Unix process creation is one cheap, uniform trick rather than a dozen special cases.
</aside>
🧪 Exercise A2.1 — Watch the ancestry in the columns
ps -o pid,ppid,comm # this session, with parent PIDs shown
bash # start a CHILD shell, inside your shell
ps -o pid,ppid,comm # look again — who is whose parent?
exit # leave the child; you are back in the original