Understanding Linux Runlevels And Targets With systemd

Linux boot behaviour can seem unfamiliar when moving from older SysV init systems to systemd. The traditional runlevel model used numbers to describe operating states, while modern distributions use named targets with dependency relationships.

This distinction matters on RHEL, CentOS Stream and Fedora, where administrators commonly use systemctl to start services, change boot modes and troubleshoot failed launches. Understanding both models makes older documentation easier to follow and current commands safer to use.

For Australian administrators, this knowledge is useful when maintaining cloud instances in Sydney or Melbourne regions, supporting small business servers, or scheduling maintenance around AEST and AEDT. A clear recovery method also reduces disruption when customers rely on services outside standard office hours.

Systemd targets are logical groups of units rather than simple numeric levels. Once their purpose is clear, tasks such as entering rescue mode, selecting a graphical boot environment or creating a controlled maintenance state become predictable.

Runlevels Before systemd

SysV init traditionally used runlevels from 0 to 6. Runlevel 0 halted the machine, 1 provided single-user recovery, 2 through 4 varied by distribution, 5 usually started a graphical environment, and 6 rebooted the system. Linux vendors did not always assign identical meanings to every number.

Administrators changed levels with commands such as init 3 or telinit 1. Startup scripts were placed in directories such as /etc/rc.d/rc3.d/, where symbolic links controlled service order. This model worked, but it offered limited dependency handling and could make parallel startup difficult to manage.

Targets Replace Runlevels

Systemd uses targets, which are units ending in .target. Common examples include multi-user.target for a non-graphical, networked server and graphical.target for a desktop environment. rescue.target supplies a more limited recovery shell, while emergency.target starts the smallest possible environment.

The usual comparisons are runlevel 3 to multi-user.target, runlevel 5 to graphical.target, runlevel 1 to rescue.target, runlevel 0 to poweroff.target, and runlevel 6 to reboot.target. These are practical equivalents rather than perfect translations, because systemd targets can express several relationships at once.

Inspect The Current Boot State

Use systemctl get-default to see the target selected for normal boot. A server will commonly return multi-user.target, while a workstation may use graphical.target. Change the default with sudo systemctl set-default multi-user.target; this creates or updates the default target link.

To see the active state, run systemctl list-units --type=target or systemctl status graphical.target. The command systemctl list-dependencies multi-user.target reveals the units pulled into that target. These checks are especially helpful on a VPS hosted in Sydney, where a remote administrator should verify the intended boot mode before restarting.

Switch Targets Safely

A temporary change uses sudo systemctl isolate rescue.target. Isolation stops units that are not required by the selected target, so it should be used carefully on production systems. Moving to multi-user.target can stop a display manager, while entering rescue mode may interrupt application services and remote sessions.

For a routine reboot, use sudo systemctl reboot; for a controlled shutdown, use sudo systemctl poweroff. When a system has failed services, systemctl --failed provides a quick summary, and journalctl -b displays messages from the current boot. Always confirm console or out-of-band access before isolating a remote machine.

Create A Maintenance Target

Custom targets are useful when a server needs a defined maintenance state. An administrator might create a target that brings up networking, monitoring and a backup agent while leaving web and application services stopped. Custom unit files normally belong in /etc/systemd/system/.

A target can declare relationships through [Unit] directives such as Requires=, Wants= and After=. Enable it with systemctl enable maintenance.target if it should be selected at boot, or start it temporarily with systemctl isolate maintenance.target. This approach is cleaner than manually stopping a long list of services.

Connect Targets With Services

A target does not contain commands in the traditional script sense. It gathers other units through dependencies. For example, enabling nginx.service may create a relationship with the default target, causing Nginx to start during normal boot. Use systemctl is-enabled nginx and systemctl status nginx to check that relationship.

When preparing a web server, compare target behaviour with the distribution’s service configuration. A practical companion is this guide to Apache virtual hosts, which helps place web configuration work in the wider context of RHEL administration. For Australian businesses handling customer records, service logs should also be managed consistently with obligations under the Privacy Act 1988; review the site’s privacy policy when documenting data practices.

Use A Reliable Administration Routine

Keep target changes separate from application changes. If a service fails after boot, inspect systemctl status service-name, review journalctl -u service-name, and check dependencies before altering the default target. This avoids masking a faulty service behind a different boot mode.

Monitoring dashboards can show whether expected units are active, much like a client-facing dashboard can present operational information. Teams working on web administration may also find this dashboard widget guide useful for understanding how status information is presented outside the shell.

Keep Recovery Steps Close

A concise command reference is valuable during an outage, especially when support staff work across Australian time zones or maintain systems during early-morning maintenance windows.

• systemctl get-default checks the boot target.
• systemctl list-dependencies TARGET displays its units.
• systemctl isolate TARGET changes the current state.
• journalctl -b reviews the current boot.

Before changing a production host, record its present configuration and confirm access through SSH, a serial console or a provider console.

• Test recovery access before isolation.
• Confirm which services the target will stop.
• Use systemctl --failed after boot.
• Record changes in the maintenance log.

On a test Fedora or RHEL machine, begin with systemctl get-default, inspect multi-user.target, and then review its dependency list. That single practical exercise provides a safe first step towards managing runlevels and systemd targets confidently.