OnCallReady

Lesson 1.15 · First Login · 12 min read

Who's in charge

In plain words

Imagine a family tree where the great-grandparent at the top is the one who got the family going, raises any child whose parents have left, and signs off the paperwork when a family member passes. That ancestor is PID 1. On Ubuntu it is systemd, and the kernel starts it as the very first program after booting.

Every other process on oncall-lab is its descendant. When a parent process dies, its children are handed to PID 1. When a process finishes, someone must collect its "final report" (its exit status); PID 1 does that for the orphans. ps -p 1 -o comm= asks the family register who the ancestor is; readlink -f /sbin/init reads the name on the door.

The box reboots at night and, in the morning, everything - SSH, the web server, your programs - is running again, although nobody logged in to start it. Something started all of it, in the right order, and keeps watching it. This lesson is that something, and how to prove what it is.

What you need to know already: 1.1 Where you are (kernel, OS), 1.3 The tree (symlinks), 1.7 Driving the shell (exit status, signals).

Processes

A program is a file on disk. A process is a program that is running: it has memory, open files, and a place in the queue for the CPU. Run ls twice at once and you have two processes of the same program.

Every process has a number, its PID (process ID). Every process was started by another process, its parent; the new one is the parent's child. Your bash is a process; when you run ls, bash starts ls as its child and waits for it.

$$ is a shell variable holding your own shell's PID.

Boot, in four moves

  1. Firmware (the small program built into the machine that runs at power-on) hands control to the bootloader, which loads the kernel from /boot.
  2. The kernel sets up the hardware, then unpacks the initramfs: a tiny starter system held in memory whose only job is to find the real disk and mount it (attach it to the directory tree - lesson 1.20). Now the kernel needs a first real program to run.
  3. It runs /sbin/init as PID 1 - the first process. On Ubuntu that path is a symlink to /usr/lib/systemd/systemd.
  4. systemd takes over: it mounts the other disks listed in /etc/fstab (the file saying which disks to attach where), then starts every service in the right order until the machine counts as "booted". That is your login prompt.

A service (also called a daemon) is a program that runs in the background with no terminal attached - the SSH server, the web server, the scheduler. systemd starts them and restarts them if they die; chapter 2 is all about that.

PID 1 is special

systemd vs launchd

Your Mac's PID 1 is launchd: same job, different everything. Its service definitions are files in /Library/LaunchDaemons (instead of systemd's unit files - its service definitions, chapter 2 - in /etc/systemd/system), you control it with launchctl (instead of systemctl), and it logs differently. The ideas transfer - declare a service, the supervisor starts and restarts it - but none of the commands do.

Two ways to prove PID 1

$ ps -p 1 -o comm=
systemd
$ readlink -f /sbin/init
/usr/lib/systemd/systemd

Different sources - the kernel's process list, and the files on disk - with the same answer. That is what makes it proof rather than a guess.

To see the whole family, pstree draws every process as a tree hanging off PID 1; -p adds each PID in brackets:

systemd(1)─┬─systemd-journal(352)
           ├─cron(600)
           ├─sshd(700)───sshd-session(1509)───sshd-session(1565)───bash(1566)
           ...

Read the sshd line left to right: the SSH server (700) started a process for your connection, which started your bash (1566). ps -o ppid= -p $$ prints your shell's PPID (parent PID) - the 1565 in that chain.

What you can now do

Why it helps

Whenever a machine "comes back up" after a reboot, PID 1 is what brought everything back. Knowing the boot order - firmware, bootloader, kernel, initramfs, PID 1, services - tells you where to look when a machine does not come back: stuck before the kernel, unable to find its disk, or up but with a service missing.

It also explains everyday things: why every process has a parent, why a program started from your SSH session dies when you disconnect, and why "kill -9 1" is harmless. Chapter 2 builds on this: systemd, PID 1, is the tool you will use to start, stop and inspect every service on the box.

Commands in this lesson

kill ps readlink

FAQ

Is systemd just an init system?

Being PID 1 is its core job: starting services in the right order, watching them and restarting them, and reaping orphans. Around that, the systemd project ships many other parts: a log collector (journald), login tracking, network and name-resolution services, time sync, and timers that replace the old scheduler. Ubuntu uses most of them. People who say "systemd does too much" mean that bundle, not PID 1 itself.

Why can't root kill PID 1?

The kernel protects it: a signal only reaches PID 1 if PID 1 has said it wants to handle that signal, and SIGKILL cannot be handled by anyone, so a kill -9 1 is simply dropped. The protection exists because if PID 1 died, nothing would be left to adopt orphans and collect exit statuses, and the kernel stops the whole machine (a "kernel panic").

What is launchd, and how does it compare?

launchd is macOS's PID 1. Same role: start and supervise background services and start them on demand. Its service definitions are XML files (plists) in /Library/LaunchDaemons and ~/Library/LaunchAgents, you control it with launchctl, and logs go to macOS's own log system. The ideas transfer to systemd; none of the commands or file formats do.

Does every Linux distribution use systemd?

Almost all mainstream ones do: Ubuntu, Debian, Red Hat and its relatives, Fedora, SUSE, Arch. Exceptions include Alpine and Gentoo, which use a different init called OpenRC, and some minimal distributions. So on the servers you are likely to meet, systemctl will be there; if ps -p 1 -o comm= says something else, expect different service commands.

What is a zombie, briefly?

A process that has finished but whose parent has not yet read its exit status. It uses no memory or CPU, only a line in the process list and its PID, and ps shows it as Z or <defunct>. You cannot kill a zombie, because it is already dead; you fix or stop the parent, then PID 1 adopts the zombie and collects the status. Chapter 3 shows one for real.

In an interview Junior

What is PID 1, and what happens to a process whose parent dies?

PID 1 is the first process the kernel starts at boot (/sbin/init); on Ubuntu it is systemd. It starts every service in order, it is the ancestor of every process, and it cannot be killed - the kernel refuses to deliver deadly signals to it, because if it died the machine would stop.

When a parent dies before its child, the child becomes an orphan and is handed to PID 1 as its new parent. That matters because a finished process stays listed as a zombie until its parent reads its exit status; PID 1 reaps every orphan it adopted, so zombies do not pile up.

How I'd check: ps -p 1 -o comm= prints systemd, readlink -f /sbin/init confirms it from the files on disk, and pstree -p or ps -o ppid= -p PID shows who a process's parent is.

Also asked: Walk me through what happens when a Linux server boots. · How do you check which init system a machine runs? · What is the difference between a program and a process?

Practise this lesson in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.