]>
Commit | Line | Data |
---|---|---|
4de66581 LP |
1 | <?xml version='1.0'?> <!--*-nxml-*--> |
2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" | |
eea10b26 | 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> |
4de66581 LP |
4 | <!-- SPDX-License-Identifier: LGPL-2.1-or-later --> |
5 | ||
6 | <refentry id="systemd-soft-reboot.service"> | |
7 | ||
8 | <refentryinfo> | |
9 | <title>systemd-soft-reboot.service</title> | |
10 | <productname>systemd</productname> | |
11 | </refentryinfo> | |
12 | ||
13 | <refmeta> | |
14 | <refentrytitle>systemd-soft-reboot.service</refentrytitle> | |
15 | <manvolnum>8</manvolnum> | |
16 | </refmeta> | |
17 | ||
18 | <refnamediv> | |
19 | <refname>systemd-soft-reboot.service</refname> | |
20 | <refpurpose>Userspace reboot operation</refpurpose> | |
21 | </refnamediv> | |
22 | ||
23 | <refsynopsisdiv> | |
24 | <para><filename>systemd-soft-reboot.service</filename></para> | |
25 | </refsynopsisdiv> | |
26 | ||
27 | <refsect1> | |
28 | <title>Description</title> | |
29 | ||
30 | <para><filename>systemd-soft-reboot.service</filename> is a system service that is pulled in by | |
31 | <filename>soft-reboot.target</filename> and is responsible for performing a userspace-only reboot | |
32 | operation. When invoked, it will send the <constant>SIGTERM</constant> signal to any processes left | |
2601482b YW |
33 | running (but does not wait for the processes to exit), and follow up with <constant>SIGKILL</constant>. |
34 | If the <filename>/run/nextroot/</filename> directory exists (which may be a regular directory, a | |
4de66581 LP |
35 | directory mount point or a symlink to either) then it will switch the file system root to it. It then |
36 | reexecutes the service manager off the (possibly now new) root file system, which will enqueue a new boot | |
37 | transaction as in a normal reboot.</para> | |
38 | ||
39 | <para>Such a userspace-only reboot operation permits updating or resetting the entirety of userspace with | |
40 | minimal downtime, as the reboot operation does <emphasis>not</emphasis> transition through:</para> | |
41 | ||
42 | <itemizedlist> | |
43 | <listitem><para>The second phase of regular shutdown, as implemented by | |
44 | <citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem> | |
45 | ||
cae4ad36 ZJS |
46 | <listitem><para>The third phase of regular shutdown, i.e. the return to the initrd context. |
47 | </para></listitem> | |
4de66581 | 48 | |
cae4ad36 | 49 | <listitem><para>The hardware reboot operation.</para></listitem> |
4de66581 | 50 | |
cae4ad36 | 51 | <listitem><para>The firmware initialization.</para></listitem> |
4de66581 | 52 | |
cae4ad36 | 53 | <listitem><para>The boot loader initialization.</para></listitem> |
4de66581 | 54 | |
cae4ad36 | 55 | <listitem><para>The kernel initialization.</para></listitem> |
4de66581 | 56 | |
cae4ad36 | 57 | <listitem><para>The initrd initialization.</para></listitem> |
4de66581 LP |
58 | </itemizedlist> |
59 | ||
60 | <para>However this form of reboot comes with drawbacks as well:</para> | |
61 | ||
62 | <itemizedlist> | |
63 | <listitem><para>The OS update remains incomplete, as the kernel is not reset and continues | |
64 | running.</para></listitem> | |
65 | ||
66 | <listitem><para>Kernel settings (such as <filename>/proc/sys/</filename> settings, a.k.a. "sysctl", or | |
67 | <filename>/sys/</filename> settings) are not reset.</para></listitem> | |
68 | </itemizedlist> | |
69 | ||
70 | <para>These limitations may be addressed by various means, which are outside of the scope of this | |
71 | documentation, such as kernel live-patching and sufficiently comprehensive | |
72 | <filename>/etc/sysctl.d/</filename> files.</para> | |
73 | </refsect1> | |
74 | ||
75 | <refsect1> | |
76 | <title>Resource Pass-Through</title> | |
77 | ||
78 | <para>Various runtime OS resources can passed from a system runtime to the next, through the userspace | |
9a27ef09 | 79 | reboot operation. Specifically:</para> |
4de66581 LP |
80 | |
81 | <itemizedlist> | |
82 | <listitem><para>File descriptors placed in the file descriptor store of services that remain active | |
83 | until the very end are passed to the next boot, where they are placed in the file descriptor store of | |
84 | the same unit. For this to work, units must declare <varname>DefaultDependencies=no</varname> (and | |
85 | avoid a manual <varname>Conflicts=shutdown.target</varname> or similar) to ensure they are not | |
86 | terminated as usual during the system shutdown operation. Alternatively, use | |
87 | <varname>FileDescriptorStorePreserve=</varname> to allow the file descriptor store to remain pinned | |
88 | even when the unit is down. See | |
89 | <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for | |
90 | details about the file descriptor store.</para></listitem> | |
91 | ||
92 | <listitem><para>Similar to this, file descriptors associated with <filename>.socket</filename> units | |
93 | remain open (and connectible) if the units are not stopped during the transition. (Achieved by | |
94 | <varname>DefaultDependencies=no</varname>.)</para></listitem> | |
95 | ||
96 | <listitem><para>The <filename>/run/</filename> file system remains mounted and populated and may be | |
97 | used to pass state information between such userspace reboot cycles.</para></listitem> | |
98 | ||
559214cb LB |
99 | <listitem><para>Service processes may continue to run over the transition, past soft-reboot and into |
100 | the next session, if they are placed in services that remain active until the very end of shutdown | |
101 | (which again is achieved via <varname>DefaultDependencies=no</varname>). They must also be set up to | |
102 | avoid being killed by the aforementioned <constant>SIGTERM</constant> and <constant>SIGKILL</constant> | |
103 | via <varname>SurviveFinalKillSignal=yes</varname>, and also be configured to avoid being stopped on | |
104 | isolate via <varname>IgnoreOnIsolate=yes</varname>. They also have to be configured to be stopped on | |
105 | normal shutdown, reboot and maintenance mode. Finally, they have to be ordered after | |
106 | <constant>basic.target</constant> to ensure correct ordeering on boot. Note that in case any new or | |
107 | custom units are used to isolate to, or that implement an equivalent shutdown functionality, they will | |
108 | also have to be configured manually for correct ordering and conflicting. For example:</para> | |
109 | ||
110 | <programlisting>[Unit] | |
111 | Description=My surviving service | |
112 | SurviveFinalKillSignal=yes | |
113 | IgnoreOnIsolate=yes | |
114 | DefaultDependencies=no | |
115 | After=basic.target | |
116 | Conflicts=reboot.target | |
117 | Before=reboot.target | |
118 | Conflicts=kexec.target | |
119 | Before=kexec.target | |
120 | Conflicts=poweroff.target | |
121 | Before=poweroff.target | |
122 | Conflicts=halt.target | |
123 | Before=halt.target | |
124 | Conflicts=rescue.target | |
125 | Before=rescue.target | |
126 | Conflicts=emergency.target | |
127 | Before=emergency.target | |
128 | ||
129 | [Service] | |
130 | Type=oneshot | |
131 | ExecStart=sleep infinity | |
132 | </programlisting> | |
133 | </listitem> | |
4de66581 LP |
134 | |
135 | <listitem><para>File system mounts may remain mounted during the transition, and complex storage | |
136 | attached, if configured to remain until the very end of the shutdown process. (Also achieved via | |
137 | <varname>DefaultDependencies=no</varname>, and by avoiding | |
138 | <varname>Conflicts=umount.target</varname>)</para></listitem> | |
139 | </itemizedlist> | |
140 | ||
141 | <para>Even though passing resources from one soft reboot cycle to the next is possible this way, we | |
142 | strongly suggest to use this functionality sparingly only, as it creates a more fragile system as | |
143 | resources from different versions of the OS and applications might be mixed with unforeseen | |
144 | consequences. In particular it's recommended to <emphasis>avoid</emphasis> allowing processes to survive | |
145 | the soft reboot operation, as this means code updates will necessarily be incomplete, and processes | |
146 | typically pin various other resources (such as the file system they are backed by), thus increasing | |
147 | memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving | |
148 | processes running during a soft-reboot operation requires disconnecting the service comprehensively from | |
149 | the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A | |
150 | possible mechanism to achieve this is the concept of <ulink | |
579fbe5b LP |
151 | url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>, but make sure no resource from the |
152 | host's OS filesystems is pinned via <varname>BindPaths=</varname> or similar unit settings, otherwise the | |
153 | old, originating filesystem will remain mounted as long as the unit is running.</para> | |
4de66581 LP |
154 | </refsect1> |
155 | ||
156 | <refsect1> | |
157 | <title>Notes</title> | |
158 | ||
159 | <para>Note that because | |
160 | <citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry> is | |
161 | not executed, the executables in <filename>/usr/lib/systemd/system-shutdown/</filename> are not executed | |
162 | either.</para> | |
163 | ||
164 | <para>Note that <filename>systemd-soft-reboot.service</filename> (and related units) should never be | |
165 | executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl | |
166 | soft-reboot</literal>.</para> | |
665a3d6d | 167 | |
5d4072d0 | 168 | <para>Note that if a new root file system has been set up on <literal>/run/nextroot/</literal>, a |
665a3d6d LB |
169 | <command>soft-reboot</command> will be performed when the <command>reboot</command> command is |
170 | invoked.</para> | |
4de66581 LP |
171 | </refsect1> |
172 | ||
173 | <refsect1> | |
174 | <title>See Also</title> | |
13a69c12 DT |
175 | <para><simplelist type="inline"> |
176 | <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
177 | <member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member> | |
178 | <member><citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry></member> | |
179 | <member><citerefentry><refentrytitle>systemd-poweroff.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
180 | <member><citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member> | |
181 | <member><citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry></member> | |
182 | </simplelist></para> | |
4de66581 LP |
183 | </refsect1> |
184 | ||
185 | </refentry> |