Managing systemd Boot Targets on RHEL

Objective

This guide covers systemd boot target management on Red Hat Enterprise Linux. By the end, you will know how to:

• Understand what systemd targets are and how they replaced SysV runlevels
• Identify the currently active and default systemd targets
• Switch between targets on a running system using systemctl isolate
• Configure the persistent default boot target using systemctl set-default
• Understand the differences between multi-user.target, graphical.target, rescue.target, and emergency.target
• Verify that a configured default target is applied after a reboot
• Use systemd jobs and journal logs to troubleshoot target and boot issues
• Apply these skills to RHCSA exam tasks involving boot configuration

Understanding systemd targets gives you control over what state a Linux system enters when it boots and the ability to change that state while the system is running. This matters in production when you need to drop a server to a text-only state for maintenance, when you need to recover a system using rescue or emergency mode, and when you need to confirm that a server comes up in the right state after a reboot.

What Are systemd Targets

A systemd target is a logical group of units that defines a particular operating state of the system. When systemd reaches a target, it has started all the services, mounts, and other units that target depends on. Targets replaced the concept of SysV runlevels, but they are more flexible: a system can have multiple targets active simultaneously, and you can define custom targets for specific purposes.

systemd Target	SysV Equivalent	What Is Active	Typical Use
poweroff.target	Runlevel 0	Nothing: system is shutting down	Halt and power off
rescue.target	Runlevel 1	Minimal: root shell, local filesystems mounted	Single-user recovery and repair
emergency.target	N/A (more minimal than runlevel 1)	Absolute minimum: root shell, root filesystem read-only	Critical recovery when rescue.target fails
multi-user.target	Runlevel 3	Full multi-user text mode, all services, no GUI	Servers, headless systems, maintenance mode
graphical.target	Runlevel 5	Everything in multi-user.target plus graphical display manager	Desktop workstations, systems needing a GUI
reboot.target	Runlevel 6	Nothing: system is rebooting	Controlled reboot

The two targets you will work with most on RHEL servers are multi-user.target and graphical.target. Most production servers should run multi-user.target since they don't need a graphical desktop and the GUI just consumes resources.

Step 1: Inspect Active and Default Targets

# Check what the system's persistent default boot target is
systemctl get-default

# Sample output:
# graphical.target

# List all currently active targets
systemctl list-units --type=target

# List all targets (including inactive ones)
systemctl list-units --type=target --all

# Get detailed information about a specific target
systemctl cat multi-user.target
systemctl cat graphical.target

The get-default command reads the symlink at /etc/systemd/system/default.target, which points to whichever target systemd will activate on next boot.

# Confirm what default.target points to directly
ls -la /etc/systemd/system/default.target

# Sample output:
# lrwxrwxrwx. 1 root root 40 Jun 15 10:00 /etc/systemd/system/default.target
# -> /usr/lib/systemd/system/graphical.target

Step 2: Switch Between Targets on a Running System

The systemctl isolate command immediately switches the running system to a specified target. It starts all units the target requires and stops all units the target does not include. This happens without rebooting.

# Switch from graphical.target to multi-user.target (drops the GUI)
# Warning: this will terminate the graphical session if you are in one
systemctl isolate multi-user.target

# Switch back to graphical.target
systemctl isolate graphical.target

# Verify the current active target after switching
systemctl list-units --type=target | grep active

Important: systemctl isolate only changes the current running state. It does not change what happens at the next boot. The default target remains whatever systemctl get-default shows until you explicitly change it with set-default.

Step 3: Set the Persistent Default Boot Target

The systemctl set-default command changes which target the system enters when it boots. This creates or updates the symlink at /etc/systemd/system/default.target.

# Set the default target to multi-user (text mode, no GUI)
systemctl set-default multi-user.target

# Confirm the change
systemctl get-default

# Set the default target to graphical (GUI mode)
systemctl set-default graphical.target

# Confirm again
systemctl get-default

Verify that the symlink was updated correctly:

# Check the symlink directly
ls -la /etc/systemd/system/default.target

# After setting multi-user.target, it should point to:
# /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target

Step 4: Verify After a Reboot

The RHCSA exam verifies target configuration by rebooting the system. The default target must be correctly set for the task to score points.

# Set the default target (example: text mode for a server)
systemctl set-default multi-user.target

# Verify before rebooting
systemctl get-default

# Reboot to confirm the persistent change takes effect
reboot

# After reboot, verify the system came up in the expected target
systemctl get-default
systemctl list-units --type=target | grep active

rescue.target and emergency.target

These two targets exist for system recovery and have important differences from each other and from the normal operating targets.

Feature	rescue.target	emergency.target
Root filesystem	Mounted read-write	Mounted read-only
Other filesystems	Mounted (from /etc/fstab)	Not mounted
Network	Not started	Not started
Services	Minimal, enough to provide a rescue shell	Absolute minimum, just a root shell
Password required	Yes, root password required	Yes, root password required
When to use	System troubleshooting, fixing bad /etc/fstab entries, password recovery	When rescue.target itself fails to boot or filesystem repair is needed

You can enter rescue or emergency mode at boot by appending the target name to the kernel command line in GRUB:

# At the GRUB menu, press 'e' to edit the boot entry
# Find the line starting with 'linux' and append one of these:

# For rescue mode
systemd.unit=rescue.target

# For emergency mode
systemd.unit=emergency.target

# Press Ctrl+X to boot with the modified parameters

# You can also switch to rescue/emergency from a running system
# WARNING: This will drop you to a minimal environment immediately
# Do NOT run isolate to rescue or emergency on a production system
# without understanding the impact
systemctl isolate rescue.target

