Outcome
- Understand why PID 1 (“mommy process”) owns every orphan on the box
- Recall the SysV init flow & its pain points
- Know what systemd bundles and why nerds argue about it
PID 1 — the mommy process
- Starts first in the kernel’s user-space hand-off → gets PID 1
- Every other process is its child, grandchild, or further down the tree
- If a parent dies, PID 1 adopts the orphan so its exit status can be reaped (prevents zombies)
- Zombie = process finished execution but still holds a slot in the table; init uses wait() to clean it up
SysV init
(a.k.a. Sys5 or “classic init”)
- Plain-text shell scripts in /etc/init.d/*
- Scripts run sequentially via run-levels (/etc/rc*.d)
Drawbacks
- Serial startup ⇒ slow boot
- No dependency handling — you hand-craft order
- Limited monitoring — service crash may go unnoticed
systemd
Think of it as “init ++”: still PID 1, but also conductor for system state and services.
What’s inside
- systemctl — master CLI to start/stop/enable units
- journalctl — unified log viewer
- networkd, logind, timedated, etc. — micro-daemons
- Units replace old scripts; simple INI syntax
Perks
- Parallel boot with dependency graph → faster startup
- Built-in health monitoring & auto-restart
- One CLI for everything (systemctl status nginx.service)
Controversies
- Bigger footprint than minimalist folks like
- Binary journal files in /var/log/journal
- Pros: indexed, structured, tamper-resistant
- Cons: need journalctl; harder with plain tools
- Want old school? set Storage=none in journald.conf
Quick commands
- Show PID 1: ps -p 1 -o comm=
- List orphans adopted by PID 1: ps -o pid,ppid,comm | awk ‘$2==1 && $1!=1’
- Tail last boot logs: journalctl -b -e
Memory prompts for exams
- “Mom adopts orphans” → PID 1 waits on zombies
- SysV = scripts + run-levels; systemd = units + parallel boot
- Recall SUID, SGID, Sticky bits from the permissions cheat-sheet
Todos
- Mini post on writing a simple .service unit
- Compare OpenRC vs systemd on Alpine/Gentoo