x SuSE Linux 13.1-RELEASE x
x SuSE Linux 13.1-RELEASEx
SYSTEMD-SOFT-REBOOT.SERVICsystemd-soft-reboot.seSYSTEMD-SOFT-REBOOT.SERVICE(8)
NAME
systemd-soft-reboot.service - Userspace reboot operation
SYNOPSIS
systemd-soft-reboot.service
DESCRIPTION
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:
o The second phase of regular shutdown, as implemented by systemd-
shutdown(8).
o The third phase of regular shutdown, i.e. the return to the initrd
context
o The hardware reboot operation
o The firmware initialization
o The boot loader initialization
o The kernel initialization
o The initrd initialization
However this form of reboot comes with drawbacks as well:
o The OS update remains incomplete, as the kernel is not reset and
continues running.
o 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
Various runtime OS resources can passed from a system runtime to the
next, through the userspace reboot operation. Specifically:
o 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.
o 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.)
o The /run/ file system remains mounted and populated and may be used
to pass state information between such userspace reboot cycles.
o 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]).
o 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], 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.
NOTES
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
systemd(1), systemctl(1), systemd.special(7), systemd-
poweroff.service(8), systemd-suspend.service(8), bootup(7)
NOTES
1. systemd and Storage Daemons for the Root File System
https://systemd.io/ROOT_STORAGE_DAEMONS
2. Portable Services
https://systemd.io/PORTABLE_SERVICES
systemd 254 SYSTEMD-SOFT-REBOOT.SERVICE(8)
Want to link to this manual page? Use this URL:
<http://star2.abcm.com/cgi-bin/bsdi-man?query=systemd-soft-reboot.service&sektion=8&manpath=>