Rescue and emergency targets require the root password. If you have forgotten the root password, these targets are not the right tool: use the RHEL root password reset procedure via the rd.break kernel parameter instead.

Troubleshooting Boot and Target Issues

View systemd Jobs During Boot

# View active systemd jobs (useful during target transitions)
systemctl list-jobs

# View jobs that failed during the last boot
systemctl --failed

# View the status of all units (including failed ones)
systemctl list-units --state=failed

Check Journal Logs for Boot and Target Issues

# View logs from the current boot
journalctl -b

# View logs from the previous boot (useful when the current boot had issues)
journalctl -b -1

# View boot logs filtered to errors only
journalctl -b -p err

# View logs related to a specific service that failed during boot
journalctl -b -u servicename

# View logs showing the boot sequence in detail
journalctl -b --no-pager | grep -E "(Starting|Started|Failed|Reached target)"

# Check how long each service took to start
systemd-analyze blame

Analyze Boot Performance

# Show total boot time
systemd-analyze

# Show time spent in each boot phase
systemd-analyze time

# Show which services took longest to start
systemd-analyze blame

# Generate a visual SVG boot chart
systemd-analyze plot > boot-chart.svg

# Find critical chain of units that determined boot time
systemd-analyze critical-chain

Common Boot Target Problems

Problem	Likely Cause	How to Investigate
System boots to wrong target	default.target symlink points to wrong target	systemctl get-default and ls -la /etc/systemd/system/default.target
System hangs during boot	A service is failing or timing out before the target is reached	journalctl -b -p err and systemctl --failed
Target switch with isolate fails	Target is not configured as isolatable or a dependency is missing	systemctl cat targetname to check AllowIsolate=yes
Boot takes much longer than expected	A service is timing out before failing, or a dependency is slow	systemd-analyze blame to identify the slow service
graphical.target but no GUI appears	Display manager service (gdm, lightdm) failed	systemctl status gdm and journalctl -u gdm -b

Restoring the Original Default Target

# If you changed the default target and want to restore it
# Check the current default
systemctl get-default

# Restore to graphical.target (typical for workstations)
systemctl set-default graphical.target

# Restore to multi-user.target (typical for servers)
systemctl set-default multi-user.target

# Verify the restore
systemctl get-default
ls -la /etc/systemd/system/default.target

Quick Reference: Target Management Commands

Command	What It Does	Persists After Reboot?
systemctl get-default	Shows the configured default boot target	Read-only, no change
systemctl set-default TARGET	Changes the default boot target persistently	Yes
systemctl isolate TARGET	Switches the running system to a target immediately	No (runtime only)
systemctl list-units --type=target	Shows all currently active targets	Read-only, no change
systemctl list-units --type=target --all	Shows all targets including inactive ones	Read-only, no change
systemctl --failed	Shows units that failed during boot or target transition	Read-only, no change
journalctl -b	Shows all journal logs from the current boot	Read-only, no change
systemd-analyze blame	Shows how long each service took to start during boot	Read-only, no change

Boot Targets and the RHCSA Exam

systemd boot target management is a direct RHCSA exam objective. Exam tasks in this area typically require one or more of:

• Setting the default boot target to multi-user.target or graphical.target using systemctl set-default
• Verifying the current default target with systemctl get-default
• Switching the running system to a different target with systemctl isolate
• Confirming the default target is applied correctly after a reboot
• Using journalctl -b and systemctl --failed to identify boot problems

The most common exam mistakes in this topic:

• Using isolate instead of set-default. systemctl isolate multi-user.target changes the running state but not the default. After a reboot the system returns to whatever get-default showed. If the task says "configure the system to boot into", you need set-default, not isolate.
  • Most exam tasks require both: set the default and verify after a reboot
• Not verifying after rebooting. The exam environment reboots hosts to check persistent configuration. Always reboot in your practice environment and confirm the system came up in the expected target.
• Confusing rescue and emergency targets. Rescue mounts all filesystems from fstab with the root read-write. Emergency mounts only the root filesystem read-only. Know which one is more minimal and why that matters for recovery scenarios.

Practice This in a Real Environment

Boot target management is a topic where the commands are simple but the concepts only become clear when you have actually switched targets, watched services stop and start, set the default wrong, rebooted and seen the system come up in the wrong state, then fixed it. Reading about isolate vs set-default is not the same as doing both and seeing exactly what each one does.

LinuxCert.Guru has a dedicated hands-on lab for this: Manage System Boot Targets. It covers inspecting active targets, switching between targets with isolate, setting and verifying the persistent default, examining rescue and emergency targets, rebooting to confirm persistent changes, and using journal logs for troubleshooting, all on real RHEL hosts with auto-graded tasks.

Practice the Manage System Boot Targets lab at LinuxCert.Guru → https://linuxcert.guru/?name=rh134-manage-boot-targets

Conclusion

systemd targets give you precise control over what operating state a Linux system enters at boot and the ability to change that state at runtime without rebooting. The concepts are straightforward once the distinction between runtime changes and persistent configuration is clear:

• systemctl isolate changes the running state now, does not persist after reboot
• systemctl set-default changes what happens at next boot, does not affect the running state
• systemctl get-default shows the persistent default, not necessarily the current running state
• multi-user.target is text mode, suitable for servers and headless systems
• graphical.target adds the display manager on top of multi-user.target
• rescue.target is for single-user recovery with filesystems mounted
• emergency.target is the most minimal recovery environment with root filesystem read-only
• Always verify with a reboot: a correctly set default target that survives a reboot is what the RHCSA exam checks