mirror of
https://github.com/systemd/systemd
synced 2024-07-21 02:05:05 +00:00
man: document the soft reboot operation
This commit is contained in:
Lennart Poettering
parent
ba1af88c3c
commit
4de665812a
|
|
@ -576,16 +576,15 @@ node /org/freedesktop/login1 {
|
|||
|
||||
<para><function>PowerOff()</function>, <function>Reboot()</function>, <function>Halt()</function>,
|
||||
<function>Suspend()</function>, and <function>Hibernate()</function> result in the system being powered
|
||||
off, rebooted, halted (shut down without turning off power), suspended (the system state is
|
||||
saved to RAM and the CPU is turned off), or hibernated (the system state is saved to disk and
|
||||
the machine is powered down). <function>HybridSleep()</function> results in the system entering a
|
||||
hybrid-sleep mode, i.e. the system is both hibernated and suspended.
|
||||
<function>SuspendThenHibernate()</function> results in the system being suspended, then later woken
|
||||
using an RTC timer and hibernated. The only argument is the polkit interactivity boolean
|
||||
<varname>interactive</varname> (see below). The main purpose of these calls is that they enforce
|
||||
polkit policy and hence allow powering off/rebooting/suspending/hibernating even by unprivileged
|
||||
users. They also enforce inhibition locks for non-privileged users. UIs should expose these calls
|
||||
as the primary mechanism to poweroff/reboot/suspend/hibernate the machine. Methods
|
||||
off, rebooted, halted (shut down without turning off power), suspended (the system state is saved to
|
||||
RAM and the CPU is turned off), or hibernated (the system state is saved to disk and the machine is
|
||||
powered down). <function>HybridSleep()</function> results in the system entering a hybrid-sleep mode,
|
||||
i.e. the system is both hibernated and suspended. <function>SuspendThenHibernate()</function> results
|
||||
in the system being suspended, then later woken using an RTC timer and hibernated. The only argument is
|
||||
the polkit interactivity boolean <varname>interactive</varname> (see below). The main purpose of these
|
||||
calls is that they enforce polkit policy and hence allow powering off/rebooting/suspending/hibernating
|
||||
even by unprivileged users. They also enforce inhibition locks for non-privileged users. UIs should
|
||||
expose these calls as the primary mechanism to poweroff/reboot/suspend/hibernate the machine. Methods
|
||||
<function>PowerOffWithFlags()</function>, <function>RebootWithFlags()</function>,
|
||||
<function>HaltWithFlags()</function>, <function>SuspendWithFlags()</function>,
|
||||
<function>HibernateWithFlags()</function>, <function>HybridSleepWithFlags()</function> and
|
||||
|
|
@ -594,12 +593,14 @@ node /org/freedesktop/login1 {
|
|||
<programlisting>
|
||||
#define SD_LOGIND_ROOT_CHECK_INHIBITORS (UINT64_C(1) << 0)
|
||||
#define SD_LOGIND_KEXEC_REBOOT (UINT64_C(1) << 1)
|
||||
#define SD_LOGIND_SOFT_REBOOT (UINT64_C(1) << 2)
|
||||
</programlisting>
|
||||
<para> When the <varname>flags</varname> is 0 then these methods behave just like the versions
|
||||
without flags. When <constant>SD_LOGIND_ROOT_CHECK_INHIBITORS</constant> (0x01) is set, active
|
||||
inhibitors are honoured for privileged users too. When <constant>SD_LOGIND_KEXEC_REBOOT</constant>
|
||||
(0x02) is set, then <function>RebootWithFlags()</function> perform kexec reboot if kexec
|
||||
kernel is loaded.</para>
|
||||
<para>When the <varname>flags</varname> is 0 then these methods behave just like the versions without
|
||||
flags. When <constant>SD_LOGIND_ROOT_CHECK_INHIBITORS</constant> (0x01) is set, active inhibitors are
|
||||
honoured for privileged users too. When <constant>SD_LOGIND_KEXEC_REBOOT</constant> (0x02) is set, then
|
||||
<function>RebootWithFlags()</function> performs a kexec reboot if kexec kernel is loaded. When
|
||||
<constant>SD_LOGIND_SOFT_REBOOT</constant> (0x04) is set, then <function>RebootWithFlags()</function>
|
||||
performs a userspace reboot only.</para>
|
||||
|
||||
<para><function>SetRebootParameter()</function> sets a parameter for a subsequent reboot operation.
|
||||
See the description of <command>reboot</command> in
|
||||
|
|
|
|||
|
|
@ -183,6 +183,8 @@ node /org/freedesktop/systemd1 {
|
|||
@org.freedesktop.systemd1.Privileged("true")
|
||||
Reboot();
|
||||
@org.freedesktop.systemd1.Privileged("true")
|
||||
SoftReboot(in s new_root);
|
||||
@org.freedesktop.systemd1.Privileged("true")
|
||||
PowerOff();
|
||||
@org.freedesktop.systemd1.Privileged("true")
|
||||
Halt();
|
||||
|
|
@ -912,6 +914,8 @@ node /org/freedesktop/systemd1 {
|
|||
|
||||
<variablelist class="dbus-method" generated="True" extra-ref="Reboot()"/>
|
||||
|
||||
<variablelist class="dbus-method" generated="True" extra-ref="SoftReboot()"/>
|
||||
|
||||
<variablelist class="dbus-method" generated="True" extra-ref="PowerOff()"/>
|
||||
|
||||
<variablelist class="dbus-method" generated="True" extra-ref="Halt()"/>
|
||||
|
|
@ -1415,15 +1419,18 @@ node /org/freedesktop/systemd1 {
|
|||
<para><function>Exit()</function> may be invoked to ask the manager to exit. This is not available for
|
||||
the system manager and is useful only for user session managers.</para>
|
||||
|
||||
<para><function>Reboot()</function>, <function>PowerOff()</function>, <function>Halt()</function>, or
|
||||
<function>KExec()</function> may be used to ask for immediate reboot, powering down, halt or kexec
|
||||
based reboot of the system. Note that this does not shut down any services and immediately transitions
|
||||
into the reboot process. These functions are normally only called as the last step of shutdown and should
|
||||
not be called directly. To shut down the machine, it is generally a better idea to invoke
|
||||
<function>Reboot()</function> or <function>PowerOff()</function> on the
|
||||
<para><function>Reboot()</function>, <function>PowerOff()</function>, <function>Halt()</function>,
|
||||
<function>KExec()</function> and <function>SoftReboot()</function> may be used to ask for immediate
|
||||
reboot, powering down, halt, kexec based reboot, or soft reboot of the system. Note that this does not
|
||||
shut down any services and immediately transitions into the later shutdown operation. These functions
|
||||
are normally only called as the last step of shutdown and should not be called directly. To shut down
|
||||
the machine, it is generally a better idea to invoke <function>Reboot()</function>,
|
||||
<function>RebootWithFlags()</function> or <function>PowerOff()</function> on the
|
||||
<filename>systemd-logind</filename> manager object; see
|
||||
<citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for more information.</para>
|
||||
for more information. <function>SoftReboot()</function> accepts an argument indicating the path for the
|
||||
root file system to activate for the next boot cycle. If an empty string is specified the
|
||||
<filename>/run/nextroot/</filename> path is used if it exists.</para>
|
||||
|
||||
<para><function>SwitchRoot()</function> may be used to transition to a new root directory. This is
|
||||
intended to be used in the initrd, and also to transition from the host system into a shutdown initrd.
|
||||
|
|
|
|||
|
|
@ -1036,6 +1036,7 @@ manpages = [
|
|||
['systemd-sleep.conf', '5', ['sleep.conf.d'], ''],
|
||||
['systemd-socket-activate', '1', [], ''],
|
||||
['systemd-socket-proxyd', '8', [], ''],
|
||||
['systemd-soft-reboot.service', '8', [], ''],
|
||||
['systemd-stdio-bridge', '1', [], ''],
|
||||
['systemd-stub',
|
||||
'7',
|
||||
|
|
|
|||
|
|
@ -1559,6 +1559,24 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>soft-reboot</command></term>
|
||||
|
||||
<listitem>
|
||||
<para>Shut down and reboot userspace. This is equivalent to <command>systemctl start
|
||||
soft-reboot.target --job-mode=replace-irreversibly --no-block</command>. This command is
|
||||
asynchronous; it will return after the reboot operation is enqueued, without waiting for it to
|
||||
complete.</para>
|
||||
|
||||
<para>This command honors <option>--force</option> and <option>--when=</option> in a similar way
|
||||
as <command>halt</command>.</para>
|
||||
|
||||
<para>This operation only reboots userspace, leaving the kernel running. See
|
||||
<citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
for details.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>exit</command> <optional><replaceable>EXIT_CODE</replaceable></optional></term>
|
||||
|
||||
|
|
|
|||
|
|
@ -68,6 +68,10 @@
|
|||
<para>Note that <filename>systemd-poweroff.service</filename> (and the related units) should never be
|
||||
executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl
|
||||
poweroff</literal>.</para>
|
||||
|
||||
<para>Another form of shutdown is provided by the
|
||||
<citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
functionality. It reboots only the OS userspace, leaving the kernel, firmware, and hardware as it is.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
@ -78,6 +82,7 @@
|
|||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
</para>
|
||||
</refsect1>
|
||||
|
|
|
|||
158
man/systemd-soft-reboot.service.xml
Normal file
158
man/systemd-soft-reboot.service.xml
Normal file
|
|
@ -0,0 +1,158 @@
|
|||
<?xml version='1.0'?> <!--*-nxml-*-->
|
||||
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
||||
|
||||
<refentry id="systemd-soft-reboot.service">
|
||||
|
||||
<refentryinfo>
|
||||
<title>systemd-soft-reboot.service</title>
|
||||
<productname>systemd</productname>
|
||||
</refentryinfo>
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>systemd-soft-reboot.service</refentrytitle>
|
||||
<manvolnum>8</manvolnum>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>systemd-soft-reboot.service</refname>
|
||||
<refpurpose>Userspace reboot operation</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<para><filename>systemd-soft-reboot.service</filename></para>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para><filename>systemd-soft-reboot.service</filename> is a system service that is pulled in by
|
||||
<filename>soft-reboot.target</filename> and is responsible for performing a userspace-only reboot
|
||||
operation. When invoked, it will send the <constant>SIGTERM</constant> signal to any processes left
|
||||
running (but does not follow up with <constant>SIGKILL</constant>, and does not wait for the processes to
|
||||
exit). If the <filename>/run/nextroot/</filename> directory exists (which may be a regular directory, a
|
||||
directory mount point or a symlink to either) then it will switch the file system root to it. It then
|
||||
reexecutes the service manager off the (possibly now new) root file system, which will enqueue a new boot
|
||||
transaction as in a normal reboot.</para>
|
||||
|
||||
<para>Such a userspace-only reboot operation permits updating or resetting the entirety of userspace with
|
||||
minimal downtime, as the reboot operation does <emphasis>not</emphasis> transition through:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>The second phase of regular shutdown, as implemented by
|
||||
<citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
|
||||
|
||||
<listitem><para>The third phase of regular shutdown, i.e. the return to the initrd
|
||||
context</para></listitem>
|
||||
|
||||
<listitem><para>The hardware reboot operation</para></listitem>
|
||||
|
||||
<listitem><para>The firmware initialization</para></listitem>
|
||||
|
||||
<listitem><para>The boot loader initialization</para></listitem>
|
||||
|
||||
<listitem><para>The kernel initialization</para></listitem>
|
||||
|
||||
<listitem><para>The initrd initialization</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>However this form of reboot comes with drawbacks as well:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>The OS update remains incomplete, as the kernel is not reset and continues
|
||||
running.</para></listitem>
|
||||
|
||||
<listitem><para>Kernel settings (such as <filename>/proc/sys/</filename> settings, a.k.a. "sysctl", or
|
||||
<filename>/sys/</filename> settings) are not reset.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These limitations may be addressed by various means, which are outside of the scope of this
|
||||
documentation, such as kernel live-patching and sufficiently comprehensive
|
||||
<filename>/etc/sysctl.d/</filename> files.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Resource Pass-Through</title>
|
||||
|
||||
<para>Various runtime OS resources can passed from a system runtime to the next, through the userspace
|
||||
reboot operation. Specificially:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>File descriptors placed in the file descriptor store of services that remain active
|
||||
until the very end are passed to the next boot, where they are placed in the file descriptor store of
|
||||
the same unit. For this to work, units must declare <varname>DefaultDependencies=no</varname> (and
|
||||
avoid a manual <varname>Conflicts=shutdown.target</varname> or similar) to ensure they are not
|
||||
terminated as usual during the system shutdown operation. Alternatively, use
|
||||
<varname>FileDescriptorStorePreserve=</varname> to allow the file descriptor store to remain pinned
|
||||
even when the unit is down. See
|
||||
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
details about the file descriptor store.</para></listitem>
|
||||
|
||||
<listitem><para>Similar to this, file descriptors associated with <filename>.socket</filename> units
|
||||
remain open (and connectible) if the units are not stopped during the transition. (Achieved by
|
||||
<varname>DefaultDependencies=no</varname>.)</para></listitem>
|
||||
|
||||
<listitem><para>The <filename>/run/</filename> file system remains mounted and populated and may be
|
||||
used to pass state information between such userspace reboot cycles.</para></listitem>
|
||||
|
||||
<listitem><para>Service processes may continue to run over the transition, if they are placed in
|
||||
services that remain active until the very end of shutdown (which again is achieved via
|
||||
<varname>DefaultDependencies=no</varname>). They must also be set up to avoid being killed by the
|
||||
aforementioned <constant>SIGTERM</constant> spree (as per <ulink
|
||||
url="https://systemd.io/ROOT_STORAGE_DAEMONS">systemd and Storage Daemons for the Root File
|
||||
System</ulink>).</para></listitem>
|
||||
|
||||
<listitem><para>File system mounts may remain mounted during the transition, and complex storage
|
||||
attached, if configured to remain until the very end of the shutdown process. (Also achieved via
|
||||
<varname>DefaultDependencies=no</varname>, and by avoiding
|
||||
<varname>Conflicts=umount.target</varname>)</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Even though passing resources from one soft reboot cycle to the next is possible this way, we
|
||||
strongly suggest to use this functionality sparingly only, as it creates a more fragile system as
|
||||
resources from different versions of the OS and applications might be mixed with unforeseen
|
||||
consequences. In particular it's recommended to <emphasis>avoid</emphasis> allowing processes to survive
|
||||
the soft reboot operation, as this means code updates will necessarily be incomplete, and processes
|
||||
typically pin various other resources (such as the file system they are backed by), thus increasing
|
||||
memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving
|
||||
processes running during a soft-reboot operation requires disconnecting the service comprehensively from
|
||||
the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A
|
||||
possible mechanism to achieve this is the concept of <ulink
|
||||
url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>.</para>
|
||||
|
||||
<para>If units shall be left running until the very end of shutdown during a soft reboot operation, but
|
||||
shall be terminated regularly during other forms of shutdown, it's recommended to set
|
||||
<varname>DefaultDependencies=no</varname> and then place
|
||||
<varname>Conflicts=</varname>/<varname>Before=</varname> onto <filename>reboot.target</filename>,
|
||||
<filename>kexec.target</filename>, <filename>poweroff.target</filename> and
|
||||
<filename>halt.target</filename> (but <emphasis>not</emphasis> onto
|
||||
<filename>soft-reboot.target</filename>).</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Notes</title>
|
||||
|
||||
<para>Note that because
|
||||
<citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
|
||||
not executed, the executables in <filename>/usr/lib/systemd/system-shutdown/</filename> are not executed
|
||||
either.</para>
|
||||
|
||||
<para>Note that <filename>systemd-soft-reboot.service</filename> (and related units) should never be
|
||||
executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl
|
||||
soft-reboot</literal>.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
<para>
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>systemd-poweroff.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
</refentry>
|
||||
|
|
@ -437,8 +437,12 @@
|
|||
|
||||
<listitem><para>An additional filesystem to be mounted in the initrd. See
|
||||
<filename>initrd-fs.target</filename> description in
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
|
||||
</para></listitem>
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. This
|
||||
is both an indicator to the initrd to mount this partition early and an indicator to the host to
|
||||
leave the partition mounted until final shutdown. Or in other words, if this flag is set it is
|
||||
assumed the mount shall be active during the entire regular runtime of the system, i.e. established
|
||||
before the initrd transitions into the host all the way until the host transitions to the final
|
||||
shutdown phase.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
|
|
|||
|
|
@ -81,6 +81,7 @@
|
|||
<filename>slices.target</filename>,
|
||||
<filename>smartcard.target</filename>,
|
||||
<filename>sockets.target</filename>,
|
||||
<filename>soft-reboot.target</filename>,
|
||||
<filename>sound.target</filename>,
|
||||
<filename>suspend.target</filename>,
|
||||
<filename>swap.target</filename>,
|
||||
|
|
@ -442,15 +443,18 @@
|
|||
<varlistentry>
|
||||
<term><filename>kexec.target</filename></term>
|
||||
<listitem>
|
||||
<para>A special target unit for shutting down and rebooting
|
||||
the system via kexec.</para>
|
||||
<para>A special target unit for shutting down and rebooting the system via kexec.</para>
|
||||
|
||||
<para>Applications wanting to reboot the system should not start this unit
|
||||
directly, but should instead execute <command>systemctl kexec</command>
|
||||
(possibly with the <option>--no-block</option> option) or call
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
||||
<command>org.freedesktop.systemd1.Manager.KExec</command> D-Bus method
|
||||
<para>Applications wanting to reboot the system should not start this unit directly, but should
|
||||
instead execute <command>systemctl kexec</command> (possibly with the
|
||||
<option>--no-block</option> option) or call
|
||||
<citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
|
||||
<function>org.freedesktop.login1.Manager.RebootWithFlags()</function> D-Bus method
|
||||
directly.</para>
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>systemd-kexec.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
for further details of the operation this target pulls in.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -559,18 +563,20 @@
|
|||
<varlistentry>
|
||||
<term><filename>reboot.target</filename></term>
|
||||
<listitem>
|
||||
<para>A special target unit for shutting down and rebooting
|
||||
the system.</para>
|
||||
<para>A special target unit for shutting down and rebooting the system.</para>
|
||||
|
||||
<para>Applications wanting to reboot the system should not start this unit
|
||||
directly, but should instead execute <command>systemctl reboot</command>
|
||||
(possibly with the <option>--no-block</option> option) or call
|
||||
<para>Applications wanting to reboot the system should not start this unit directly, but should
|
||||
instead execute <command>systemctl reboot</command> (possibly with the
|
||||
<option>--no-block</option> option) or call
|
||||
<citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
|
||||
<command>org.freedesktop.login1.Manager.Reboot</command> D-Bus method
|
||||
directly.</para>
|
||||
<function>org.freedesktop.login1.Manager.Reboot()</function> D-Bus method directly.</para>
|
||||
|
||||
<para><filename>runlevel6.target</filename> is an alias for
|
||||
this target unit, for compatibility with SysV.</para>
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>systemd-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
for further details of the operation this target pulls in.</para>
|
||||
|
||||
<para><filename>runlevel6.target</filename> is an alias for this target unit, for compatibility
|
||||
with SysV.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -703,6 +709,24 @@
|
|||
section.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><filename>soft-reboot.target</filename></term>
|
||||
<listitem>
|
||||
<para>A special target unit for shutting down and rebooting the userspace of the system (leaving
|
||||
the kernel running).</para>
|
||||
|
||||
<para>Applications wanting to reboot the system should not start this unit directly, but should
|
||||
instead execute <command>systemctl soft-reboot</command> (possibly with the
|
||||
<option>--no-block</option> option) or call
|
||||
<citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
|
||||
<function>org.freedesktop.login1.Manager.RebootWithFlags()</function> D-Bus method
|
||||
directly.</para>
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
for further details of the operation this target pulls in.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><filename>suspend.target</filename></term>
|
||||
<listitem>
|
||||
|
|
|
|||
|
|
@ -999,27 +999,34 @@
|
|||
<term><varname>FailureAction=</varname></term>
|
||||
<term><varname>SuccessAction=</varname></term>
|
||||
|
||||
<listitem><para>Configure the action to take when the unit stops and enters a failed state or inactive state.
|
||||
Takes one of <option>none</option>, <option>reboot</option>, <option>reboot-force</option>,
|
||||
<option>reboot-immediate</option>, <option>poweroff</option>, <option>poweroff-force</option>,
|
||||
<option>poweroff-immediate</option>, <option>exit</option>, and <option>exit-force</option>. In system mode,
|
||||
all options are allowed. In user mode, only <option>none</option>, <option>exit</option>, and
|
||||
<option>exit-force</option> are allowed. Both options default to <option>none</option>.</para>
|
||||
<listitem><para>Configure the action to take when the unit stops and enters a failed state or
|
||||
inactive state. Takes one of <option>none</option>, <option>reboot</option>,
|
||||
<option>reboot-force</option>, <option>reboot-immediate</option>, <option>poweroff</option>,
|
||||
<option>poweroff-force</option>, <option>poweroff-immediate</option>, <option>exit</option>,
|
||||
<option>exit-force</option>, <option>soft-reboot</option> and <option>soft-reboot-force</option>. In
|
||||
system mode, all options are allowed. In user mode, only <option>none</option>,
|
||||
<option>exit</option>, <option>exit-force</option>, <option>soft-reboot</option> and
|
||||
<option>soft-reboot-force</option> are allowed. Both options default to <option>none</option>.</para>
|
||||
|
||||
<para>If <option>none</option> is set, no action will be triggered. <option>reboot</option> causes a reboot
|
||||
following the normal shutdown procedure (i.e. equivalent to <command>systemctl reboot</command>).
|
||||
<option>reboot-force</option> causes a forced reboot which will terminate all processes forcibly but should
|
||||
cause no dirty file systems on reboot (i.e. equivalent to <command>systemctl reboot -f</command>) and
|
||||
<option>reboot-immediate</option> causes immediate execution of the
|
||||
<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, which
|
||||
might result in data loss (i.e. equivalent to <command>systemctl reboot -ff</command>). Similarly,
|
||||
<option>poweroff</option>, <option>poweroff-force</option>, <option>poweroff-immediate</option> have the effect
|
||||
of powering down the system with similar semantics. <option>exit</option> causes the manager to exit following
|
||||
the normal shutdown procedure, and <option>exit-force</option> causes it terminate without shutting down
|
||||
services. When <option>exit</option> or <option>exit-force</option> is used by default the exit status of the
|
||||
main process of the unit (if this applies) is returned from the service manager. However, this may be overridden
|
||||
with <varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see
|
||||
below.</para></listitem>
|
||||
<para>If <option>none</option> is set, no action will be triggered. <option>reboot</option> causes a
|
||||
reboot following the normal shutdown procedure (i.e. equivalent to <command>systemctl
|
||||
reboot</command>). <option>reboot-force</option> causes a forced reboot which will terminate all
|
||||
processes forcibly but should cause no dirty file systems on reboot (i.e. equivalent to
|
||||
<command>systemctl reboot -f</command>) and <option>reboot-immediate</option> causes immediate
|
||||
execution of the
|
||||
<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
|
||||
call, which might result in data loss (i.e. equivalent to <command>systemctl reboot
|
||||
-ff</command>). Similarly, <option>poweroff</option>, <option>poweroff-force</option>,
|
||||
<option>poweroff-immediate</option> have the effect of powering down the system with similar
|
||||
semantics. <option>exit</option> causes the manager to exit following the normal shutdown procedure,
|
||||
and <option>exit-force</option> causes it terminate without shutting down services. When
|
||||
<option>exit</option> or <option>exit-force</option> is used by default the exit status of the main
|
||||
process of the unit (if this applies) is returned from the service manager. However, this may be
|
||||
overridden with
|
||||
<varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see
|
||||
below. <option>soft-reboot</option> will trigger a userspace reboot
|
||||
operation. <option>soft-reboot-force</option> does that too, but does not go through the shutdown
|
||||
transaction beforehand.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -519,6 +519,15 @@
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>SIGRTMIN+7</constant></term>
|
||||
|
||||
<listitem><para>Reboots userspace, starts the <filename>soft-reboot.target</filename> unit. This is
|
||||
mostly equivalent to <command>systemctl start soft-reboot.target
|
||||
--job-mode=replace-irreversibly</command>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>SIGRTMIN+13</constant></term>
|
||||
|
||||
|
|
@ -543,6 +552,12 @@
|
|||
<listitem><para>Immediately reboots the machine with kexec.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>SIGRTMIN+17</constant></term>
|
||||
|
||||
<listitem><para>Immediately reboots the userspace.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>SIGRTMIN+20</constant></term>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue