|
HTML rendering created 2023-12-22 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|
|
NAME | SYNOPSIS | DESCRIPTION | RESOURCE PASS-THROUGH | NOTES | SEE ALSO | NOTES | COLOPHON |
|
|
|
SYSTEMD-....SERVICE(8) systemd-soft-reboot.serviceSYSTEMD-....SERVICE(8)
systemd-soft-reboot.service - Userspace reboot operation
systemd-soft-reboot.service
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:
• 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.
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,
past soft-reboot and into the next session, 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 and SIGKILL via
SurviveFinalKillSignal=yes, and also be configured to avoid
being stopped on isolate via IgnoreOnIsolate=yes. They also
have to be configured to be stopped on normal shutdown,
reboot and maintenance mode. Finally, they have to be ordered
after basic.target to ensure correct ordeering on boot. Note
that in case any new or custom units are used to isolate to,
or that implement an equivalent shutdown functionality, they
will also have to be configured manually for correct ordering
and conflicting. For example:
[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
• 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[1],
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.
systemd(1), systemctl(1), systemd.special(7),
systemd-poweroff.service(8), systemd-suspend.service(8),
bootup(7)
1. Portable Services
https://systemd.io/PORTABLE_SERVICES
This page is part of the systemd (systemd system and service
manager) project. Information about the project can be found at
⟨http:https://www.freedesktop.org/wiki/Software/systemd⟩. If you have
a bug report for this manual page, see
⟨http:https://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-12-22. (At that
time, the date of the most recent commit that was found in the
repository was 2023-12-22.) 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
[email protected]
systemd 255 SYSTEMD-....SERVICE(8)
Pages that refer to this page: systemctl(1), systemd.exec(5), systemd.directives(7), systemd.index(7), systemd.special(7), systemd-poweroff.service(8)
|
HTML rendering created 2023-12-22 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|