man/systemd-soft-reboot.service.xml

   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.5/docbookx.dtd">
   4 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
   5
   6 <refentry id="systemd-soft-reboot.service"
   7     xmlns:xi="http://www.w3.org/2001/XInclude">
   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
  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
  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
  47       <listitem><para>The third phase of regular shutdown, i.e. the return to the initrd context.
  48       </para></listitem>
  49
  50       <listitem><para>The hardware reboot operation.</para></listitem>
  51
  52       <listitem><para>The firmware initialization.</para></listitem>
  53
  54       <listitem><para>The boot loader initialization.</para></listitem>
  55
  56       <listitem><para>The kernel initialization.</para></listitem>
  57
  58       <listitem><para>The initrd initialization.</para></listitem>
  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
  80     reboot operation. Specifically:</para>
  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
 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 ordering 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 kexec.target poweroff.target halt.target rescue.target emergency.target
 118 Before=shutdown.target rescue.target emergency.target
 119
 120 [Service]
 121 Type=oneshot
 122 ExecStart=sleep infinity</programlisting>
 123       </listitem>
 124
 125       <listitem><para>On top of the above, templated units also need a configuration file for their slice, as
 126       they by default use a slice named after the non-templated part of the unit. For example, for a
 127       <filename>foo@test.service</filename> instance, a <filename>system-foo.slice</filename> unit may be
 128       added with the following content:</para>
 129
 130       <programlisting>[Unit]
 131 SurviveFinalKillSignal=yes
 132 IgnoreOnIsolate=yes
 133 DefaultDependencies=no</programlisting>
 134       </listitem>
 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>
 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
 143       <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 144       library this can be achieved by adapting the following example.
 145       <programlisting><xi:include href="sd_bus_service_reconnect.c" parse="text"/></programlisting>
 146       </para></listitem>
 147     </itemizedlist>
 148
 149     <para>Even though passing resources from one soft reboot cycle to the next is possible this way, we
 150     strongly suggest to use this functionality sparingly only, as it creates a more fragile system as
 151     resources from different versions of the OS and applications might be mixed with unforeseen
 152     consequences. In particular it is recommended to <emphasis>avoid</emphasis> allowing processes to survive
 153     the soft reboot operation, as this means code updates will necessarily be incomplete, and processes
 154     typically pin various other resources (such as the file system they are backed by), thus increasing
 155     memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving
 156     processes running during a soft-reboot operation requires disconnecting the service comprehensively from
 157     the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A
 158     possible mechanism to achieve this is the concept of <ulink
 159     url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>, but make sure no resource from the
 160     host's OS filesystems is pinned via <varname>BindPaths=</varname> or similar unit settings, otherwise the
 161     old, originating filesystem will remain mounted as long as the unit is running.</para>
 162   </refsect1>
 163
 164   <refsect1>
 165     <title>Notes</title>
 166
 167     <para>Note that because
 168     <citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
 169     not executed, the executables in <filename>/usr/lib/systemd/system-shutdown/</filename> are not executed
 170     either.</para>
 171
 172     <para>Note that <filename>systemd-soft-reboot.service</filename> (and related units) should never be
 173     executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl
 174     soft-reboot</literal>.</para>
 175
 176     <para>Note that if a new root file system has been set up on <literal>/run/nextroot/</literal>, a
 177     <command>soft-reboot</command> will be performed when the <command>reboot</command> command is
 178     invoked.</para>
 179   </refsect1>
 180
 181   <refsect1>
 182     <title>See Also</title>
 183     <para><simplelist type="inline">
 184       <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
 185       <member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
 186       <member><citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
 187       <member><citerefentry><refentrytitle>systemd-poweroff.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
 188       <member><citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
 189       <member><citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
 190     </simplelist></para>
 191   </refsect1>
 192
 193 </refentry>