1SYSTEMD-SOFT-REBOOT.SERVICEs(y8s)temd-soft-reboot.serSvYiScTeEMD-SOFT-REBOOT.SERVICE(8)
2
6 systemd-soft-reboot.service - Userspace reboot operation
7
9 systemd-soft-reboot.service
10
12 systemd-soft-reboot.service is a system service that is pulled in by
13 soft-reboot.target and is responsible for performing a userspace-only
14 reboot operation. When invoked, it will send the SIGTERM signal to any
15 processes left running (but does not follow up with SIGKILL, and does
16 not wait for the processes to exit). If the /run/nextroot/ directory
17 exists (which may be a regular directory, a directory mount point or a
18 symlink to either) then it will switch the file system root to it. It
19 then reexecutes the service manager off the (possibly now new) root
20 file system, which will enqueue a new boot transaction as in a normal
21 reboot.
22 Such a userspace-only reboot operation permits updating or resetting
24 the entirety of userspace with minimal downtime, as the reboot
25 operation does not transition through:
26 • The second phase of regular shutdown, as implemented by systemd-
28 shutdown(8).
29 • The third phase of regular shutdown, i.e. the return to the initrd
31 context
32 • The hardware reboot operation
34 • The firmware initialization
36 • The boot loader initialization
38 • The kernel initialization
40 • The initrd initialization
42 However this form of reboot comes with drawbacks as well:
44 • The OS update remains incomplete, as the kernel is not reset and
46 continues running.
47 • Kernel settings (such as /proc/sys/ settings, a.k.a. "sysctl", or
49 /sys/ settings) are not reset.
50 These limitations may be addressed by various means, which are outside
52 of the scope of this documentation, such as kernel live-patching and
53 sufficiently comprehensive /etc/sysctl.d/ files.
54
56 Various runtime OS resources can passed from a system runtime to the
57 next, through the userspace reboot operation. Specifically:
58 • File descriptors placed in the file descriptor store of services
60 that remain active until the very end are passed to the next boot,
61 where they are placed in the file descriptor store of the same
62 unit. For this to work, units must declare DefaultDependencies=no
63 (and avoid a manual Conflicts=shutdown.target or similar) to ensure
64 they are not terminated as usual during the system shutdown
65 operation. Alternatively, use FileDescriptorStorePreserve= to allow
66 the file descriptor store to remain pinned even when the unit is
67 down. See systemd.service(5) for details about the file descriptor
68 store.
69 • Similar to this, file descriptors associated with .socket units
71 remain open (and connectible) if the units are not stopped during
72 the transition. (Achieved by DefaultDependencies=no.)
73 • The /run/ file system remains mounted and populated and may be used
75 to pass state information between such userspace reboot cycles.
76 • Service processes may continue to run over the transition, if they
78 are placed in services that remain active until the very end of
79 shutdown (which again is achieved via DefaultDependencies=no). They
80 must also be set up to avoid being killed by the aforementioned
81 SIGTERM spree (as per systemd and Storage Daemons for the Root File
82 System[1]).
83 • File system mounts may remain mounted during the transition, and
85 complex storage attached, if configured to remain until the very
86 end of the shutdown process. (Also achieved via
87 DefaultDependencies=no, and by avoiding Conflicts=umount.target)
88 Even though passing resources from one soft reboot cycle to the next is
90 possible this way, we strongly suggest to use this functionality
91 sparingly only, as it creates a more fragile system as resources from
92 different versions of the OS and applications might be mixed with
93 unforeseen consequences. In particular it's recommended to avoid
94 allowing processes to survive the soft reboot operation, as this means
95 code updates will necessarily be incomplete, and processes typically
96 pin various other resources (such as the file system they are backed
97 by), thus increasing memory usage (as two versions of the
98 OS/application/file system might be kept in memory). Leaving processes
99 running during a soft-reboot operation requires disconnecting the
100 service comprehensively from the rest of the OS, i.e. minimizing IPC
101 and reducing sharing of resources with the rest of the OS. A possible
102 mechanism to achieve this is the concept of Portable Services[2], but
103 make sure no resource from the host's OS filesystems is pinned via
104 BindPaths= or similar unit settings, otherwise the old, originating
105 filesystem will remain mounted as long as the unit is running.
106
108 Note that because systemd-shutdown(8) is not executed, the executables
109 in /usr/lib/systemd/system-shutdown/ are not executed either.
110 Note that systemd-soft-reboot.service (and related units) should never
112 be executed directly. Instead, trigger system shutdown with a command
113 such as "systemctl soft-reboot".
114
116 systemd(1), systemctl(1), systemd.special(7), systemd-
117 poweroff.service(8), systemd-suspend.service(8), bootup(7)
118
120 1. systemd and Storage Daemons for the Root File System
121 https://systemd.io/ROOT_STORAGE_DAEMONS
122 2. Portable Services
124 https://systemd.io/PORTABLE_SERVICES
125systemd 254 SYSTEMD-SOFT-REBOOT.SERVICE(8)