Systemd 255+ brings a significant shift in how reboots can be handled on Linux systems, introducing a soft-reboot feature that allows userspace to reboot into a new root filesystem while leaving the kernel running. This method reduces downtime and avoids the full hardware reset typically associated with traditional reboots, making it especially useful for rapid system updates or testing new environments. Understanding how to leverage this feature can streamline administrative tasks and minimize service interruptions.

Soft-Reboot Overview in Systemd 255+

Soft-rebooting, as implemented in systemd 255 and above, lets the system transition userspace to a new root (/run/nextroot/) without shutting down or restarting the kernel. This process is particularly valuable for scenarios such as:

  • Testing new root filesystems or system images without a full hardware reboot.
  • Applying critical updates that require userspace restart but not kernel replacement.
  • Reducing system downtime for services that can tolerate userspace restarts.

During a soft-reboot, systemd cleans up userspace processes, switches to the specified new root, and restarts system services, all while the kernel remains active. This approach is faster and less disruptive than a complete system reboot.

Initiating a Soft-Reboot with systemd

Step 1: Prepare the New Root Filesystem

Create and populate a directory—typically /run/nextroot/—with the new root filesystem you want the system to boot into. This directory should contain all necessary binaries, libraries, configuration files, and essential system directories. Make sure the structure matches what a root filesystem expects (/bin, /sbin, /etc, etc.).

It's crucial to verify file permissions and ownership, as improper setup can prevent the system from starting necessary services after the transition.

Step 2: Trigger the Soft-Reboot

Once /run/nextroot/ is ready, initiate a soft-reboot using the following command:

systemctl soft-reboot

Alternatively, if you issue a standard reboot command and /run/nextroot/ exists, systemd 255+ will automatically perform a soft-reboot into the new root:

systemctl reboot

Systemd detects the presence of /run/nextroot/ and switches userspace accordingly, bypassing a full hardware reboot.

Step 3: Monitor the Transition

After the command is issued, systemd will:

  • Terminate all userspace processes except those explicitly configured to survive (see below).
  • Switch the root to /run/nextroot/ and reinitialize userspace from this new environment.
  • Restart system services as defined in the new root’s /etc/systemd/system/ and related unit files.

Keep an eye on system logs and console output for any errors during the transition. If the new root is misconfigured or missing critical files, the system may fail to start essential services, potentially requiring manual intervention.

Configuring Services to Survive Soft-Reboot

By default, systemd sends SIGTERM and SIGKILL to all userspace processes when rebooting. However, systemd 255 introduces the SurviveFinalKillSignal= option, which can be set in unit files to allow specific services to persist through a soft-reboot. This is useful for storage daemons or other critical processes that must remain running throughout the transition.

To configure a service to survive, add the following line to its unit file under the [Unit] section:

SurviveFinalKillSignal=yes

This setting ensures that the designated service will not receive the final termination signals during a soft-reboot, allowing it to continue operating as userspace is restarted around it.

Considerations and Limitations

While soft-reboot offers a faster way to transition userspace, it is not a substitute for a full reboot in all scenarios. For example, kernel updates, firmware changes, or hardware-level resets still require a traditional reboot. Additionally, all services and applications must be compatible with being restarted from a new root; legacy or statically configured services may not function as expected if their dependencies are missing or paths have changed.

Always test the soft-reboot process in a controlled environment before deploying on production systems, especially when introducing major changes to the root filesystem or critical services.

Additional Features in systemd 255+

Beyond soft-reboot, systemd 255 introduces several other capabilities:

  • systemd-bsod: Displays full-screen error messages for critical boot failures, including QR codes for troubleshooting.
  • systemd-vmspawn: Experimental tool for spawning virtual machines using QEMU.
  • TPM2 and security improvements: Expanded options for measured Unified Kernel Images and TPM event logging.
  • Deprecation notices: System V init script support is deprecated and will be removed in future releases.

Systemd’s soft-reboot feature in version 255 and later provides a practical way to reboot userspace into a new root without restarting the kernel, reducing downtime and supporting advanced update workflows. Careful preparation and testing are key to making the most of this capability.