What systemd manages

When the Linux kernel finishes booting, it starts exactly one process. On most Ubuntu servers that process is systemd. It runs as PID 1, and every other process on the machine descends from it.

You can check this yourself. Ask ps about process 1:

ps -p 1 -o pid,comm,args

  PID COMMAND         COMMAND
    1 systemd         /sbin/init

/sbin/init is a symlink to the systemd binary. The name is a leftover from older init systems. The process is systemd.

Units, not scripts

Older init systems treated startup as a pile of shell scripts that ran in order. systemd works differently. It models the whole system as units: named objects with a type, a state, and relationships to other units.

Services are the unit type you will touch most. But they are not the only one. Sockets, timers, mounts, paths, targets, and devices are units too. A timer can activate a service. A target can group dozens of units into one named system state, like multi-user.target.

This is why I say systemd owns more than background processes. It knows that your backup timer triggers backup.service. It knows nginx.service wants the network first. It knows which control group every process belongs to.

See what it tracks

Let’s list the services running right now:

systemctl list-units --type=service --state=running

  UNIT           LOAD   ACTIVE SUB     DESCRIPTION
  cron.service   loaded active running Regular background program processing daemon
  nginx.service  loaded active running A high performance web server
  ssh.service    loaded active running OpenBSD Secure Shell server

Swap --type=service for --type=timer or --type=socket and you see the other unit types the manager is tracking. Every one of them has a state and a set of relationships. Nothing here is a long shell script.

Try to connect the two views in your head. There is the process tree hanging off PID 1, and there is the unit list explaining why each piece of that tree exists.

A habit worth building early

When a process misbehaves, ask systemd about it before reaching for ps.

ps tells you a process exists. systemd tells you which unit owns it, why it started, and what happens when it dies. That is far more useful when something is wrong at 3 AM.

Run the two commands above on a server you have access to. Pick one running service and find its main process in ps. Then find the same service in systemctl list-units. Once you can go back and forth between those two views, the rest of this course will make a lot more sense.