systemd-soft-reboot.service - Userspace reboot operation
systemd-soft-reboot.service is a system service that is pulled in by soft-reboot.target and is responsible for performing a userspace-only reboot operation. When invoked, it will send the SIGTERM signal to any processes left running (but does not wait for the processes to exit), and follow up with SIGKILL. If the /run/nextroot/ directory exists (which may be a regular directory, a directory mount point or a symlink to either) then it will switch the file system root to it. It then reexecutes the service manager off the (possibly now new) root file system, which will enqueue a new boot transaction as in a normal reboot.
Such a userspace-only reboot operation permits updating or resetting the entirety of userspace with minimal downtime, as the reboot operation does not transition through:
However this form of reboot comes with drawbacks as well:
These limitations may be addressed by various means, which are outside of the scope of this documentation, such as kernel live-patching and sufficiently comprehensive /etc/sysctl.d/ files.
Various runtime OS resources can passed from a system runtime to the next, through the userspace reboot operation. Specifically:
[Unit] Description=My surviving service SurviveFinalKillSignal=yes IgnoreOnIsolate=yes DefaultDependencies=no After=basic.target Conflicts=reboot.target Before=reboot.target Conflicts=kexec.target Before=kexec.target Conflicts=poweroff.target Before=poweroff.target Conflicts=halt.target Before=halt.target Conflicts=rescue.target Before=rescue.target Conflicts=emergency.target Before=emergency.target [Service] Type=oneshot ExecStart=sleep infinity
Even though passing resources from one soft reboot cycle to the next is possible this way, we strongly suggest to use this functionality sparingly only, as it creates a more fragile system as resources from different versions of the OS and applications might be mixed with unforeseen consequences. In particular it's recommended to avoid allowing processes to survive the soft reboot operation, as this means code updates will necessarily be incomplete, and processes typically pin various other resources (such as the file system they are backed by), thus increasing memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving processes running during a soft-reboot operation requires disconnecting the service comprehensively from the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A possible mechanism to achieve this is the concept of Portable Services, but make sure no resource from the host's OS filesystems is pinned via BindPaths= or similar unit settings, otherwise the old, originating filesystem will remain mounted as long as the unit is running.
Note that because systemd-shutdown(8) is not executed, the executables in /usr/lib/systemd/system-shutdown/ are not executed either.
Note that systemd-soft-reboot.service (and related units) should never be executed directly. Instead, trigger system shutdown with a command such as "systemctl soft-reboot".
Note that if a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed when the reboot command is invoked.
- Portable Services