<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
-<!ENTITY % entities SYSTEM "custom-entities.ent" >
-%entities;
-]>
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
This file is part of systemd.
<filename>shutdown.target</filename>,
<filename>sigpwr.target</filename>,
<filename>sleep.target</filename>,
+ <filename>slices.target</filename>,
<filename>smartcard.target</filename>,
<filename>sockets.target</filename>,
<filename>sound.target</filename>,
for this target unit to all services (except for those with
<varname>DefaultDependencies=no</varname>).</para>
- <para>Usually this should pull-in all mount points, swap
- devices, sockets, timers, and path units and other basic
- initialization necessary for general purpose daemons.</para>
+ <para>Usually, this should pull-in all local mount points plus
+ <filename>/var</filename>, <filename>/tmp</filename> and
+ <filename>/var/tmp</filename>, swap devices, sockets, timers,
+ path units and other basic initialization necessary for general
+ purpose daemons. The mentioned mount points are special cased
+ to allow them to be remote.
+ </para>
+
+ <para>This target usually does not pull in any non-target units
+ directly, but rather does so indirectly via other early boot targets.
+ It is instead meant as a synchronization point for late boot
+ services. Refer to
+ <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ for details on the targets involved.
+ </para>
+
</listitem>
</varlistentry>
<varlistentry>
<term><filename>ctrl-alt-del.target</filename></term>
<listitem>
<para>systemd starts this target whenever Control+Alt+Del is
- pressed on the console. Usually this should be aliased
+ pressed on the console. Usually, this should be aliased
(symlinked) to <filename>reboot.target</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>default.target</filename></term>
<listitem>
- <para>The default unit systemd starts at bootup. Usually
+ <para>The default unit systemd starts at bootup. Usually,
this should be aliased (symlinked) to
<filename>multi-user.target</filename> or
<filename>graphical.target</filename>.</para>
<varlistentry>
<term><filename>display-manager.service</filename></term>
<listitem>
- <para>The display manager service. Usually this should be
+ <para>The display manager service. Usually, this should be
aliased (symlinked) to <filename>gdm.service</filename> or a
similar display manager service.</para>
</listitem>
<varlistentry>
<term><filename>emergency.target</filename></term>
<listitem>
- <para>A special target unit that starts an emergency shell
- on the main console. This unit is supposed to be used with
- the kernel command line option
- <varname>systemd.unit=</varname> and has otherwise little
- use.
- </para>
+ <para>A special target unit that starts an emergency shell on the main console. This target does not pull in
+ any services or mounts. It is the most minimal version of starting the system in order to acquire an
+ interactive shell; the only processes running are usually just the system manager (PID 1) and the shell
+ process. This unit is supposed to be used with the kernel command line option
+ <varname>systemd.unit=</varname>; it is also used when a file system check on a required file system fails,
+ and boot-up cannot continue. Compare with <filename>rescue.target</filename>, which serves a similar purpose,
+ but also starts the most basic services and mounts all file systems.</para>
+
+ <para>Use the <literal>systemd.unit=emergency.target</literal> kernel command line option to boot into this
+ mode. A short alias for this kernel command line option is <literal>emergency</literal>, for compatibility
+ with SysV.</para>
+
+ <para>In many ways booting into <filename>emergency.target</filename> is similar to the effect of booting
+ with <literal>init=/bin/sh</literal> on the kernel command line, except that emergency mode provides you with
+ the full system and service manager, and allows starting individual units in order to continue the boot
+ process in steps.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>exit.target</filename></term>
+ <listitem>
+ <para>A special service unit for shutting down the system or
+ user service manager. It is equivalent to
+ <filename>poweroff.target</filename> on non-container
+ systems, and also works in containers.</para>
+
+ <para>systemd will start this unit when it receives a
+ request to shut down over D-Bus or a
+ <constant>SIGTERM</constant> or <constant>SIGINT</constant>
+ signal when running as user service daemon.</para>
+
+ <para>Normally, this (indirectly) pulls in
+ <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>
</listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><filename>rescue.target</filename></term>
<listitem>
- <para>A special target unit for setting up the base system
- and a rescue shell.</para>
+ <para>A special target unit that pulls in the base system (including system mounts) and spawns a rescue
+ shell. Isolate to this target in order to administer the system in single-user mode with all file systems
+ mounted but with no services running, except for the most basic. Compare with
+ <filename>emergency.target</filename>, which is much more reduced and does not provide the file systems or
+ most basic services.</para>
- <para><filename>runlevel1.target</filename> is an alias for
- this target unit, for compatibility with SysV.</para>
+ <para><filename>runlevel1.target</filename> is an alias for this target unit, for compatibility with
+ SysV.</para>
+
+ <para>Use the <literal>systemd.unit=rescue.target</literal> kernel command line option to boot into this
+ mode. A short alias for this kernel command line option is <literal>1</literal>, for compatibility with
+ SysV.</para>
</listitem>
</varlistentry>
<varlistentry>
hook units into the sleep state logic.</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><filename>slices.target</filename></term>
+ <listitem>
+ <para>A special target unit that sets up all slice units (see
+ <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+ details) that shall be active after boot. By default the generic <filename>user.slice</filename>,
+ <filename>system.slice</filename>, <filename>machines.slice</filename> slice units, as well as the root
+ slice unit <filename>-.slice</filename> are pulled in and ordered before this unit (see below).</para>
+
+ <para>It's a good idea to add <varname>WantedBy=slices.target</varname> lines to the <literal>[Install]</literal>
+ section of all slices units that may be installed dynamically.</para>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term><filename>sockets.target</filename></term>
<listitem>
<para>A special target unit that sets up all socket
- units.(see
+ units (see
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details) that shall be active after boot.</para>
<varlistentry>
<term><filename>sysinit.target</filename></term>
<listitem>
- <para>A special target unit covering early boot-up
- scripts.</para>
+ <para>This target pulls in the services required for system
+ initialization. System services pulled in by this target should
+ declare <varname>DefaultDependencies=no</varname> and specify
+ all their dependencies manually, including access to anything
+ more than a read only root filesystem. For details on the
+ dependencies of this target, refer to
+ <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><filename>umount.target</filename></term>
<listitem>
- <para>A special target unit that umounts all mount and
+ <para>A special target unit that unmounts all mount and
automount points on system shutdown.</para>
<para>Mounts that shall be unmounted on system shutdown
defined what that is supposed to mean, with one exception:
at shutdown, a unit that is ordered after
<filename>network.target</filename> will be stopped before
- the network -- to whatever level it might be set up then --
+ the network — to whatever level it might be set up 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
<para>When systemd runs as a user instance, the following special
units are available, which have similar definitions as their
system counterparts:
+ <filename>exit.target</filename>,
<filename>default.target</filename>,
<filename>shutdown.target</filename>,
<filename>sockets.target</filename>,
<filename>printer.target</filename>,
<filename>smartcard.target</filename>,
<filename>sound.target</filename>.</para>
-
- <para>In addition, the following special unit is understood only
- when systemd runs as service instance:</para>
-
- <variablelist>
- <varlistentry>
- <term><filename>exit.target</filename></term>
- <listitem>
- <para>A special service unit for shutting down the user
- service manager.</para>
-
- <para>Applications wanting to terminate the user service
- manager should start this unit. If systemd receives
- <constant>SIGTERM</constant> or <constant>SIGINT</constant>
- when running as user service daemon, it will start this
- unit.</para>
-
- <para>Normally, this pulls in
- <filename>shutdown.target</filename> which in turn should be
- conflicted by all units that want to be shut down on user
- service manager exit.</para>
- </listitem>
- </varlistentry>
- </variablelist>
</refsect1>
<refsect1>
<varlistentry>
<term><filename>system.slice</filename></term>
<listitem>
- <para>By default, all services services started by
+ <para>By default, all system services started by
<command>systemd</command> are found in this slice.</para>
</listitem>
</varlistentry>
projects / thirdparty / systemd.git / blobdiff