Restart Userspace Only with systemctl soft-reboot

Systemctl soft-reboot restarts userspace only, skipping firmware and kernel startup, so it lands much faster than a real reboot. You will learn to request one safely, check what it did, and decide whether a full reboot is still needed. On the installed system, the relevant package is systemd 255.4-1ubuntu8.17.

• Allow: about ten minutes for a planned test, plus the time your services need to come back up.
• You need: an interactive shell, a way to reconnect to the host, and root or sudo access.

1. Check the installed contract

Confirm the manager version and that this system exposes the soft-reboot verb. These are ordinary, read-only commands.

$ systemctl --version
systemd 255 (255.4-1ubuntu8.17)
$ systemctl --help | grep soft-reboot
  soft-reboot                         Shut down and reboot userspace

The exact package suffix and help formatting vary. What matters is that this host is systemd 255 and soft-reboot is listed.

2. Check what a soft reboot will not reset

A soft reboot earns its speed by skipping the later shutdown phase, the return to the initrd, the hardware reboot, firmware and boot-loader initialisation, and kernel and initrd initialisation entirely.

That speed has a boundary. The running kernel stays in memory, so a kernel update is not complete after this operation. Kernel settings, including values under /proc/sys/ and /sys/, also stay in place. If your change needs a new kernel, new kernel command-line settings, new firmware state, or a reset of kernel settings, schedule a normal reboot instead.

3. Check for the next root filesystem

During a soft reboot, systemd checks /run/nextroot/. If it exists as a directory, mount point or symlink to one, systemd switches the filesystem root to it before re-executing the service manager, which gives you a mechanism for handing a prepared userspace root to the next cycle.

Only inspect that path if your update process deliberately prepares it. This command is read-only and does not create or mount anything.

$ ls -ld /run/nextroot 2>/dev/null || printf '%s\n' '/run/nextroot is not present'

4. Identify services that must be handled carefully

The soft-reboot service sends SIGTERM to processes still running, then follows with SIGKILL without waiting for every process to exit. Expect ordinary services to stop and start again; a client connection, shell session or application request can be interrupted even though the machine does not power-cycle.

Before the change, check the units most likely to affect your access and workload.

$ systemctl --no-pager --type=service --state=running
$ systemctl is-active ssh.service
active

The service name may be sshd.service on another distribution: confirm the actual unit name with the first command. Keep a second access path available, since a successful soft reboot can still terminate the network service briefly.

Some units can deliberately survive the transition, but this is an advanced design, not a default. Surviving it needs careful ordering and settings such as DefaultDependencies=no, IgnoreOnIsolate=yes and SurviveFinalKillSignal=yes, along with conflicts for normal shutdown and reboot targets. The systemd documentation warns that surviving processes can mix old and new userspace resources, pin old filesystems and leave an update incomplete. Prefer restarting services cleanly unless there is a strong, tested reason to preserve them.

5. Request the soft reboot

$ sudo systemctl soft-reboot

sudo may ask for your password, and the command normally does not return to a usable prompt on the same session. Do not add --force or improvise a direct unit start. If the operation is not approved, press Ctrl-C before submitting the command. After submission, reconnect only once the host's normal access path is available again.

6. Verify the new userspace cycle

After reconnecting, verify the service manager and the services that matter to the change.

$ systemctl is-system-running
running
$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
$ systemctl is-active ssh.service
active

A system can report degraded rather than running if one or more units failed: treat that as a prompt to investigate, not as proof the soft reboot itself failed. Use systemctl --failed, then inspect a specific unit with systemctl status UNIT.service and journalctl -u UNIT.service -b. The boot journal identifier changes across manager cycles, so start with the current boot selected by default.

Recheck the application or update that motivated the operation, and confirm its userspace version, but do not conclude a kernel update has taken effect merely because systemd is running again.

$ uname -r
$ systemctl --version | head -1

7. Choose recovery when the result is not clean

If an important service failed, restart it only after reading its status and recent journal. For a unit called example.service:

$ systemctl status example.service --no-pager
$ journalctl -u example.service -b --no-pager -n 80
$ sudo systemctl restart example.service

The restart changes service state and requires elevated privileges. If the new userspace root turned out wrong, do not repeatedly reboot into it: return to the update system's documented rollback, or use console access to restore the previous root before another transition.

When the missing change is kernel-level, the recovery is a planned full reboot, not another soft reboot. A normal sudo systemctl reboot passes through the shutdown and boot path this operation intentionally skips. Schedule it with the same access and service checks, and keep the soft-reboot result in your change record.