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