Skip to content

Targets & Runlevels

Systemd introduced the concept of targets as a modern replacement for the traditional init system's runlevels. While runlevels were numeric (0–6) and rigidly defined, systemd targets are named, hierarchical, and flexible, enabling more granular control over system states. This section explores how systemd targets function, how they differ from legacy runlevels, and their role in managing system behavior.

Understanding Systemd Targets

Systemd targets are analogous to runlevels but offer greater flexibility. Each target represents a predefined set of services and dependencies that define a system state. Common targets include:

  • multi-user.target (equivalent to runlevel 3): Minimal multi-user mode without a graphical interface.
  • graphical.target (equivalent to runlevel 5): Full graphical desktop environment.
  • rescue.target: A minimal state for troubleshooting, similar to runlevel 1.
  • emergency.target: A bare-bones state for critical recovery, akin to runlevel 0.

Unlike runlevels, targets can have dependencies on other units (e.g., services, sockets), allowing systemd to automatically enable or disable services when switching states. This ensures consistency and reduces manual configuration.

Traditional Runlevels vs. Systemd Targets

Feature Traditional Runlevels (init) Systemd Targets
Representation Numeric (0–6) Human-readable names
State Definition Static, predefined Dynamic, with dependencies
Service Management Manual switching (e.g., telinit 3) Automated via systemctl isolate
Default State /etc/inittab defines default systemctl get-default determines
Customization Limited Fully customizable

For example, switching to runlevel 3 in init required executing telinit 3, while systemd uses systemctl isolate multi-user.target to achieve the same result. The latter approach ensures services are properly enabled or disabled based on the target's dependencies.

Managing Systemd Targets

Switching Between Targets

Use systemctl isolate <target> to transition the system to a specific target. For example: 

sudo systemctl isolate graphical.target
This starts the graphical interface and stops services not required for that state.

Checking the Default Target

systemctl get-default
Output might show graphical.target or multi-user.target, depending on the system's configuration.

Setting a New Default Target

sudo systemctl set-default multi-user.target
This changes the system's default boot state to multi-user mode.

Listing Available Targets

systemctl list-units --type=target
This displays all predefined targets and their current status.

Custom Targets and Use Cases

Systemd allows creating custom targets for specialized scenarios. For instance, a maintenance target could be defined to disable non-essential services: 

sudo systemctl enable maintenance.target
sudo systemctl isolate maintenance.target
Custom targets are useful for temporary states like backup operations or security audits.

Key takeaways

  • Targets replace runlevels: They offer descriptive names and dynamic dependency management.
  • Automation: Switching targets automatically enables/disables services based on dependencies.
  • Flexibility: Custom targets enable tailored system states for specific use cases.
  • Commands: Use systemctl isolate, get-default, and set-default to manage targets.
  • Modern approach: Targets simplify system state transitions compared to the rigid, numeric runlevel model.