Boot Targets vs Runlevels

SysV init used numbered runlevels (0-6) to define what state the system is in. systemd replaces these with named targets that are more descriptive and flexible. Both solve the same problem: defining which services run at any given system state.

SysV Runlevels

RunlevelMeaning
0Halt — shutdown the system
1Single-user mode — root only, no networking, for recovery
2Multi-user without networking (Debian)
3Multi-user with networking, text mode (standard server)
4Unused (user-defined)
5Multi-user with networking + graphical desktop
6Reboot

systemd Targets

systemd TargetSysV EquivalentWhat it does
poweroff.targetRunlevel 0Shutdown
rescue.targetRunlevel 1Single-user rescue shell (root password required)
multi-user.targetRunlevel 3Multi-user text mode (standard servers)
graphical.targetRunlevel 5Multi-user + graphical desktop
reboot.targetRunlevel 6Reboot
emergency.targetN/AMinimal shell — even more stripped than rescue

Changing Targets

# Check current default target systemctl get-default # Change default target sudo systemctl set-default multi-user.target # boot to text mode sudo systemctl set-default graphical.target # boot to desktop # Switch target right now (without rebooting) sudo systemctl isolate multi-user.target

Rescue Mode and Emergency Mode

What's the difference between rescue.target and emergency.target? rescue.target: mounts all filesystems, starts basic services, gives you a root shell. More functional, good for most recovery tasks.

emergency.target: mounts only the root filesystem (read-only), starts almost nothing. For situations where rescue mode itself won't boot.
# Boot into rescue mode (two methods): # Method 1: Append to GRUB kernel line (press 'e' at GRUB menu) linux /boot/vmlinuz-... root=UUID=... ro systemd.unit=rescue.target # Method 2: After booting sudo systemctl rescue # Emergency mode (even more minimal) sudo systemctl emergency
# After fixing issues in rescue mode, continue normal boot: sudo systemctl default # switch to default.target

How Targets Pull in Services

How does systemd know which services belong to multi-user.target? Through symlinks in /etc/systemd/system/multi-user.target.wants/. When you run systemctl enable nginx, it creates a symlink there. At boot, systemd reads the .wants/ directory and starts everything linked from it.
ls /etc/systemd/system/multi-user.target.wants/ # nginx.service -> /lib/systemd/system/nginx.service # ssh.service -> /lib/systemd/system/ssh.service # ...

Frequently Asked Questions

What will I learn here?

This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.

How should I use this page?

Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.

What should I read next?

Use the navigation below to continue to the next lesson or explore related topics.