]>
Commit | Line | Data |
---|---|---|
4de66581 LP |
1 | <?xml version='1.0'?> <!--*-nxml-*--> |
2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" | |
3 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | |
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 | |
33 | running (but does not follow up with <constant>SIGKILL</constant>, and does not wait for the processes to | |
34 | exit). If the <filename>/run/nextroot/</filename> directory exists (which may be a regular directory, a | |
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 | ||
46 | <listitem><para>The third phase of regular shutdown, i.e. the return to the initrd | |
47 | context</para></listitem> | |
48 | ||
49 | <listitem><para>The hardware reboot operation</para></listitem> | |
50 | ||
51 | <listitem><para>The firmware initialization</para></listitem> | |
52 | ||
53 | <listitem><para>The boot loader initialization</para></listitem> | |
54 | ||
55 | <listitem><para>The kernel initialization</para></listitem> | |
56 | ||
57 | <listitem><para>The initrd initialization</para></listitem> | |
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 | ||
99 | <listitem><para>Service processes may continue to run over the transition, if they are placed in | |
100 | services that remain active until the very end of shutdown (which again is achieved via | |
101 | <varname>DefaultDependencies=no</varname>). They must also be set up to avoid being killed by the | |
102 | aforementioned <constant>SIGTERM</constant> spree (as per <ulink | |
103 | url="https://systemd.io/ROOT_STORAGE_DAEMONS">systemd and Storage Daemons for the Root File | |
104 | System</ulink>).</para></listitem> | |
105 | ||
106 | <listitem><para>File system mounts may remain mounted during the transition, and complex storage | |
107 | attached, if configured to remain until the very end of the shutdown process. (Also achieved via | |
108 | <varname>DefaultDependencies=no</varname>, and by avoiding | |
109 | <varname>Conflicts=umount.target</varname>)</para></listitem> | |
110 | </itemizedlist> | |
111 | ||
112 | <para>Even though passing resources from one soft reboot cycle to the next is possible this way, we | |
113 | strongly suggest to use this functionality sparingly only, as it creates a more fragile system as | |
114 | resources from different versions of the OS and applications might be mixed with unforeseen | |
115 | consequences. In particular it's recommended to <emphasis>avoid</emphasis> allowing processes to survive | |
116 | the soft reboot operation, as this means code updates will necessarily be incomplete, and processes | |
117 | typically pin various other resources (such as the file system they are backed by), thus increasing | |
118 | memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving | |
119 | processes running during a soft-reboot operation requires disconnecting the service comprehensively from | |
120 | the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A | |
121 | possible mechanism to achieve this is the concept of <ulink | |
947d836a LB |
122 | url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>, but make sure no resource from |
123 | the host's root filesystem is pinned via <varname>BindPaths=</varname> or similar unit settings, | |
124 | otherwise the old root filesystem will be kept in memory as long as the unit is running.</para> | |
4de66581 LP |
125 | |
126 | <para>If units shall be left running until the very end of shutdown during a soft reboot operation, but | |
127 | shall be terminated regularly during other forms of shutdown, it's recommended to set | |
128 | <varname>DefaultDependencies=no</varname> and then place | |
129 | <varname>Conflicts=</varname>/<varname>Before=</varname> onto <filename>reboot.target</filename>, | |
130 | <filename>kexec.target</filename>, <filename>poweroff.target</filename> and | |
131 | <filename>halt.target</filename> (but <emphasis>not</emphasis> onto | |
132 | <filename>soft-reboot.target</filename>).</para> | |
133 | </refsect1> | |
134 | ||
135 | <refsect1> | |
136 | <title>Notes</title> | |
137 | ||
138 | <para>Note that because | |
139 | <citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry> is | |
140 | not executed, the executables in <filename>/usr/lib/systemd/system-shutdown/</filename> are not executed | |
141 | either.</para> | |
142 | ||
143 | <para>Note that <filename>systemd-soft-reboot.service</filename> (and related units) should never be | |
144 | executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl | |
145 | soft-reboot</literal>.</para> | |
146 | </refsect1> | |
147 | ||
148 | <refsect1> | |
149 | <title>See Also</title> | |
150 | <para> | |
151 | <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, | |
152 | <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, | |
153 | <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, | |
154 | <citerefentry><refentrytitle>systemd-poweroff.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, | |
155 | <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, | |
156 | <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> | |
157 | </para> | |
158 | </refsect1> | |
159 | ||
160 | </refentry> |