How to set the default boot target in systemd

Changing the default boot target in systemd controls which group of units the system tries to reach after each normal boot. This lets you move a host between a text-mode multi-user environment and a graphical login without editing the boot loader for every restart, which is useful when repurposing a desktop as a server or restoring a GUI after maintenance.

At boot, systemd resolves default.target and starts the units pulled in by that target. Commands such as systemctl get-default and systemctl set-default read or change that boot default, typically through the /etc/systemd/system/default.target symlink, while targets such as multi-user.target and graphical.target describe the service set the system should reach.

Changing the default target affects the next boot rather than the current session, so plan the change around a reboot window if the host provides remote access or a local desktop. Recovery targets such as rescue.target and emergency.target are meant for troubleshooting rather than routine startup, and some distributions resolve the new symlink under /usr/lib/systemd/system while others use /lib/systemd/system.

Steps to set the default boot target in systemd:

Open a terminal session with an account that can use sudo.
Check the current default target before changing it.
```
$ systemctl get-default
graphical.target
```
Server installs often already report multi-user.target, while desktop-oriented systems commonly report graphical.target.

Related: How to check the default boot target in systemd
List the available target unit files if you need to confirm the target name before changing it.
```
$ systemctl list-unit-files --type=target --no-pager
UNIT FILE                     STATE    PRESET
emergency.target              static   -
graphical.target              static   -
multi-user.target             static   -
rescue.target                 static   -
```
For normal day-to-day boots, multi-user.target is the usual text-mode server target and graphical.target adds the display manager on top of it. rescue.target and emergency.target are recovery targets and are usually not suitable permanent defaults.

Related: How to list systemd targets
Set the target that the system should use on future boots.
```
$ sudo systemctl set-default multi-user.target
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.
```
Replace multi-user.target with graphical.target when the system should boot to a graphical login instead.

If another default target was already set explicitly, systemctl may first print a line showing that the existing /etc/systemd/system/default.target symlink was removed before the new one is created.
Verify that systemd now reports the new default target.
```
$ systemctl get-default
multi-user.target
```
Confirm that the default.target symlink resolves to the expected target unit file.
```
$ readlink -f /etc/systemd/system/default.target
/usr/lib/systemd/system/multi-user.target
```
On some distributions the resolved path ends under /lib/systemd/system instead, but the target filename should still match the value selected in the previous step.
Reboot the system when you are ready to start using the new boot target.
```
$ sudo systemctl reboot
```
Changing from graphical.target to multi-user.target removes the graphical login on the next boot. On remote hosts, confirm that SSH or another out-of-band access path is working before rebooting.
After the system comes back, confirm that the default target still matches the intended boot mode.
```
$ systemctl get-default
multi-user.target
```
For graphical.target, expect the display manager to return after the reboot. For multi-user.target, expect a text-mode boot with system services running but no graphical login.

If you need to change the current session immediately instead of waiting for a reboot, use sudo systemctl isolate default.target only when you understand which services and sessions the target switch will stop.

Related: How to isolate a systemd target

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.