systemd architecture — PID 1 and the unit model · Linux

systemd is the init system on every major Linux distribution. It runs as PID 1, manages every other process on the system, and owns the dependency graph that determines start and stop order. Understanding systemd is non-negotiable for production Linux.

Why PID 1 matters

When the Linux kernel finishes boot, it execs /sbin/init (or /lib/systemd/systemd on modern systems). This process becomes PID 1 and never exits — it owns the lifecycle of every other process.

PID 1 has two special properties:

It cannot be killed by SIGKILL or SIGSTOP. The kernel ignores these signals for PID 1 by design.
If PID 1 exits, the kernel panics. There is no userspace fallback.

On modern Linux, PID 1 is systemd. The kernel init= parameter can choose a different init, but doing so forfeits the entire userspace — every distribution assumes systemd.

Unit types

systemd manages the system through “units”. Each unit describes a resource: a service, a mount point, a socket, a timer, a device.

Unit type	Suffix	Purpose
Service	`.service`	A daemon process
Socket	`.socket`	A listening socket that activates a service on connection
Mount	`.mount`	A filesystem mount point
Automount	`.automount`	An on-demand mount
Swap	`.swap`	A swap device
Path	`.path`	A file-system path monitored for changes
Timer	`.timer`	A timer that activates a service at a time or interval
Target	`.target`	A grouping of units (like a runlevel)
Device	`.device`	A kernel-recognised device
Scope	`.scope`	A group of externally-created processes
Slice	`.slice`	A cgroup hierarchy node

Read-only / Safesystemctl list-units— systemctl list-units shows every unit, its load state (loaded/not-found), active state (active/inactive/failed), sub-state (running/dead/exited), and a one-line description. --type filters by type; --state filters by active state.

$ systemctl list-units --type=service --state=running | head

UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
accounts-daemon.service      loaded active running Accounts Service
chrony.service                loaded active running chrony, an NTP client/server
cron.service                  loaded active running Regular background program processing daemon
dbus.service                  loaded active running D-Bus System Message Bus
...

Illustrative output

Unit locations

Unit files live in three directories:

Path	Vendor	Override
`/usr/lib/systemd/system/`	Distribution packages	DO NOT EDIT — overwritten by package updates
/etc/systemd/system/	Local admin	Use for host-specific overrides
`/run/systemd/transient/`	Runtime	Created by `systemd-run`; ephemeral

A unit can be replaced by a same-named file in a higher-priority directory. /etc/systemd/system overrides /usr/lib/systemd/system.

Read-only / SafeFragmentPath— FragmentPath tells you exactly which file systemd is reading for this unit. If a /etc override is in place, the path is the override. If multiple files contribute (a vendor file plus drop-ins), DropInPaths lists the drop-ins.

$ systemctl show sshd.service -p FragmentPath

FragmentPath=/usr/lib/systemd/system/sshd.service

Illustrative output

Dependencies

Units declare dependencies on each other through directives in their [Unit] section:

Directive	Effect on start	Effect on stop
`Requires=`	Start the dependency; if it fails and `After=` names it, this unit does not start	Upwards, not downwards. If the DEPENDENCY is explicitly stopped or restarted, this unit is stopped or restarted too. Stopping this unit does not stop the dependency
`Wants=`	Start the dependency as a soft preference	(no effect)
`Requisite=`	Like Requires, but the dependency must already be active	(no effect)
`BindsTo=`	Like Requires, but stronger — if the dependency is stopped, this unit is also stopped	Stops together
`PartOf=`	(no effect on start)	When the LISTED unit is stopped or restarted, this unit is stopped/restarted too. One-way: changes to this unit do not affect the listed unit
`Conflicts=`	Cannot be active at the same time	(no effect)
`Before=`	This unit is ordered before the named unit	(no effect)
`After=`	This unit is ordered after the named unit	(no effect)

PartOf= propagates downwards, not upwards

PartOf= is the directive people most often wire backwards. Read it as “this unit is part of that one”. Put PartOf=myapp.target in worker-1.service and the propagation runs from the target to the worker:

systemctl stop myapp.target stops worker-1.service too.
systemctl restart myapp.target restarts worker-1.service too.
systemctl restart worker-1.service does nothing to the target or to the other workers.

The reverse reading - “restarting this unit restarts the listed one” - is wrong, and it fails in both directions at once. A team that believes it will run systemctl restart worker-1 expecting to cycle the group, and nothing propagates. The same team will run systemctl stop myapp.target during a change window believing the workers are unaffected, and every worker stops. man 5 systemd.unit states it plainly: “When systemd stops or restarts the units listed here, the action is propagated to this unit.”

Verify the direction rather than trusting the memory of it:

# What does myapp.target pull down with it?
systemctl list-dependencies --reverse myapp.target

# What does this unit actually declare?
systemctl show worker-1.service -p PartOf -p ConsistsOf

ConsistsOf= is the automatic inverse systemd creates on the target. It cannot be set in a unit file; seeing it on the target confirms the PartOf= was written on the right side.

Read-only / Safelist-dependencies— systemctl list-dependencies shows the dependency tree of a unit. sshd.service depends on network.target (which in turn depends on NetworkManager.service and network-online.target) and sysinit.target (which depends on the mount units and early services).

$ systemctl list-dependencies sshd.service

sshd.service
● ├─system.slice
● ├─-.mount
● ├─network.target
● │ ├─NetworkManager.service
● │ └─network-online.target
● └─sysinit.target
●   ├─ apparmor.service
●   ├─ dev-hugepages.mount
●   ...

Illustrative output

The transaction model

systemd does not start services one at a time. Instead, on every state change (boot, runlevel change, manual start), it:

Builds the full dependency graph.
Computes the transaction: a list of jobs (start, stop, restart) to bring the system to the desired state.
Verifies the transaction is consistent — no cycles, no missing dependencies.
Applies the jobs in parallel where dependencies allow.

The transaction model is what makes systemd fast and reliable. A service that depends on the network will not start until the network is up; a service that conflicts with another cannot be in the running set; a typo in a unit file is detected before any job runs.

The cost: the dependency graph must be correct. A cycle in dependencies causes the transaction to fail. Adding a new service requires thinking about what it depends on and what depends on it.

Targets

Targets group units that should reach a particular state together. The classic runlevels are targets:

Runlevel	Target	Purpose
0	`poweroff.target`	Halt
1	`rescue.target`	Single-user mode
3	`multi-user.target`	Multi-user, no GUI
5	`graphical.target`	Multi-user, GUI
6	`reboot.target`	Reboot

The default.target is what the system boots into by default. It is usually a symlink to graphical.target or multi-user.target.

Read-only / Safedefault target— systemctl get-default reads the default.target symlink. multi-user.target is the standard non-GUI target. Change with systemctl set-default graphical.target.

$ systemctl get-default; ls -l /etc/systemd/system/default.target

multi-user.target
lrwxrwxrwx 1 root root 36 Aug  9 11:11 /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target

Illustrative output

Production discipline

Never edit /usr/lib/systemd/system/* — package updates overwrite it.
Edit /etc/systemd/system/* for host-specific overrides.
Use drop-ins (/etc/systemd/system/<unit>.d/override.conf) for partial overrides; the diff against the vendor file is clearer than a full replacement.
After every edit, run systemctl daemon-reload to make systemd re-read units.
After every enable/disable, verify with systemctl is-enabled <unit>.

Why PID 1 matters

Unit types

Unit locations

Dependencies

Targets

Production discipline

Knowledge check