<?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">
+ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
-<refentry id="systemd.special">
+<refentry id="systemd.special" xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd.special</title>
<filename>slices.target</filename>,
<filename>smartcard.target</filename>,
<filename>sockets.target</filename>,
+ <filename>soft-reboot.target</filename>,
<filename>sound.target</filename>,
+ <filename>storage-target-mode.target</filename>,
<filename>suspend.target</filename>,
<filename>swap.target</filename>,
<filename>sysinit.target</filename>,
<para>The root mount point, i.e. the mount unit for the <filename>/</filename>
path. This unit is unconditionally active, during the entire time the system is up, as
this mount point is where the basic userspace is running from.</para>
+
+ <xi:include href="version-info.xml" xpointer="v235"/>
</listitem>
</varlistentry>
<citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for a service that propagates boot success information to the boot loader, and orders itself after
<filename>boot-complete.target</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v240"/>
</listitem>
</varlistentry>
<varlistentry>
<listitem>
<para>A target that pulls in setup services for all
verity integrity protected block devices.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/>
</listitem>
</varlistentry>
<varlistentry>
<filename>shutdown.target</filename>, which in turn should be
conflicted by all units that want to be scheduled for
shutdown when the service manager starts to exit.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>factory-reset.target</filename></term>
<listitem>
<para>A special target to trigger a factory reset.</para>
+
+ <xi:include href="version-info.xml" xpointer="v250"/>
</listitem>
</varlistentry>
<varlistentry>
<para>A special target unit for hibernating and suspending
the system at the same time. This pulls in
<filename>sleep.target</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v196"/>
</listitem>
</varlistentry>
<varlistentry>
<para>A special target unit for suspending the system for a period
of time, waking it and putting it into hibernate. This pulls in
<filename>sleep.target</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v239"/>
</listitem>
</varlistentry>
<listitem>
<para>This scope unit is where the system and service manager (PID 1) itself resides. It
is active as long as the system is running.</para>
+
+ <xi:include href="version-info.xml" xpointer="v235"/>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>initrd.target</filename></term>
<listitem>
- <para>This is the default target in the initramfs, similar to <filename>default.target</filename>
- in the main system. It is used to mount the real root and transition to it. See
+ <para>This is the default target in the initrd, similar to <filename>default.target</filename> in
+ the main system. It is used to mount the real root and transition to it. See
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
more discussion.</para>
+
+ <xi:include href="version-info.xml" xpointer="v245"/>
</listitem>
</varlistentry>
<varlistentry>
<filename>sysroot.mount</filename>. Thus, once this target is reached the
<filename>/sysroot/</filename> hierarchy is fully set up, in preparation for the transition to
the host OS.</para>
+
+ <xi:include href="version-info.xml" xpointer="v199"/>
</listitem>
</varlistentry>
<varlistentry>
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
automatically setup the appropriate dependencies to make this happen.
</para>
+
+ <xi:include href="version-info.xml" xpointer="v230"/>
</listitem>
</varlistentry>
<varlistentry>
automatically adds dependencies of type <varname>Before=</varname> to the
<filename>sysroot.mount</filename> unit, which is generated from the kernel command line's
<varname>root=</varname> setting (or equivalent).</para>
+
+ <xi:include href="version-info.xml" xpointer="v199"/>
</listitem>
</varlistentry>
<varlistentry>
the file system backing <filename>/usr/</filename> is mounted, though possibly at two different
locations, either below the <filename>/sysusr/</filename> or the <filename>/sysroot/</filename>
hierarchies.</para>
+
+ <xi:include href="version-info.xml" xpointer="v249"/>
</listitem>
</varlistentry>
<varlistentry>
<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>
<para>A standard target unit for starting all the containers
and other virtual machines. See <filename>systemd-nspawn@.service</filename>
for an example.</para>
+
+ <xi:include href="version-info.xml" xpointer="v233"/>
</listitem>
</varlistentry>
<varlistentry>
sufficiently set up. What precisely this requires is left to
the implementation of the network managing service.</para>
- <para>Note the distinction between this unit and
- <filename>network.target</filename>. This unit is an active
- unit (i.e. pulled in by the consumer rather than the
- provider of this functionality) and pulls in a service which
- possibly adds substantial delays to further execution. In
- contrast, <filename>network.target</filename> is a passive
- unit (i.e. pulled in by the provider of the functionality,
- rather than the consumer) that usually does not delay
- execution much. Usually, <filename>network.target</filename>
- is part of the boot of most systems, while
- <filename>network-online.target</filename> is not, except
- when at least one unit requires it. Also see <ulink
- url="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running
- Services After the Network is up</ulink> for more
- information.</para>
+ <para>Note the distinction between this unit and <filename>network.target</filename>. This unit
+ is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality)
+ and pulls in a service which possibly adds substantial delays to further execution. In contrast,
+ <filename>network.target</filename> is a passive unit (i.e. pulled in by the provider of the
+ functionality, rather than the consumer) that usually does not delay execution much. Usually,
+ <filename>network.target</filename> is part of the boot of most systems, while
+ <filename>network-online.target</filename> is not, except when at least one unit requires
+ it. Also see <ulink url="https://systemd.io/NETWORK_ONLINE">Running Services After the Network Is
+ Up</ulink> for more information.</para>
<para>All mount units for remote network file systems automatically pull in this unit, and order
themselves after it. Note that networking daemons that simply <emphasis>provide</emphasis>
logic. After the system has completed booting up, it will not track the online state of
the system anymore. Due to this it cannot be used as a network connection monitor
concept, it is purely a one-time system start-up concept.</para>
+
+ <xi:include href="version-info.xml" xpointer="v200"/>
</listitem>
</varlistentry>
<varlistentry>
dependencies from this unit. This is best configured via a
<varname>WantedBy=paths.target</varname> in the path unit's
[Install] section.</para>
+
+ <xi:include href="version-info.xml" xpointer="v199"/>
</listitem>
</varlistentry>
<varlistentry>
<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>
devices which are accessed over the network. It is used for
<citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>8</manvolnum></citerefentry>
entries marked with <option>_netdev</option>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v235"/>
</listitem>
</varlistentry>
<varlistentry>
integrity protected devices which are accessed over the network. It is used for
<citerefentry><refentrytitle>veritytab</refentrytitle><manvolnum>8</manvolnum></citerefentry>
entries marked with <option>_netdev</option>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/>
</listitem>
</varlistentry>
<varlistentry>
section should only be done for units that need to be always active. In that case care
needs to be taken to avoid creating a loop through the automatic dependencies on
"parent" slices.</para>
+
+ <xi:include href="version-info.xml" xpointer="v229"/>
</listitem>
</varlistentry>
<varlistentry>
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>
+
+ <xi:include href="version-info.xml" xpointer="v254"/>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>storage-target-mode.target</filename></term>
+ <listitem>
+ <para>A special target unit that can be booted into that selects the "Storage Target Mode" for
+ the OS. In this mode all local storage disks are exposed to external systems as block
+ devices. This invokes
+ <citerefentry><refentrytitle>systemd-storagetm.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ which exposes all local disks as NVMe-TCP devices for access over the network. It might as well
+ invoke other services too that make local disks available via other mechanisms.</para>
+ <xi:include href="version-info.xml" xpointer="v255"/>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term><filename>suspend.target</filename></term>
<listitem>
<listitem>
<para>A special target unit that is used for offline system updates.
<citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- will redirect the boot process to this target if <filename>/system-update</filename>
- exists. For more information see
+ will redirect the boot process to this target if <filename>/system-update</filename> or
+ <filename>/etc/system-update</filename> exists. For more information see
<citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
<filename>system-update-pre.target</filename> but not pull it in. Services which want to
run during system updates only, but before the actual system update is executed should
order themselves before this unit and pull it in. As a safety measure, if this does not
- happen, and <filename>/system-update</filename> still exists after
+ happen, and <filename>/system-update</filename> or
+ <filename>/etc/system-update</filename> still exists after
<filename>system-update.target</filename> is reached,
- <filename>system-update-cleanup.service</filename> will remove this symlink and reboot
+ <filename>system-update-cleanup.service</filename> will remove the symlinks and reboot
the machine.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/>
</listitem>
</varlistentry>
<varlistentry>
dependencies from this unit. This is best configured via
<varname>WantedBy=timers.target</varname> in the timer
unit's [Install] section.</para>
+
+ <xi:include href="version-info.xml" xpointer="v199"/>
</listitem>
</varlistentry>
<varlistentry>
<para>This may be used to pull in usb gadget
dynamically when UDC hardware is found.</para>
+
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
</variablelist>
part of any transaction unless a storage daemon is used. The instance name for instances of this
template unit must be a properly escaped block device node path, e.g.
<filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device
- <filename index="false">/dev/mapper/foobar</filename>.</para></listitem>
+ <filename index="false">/dev/mapper/foobar</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v245"/></listitem>
</varlistentry>
<varlistentry>
<term><filename>cryptsetup-pre.target</filename></term>
particularly useful to ensure that a service is shut down
only after all encrypted block devices are fully
stopped.</para>
+
+ <xi:include href="version-info.xml" xpointer="v215"/>
</listitem>
</varlistentry>
<varlistentry>
between units, this target is particularly useful to ensure
that a service is shut down only after all verity integrity
protected block devices are fully stopped.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/>
</listitem>
</varlistentry>
<varlistentry>
be committed to disk, marking the first boot as completed. If the boot is aborted at any time
before that, the next boot will re-run any units with <varname>ConditionFirstBoot=yes</varname>.
</para>
+
+ <xi:include href="version-info.xml" xpointer="v247"/>
</listitem>
</varlistentry>
<varlistentry>
unit before this unit if you want to make use of the console
just before <filename>getty</filename> is started.
</para>
+
+ <xi:include href="version-info.xml" xpointer="v235"/>
</listitem>
</varlistentry>
<varlistentry>
will be stopped before the network — to whatever level it might be set up by then — is shut
down. It is hence useful when writing service files that require network access on shutdown,
which should order themselves after this target, but not pull it in. Also see <ulink
- url="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running Services After
- the Network is up</ulink> for more information.</para></listitem>
+ url="https://systemd.io/NETWORK_ONLINE">Running Services After the Network Is Up</ulink> for
+ more information.</para></listitem>
</itemizedlist>
<para>It must emphasized that at start-up there's no guarantee that hardware-based devices have
<varlistentry>
<term><filename>network-pre.target</filename></term>
<listitem>
- <para>This passive target unit may be pulled in by services
- that want to run before any network is set up, for example
- for the purpose of setting up a firewall. All network
- management software orders itself after this target, but
- does not pull it in.</para>
+ <para>This passive target unit may be pulled in by services that want to run before any network
+ is set up, for example for the purpose of setting up a firewall. All network management software
+ orders itself after this target, but does not pull it in. Also see <ulink
+ url="https://systemd.io/NETWORK_ONLINE">Running Services After the Network Is Up</ulink> for more
+ information.</para>
+
+ <xi:include href="version-info.xml" xpointer="v214"/>
</listitem>
</varlistentry>
<varlistentry>
<citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service is a simple daemon that pulls in this target and orders itself before it. Besides
implementing the SNTP network protocol it maintains a timestamp file on disk whose modification
- time is regularlary updated. At service start-up the local system clock is set from that modification time,
+ time is regularly updated. At service start-up the local system clock is set from that modification time,
ensuring it increases roughly monotonically.</para>
<para>Note that ordering a unit after <filename>time-set.target</filename> only has effect if
monotonic. Enable
<citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
or an alternative NTP implementation to delay the target.</para>
+
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
<varlistentry>
<listitem>
<para>The root slice is the root of the slice hierarchy. It usually does not contain
units directly, but may be used to set defaults for the whole tree.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/>
</listitem>
</varlistentry>
<listitem>
<para>By default, all system services started by
<command>systemd</command> are found in this slice.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/>
</listitem>
</varlistentry>
behalf of the user, including the per-user systemd instance
are found in this slice. This is pulled in by
<filename>systemd-logind.service</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/>
</listitem>
</varlistentry>
registered with <command>systemd-machined</command> are
found in this slice. This is pulled in by
<filename>systemd-machined.service</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/>
</listitem>
</varlistentry>
</variablelist>
compose the normal user session should be pulled into this target. In this regard,
<filename>default.target</filename> is similar to <filename>multi-user.target</filename> in the
system instance, but it is a real unit, not an alias.</para>
+
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
</variablelist>
[Service]
…</programlisting>
</example>
+
+ <xi:include href="version-info.xml" xpointer="v234"/>
</listitem>
</varlistentry>
upgrade (which needs to happen before starting any process that might use them). This
target must be started before starting a graphical session like
<filename>gnome-session.target</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v234"/>
</listitem>
</varlistentry>
for the XDG desktop files in autostart directories. Desktop Environments can opt-in to use this
service by adding a <varname>Wants=</varname> dependency on
<filename>xdg-desktop-autostart.target</filename>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v246"/>
</listitem>
</varlistentry>
</variablelist>
<listitem>
<para>The root slice is the root of the user's slice hierarchy.
It usually does not contain units directly, but may be used to set defaults for the whole tree.</para>
+
+ <xi:include href="version-info.xml" xpointer="v247"/>
</listitem>
</varlistentry>
<command>systemd</command> are found in this slice.
All interactively launched applications like web browsers and text editors
as well as non-critical services should be placed into this slice.</para>
+
+ <xi:include href="version-info.xml" xpointer="v247"/>
</listitem>
</varlistentry>
This includes the display server, screen readers and other services such as DBus or XDG portals.
Such services should be configured to be part of this slice by
adding <varname>Slice=session.slice</varname> to their unit files.</para>
+
+ <xi:include href="version-info.xml" xpointer="v247"/>
</listitem>
</varlistentry>
This permits resources to be preferentially assigned to the other slices.
Examples include non-interactive tasks like file indexing or backup operations
where latency is not important.</para>
+
+ <xi:include href="version-info.xml" xpointer="v247"/>
</listitem>
</varlistentry>
</variablelist>
<refsect1>
<title>See Also</title>
- <para>
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- </para>
+ <para><simplelist type="inline">
+ <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
+ <member><citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
+ </simplelist></para>
</refsect1>
</refentry>
projects / thirdparty / systemd.git / blobdiff