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.
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.
$ 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.
$ 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.
$ 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.
$ 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.
$ 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.