<aside> 🧭
Module 02 · Processes — how they are born, how they die
Most Linux problems you will ever debug are process problems. This module shows you where processes come from, how they end, and what those odd letters in ps actually mean.
🧠 concept → 🧩 real-world analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> ✅
Before you start, you should already know (all from Module 01): what the kernel is, what user space and kernel space mean, what a system call is, how to use strace, and how to read files under /proc.
If any of those is fuzzy, go back. This module builds directly on them.
</aside>
<aside> 📖
Official docs: proc_pid_status(5) · proc_pid_stat(5) · proc(5)
</aside>
In Module 01 you learned that a process is a running copy of a program.
To manage a process, the kernel has to remember things about it. It keeps a set of notes for every single process on the machine. Textbooks call these notes the Process Control Block. The name does not matter. What matters is what is written on it.
Here is what the kernel writes down:
| What it remembers | Why it needs it | Where you can see it |
|---|---|---|
| Its number (PID) | So everything else can refer to this process | /proc/PID/status |
| Its parent (PPID) | So it knows who to report to when the process dies | /proc/PID/status |
| Its state | So the kernel knows whether to give it CPU time | ps STAT column |
| Where it stopped | So it can carry on from the same place after being paused | Not visible — CPU registers |
| Its memory map | So it can never touch another process's memory | /proc/PID/maps |
| Its open files | So read and write know what you meant |
/proc/PID/fd |
| Which user it runs as | So the kernel can decide what it is allowed to do | /proc/PID/status |
| CPU time used | So the scheduler can share fairly | ps TIME column |
This is why /proc/PID/ had all those files in Module 01. It is the kernel's notes, opened up for you to read.
<aside> 🧩
Real-world analogy — the chart at the end of a hospital bed
Every patient in a hospital has a chart. It has their ID number, who admitted them, how they are doing right now, what they are on, and what has been done so far.
The chart is not the patient. It is what the hospital needs to know in order to look after them. Nurses change shift, doctors come and go, but the chart stays and anyone can pick it up and carry on.
The kernel's notes work the same way. Your process gets moved off the CPU hundreds of times a second, and each time the kernel needs the chart to pick up where it left off.
Where the analogy stops working. A hospital chart is written by people, slowly. The kernel's notes are updated constantly, by the kernel itself, and you are only ever allowed to read them. You cannot pick up the chart and change the patient's blood type.
</aside>
🧪 Exercise A1.1 — Read the kernel's notes about your own shell
# $$ is your shell's own PID
echo "My shell is PID $$"
# The kernel's notes, in a form humans can read
grep -E '^(Name|State|Pid|PPid|Uid|Gid|Threads|VmRSS)' /proc/$$/status
# How many separate things is the kernel remembering here?
wc -l < /proc/$$/status
<aside> 📖
Official docs: credentials(7) — process identifiers · pstree(1) · proc_pid_stat(5)
</aside>
Two simple rules explain the whole shape of a Linux system: