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.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
  79     reboot operation. Specifically:</para>
  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
 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>
 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>