systemd soft-reboot restarts userspace while the kernel keeps running

Restarting userspace without rebooting the machine

A practical operator guide published on dev.to walks through systemctl soft-reboot, a systemd capability that tears down and rebuilds the entire userspace of a Linux host while the kernel keeps running. The scenario it targets is familiar: a userspace package update has changed libraries and daemons, the machine is technically up, but much of the stack is still running the previous generation. The reflex is a full reboot, which pays for firmware initialization, the bootloader, kernel bring-up and the initrd even though the kernel itself did not change. Soft-reboot shrinks the outage to what the article describes as a service-manager re-execution plus a new boot transaction.

The command arrived in systemd 254, and the author notes that current-generation distributions ship newer releases — Debian 13, for instance, carries 257.x — so the feature is broadly available on up-to-date systems.

What actually happens

According to the man pages quoted in the piece, systemctl soft-reboot isolates toward soft-reboot.target, which requires systemd-soft-reboot.service. Near the end of the transaction, surviving processes receive SIGTERM and then SIGKILL, with no polite wait on the final kill wave. PID 1 then re-executes the service manager and enqueues a fresh boot transaction, similar to the userspace phase of an ordinary reboot.

Deliberately skipped are the second shutdown phase handled by systemd-shutdown, the return to the initrd context, the hardware reboot, firmware and bootloader initialization, and kernel and initrd bring-up. Kernel-held state — routes, some device setup, sysctl knobs — carries over untouched.

A fail-safe is built in: the target carries a 30-minute job timeout that escalates to soft-reboot-force, so a wedged soft path forces its way through rather than hanging in a half-shut state forever.

One sharp edge the guide stresses: never start systemd-soft-reboot.service by hand. Trigger the operation through systemctl soft-reboot, which behaves like starting the target with --job-mode=replace-irreversibly --no-block. The command is asynchronous and returns once the job is enqueued, and it accepts --when= scheduling and cancellation the same way other power commands do.

Three depths of reboot

The article frames the tooling as three tiers:

• Soft-reboot: userspace only; the kernel stays and firmware and bootloader are skipped. Suited to userspace refreshes and A/B root flips.
• kexec: a new kernel with the firmware path mostly skipped, for kernel updates without a full POST.
• Full reboot: the complete cycle, for firmware, kernel, initrd or device topology changes.

The contract matters: soft-reboot is not simply a faster reboot. Kernel state is continuous while userspace state is not, unless survivors are deliberately pinned. ArchWiki, cited in the guide, adds that unlocked dm-crypt devices can remain attached across a soft-reboot, and warns against treating soft-reboot as sufficient after updates that changed the kernel and initramfs — those still need kexec or a full reboot.

Verification and boundaries

Because an interactive SSH session drops the same way it would during a reboot, plan for console or out-of-band access. The suggested before-and-after checks: uname -r must be unchanged afterward, since a changed release means you did not actually soft-reboot; UserspaceTimestamp should advance while FirmwareTimestamp, LoaderTimestamp and KernelTimestamp stay continuous; and systemctl --failed plus a fresh journalctl -b reveal the state of the new userspace cycle. The author cautions not to assume every boot-counter UI agrees, since boot_id behaves differently across these paths.

Another boundary: executables under /usr/lib/systemd/system-shutdown/ never run, because systemd-shutdown is not invoked. Anything critical — disk flush logic, LED scripts — belongs in normal unit ExecStop= or ExecStopPost= handlers instead.

Switching roots with /run/nextroot/

The feature's power play is image-based root handoff. If /run/nextroot/ exists as a directory, mount point, or symlink to either, soft-reboot switches the root filesystem to it, and systemd automatically promotes a non-mount path into a mount point when needed. That enables A/B-style updates where kernel-held state such as network routes, unlocked LUKS mappings and non-reset sysctls survives the transition while userspace boots into the new image. The author demonstrates the mechanism on a disposable VM with a minimal teaching root, stressing that a real next root needs a bootable userspace: /usr, /etc, a /var skeleton, device node or devtmpfs policy, and a systemd binary.

Why it matters

Downtime is the expensive part of a maintenance window, and most of a full reboot's cost — firmware POST, bootloader, kernel and initrd bring-up — is wasted work when only userspace changed. Soft-reboot reduces the outage to a service-manager re-execution and a new boot transaction, skipping all of that hardware-level overhead. For image-based and A/B deployments, /run/nextroot/ offers userspace swaps with kernel state intact. The limits are just as practical: kernel and initramfs updates still require kexec or a full cycle, shutdown hooks are silently skipped, and kernel-level settings are never reset. It is a precise tool for userspace-shaped maintenance, not a universal replacement for rebooting.