the process tree and init / PID 1

Because every process is created by another process (via fork), processes naturally form a family tree rather than a flat crowd. Each process has exactly one parent and may have many children, those children have children, and so on - a branching genealogy. Run pstree on Linux and you literally see it drawn: one root at the top, branches fanning out to every running process. This shape is the process tree, and it is the backbone of how the system organizes everything that is running.

At the very root of the tree sits one special process: init, which always has PID 1. It is the first user-space process the kernel starts at boot, and every other process descends from it. On modern Linux this role is usually filled by systemd; classically it was a program literally named init. PID 1 has two unique jobs. First, it bootstraps and supervises the system - starting services, mounting filesystems, bringing the machine to life. Second, and crucial for this field, it is the universal adopter: when any process dies while it still has living children, those children become orphans, and the kernel reparents them to PID 1. init then dutifully waits on them when they finish, reaping them so they do not become permanent zombies. PID 1 is also special in that if it ever dies, the kernel panics - the whole system cannot continue without its root.

Why it matters: the tree explains reparenting (orphans always have a home at PID 1), zombie cleanup (init reaps the children nobody else will), and signal/permission propagation through process groups. It is also why containers need an init-like process: if the program you run as PID 1 inside a container does not reap its adopted orphans, zombies pile up. Knowing the tree exists - and that PID 1 catches everyone who falls - turns a confusing pile of processes into an organized hierarchy you can reason about.