systemd Targets and Boot Dependencies: From Runlevels to multi-user.target

May 17, 2026

Targets describe desired system states in systemd. Once you understand how targets and dependency directives work together, boot behavior becomes predictable instead of mysterious.

Table of Contents

This post maps classic runlevels to targets and explains dependency semantics you will use often.

Targets and States

• Targets and runlevels
• Inspect and change the default target
• Common operational targets

Dependency Semantics

• Dependency keywords that matter
• View dependency trees
• Use isolate carefully

Series Navigation

• Next in this series

Targets and runlevels

SysV runlevels grouped startup scripts into coarse execution modes. systemd targets are more flexible because they are units that can depend on other units and targets.

SysV runlevel     Rough systemd target mapping
---------------   --------------------------------
0                 poweroff.target
1                 rescue.target
3                 multi-user.target
5                 graphical.target
6                 reboot.target

The mapping is conceptual, not one-to-one compatibility, because systemd uses dependency graphs instead of fixed script sequences.

Inspect and change the default target

Use default.target to see what boot mode your system enters by default.

systemctl get-default
sudo systemctl set-default multi-user.target
sudo systemctl set-default graphical.target

set-default changes future boots and does not immediately switch the active mode.

Common operational targets

These targets appear frequently in operations:

• multi-user.target for non-graphical multi-user server mode
• graphical.target for full desktop environments
• rescue.target for minimal recovery shell with basic services
• emergency.target for the most minimal emergency environment
• network-online.target for services that must wait for connectivity

Dependency keywords that matter

These directives shape startup and shutdown behavior:

• Requires means the dependency is mandatory for the unit to run
• Wants means the dependency is preferred but not strictly required
• After and Before set ordering only and do not imply requirement
• Conflicts prevents units from running at the same time
• PartOf propagates stop and restart actions between related units

Minimal example:

[Unit]
Requires=network-online.target
After=network-online.target
PartOf=my-stack.target

Here, startup both requires and orders around network readiness.

View dependency trees

Dependency visualization is useful for understanding why services start late or fail when prerequisites are missing.

systemctl list-dependencies multi-user.target
systemctl list-dependencies --reverse network-online.target
systemd-analyze critical-chain

Use reverse dependencies to find what consumes a specific target.

Use isolate carefully

systemctl isolate switches to a target immediately and stops units not part of that target. This is powerful and potentially disruptive.

sudo systemctl isolate rescue.target

Safe usage guidance:

• Use isolation during controlled maintenance windows
• Ensure remote access safety before isolating on headless servers
• Prefer set-default for future behavior when immediate switch is unnecessary

Series navigation

Targets explain system state transitions, and the next step is observability through journald and journalctl.

Next in this series

Next, we cover systemd logging with journal queries, filtering techniques, and retention controls.

journald and journalctl: Logging the systemd Way