How to Perform Userspace-Only Soft Reboots in Ubuntu Using systemctl soft-reboot

In high-availability enterprise environments, server reboots often incur noticeable downtime. A traditional hardware restart requires traversing UEFI/BIOS POST initialization, PCI device discovery, IPMI handshakes, and Linux kernel initialization—a process that frequently takes several minutes on enterprise server hardware. Even modern kernel execution (kexec) requires reloading driver subsystems. Beginning with systemd version 254 (standardized in Ubuntu 24.04 LTS Noble Numbat), systemd introduces soft-reboot (systemctl soft-reboot). This mechanism tears down and restarts the entire userspace filesystem and service hierarchy while keeping the Linux kernel running continuously without resetting physical hardware.

Architecture of systemd Userspace Soft Reboots

Unlike a standard reboot (which invokes reboot(2)) or kexec (which boots a secondary kernel image), a userspace soft-reboot isolates system restarts strictly to userspace processes:

• Kernel Persistence: The running Linux kernel, active device drivers, network interfaces, and in-memory page tables remain entirely intact. Physical network link states and PCIe endpoints experience zero physical link flaps.
• Userspace Teardown: Systemd unmounts non-root filesystems, terminates all background daemons and user sessions, and transitions into soft-reboot.target.
• Root Filesystem Pivot: Systemd pivots back into a fresh root filesystem (or re-executes against the existing updated root volume), reloading system configuration, updated glibc binaries, and newly upgraded system packages without a power cycle.

Prerequisites and Verifying systemd Version in Ubuntu

Userspace soft-reboot requires systemd v254 or later. In Ubuntu 24.04 LTS, check the installed systemd version in the terminal:

systemd --version

Ensure that the output indicates version 254 or higher. Additionally, confirm that your target units are compatible with soft reboots by verifying the presence of soft-reboot.target:

systemctl list-unit-files soft-reboot.target

Preserving Runtime File Descriptors and Storage Across Soft Reboots

One of the most powerful features of systemctl soft-reboot is the ability to maintain state across the restart. Files located within /run/nextroot/ or specifically marked temporary filesystems can persist across userspace transitions.

Furthermore, systemd services utilizing FileDescriptorStorePreserve=yes can hold listening sockets (such as open HTTP or database connection ports) in systemd’s file descriptor store, allowing daemons to restart without dropping established TCP connections.

Executing a Userspace Soft Reboot

Before executing a soft reboot on a production system, ensure all critical data transactions have completed. To initiate the soft restart, execute:

sudo systemctl soft-reboot

The system will instantly begin userspace teardown:

1. Active userspace services receive SIGTERM followed by SIGKILL.
2. Filesystem sync buffers are flushed to persistent storage.
3. The system re-executes systemd as PID 1 against the root partition.
4. Startup target units (such as default.target and multi-user.target) reinitialize within seconds.

On modern NVMe systems, the entire soft-reboot sequence typically completes in 2 to 5 seconds—compared to 3 to 10 minutes for an enterprise hardware reboot.

Verifying System Uptime and Kernel Continuity

Once you reconnect to the system, verify that the userspace restarted while the underlying kernel maintained its continuous runtime:

# Check kernel uptime (remains uninterrupted)
uptime

# Inspect the systemd journal for the soft-reboot transition
journalctl -b 0 -u systemd-journald

The uptime command will display cumulative system running time spanning prior to the soft-reboot, whereas journalctl confirms that PID 1 reloaded its execution environment without a kernel initialization log.

Best Practices and Operational Limitations

While systemctl soft-reboot is ideal for applying userspace software updates, glibc upgrades, and daemon reconfigurations, administrators must understand when a full kernel reboot remains necessary:

• Kernel Upgrades: If an apt upgrade installs a new Linux kernel image (e.g., updating from 6.8.0-31 to 6.8.0-35), a soft-reboot will not load the new kernel. Kernel updates require either a traditional reboot or systemctl kexec.
• Firmware / Microcode Patches: Motherboard UEFI updates, CPU microcode changes, and GPU firmware upgrades require hardware-level power cycles.
• Root Filesystem Replacements (OS Image Pivots): For immutable or containerised operating system deployments, systemd soft-reboot allows atomic operating system upgrades by pointing /run/nextroot/ to a freshly deployed OS tree.

By incorporating systemctl soft-reboot into Ubuntu server administration workflows, system operators can drastically compress maintenance windows, ensuring near-instantaneous service recovery following software stack upgrades.