systemd-soft-reboot.service(8) — Linux manual page

NAME | SYNOPSIS | DESCRIPTION | RESOURCE PASS-THROUGH | NOTES | SEE ALSO | NOTES | COLOPHON

SYSTEMD-SOFT-REBOOT.SERVICE(8)-soft-reboot.serviceSOFT-REBOOT.SERVICE(8)

NAME         top

       systemd-soft-reboot.service - Userspace reboot operation

SYNOPSIS         top

       systemd-soft-reboot.service

DESCRIPTION         top

       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 follow
       up with SIGKILL, and does not wait for the processes to exit). 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:

       •   The second phase of regular shutdown, as implemented by
           systemd-shutdown(8).

       •   The third phase of regular shutdown, i.e. the return to the
           initrd context

       •   The hardware reboot operation

       •   The firmware initialization

       •   The boot loader initialization

       •   The kernel initialization

       •   The initrd initialization

       However this form of reboot comes with drawbacks as well:

       •   The OS update remains incomplete, as the kernel is not reset
           and continues running.

       •   Kernel settings (such as /proc/sys/ settings, a.k.a.
           "sysctl", or /sys/ settings) are not reset.

       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.

RESOURCE PASS-THROUGH         top

       Various runtime OS resources can passed from a system runtime to
       the next, through the userspace reboot operation. Specifically:

       •   File descriptors placed in the file descriptor store of
           services that remain active until the very end are passed to
           the next boot, where they are placed in the file descriptor
           store of the same unit. For this to work, units must declare
           DefaultDependencies=no (and avoid a manual
           Conflicts=shutdown.target or similar) to ensure they are not
           terminated as usual during the system shutdown operation.
           Alternatively, use FileDescriptorStorePreserve= to allow the
           file descriptor store to remain pinned even when the unit is
           down. See systemd.service(5) for details about the file
           descriptor store.

       •   Similar to this, file descriptors associated with .socket
           units remain open (and connectible) if the units are not
           stopped during the transition. (Achieved by
           DefaultDependencies=no.)

       •   The /run/ file system remains mounted and populated and may
           be used to pass state information between such userspace
           reboot cycles.

       •   Service processes may continue to run over the transition, if
           they are placed in services that remain active until the very
           end of shutdown (which again is achieved via
           DefaultDependencies=no). They must also be set up to avoid
           being killed by the aforementioned SIGTERM spree (as per
           systemd and Storage Daemons for the Root File System[1]).

       •   File system mounts may remain mounted during the transition,
           and complex storage attached, if configured to remain until
           the very end of the shutdown process. (Also achieved via
           DefaultDependencies=no, and by avoiding
           Conflicts=umount.target)

       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[2].

       If units shall be left running until the very end of shutdown
       during a soft reboot operation, but shall be terminated regularly
       during other forms of shutdown, it's recommended to set
       DefaultDependencies=no and then place Conflicts=/Before= onto
       reboot.target, kexec.target, poweroff.target and halt.target (but
       not onto soft-reboot.target).

NOTES         top

       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".

SEE ALSO         top

       systemd(1), systemctl(1), systemd.special(7),
       systemd-poweroff.service(8), systemd-suspend.service(8),
       bootup(7)

NOTES         top

        1. systemd and Storage Daemons for the Root File System
           https://systemd.io/ROOT_STORAGE_DAEMONS

        2. Portable Services
           https://systemd.io/PORTABLE_SERVICES

COLOPHON         top

       This page is part of the systemd (systemd system and service
       manager) project.  Information about the project can be found at
       ⟨http://www.freedesktop.org/wiki/Software/systemd⟩.  If you have
       a bug report for this manual page, see
       ⟨http://www.freedesktop.org/wiki/Software/systemd/#bugreports⟩.
       This page was obtained from the project's upstream Git repository
       ⟨https://github.com/systemd/systemd.git⟩ on 2023-06-23.  (At that
       time, the date of the most recent commit that was found in the
       repository was 2023-06-23.)  If you discover any rendering
       problems in this HTML version of the page, or you believe there
       is a better or more up-to-date source for the page, or you have
       corrections or improvements to the information in this COLOPHON
       (which is not part of the original manual page), send a mail to
       man-pages@man7.org

systemd 253                               SYSTEMD-SOFT-REBOOT.SERVICE(8)

Pages that refer to this page: systemctl(1)systemd.directives(7)systemd.index(7)systemd.special(7)systemd-poweroff.service(8)