Isolating a systemd target switches the running system into a different operating state without waiting for a reboot. That is useful when a desktop needs to drop to a text-only maintenance session, when a recovery target must be reached immediately, or when a temporary target change is safer than rewriting the next boot mode.
The systemctl isolate command starts the requested target and the units it depends on, then stops units that are not part of that target unless they are marked IgnoreOnIsolate=yes. Only units that allow isolation can be used this way, which is why built-in runlevel-style targets such as multi-user.target, graphical.target, rescue.target, and emergency.target work while ordinary services do not.
Examples below use an Ubuntu 24.04 desktop host that starts in graphical.target and switches temporarily to multi-user.target, so the verification step checks gdm.service as the display manager. Replace that unit with sddm.service, lightdm.service, or the local display-manager service on other desktops, and prefer console or out-of-band access before isolating to rescue.target or emergency.target because the current graphical session, SSH session, or terminal may be stopped immediately.
Steps to isolate a systemd target:
- Open a terminal on the host that runs systemd.
Use a local console, hypervisor console, IPMI, or another recovery path when the current session could disappear. Current upstream systemctl behavior warns that isolate immediately stops processes that are not enabled in the new target, which can include the graphical environment or the terminal that launched the command.
- List the common built-in targets and decide which one the running system should reach.
$ systemctl list-unit-files --type=target --no-pager | grep -E '^(UNIT FILE|graphical.target|multi-user.target|rescue.target|emergency.target)' UNIT FILE STATE PRESET emergency.target static - graphical.target static - multi-user.target static - rescue.target static -
For routine runtime switches, multi-user.target is the usual non-graphical state and graphical.target adds the display manager on top of it. rescue.target and emergency.target are recovery targets and are usually meant for troubleshooting, not normal interactive work.
- Check the current state of the targets involved before switching away from them.
$ systemctl is-active graphical.target multi-user.target rescue.target emergency.target active active inactive inactive
On graphical systems, graphical.target usually pulls in multi-user.target, so both can be active at the same time. Only targets that ship with AllowIsolate=yes can be used with systemctl isolate, and the common built-in targets above do.
- Isolate the target that the current session should enter.
$ sudo systemctl isolate multi-user.target
Replace multi-user.target with the real target name chosen in the previous step. Isolating the target that is already active is effectively a no-op.
Switching from graphical.target to multi-user.target stops the display manager and closes the local desktop session. Isolating rescue.target or emergency.target is more disruptive and can stop network access or other services that the current shell depends on.
- Verify that the new target is active and that target-specific services from the previous state are no longer running.
$ systemctl is-active graphical.target multi-user.target gdm.service inactive active inactive
On this Ubuntu 24.04 example, gdm.service is the graphical login manager, so it becomes inactive after the switch. On other desktops, check the local display-manager unit such as sddm.service or lightdm.service instead.
The remaining active target list should still include dependencies such as basic.target, local-fs.target, and network.target because the isolated target still depends on them, and systemd also keeps units marked IgnoreOnIsolate=yes.
- Isolate back to the graphical target when the desktop session should return.
$ sudo systemctl isolate graphical.target $ systemctl is-active graphical.target multi-user.target gdm.service active active active
Use the target that represents the state the host should re-enter. On a headless server, the restore action may be unnecessary because multi-user.target is often already the normal runtime target.
systemctl isolate changes the current runtime target only. Use How to set the default boot target in systemd when later boots should land in a different target.
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.
