X-Git-Url: http://git.ipfire.org/?a=blobdiff_plain;f=man%2Fsystemd.special.xml;h=14998b9647dd089f6f1b11fd38d4834ddfbba69d;hb=ccddd104fc95e0e769142af6e1fe1edec5be70a6;hp=d28f3d5f90d44aebc82cb7762f0b02bbcc0e244f;hpb=d90833c93c5fd171440d0d5bbe42f5aab88e393f;p=thirdparty%2Fsystemd.git

diff --git a/man/systemd.special.xml b/man/systemd.special.xml
index d28f3d5f90d..14998b9647d 100644
--- a/man/systemd.special.xml
+++ b/man/systemd.special.xml
@@ -92,6 +92,7 @@
     <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>,
@@ -203,12 +204,22 @@
       <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>
@@ -439,11 +450,18 @@
       <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>
@@ -502,11 +520,24 @@
           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>
 
@@ -711,7 +742,7 @@
           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