move man pages to appropriate directories

40 files changed, 19832 insertions, 0 deletions

diff --git a/src/grp-system/bootup.xml b/src/grp-system/bootup.xml
new file mode 100644
index 0000000000..986996398c
--- /dev/null
+++ b/src/grp-system/bootup.xml
@@ -0,0 +1,305 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="bootup">
+
+  <refentryinfo>
+    <title>bootup</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>bootup</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>bootup</refname>
+    <refpurpose>System bootup process</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A number of different components are involved in the system
+    boot. Immediately after power-up, the system BIOS will do minimal
+    hardware initialization, and hand control over to a boot loader
+    stored on a persistent storage device. This boot loader will then
+    invoke an OS kernel from disk (or the network). In the Linux case,
+    this kernel (optionally) extracts and executes an initial RAM disk
+    image (initrd), such as generated by
+    <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    which looks for the root file system (possibly using
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for this). After the root file system is found and mounted, the
+    initrd hands over control to the host's system manager (such as
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+    stored on the OS image, which is then responsible for probing all
+    remaining hardware, mounting all necessary file systems and
+    spawning all configured services.</para>
+
+    <para>On shutdown, the system manager stops all services, unmounts
+    all file systems (detaching the storage technologies backing
+    them), and then (optionally) jumps back into the initrd code which
+    unmounts/detaches the root file system and the storage it resides
+    on. As a last step, the system is powered down.</para>
+
+    <para>Additional information about the system boot process may be
+    found in
+    <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>System Manager Bootup</title>
+
+    <para>At boot, the system manager on the OS image is responsible
+    for initializing the required file systems, services and drivers
+    that are necessary for operation of the system. On
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    systems, this process is split up in various discrete steps which
+    are exposed as target units. (See
+    <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for detailed information about target units.) The boot-up process
+    is highly parallelized so that the order in which specific target
+    units are reached is not deterministic, but still adheres to a
+    limited amount of ordering structure.</para>
+
+    <para>When systemd starts up the system, it will activate all
+    units that are dependencies of <filename>default.target</filename>
+    (as well as recursively all dependencies of these dependencies).
+    Usually, <filename>default.target</filename> is simply an alias of
+    <filename>graphical.target</filename> or
+    <filename>multi-user.target</filename>, depending on whether the
+    system is configured for a graphical UI or only for a text
+    console. To enforce minimal ordering between the units pulled in,
+    a number of well-known target units are available, as listed on
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>The following chart is a structural overview of these
+    well-known units and their position in the boot-up logic. The
+    arrows describe which units are pulled in and ordered before which
+    other units. Units near the top are started before units nearer to
+    the bottom of the chart.</para>
+
+<programlisting>local-fs-pre.target
+         |
+         v
+(various mounts and   (various swap   (various cryptsetup
+ fsck services...)     devices...)        devices...)       (various low-level   (various low-level
+         |                  |                  |             services: udevd,     API VFS mounts:
+         v                  v                  v             tmpfiles, random     mqueue, configfs,
+  local-fs.target      swap.target     cryptsetup.target    seed, sysctl, ...)      debugfs, ...)
+         |                  |                  |                    |                    |
+         \__________________|_________________ | ___________________|____________________/
+                                              \|/
+                                               v
+                                        sysinit.target
+                                               |
+          ____________________________________/|\________________________________________
+         /                  |                  |                    |                    \
+         |                  |                  |                    |                    |
+         v                  v                  |                    v                    v
+     (various           (various               |                (various          rescue.service
+    timers...)          paths...)              |               sockets...)               |
+         |                  |                  |                    |                    v
+         v                  v                  |                    v              <emphasis>rescue.target</emphasis>
+   timers.target      paths.target             |             sockets.target
+         |                  |                  |                    |
+         v                  \_________________ | ___________________/
+                                              \|/
+                                               v
+                                         basic.target
+                                               |
+          ____________________________________/|                                 emergency.service
+         /                  |                  |                                         |
+         |                  |                  |                                         v
+         v                  v                  v                                 <emphasis>emergency.target</emphasis>
+     display-        (various system    (various system
+ manager.service         services           services)
+         |             required for            |
+         |            graphical UIs)           v
+         |                  |           <emphasis>multi-user.target</emphasis>
+         |                  |                  |
+         \_________________ | _________________/
+                           \|/
+                            v
+                  <emphasis>graphical.target</emphasis></programlisting>
+
+    <para>Target units that are commonly used as boot targets are
+    <emphasis>emphasized</emphasis>. These units are good choices as
+    goal targets, for example by passing them to the
+    <varname>systemd.unit=</varname> kernel command line option (see
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+    or by symlinking <filename>default.target</filename> to them.
+    </para>
+
+    <para><filename>timers.target</filename> is pulled-in by
+    <filename>basic.target</filename> asynchronously. This allows
+    timers units to depend on services which become only available
+    later in boot.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Bootup in the Initial RAM Disk (initrd)</title>
+    <para>The initial RAM disk implementation (initrd) can be set up
+    using systemd as well. In this case, boot up inside the initrd
+    follows the following structure.</para>
+
+    <para>The default target in the initrd is
+    <filename>initrd.target</filename>. The bootup process begins
+    identical to the system manager bootup (see above) until it
+    reaches <filename>basic.target</filename>. From there, systemd
+    approaches the special target <filename>initrd.target</filename>.
+    When the root device becomes available,
+    <filename>initd-root-device.target</filename> is reached.
+    If the root device can be mounted at
+    <filename>/sysroot</filename>, the
+    <filename>sysroot.mount</filename> unit becomes active and
+    <filename>initrd-root-fs.target</filename> is reached. The service
+    <filename>initrd-parse-etc.service</filename> scans
+    <filename>/sysroot/etc/fstab</filename> for a possible
+    <filename>/usr</filename> mount point and additional entries
+    marked with the <emphasis>x-initrd.mount</emphasis> option. All
+    entries found are mounted below <filename>/sysroot</filename>, and
+    <filename>initrd-fs.target</filename> is reached. The service
+    <filename>initrd-cleanup.service</filename> isolates to the
+    <filename>initrd-switch-root.target</filename>, where cleanup
+    services can run. As the very last step, the
+    <filename>initrd-switch-root.service</filename> is activated,
+    which will cause the system to switch its root to
+    <filename>/sysroot</filename>.
+    </para>
+
+<programlisting>                                               : (beginning identical to above)
+                                               :
+                                               v
+                                         basic.target
+                                               |                                 emergency.service
+                        ______________________/|                                         |
+                       /                       |                                         v
+                       |            initrd-root-device.target                    <emphasis>emergency.target</emphasis>
+                       |                       |
+                       |                       v
+                       |                  sysroot.mount
+                       |                       |
+                       |                       v
+                       |             initrd-root-fs.target
+                       |                       |
+                       |                       v
+                       v            initrd-parse-etc.service
+                (custom initrd                 |
+                 services...)                  v
+                       |            (sysroot-usr.mount and
+                       |             various mounts marked
+                       |               with fstab option
+                       |              x-initrd.mount...)
+                       |                       |
+                       |                       v
+                       |                initrd-fs.target
+                       \______________________ |
+                                              \|
+                                               v
+                                          initrd.target
+                                               |
+                                               v
+                                     initrd-cleanup.service
+                                          isolates to
+                                    initrd-switch-root.target
+                                               |
+                                               v
+                        ______________________/|
+                       /                       v
+                       |        initrd-udevadm-cleanup-db.service
+                       v                       |
+                (custom initrd                 |
+                 services...)                  |
+                       \______________________ |
+                                              \|
+                                               v
+                                   initrd-switch-root.target
+                                               |
+                                               v
+                                   initrd-switch-root.service
+                                               |
+                                               v
+                                     Transition to Host OS</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>System Manager Shutdown</title>
+
+    <para>System shutdown with systemd also consists of various target
+    units with some minimal ordering structure applied:</para>
+
+<programlisting>                                  (conflicts with  (conflicts with
+                                    all system     all file system
+                                     services)     mounts, swaps,
+                                         |           cryptsetup
+                                         |          devices, ...)
+                                         |                |
+                                         v                v
+                                  shutdown.target    umount.target
+                                         |                |
+                                         \_______   ______/
+                                                 \ /
+                                                  v
+                                         (various low-level
+                                              services)
+                                                  |
+                                                  v
+                                            final.target
+                                                  |
+            _____________________________________/ \_________________________________
+           /                         |                        |                      \
+           |                         |                        |                      |
+           v                         v                        v                      v
+systemd-reboot.service   systemd-poweroff.service   systemd-halt.service   systemd-kexec.service
+           |                         |                        |                      |
+           v                         v                        v                      v
+    <emphasis>reboot.target</emphasis>             <emphasis>poweroff.target</emphasis>            <emphasis>halt.target</emphasis>           <emphasis>kexec.target</emphasis></programlisting>
+
+    <para>Commonly used system shutdown targets are
+    <emphasis>emphasized</emphasis>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/grp-utils/systemd-analyze/systemd-analyze.xml b/src/grp-system/grp-utils/systemd-analyze/systemd-analyze.xml
new file mode 100644
index 0000000000..bc37765dff
--- /dev/null
+++ b/src/grp-system/grp-utils/systemd-analyze/systemd-analyze.xml
@@ -0,0 +1,388 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd-analyze"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-analyze</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Harald</firstname>
+        <surname>Hoyer</surname>
+        <email>harald@redhat.com</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-analyze</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-analyze</refname>
+    <refpurpose>Analyze system boot-up performance</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg>time</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">blame</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">critical-chain</arg>
+      <arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">plot</arg>
+      <arg choice="opt">&gt; file.svg</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">dot</arg>
+      <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg>
+      <arg choice="opt">&gt; file.dot</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">dump</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">set-log-level</arg>
+      <arg choice="plain"><replaceable>LEVEL</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">set-log-target</arg>
+      <arg choice="plain"><replaceable>TARGET</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">verify</arg>
+      <arg choice="opt" rep="repeat"><replaceable>FILES</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-analyze</command> may be used to determine
+    system boot-up performance statistics and retrieve other state and
+    tracing information from the system and service manager, and to
+    verify the correctness of unit files.</para>
+
+    <para><command>systemd-analyze time</command> prints the time
+    spent in the kernel before userspace has been reached, the time
+    spent in the initial RAM disk (initrd) before normal system
+    userspace has been reached, and the time normal system userspace
+    took to initialize. Note that these measurements simply measure
+    the time passed up to the point where all system services have
+    been spawned, but not necessarily until they fully finished
+    initialization or the disk is idle.</para>
+
+    <para><command>systemd-analyze blame</command> prints a list of
+    all running units, ordered by the time they took to initialize.
+    This information may be used to optimize boot-up times. Note that
+    the output might be misleading as the initialization of one
+    service might be slow simply because it waits for the
+    initialization of another service to complete.</para>
+
+    <para><command>systemd-analyze critical-chain
+    [<replaceable>UNIT...</replaceable>]</command> prints a tree of
+    the time-critical chain of units (for each of the specified
+    <replaceable>UNIT</replaceable>s or for the default target
+    otherwise). The time after the unit is active or started is
+    printed after the "@" character. The time the unit takes to start
+    is printed after the "+" character. Note that the output might be
+    misleading as the initialization of one service might depend on
+    socket activation and because of the parallel execution of
+    units.</para>
+
+    <para><command>systemd-analyze plot</command> prints an SVG
+    graphic detailing which system services have been started at what
+    time, highlighting the time they spent on initialization.</para>
+
+    <para><command>systemd-analyze dot</command> generates textual
+    dependency graph description in dot format for further processing
+    with the GraphViz
+    <citerefentry project='die-net'><refentrytitle>dot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool. Use a command line like <command>systemd-analyze dot | dot
+    -Tsvg > systemd.svg</command> to generate a graphical dependency
+    tree. Unless <option>--order</option> or
+    <option>--require</option> is passed, the generated graph will
+    show both ordering and requirement dependencies. Optional pattern
+    globbing style specifications (e.g. <filename>*.target</filename>)
+    may be given at the end. A unit dependency is included in the
+    graph if any of these patterns match either the origin or
+    destination node.</para>
+
+    <para><command>systemd-analyze dump</command> outputs a (usually
+    very long) human-readable serialization of the complete server
+    state. Its format is subject to change without notice and should
+    not be parsed by applications.</para>
+
+    <para><command>systemd-analyze set-log-level
+    <replaceable>LEVEL</replaceable></command> changes the current log
+    level of the <command>systemd</command> daemon to
+    <replaceable>LEVEL</replaceable> (accepts the same values as
+    <option>--log-level=</option> described in
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para>
+
+    <para><command>systemd-analyze set-log-target
+    <replaceable>TARGET</replaceable></command> changes the current log
+    target of the <command>systemd</command> daemon to
+    <replaceable>TARGET</replaceable> (accepts the same values as
+    <option>--log-target=</option>, described in
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para>
+
+    <para><command>systemd-analyze verify</command> will load unit
+    files and print warnings if any errors are detected. Files
+    specified on the command line will be loaded, but also any other
+    units referenced by them. This command works by prepending the
+    directories for all command line arguments at the beginning of the
+    unit load path, which means that all units files found in those
+    directories will be used in preference to the unit files found in
+    the standard locations, even if not listed explicitly.</para>
+
+    <para>If no command is passed, <command>systemd-analyze
+    time</command> is implied.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--user</option></term>
+
+        <listitem><para>Operates on the user systemd
+        instance.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--system</option></term>
+
+        <listitem><para>Operates on the system systemd instance. This
+        is the implied default.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--order</option></term>
+        <term><option>--require</option></term>
+
+        <listitem><para>When used in conjunction with the
+        <command>dot</command> command (see above), selects which
+        dependencies are shown in the dependency graph. If
+        <option>--order</option> is passed, only dependencies of type
+        <varname>After=</varname> or <varname>Before=</varname> are
+        shown. If <option>--require</option> is passed, only
+        dependencies of type <varname>Requires=</varname>,
+        <varname>Requisite=</varname>,
+        <varname>Wants=</varname> and <varname>Conflicts=</varname>
+        are shown. If neither is passed, this shows dependencies of
+        all these types.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--from-pattern=</option></term>
+        <term><option>--to-pattern=</option></term>
+
+        <listitem><para>When used in conjunction with the
+        <command>dot</command> command (see above), this selects which
+        relationships are shown in the dependency graph. Both options
+        require a
+        <citerefentry project='die-net'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        pattern as an argument, which will be matched against the
+        left-hand and the right-hand, respectively, nodes of a
+        relationship.</para>
+
+        <para>Each of these can be used more than once, in which case
+        the unit name must match one of the values. When tests for
+        both sides of the relation are present, a relation must pass
+        both tests to be shown. When patterns are also specified as
+        positional arguments, they must match at least one side of the
+        relation. In other words, patterns specified with those two
+        options will trim the list of edges matched by the positional
+        arguments, if any are given, and fully determine the list of
+        edges shown otherwise.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fuzz=</option><replaceable>timespan</replaceable></term>
+
+        <listitem><para>When used in conjunction with the
+        <command>critical-chain</command> command (see above), also
+        show units, which finished <replaceable>timespan</replaceable>
+        earlier, than the latest unit in the same level. The unit of
+        <replaceable>timespan</replaceable> is seconds unless
+        specified with a different unit, e.g.
+        "50ms".</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-man</option></term>
+
+        <listitem><para>Do not invoke man to verify the existence of
+        man pages listed in <varname>Documentation=</varname>.
+        </para></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples for <command>dot</command></title>
+
+    <example>
+      <title>Plots all dependencies of any unit whose name starts with
+      <literal>avahi-daemon</literal></title>
+
+      <programlisting>$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg > avahi.svg
+      $ eog avahi.svg</programlisting>
+    </example>
+
+    <example>
+      <title>Plots the dependencies between all known target units</title>
+
+      <programlisting>systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' | dot -Tsvg > targets.svg
+$ eog targets.svg</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples for <command>verify</command></title>
+
+    <para>The following errors are currently detected:</para>
+    <itemizedlist>
+      <listitem><para>unknown sections and directives,
+      </para></listitem>
+
+      <listitem><para>missing dependencies which are required to start
+      the given unit, </para></listitem>
+
+      <listitem><para>man pages listed in
+      <varname>Documentation=</varname> which are not found in the
+      system,</para></listitem>
+
+      <listitem><para>commands listed in <varname>ExecStart=</varname>
+      and similar which are not found in the system or not
+      executable.</para></listitem>
+    </itemizedlist>
+
+    <example>
+      <title>Misspelt directives</title>
+
+      <programlisting>$ cat ./user.slice
+[Unit]
+WhatIsThis=11
+Documentation=man:nosuchfile(1)
+Requires=different.service
+
+[Service]
+Desription=x
+
+$ systemd-analyze verify ./user.slice
+[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
+[./user.slice:13] Unknown section 'Service'. Ignoring.
+Error: org.freedesktop.systemd1.LoadFailed:
+   Unit different.service failed to load:
+   No such file or directory.
+Failed to create user.slice/start: Invalid argument
+user.slice: man nosuchfile(1) command failed with code 16
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Missing service units</title>
+
+      <programlisting>$ tail ./a.socket ./b.socket
+==> ./a.socket &lt;==
+[Socket]
+ListenStream=100
+
+==> ./b.socket &lt;==
+[Socket]
+ListenStream=100
+Accept=yes
+
+$ systemd-analyze verify ./a.socket ./b.socket
+Service a.service not loaded, a.socket cannot be started.
+Service b@0.service not loaded, b.socket cannot be started.
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="less-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/grp-utils/systemd-delta/systemd-delta.xml b/src/grp-system/grp-utils/systemd-delta/systemd-delta.xml
new file mode 100644
index 0000000000..99709604aa
--- /dev/null
+++ b/src/grp-system/grp-utils/systemd-delta/systemd-delta.xml
@@ -0,0 +1,205 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd-delta"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-delta</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-delta</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-delta</refname>
+    <refpurpose>Find overridden configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-delta</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-delta</command> may be used to identify and
+    compare configuration files that override other configuration
+    files. Files in <filename>/etc</filename> have highest priority,
+    files in <filename>/run</filename> have the second highest
+    priority, ..., files in <filename>/lib</filename> have lowest
+    priority. Files in a directory with higher priority override files
+    with the same name in directories of lower priority. In addition,
+    certain configuration files can have <literal>.d</literal>
+    directories which contain "drop-in" files with configuration
+    snippets which augment the main configuration file. "Drop-in"
+    files can be overridden in the same way by placing files with the
+    same name in a directory of higher priority (except that, in case
+    of "drop-in" files, both the "drop-in" file name and the name of
+    the containing directory, which corresponds to the name of the
+    main configuration file, must match). For a fuller explanation,
+    see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>The command line argument will be split into a prefix and a
+    suffix. Either is optional. The prefix must be one of the
+    directories containing configuration files
+    (<filename>/etc</filename>, <filename>/run</filename>,
+    <filename>/usr/lib</filename>, ...). If it is given, only
+    overriding files contained in this directory will be shown.
+    Otherwise, all overriding files will be shown. The suffix must be
+    a name of a subdirectory containing configuration files like
+    <filename>tmpfiles.d</filename>, <filename>sysctl.d</filename> or
+    <filename>systemd/system</filename>. If it is given, only
+    configuration files in this subdirectory (across all configuration
+    paths) will be analyzed. Otherwise, all configuration files will
+    be analyzed. If the command line argument is not given at all, all
+    configuration files will be analyzed. See below for some
+    examples.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--type=</option></term>
+
+        <listitem><para>When listing the differences, only list those
+        that are asked for. The list itself is a comma-separated list
+        of desired difference types.</para>
+
+        <para>Recognized types are:
+
+          <variablelist>
+            <varlistentry>
+              <term><varname>masked</varname></term>
+
+              <listitem><para>Show masked files</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>equivalent</varname></term>
+
+              <listitem><para>Show overridden files that while
+              overridden, do not differ in content.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>redirected</varname></term>
+
+              <listitem><para>Show files that are redirected to
+              another.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>overridden</varname></term>
+
+              <listitem><para>Show overridden, and changed
+              files.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>extended</varname></term>
+
+              <listitem><para>Show <filename>*.conf</filename> files
+              in drop-in directories for units.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>unchanged</varname></term>
+
+              <listitem><para>Show unmodified files
+              too.</para></listitem>
+            </varlistentry>
+          </variablelist>
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--diff=</option></term>
+
+        <listitem><para>When showing modified files, when a file is
+        overridden show a diff as well. This option takes a boolean
+        argument. If omitted, it defaults to
+        <option>true</option>.</para></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>To see all local configuration:</para>
+    <programlisting>systemd-delta</programlisting>
+
+    <para>To see all runtime configuration:</para>
+    <programlisting>systemd-delta /run</programlisting>
+
+    <para>To see all system unit configuration changes:</para>
+    <programlisting>systemd-delta systemd/system</programlisting>
+
+    <para>To see all runtime "drop-in" changes for system units:</para>
+    <programlisting>systemd-delta --type=extended /run/systemd/system</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/grp-utils/systemd-fstab-generator/systemd-fstab-generator.xml b/src/grp-system/grp-utils/systemd-fstab-generator/systemd-fstab-generator.xml
new file mode 100644
index 0000000000..a971cb3675
--- /dev/null
+++ b/src/grp-system/grp-utils/systemd-fstab-generator/systemd-fstab-generator.xml
@@ -0,0 +1,183 @@
+<?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">
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+<refentry id="systemd-fstab-generator">
+
+  <refentryinfo>
+    <title>systemd-fstab-generator</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-fstab-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-fstab-generator</refname>
+    <refpurpose>Unit generator for /etc/fstab</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-fstab-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-fstab-generator</filename> is a generator
+    that translates <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details) into native systemd units early at boot and when
+    configuration of the system manager is reloaded. This will
+    instantiate mount and swap units as necessary.</para>
+
+    <para>The <varname>passno</varname> field is treated like a simple
+    boolean, and the ordering information is discarded. However, if
+    the root file system is checked, it is checked before all the
+    other file systems.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about special <filename>/etc/fstab</filename>
+    mount options this generator understands.</para>
+
+    <para><filename>systemd-fstab-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-fstab-generator</filename> understands the
+    following kernel command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+
+      <varlistentry>
+        <term><varname>fstab=</varname></term>
+        <term><varname>rd.fstab=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to
+        <literal>yes</literal>. If <literal>no</literal>, causes the
+        generator to ignore any mounts or swaps configured in
+        <filename>/etc/fstab</filename>. <varname>rd.fstab=</varname>
+        is honored only by initial RAM disk (initrd) while
+        <varname>fstab=</varname> is honored by both the main system
+        and the initrd.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>root=</varname></term>
+
+        <listitem><para>Takes the root filesystem to mount in the
+        initrd. <varname>root=</varname> is honored by the
+        initrd.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>rootfstype=</varname></term>
+
+        <listitem><para>Takes the root filesystem type that will be
+        passed to the mount command. <varname>rootfstype=</varname> is
+        honored by the initrd.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>rootflags=</varname></term>
+
+        <listitem><para>Takes the root filesystem mount options to
+        use. <varname>rootflags=</varname> is honored by the
+        initrd.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>mount.usr=</varname></term>
+
+        <listitem><para>Takes the <filename>/usr</filename> filesystem
+        to be mounted by the initrd. If
+        <varname>mount.usrfstype=</varname> or
+        <varname>mount.usrflags=</varname> is set, then
+        <varname>mount.usr=</varname> will default to the value set in
+        <varname>root=</varname>.</para>
+
+        <para>Otherwise, this parameter defaults to the
+        <filename>/usr</filename> entry found in
+        <filename>/etc/fstab</filename> on the root filesystem.</para>
+
+        <para><varname>mount.usr=</varname> is honored by the initrd.
+        </para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>mount.usrfstype=</varname></term>
+
+        <listitem><para>Takes the <filename>/usr</filename> filesystem
+        type that will be passed to the mount command. If
+        <varname>mount.usr=</varname> or
+        <varname>mount.usrflags=</varname> is set, then
+        <varname>mount.usrfstype=</varname> will default to the value
+        set in <varname>rootfstype=</varname>.</para>
+
+        <para>Otherwise, this value will be read from the
+        <filename>/usr</filename> entry in
+        <filename>/etc/fstab</filename> on the root filesystem.</para>
+
+        <para><varname>mount.usrfstype=</varname> is honored by the
+        initrd.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>mount.usrflags=</varname></term>
+
+        <listitem><para>Takes the <filename>/usr</filename> filesystem
+        mount options to use. If <varname>mount.usr=</varname> or
+        <varname>mount.usrfstype=</varname> is set, then
+        <varname>mount.usrflags=</varname> will default to the value
+        set in <varname>rootflags=</varname>.</para>
+
+        <para>Otherwise, this value will be read from the
+        <filename>/usr</filename> entry in
+        <filename>/etc/fstab</filename> on the root filesystem.</para>
+
+        <para><varname>mount.usrflags=</varname> is honored by the
+        initrd.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/grp-utils/systemd-run/systemd-run.xml b/src/grp-system/grp-utils/systemd-run/systemd-run.xml
new file mode 100644
index 0000000000..9c1a29218e
--- /dev/null
+++ b/src/grp-system/grp-utils/systemd-run/systemd-run.xml
@@ -0,0 +1,459 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd-run"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-run</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-run</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-run</refname>
+    <refpurpose>Run programs in transient scope or service or timer units</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-run</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain"><replaceable>COMMAND</replaceable>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+      </arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-run</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">TIMER OPTIONS</arg>
+      <arg choice="req"><replaceable>COMMAND</replaceable></arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-run</command> may be used to create and
+    start a transient <filename>.service</filename> or
+    <filename>.scope</filename> unit and run the specified
+    <replaceable>COMMAND</replaceable> in it. It may also be used to
+    create and start transient <filename>.timer</filename>
+    units.</para>
+
+    <para>If a command is run as transient service unit, it will be
+    started and managed by the service manager like any other service,
+    and thus shows up in the output of <command>systemctl
+    list-units</command> like any other unit. It will run in a clean
+    and detached execution environment, with the service manager as
+    its parent process. In this mode, <command>systemd-run</command>
+    will start the service asynchronously in the background and return
+    after the command has begun execution.</para>
+
+    <para>If a command is run as transient scope unit, it will be
+    started by <command>systemd-run</command> itself as parent process
+    and will thus inherit the execution environment of the
+    caller. However, the processes of the command are managed by the
+    service manager similar to normal services, and will show up in
+    the output of <command>systemctl list-units</command>. Execution
+    in this case is synchronous, and will return only when the command
+    finishes. This mode is enabled via the <option>--scope</option>
+    switch (see below). </para>
+
+    <para>If a command is run with timer options such as
+    <option>--on-calendar=</option> (see below), a transient timer
+    unit is created alongside the service unit for the specified
+    command. Only the transient timer unit is started immediately, the
+    transient service unit will be started when the transient timer
+    elapses. If the <option>--unit=</option> is specified, the
+    <replaceable>COMMAND</replaceable> may be omitted. In this case,
+    <command>systemd-run</command> only creates a
+    <filename>.timer</filename> unit that invokes the specified unit
+    when elapsing.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem><para>Do not query the user for authentication for
+        privileged operations.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--scope</option></term>
+
+        <listitem>
+          <para>Create a transient <filename>.scope</filename> unit instead of
+          the default transient <filename>.service</filename> unit.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--unit=</option></term>
+
+        <listitem><para>Use this unit name instead of an automatically
+        generated one.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--property=</option></term>
+        <term><option>-p</option></term>
+
+        <listitem><para>Sets a unit property for the scope or service
+        unit that is created. This takes an assignment in the same
+        format as
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>set-property</command> command.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--description=</option></term>
+
+        <listitem><para>Provide a description for the service or scope
+        unit. If not specified, the command itself will be used as a
+        description. See <varname>Description=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--slice=</option></term>
+
+        <listitem><para>Make the new <filename>.service</filename> or
+        <filename>.scope</filename> unit part of the specified slice,
+        instead of the <filename>system.slice</filename>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--remain-after-exit</option></term>
+
+        <listitem><para>After the service or scope process has
+        terminated, keep the service around until it is explicitly
+        stopped. This is useful to collect runtime information about
+        the service after it finished running. Also see
+        <varname>RemainAfterExit=</varname> in
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--send-sighup</option></term>
+
+        <listitem><para>When terminating the scope or service unit,
+        send a SIGHUP immediately after SIGTERM. This is useful to
+        indicate to shells and shell-like processes that the
+        connection has been severed. Also see
+        <varname>SendSIGHUP=</varname> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--service-type=</option></term>
+
+        <listitem><para>Sets the service type. Also see
+        <varname>Type=</varname> in
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+        option has no effect in conjunction with
+        <option>--scope</option>. Defaults to
+        <constant>simple</constant>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--uid=</option></term>
+        <term><option>--gid=</option></term>
+
+        <listitem><para>Runs the service process under the UNIX user
+        and group. Also see <varname>User=</varname> and
+        <varname>Group=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--nice=</option></term>
+
+        <listitem><para>Runs the service process with the specified
+        nice level. Also see <varname>Nice=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-E <replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term>
+        <term><option>--setenv=<replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term>
+
+        <listitem><para>Runs the service process with the specified environment variable set.
+        Also see <varname>Environment=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pty</option></term>
+        <term><option>-t</option></term>
+
+        <listitem><para>When invoking a command, the service connects
+        its standard input and output to the invoking tty via a
+        pseudo TTY device. This allows invoking binaries as services
+        that expect interactive user input, such as interactive
+        command shells.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--quiet</option></term>
+        <term><option>-q</option></term>
+
+        <listitem><para>Suppresses additional informational output
+        while running. This is particularly useful in combination with
+        <option>--pty</option> when it will suppress the initial
+        message explaining how to terminate the TTY connection.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--on-active=</option></term>
+        <term><option>--on-boot=</option></term>
+        <term><option>--on-startup=</option></term>
+        <term><option>--on-unit-active=</option></term>
+        <term><option>--on-unit-inactive=</option></term>
+
+        <listitem><para>Defines monotonic timers relative to different
+        starting points. Also see <varname>OnActiveSec=</varname>,
+        <varname>OnBootSec=</varname>,
+        <varname>OnStartupSec=</varname>,
+        <varname>OnUnitActiveSec=</varname> and
+        <varname>OnUnitInactiveSec=</varname> in
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+        options have no effect in conjunction with
+        <option>--scope</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--on-calendar=</option></term>
+
+        <listitem><para>Defines realtime (i.e. wallclock) timers with
+        calendar event expressions. Also see
+        <varname>OnCalendar=</varname> in
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+        option has no effect in conjunction with
+        <option>--scope</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timer-property=</option></term>
+
+        <listitem><para>Sets a timer unit property for the timer unit
+        that is created. It is similar with
+        <option>--property</option> but only for created timer
+        unit. This option only has effect in conjunction with
+        <option>--on-active=</option>, <option>--on-boot=</option>,
+        <option>--on-startup=</option>,
+        <option>--on-unit-active=</option>,
+        <option>--on-unit-inactive=</option>,
+        <option>--on-calendar=</option>. This takes an assignment in
+        the same format as
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>set-property</command> command.</para> </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem>
+          <para>Do not synchronously wait for the requested operation
+          to finish. If this is not specified, the job will be
+          verified, enqueued and <command>systemd-run</command> will
+          wait until the unit's start-up is completed. By passing this
+          argument, it is only verified and enqueued.</para>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+    <para>All command line arguments after the first non-option
+    argument become part of the command line of the launched
+    process. If a command is run as service unit, its first argument
+    needs to be an absolute binary path.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Logging environment variables provided by systemd to services</title>
+
+      <programlisting># systemd-run env
+Running as unit: run-19945.service
+# journalctl -u run-19945.service
+Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env...
+Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env.
+Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
+Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8
+Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64</programlisting>
+    </example>
+
+    <example>
+      <title>Limiting resources available to a command</title>
+
+      <programlisting># systemd-run -p BlockIOWeight=10 updatedb</programlisting>
+
+      <para>This command invokes the
+      <citerefentry project='man-pages'><refentrytitle>updatedb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      tool, but lowers the block I/O weight for it to 10. See
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for more information on the <varname>BlockIOWeight=</varname>
+      property.</para>
+    </example>
+
+    <example>
+      <title>Running commands at a specified time</title>
+
+      <para>The following command will touch a file after 30 seconds.</para>
+
+      <programlisting># date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
+Mon Dec  8 20:44:24 KST 2014
+Running as unit: run-71.timer
+Will run service as unit: run-71.service
+# journalctl -b -u run-71.timer
+-- Logs begin at Fri 2014-12-05 19:09:21 KST, end at Mon 2014-12-08 20:44:54 KST. --
+Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
+Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
+# journalctl -b -u run-71.service
+-- Logs begin at Fri 2014-12-05 19:09:21 KST, end at Mon 2014-12-08 20:44:54 KST. --
+Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
+Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.</programlisting>
+    </example>
+
+    <example>
+      <title>Allowing access to the tty</title>
+
+      <para>The following command invokes <filename>/bin/bash</filename> as a service
+      passing its standard input, output and error to the calling TTY.</para>
+
+      <programlisting># systemd-run -t --send-sighup /bin/bash</programlisting>
+    </example>
+
+    <example>
+      <title>Start <command>screen</command> as a user service</title>
+
+      <programlisting>$ systemd-run --scope --user screen
+Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope.
+
+$ screen -ls
+There is a screen on:
+        492..laptop     (Detached)
+1 Socket in /var/run/screen/S-fatima.
+</programlisting>
+
+      <para>This starts the <command>screen</command> process as a child of the
+      <command>systemd --user</command> process that was started by
+      <filename>user@.service</filename>, in a scope unit. A
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      unit is used instead of a
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      unit, because <command>screen</command> will exit when detaching from the terminal,
+      and a service unit would be terminated. Running <command>screen</command>
+      as a user unit has the advantage that it is not part of the session scope.
+      If <varname>KillUserProcesses=yes</varname> is configured in
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      the default, the session scope will be terminated when the user logs
+      out of that session.</para>
+
+      <para>The <filename>user@.service</filename> is started automatically
+      when the user first logs in, and stays around as long as at least one
+      login session is open. After the user logs out of the last session,
+      <filename>user@.service</filename> and all services underneath it
+      are terminated. This behaviour is the default, when "lingering" is
+      not enabled for that user. Enabling lingering means that
+      <filename>user@.service</filename> is started automatically during
+      boot, even if the user is not logged in, and that the service is
+      not terminated when the user logs out.</para>
+
+      <para>Enabling lingering allows the user to run processes without being logged in,
+      for example to allow <command>screen</command> to persist after the user logs out,
+      even if the session scope is terminated. In the default configuration, users can
+      enable lingering for themselves:</para>
+
+      <programlisting>$ loginctl enable-linger</programlisting>
+    </example>
+  </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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/grp-utils/systemd-sysv-generator/systemd-sysv-generator.xml b/src/grp-system/grp-utils/systemd-sysv-generator/systemd-sysv-generator.xml
new file mode 100644
index 0000000000..2353eb3efe
--- /dev/null
+++ b/src/grp-system/grp-utils/systemd-sysv-generator/systemd-sysv-generator.xml
@@ -0,0 +1,97 @@
+<?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">
+<!--
+  This file is part of systemd.
+
+  Copyright 2014 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+<refentry id="systemd-sysv-generator" conditional="HAVE_SYSV_COMPAT">
+
+  <refentryinfo>
+    <title>systemd-sysv-generator</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Documentation</contrib>
+        <firstname>Zbigniew</firstname>
+        <surname>Jędrzejewski-Szmek</surname>
+        <email>zbyszek@in.waw.pl</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sysv-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sysv-generator</refname>
+    <refpurpose>Unit generator for SysV init scripts</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-sysv-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-sysv-generator</filename> is a generator
+    that creates wrapper .service units for
+    <ulink url="https://savannah.nongnu.org/projects/sysvinit">SysV init</ulink>
+    scripts in <filename>/etc/init.d/*</filename> at boot and when
+    configuration of the system manager is reloaded. This will allow
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to support them similarly to native units.</para>
+
+    <para><ulink url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB headers</ulink>
+    in SysV init scripts are interpreted, and the ordering specified
+    in the header is turned into dependencies between the generated
+    unit and other units. The LSB facilities
+    <literal>$remote_fs</literal>, <literal>$network</literal>,
+    <literal>$named</literal>, <literal>$portmap</literal>,
+    <literal>$time</literal> are supported and will be turned into
+    dependencies on specific native systemd targets.  See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more details.</para>
+
+    <para>SysV runlevels have corresponding systemd targets
+    (<filename>runlevel<replaceable>X</replaceable>.target</filename>).
+    The wrapper unit that is generated will be wanted by those targets
+    which correspond to runlevels for which the script is
+    enabled.</para>
+
+    <para><command>systemd</command> does not support SysV scripts as
+    part of early boot, so all wrapper units are ordered after
+    <filename>basic.target</filename>.</para>
+
+    <para><filename>systemd-sysv-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/kernel-command-line.xml b/src/grp-system/kernel-command-line.xml
new file mode 100644
index 0000000000..9c04849f66
--- /dev/null
+++ b/src/grp-system/kernel-command-line.xml
@@ -0,0 +1,382 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="kernel-command-line">
+
+  <refentryinfo>
+    <title>kernel-command-line</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>kernel-command-line</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>kernel-command-line</refname>
+    <refpurpose>Kernel command line parameters</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/proc/cmdline</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The kernel, the initial RAM disk (initrd) and
+    basic userspace functionality may be configured at boot via
+    kernel command line arguments.</para>
+
+    <para>For command line parameters understood by the kernel, please
+    see <ulink
+    url="https://www.kernel.org/doc/Documentation/kernel-parameters.txt"><filename>kernel-parameters.txt</filename></ulink>
+    and
+    <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>For command line parameters understood by the initial RAM
+    disk, please see
+    <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+    or the documentation of the specific initrd implementation of your
+    installation.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Core OS Command Line Arguments</title>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.unit=</varname></term>
+        <term><varname>rd.systemd.unit=</varname></term>
+        <term><varname>systemd.dump_core=</varname></term>
+        <term><varname>systemd.crash_chvt=</varname></term>
+        <term><varname>systemd.crash_shell=</varname></term>
+        <term><varname>systemd.crash_reboot=</varname></term>
+        <term><varname>systemd.confirm_spawn=</varname></term>
+        <term><varname>systemd.show_status=</varname></term>
+        <term><varname>systemd.log_target=</varname></term>
+        <term><varname>systemd.log_level=</varname></term>
+        <term><varname>systemd.log_color=</varname></term>
+        <term><varname>systemd.log_location=</varname></term>
+        <term><varname>systemd.default_standard_output=</varname></term>
+        <term><varname>systemd.default_standard_error=</varname></term>
+        <term><varname>systemd.setenv=</varname></term>
+        <term><varname>systemd.machine_id=</varname></term>
+        <listitem>
+          <para>Parameters understood by the system and service
+          manager to control system behavior. For details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.mask=</varname></term>
+        <term><varname>systemd.wants=</varname></term>
+        <term><varname>systemd.debug-shell</varname></term>
+        <listitem>
+          <para>Additional parameters understood by
+          <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+          to mask or start specific units at boot, or invoke a debug
+          shell on tty9.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.restore_state=</varname></term>
+        <listitem>
+          <para>This parameter is understood by several system tools
+          to control whether or not they should restore system state
+          from the previous boot. For details, see
+          <citerefentry><refentrytitle>systemd-backlight@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-rfkill.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>quiet</varname></term>
+        <listitem>
+          <para>Parameter understood by both the kernel and the system
+          and service manager to control console log verbosity. For
+          details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname></term>
+        <listitem>
+          <para>Parameter understood by both the kernel and the system
+          and service manager to control console log verbosity. For
+          details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>-b</varname></term>
+        <term><varname>emergency</varname></term>
+        <term><varname>rescue</varname></term>
+        <term><varname>single</varname></term>
+        <term><varname>s</varname></term>
+        <term><varname>S</varname></term>
+        <term><varname>1</varname></term>
+        <term><varname>2</varname></term>
+        <term><varname>3</varname></term>
+        <term><varname>4</varname></term>
+        <term><varname>5</varname></term>
+        <listitem>
+          <para>Parameters understood by the system and service
+          manager, as compatibility options. For details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>locale.LANG=</varname></term>
+        <term><varname>locale.LANGUAGE=</varname></term>
+        <term><varname>locale.LC_CTYPE=</varname></term>
+        <term><varname>locale.LC_NUMERIC=</varname></term>
+        <term><varname>locale.LC_TIME=</varname></term>
+        <term><varname>locale.LC_COLLATE=</varname></term>
+        <term><varname>locale.LC_MONETARY=</varname></term>
+        <term><varname>locale.LC_MESSAGES=</varname></term>
+        <term><varname>locale.LC_PAPER=</varname></term>
+        <term><varname>locale.LC_NAME=</varname></term>
+        <term><varname>locale.LC_ADDRESS=</varname></term>
+        <term><varname>locale.LC_TELEPHONE=</varname></term>
+        <term><varname>locale.LC_MEASUREMENT=</varname></term>
+        <term><varname>locale.LC_IDENTIFICATION=</varname></term>
+        <listitem>
+          <para>Parameters understood by the system and service
+          manager to control locale and language settings. For
+          details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>fsck.mode=</varname></term>
+        <term><varname>fsck.repair=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the file system checker
+          services. For details, see
+          <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>quotacheck.mode=</varname></term>
+
+        <listitem>
+          <para>Parameter understood by the file quota checker
+          service. For details, see
+          <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.journald.forward_to_syslog=</varname></term>
+        <term><varname>systemd.journald.forward_to_kmsg=</varname></term>
+        <term><varname>systemd.journald.forward_to_console=</varname></term>
+        <term><varname>systemd.journald.forward_to_wall=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the journal service. For
+          details, see
+          <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>vconsole.keymap=</varname></term>
+        <term><varname>vconsole.keymap.toggle=</varname></term>
+        <term><varname>vconsole.font=</varname></term>
+        <term><varname>vconsole.font.map=</varname></term>
+        <term><varname>vconsole.font.unimap=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the virtual console setup
+          logic. For details, see
+          <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>udev.log-priority=</varname></term>
+        <term><varname>rd.udev.log-priority=</varname></term>
+        <term><varname>udev.children-max=</varname></term>
+        <term><varname>rd.udev.children-max=</varname></term>
+        <term><varname>udev.exec-delay=</varname></term>
+        <term><varname>rd.udev.exec-delay=</varname></term>
+        <term><varname>udev.event-timeout=</varname></term>
+        <term><varname>rd.udev.event-timeout=</varname></term>
+        <term><varname>net.ifnames=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the device event managing
+          daemon. For details, see
+          <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>plymouth.enable=</varname></term>
+
+        <listitem>
+          <para>May be used to disable the Plymouth boot splash. For
+          details, see
+          <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks=</varname></term>
+        <term><varname>rd.luks=</varname></term>
+        <term><varname>luks.crypttab=</varname></term>
+        <term><varname>rd.luks.crypttab=</varname></term>
+        <term><varname>luks.name=</varname></term>
+        <term><varname>rd.luks.name=</varname></term>
+        <term><varname>luks.uuid=</varname></term>
+        <term><varname>rd.luks.uuid=</varname></term>
+        <term><varname>luks.options=</varname></term>
+        <term><varname>rd.luks.options=</varname></term>
+        <term><varname>luks.key=</varname></term>
+        <term><varname>rd.luks.key=</varname></term>
+
+        <listitem>
+          <para>Configures the LUKS full-disk encryption logic at
+          boot. For details, see
+          <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>fstab=</varname></term>
+        <term><varname>rd.fstab=</varname></term>
+
+        <listitem>
+          <para>Configures the <filename>/etc/fstab</filename> logic
+          at boot. For details, see
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>root=</varname></term>
+        <term><varname>rootfstype=</varname></term>
+        <term><varname>rootflags=</varname></term>
+        <term><varname>ro</varname></term>
+        <term><varname>rw</varname></term>
+
+        <listitem>
+          <para>Configures the root file system and its file system
+          type and mount options, as well as whether it shall be
+          mounted read-only or read-writable initially. For details,
+          see
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.gpt_auto=</varname></term>
+        <term><varname>rd.systemd.gpt_auto=</varname></term>
+
+        <listitem>
+          <para>Configures whether GPT based partition auto-discovery
+          shall be attempted. For details, see
+          <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.default_timeout_start_sec=</varname></term>
+
+        <listitem>
+          <para>Overwrites the default start job timeout <varname>DefaultTimeoutStartSec=</varname> at boot. For details,
+          see <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>modules-load=</varname></term>
+        <term><varname>rd.modules-load=</varname></term>
+
+        <listitem>
+          <para>Load a specific kernel module early at boot. For
+          details, see
+          <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>resume=</varname></term>
+
+        <listitem>
+          <para>Enables resume from hibernation using the specified
+          device. All
+          <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-like
+          paths are supported. For details, see
+          <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-backlight@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-rfkill.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemctl/halt.xml b/src/grp-system/systemctl/halt.xml
new file mode 100644
index 0000000000..e3fa60a915
--- /dev/null
+++ b/src/grp-system/systemctl/halt.xml
@@ -0,0 +1,176 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="halt"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>halt</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>halt</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>halt</refname>
+    <refname>poweroff</refname>
+    <refname>reboot</refname>
+    <refpurpose>Halt, power-off or reboot the machine</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>halt</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>poweroff</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>reboot</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>halt</command>, <command>poweroff</command>,
+    <command>reboot</command> may be used to halt, power-off or reboot
+    the machine.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--halt</option></term>
+
+        <listitem><para>Halt the machine, regardless of which one of
+        the three commands is invoked.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--poweroff</option></term>
+
+        <listitem><para>Power-off the machine, regardless of which one
+        of the three commands is invoked.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reboot</option></term>
+
+        <listitem><para>Reboot the machine, regardless of which one of
+        the three commands is invoked.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-f</option></term>
+        <term><option>--force</option></term>
+
+        <listitem><para>Force immediate halt, power-off, reboot. Do
+        not contact the init system.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-w</option></term>
+        <term><option>--wtmp-only</option></term>
+
+        <listitem><para>Only write wtmp shutdown entry, do not
+        actually halt, power-off, reboot.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-d</option></term>
+        <term><option>--no-wtmp</option></term>
+
+        <listitem><para>Do not write wtmp shutdown
+        entry.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--no-sync</option></term>
+
+        <listitem><para>Don't sync hard disks/storage media before
+        halt, power-off, reboot.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem><para>Do not send wall message before halt,
+        power-off, reboot.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <para>These are legacy commands available for compatibility
+    only.</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>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemctl/runlevel.xml b/src/grp-system/systemctl/runlevel.xml
new file mode 100644
index 0000000000..ca29c7c22c
--- /dev/null
+++ b/src/grp-system/systemctl/runlevel.xml
@@ -0,0 +1,192 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="runlevel"
+    xmlns:xi="http://www.w3.org/2001/XInclude"
+    conditional="HAVE_UTMP">
+
+  <refentryinfo>
+    <title>runlevel</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>runlevel</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>runlevel</refname>
+    <refpurpose>Print previous and current SysV runlevel</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>runlevel</command>
+      <arg choice="opt" rep="repeat">options</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Overview</title>
+
+    <para>"Runlevels" are an obsolete way to start and stop groups of
+    services used in SysV init. systemd provides a compatibility layer
+    that maps runlevels to targets, and associated binaries like
+    <command>runlevel</command>. Nevertheless, only one runlevel can
+    be "active" at a given time, while systemd can activate multiple
+    targets concurrently, so the mapping to runlevels is confusing
+    and only approximate. Runlevels should not be used in new code,
+    and are mostly useful as a shorthand way to refer the matching
+    systemd targets in kernel boot parameters.</para>
+
+    <table>
+      <title>Mapping between runlevels and systemd targets</title>
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="runlevel" />
+        <colspec colname="target" />
+        <thead>
+          <row>
+            <entry>Runlevel</entry>
+            <entry>Target</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>0</entry>
+            <entry><filename>poweroff.target</filename></entry>
+          </row>
+          <row>
+            <entry>1</entry>
+            <entry><filename>rescue.target</filename></entry>
+          </row>
+          <row>
+            <entry>2, 3, 4</entry>
+            <entry><filename>multi-user.target</filename></entry>
+          </row>
+          <row>
+            <entry>5</entry>
+            <entry><filename>graphical.target</filename></entry>
+          </row>
+          <row>
+            <entry>6</entry>
+            <entry><filename>reboot.target</filename></entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>runlevel</command> prints the previous and current
+    SysV runlevel if they are known.</para>
+
+    <para>The two runlevel characters are separated by a single space
+    character. If a runlevel cannot be determined, N is printed
+    instead. If neither can be determined, the word "unknown" is
+    printed.</para>
+
+    <para>Unless overridden in the environment, this will check the
+    utmp database for recent runlevel changes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following option is understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>If one or both runlevels could be determined, 0 is returned,
+    a non-zero failure code otherwise.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$RUNLEVEL</varname></term>
+
+        <listitem><para>If <varname>$RUNLEVEL</varname> is set,
+        <command>runlevel</command> will print this value as current
+        runlevel and ignore utmp.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$PREVLEVEL</varname></term>
+
+        <listitem><para>If <varname>$PREVLEVEL</varname> is set,
+        <command>runlevel</command> will print this value as previous
+        runlevel and ignore utmp.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/var/run/utmp</filename></term>
+
+        <listitem><para>The utmp database <command>runlevel</command>
+        reads the previous and current runlevel
+        from.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemctl/shutdown.xml b/src/grp-system/systemctl/shutdown.xml
new file mode 100644
index 0000000000..a8af387c67
--- /dev/null
+++ b/src/grp-system/systemctl/shutdown.xml
@@ -0,0 +1,175 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="shutdown"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>shutdown</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>shutdown</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>shutdown</refname>
+    <refpurpose>Halt, power-off or reboot the machine</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>shutdown</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt">TIME</arg>
+      <arg choice="opt" rep="repeat">WALL</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>shutdown</command> may be used to halt, power-off
+    or reboot the machine.</para>
+
+    <para>The first argument may be a time string (which is usually
+    <literal>now</literal>). Optionally, this may be followed by a
+    wall message to be sent to all logged-in users before going
+    down.</para>
+
+    <para>The time string may either be in the format
+    <literal>hh:mm</literal> for hour/minutes specifying the time to
+    execute the shutdown at, specified in 24h clock format.
+    Alternatively it may be in the syntax <literal>+m</literal>
+    referring to the specified number of minutes m from now.
+    <literal>now</literal> is an alias for <literal>+0</literal>, i.e.
+    for triggering an immediate shutdown. If no time argument is
+    specified, <literal>+1</literal> is implied.</para>
+
+    <para>Note that to specify a wall message you must specify a time
+    argument, too.</para>
+
+    <para>If the time argument is used, 5 minutes before the system
+    goes down the <filename>/run/nologin</filename> file is created to
+    ensure that further logins shall not be allowed.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-H</option></term>
+        <term><option>--halt</option></term>
+
+        <listitem><para>Halt the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-P</option></term>
+        <term><option>--poweroff</option></term>
+
+        <listitem><para>Power-off the machine (the
+        default).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--reboot</option></term>
+
+        <listitem><para>Reboot the
+        machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-h</option></term>
+
+        <listitem><para>Equivalent to <option>--poweroff</option>,
+        unless <option>--halt</option> is specified.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-k</option></term>
+
+        <listitem><para>Do not halt, power-off, reboot, just write
+        wall message.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem><para>Do not send wall
+        message before
+        halt, power-off, reboot.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-c</option></term>
+
+        <listitem><para>Cancel a pending shutdown. This may be used
+        cancel the effect of an invocation of
+        <command>shutdown</command> with a time argument that is not
+        <literal>+0</literal> or
+        <literal>now</literal>.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</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>halt</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemctl/systemctl.xml b/src/grp-system/systemctl/systemctl.xml
new file mode 100644
index 0000000000..991e9bafaf
--- /dev/null
+++ b/src/grp-system/systemctl/systemctl.xml
@@ -0,0 +1,1838 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!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;
+]>
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemctl"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemctl</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemctl</refname>
+    <refpurpose>Control the systemd system and service manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemctl</command> may be used to introspect and
+    control the state of the <literal>systemd</literal> system and
+    service manager. Please refer to
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for an introduction into the basic concepts and functionality this
+    tool manages.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--type=</option></term>
+
+        <listitem>
+          <para>The argument should be a comma-separated list of unit
+          types such as <option>service</option> and
+          <option>socket</option>.
+          </para>
+
+          <para>If one of the arguments is a unit type, when listing
+          units, limit display to certain unit types. Otherwise, units
+          of all types will be shown.</para>
+
+          <para>As a special case, if one of the arguments is
+          <option>help</option>, a list of allowed values will be
+          printed and the program will exit.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--state=</option></term>
+
+        <listitem>
+          <para>The argument should be a comma-separated list of unit
+          LOAD, SUB, or ACTIVE states. When listing units, show only
+          those in the specified states. Use <option>--state=failed</option>
+          to show only failed units.</para>
+
+          <para>As a special case, if one of the arguments is
+          <option>help</option>, a list of allowed values will be
+          printed and the program will exit.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--property=</option></term>
+
+        <listitem>
+          <para>When showing unit/job/manager properties with the
+          <command>show</command> command, limit display to properties
+          specified in the argument. The argument should be a
+          comma-separated list of property names, such as
+          <literal>MainPID</literal>. Unless specified, all known
+          properties are shown. If specified more than once, all
+          properties with the specified names are shown. Shell
+          completion is implemented for property names.</para>
+
+          <para>For the manager itself,
+          <command>systemctl show</command> will show all available
+          properties. Those properties are documented in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <para>Properties for units vary by unit type, so showing any
+          unit (even a non-existent one) is a way to list properties
+          pertaining to this type. Similarly, showing any job will list
+          properties pertaining to all jobs. Properties for units are
+          documented in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          and the pages for individual unit types
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          etc.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--all</option></term>
+
+        <listitem>
+          <para>When listing units, show all loaded units, regardless
+          of their state, including inactive units. When showing
+          unit/job/manager properties, show all properties regardless
+          whether they are set or not.</para>
+          <para>To list all units installed on the system, use the
+          <command>list-unit-files</command> command instead.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--recursive</option></term>
+
+        <listitem>
+          <para>When listing units, also show units of local
+          containers. Units of local containers will be prefixed with
+          the container name, separated by a single colon character
+          (<literal>:</literal>).</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reverse</option></term>
+
+        <listitem>
+          <para>Show reverse dependencies between units with
+          <command>list-dependencies</command>, i.e. follow
+          dependencies of type <varname>WantedBy=</varname>,
+          <varname>RequiredBy=</varname>,
+          <varname>PartOf=</varname>, <varname>BoundBy=</varname>,
+          instead of <varname>Wants=</varname> and similar.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--after</option></term>
+
+        <listitem>
+          <para>With <command>list-dependencies</command>, show the
+          units that are ordered before the specified unit. In other
+          words, recursively list units following the
+          <varname>After=</varname> dependency.</para>
+
+          <para>Note that any <varname>After=</varname> dependency is
+          automatically mirrored to create a
+          <varname>Before=</varname> dependency. Temporal dependencies
+          may be specified explicitly, but are also created implicitly
+          for units which are <varname>WantedBy=</varname> targets
+          (see
+          <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
+          and as a result of other directives (for example
+          <varname>RequiresMountsFor=</varname>). Both explicitly
+          and implicitly introduced dependencies are shown with
+          <command>list-dependencies</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--before</option></term>
+
+        <listitem>
+          <para>With <command>list-dependencies</command>, show the
+          units that are ordered after the specified unit. In other
+          words, recursively list units following the
+          <varname>Before=</varname> dependency.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem>
+          <para>Do not ellipsize unit names, process tree entries,
+          journal output, or truncate unit descriptions in the output
+          of <command>status</command>, <command>list-units</command>,
+          <command>list-jobs</command>, and
+          <command>list-timers</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--value</option></term>
+
+        <listitem>
+          <para>When printing properties with <command>show</command>,
+          only print the value, and skip the property name and
+          <literal>=</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--show-types</option></term>
+
+        <listitem>
+          <para>When showing sockets, show the type of the socket.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--job-mode=</option></term>
+
+        <listitem>
+        <para>When queuing a new job, this option controls how to deal with
+        already queued jobs. It takes one of <literal>fail</literal>,
+        <literal>replace</literal>,
+        <literal>replace-irreversibly</literal>,
+        <literal>isolate</literal>,
+        <literal>ignore-dependencies</literal>,
+        <literal>ignore-requirements</literal> or
+        <literal>flush</literal>. Defaults to
+        <literal>replace</literal>, except when the
+        <command>isolate</command> command is used which implies the
+        <literal>isolate</literal> job mode.</para>
+
+        <para>If <literal>fail</literal> is specified and a requested
+        operation conflicts with a pending job (more specifically:
+        causes an already pending start job to be reversed into a stop
+        job or vice versa), cause the operation to fail.</para>
+
+        <para>If <literal>replace</literal> (the default) is
+        specified, any conflicting pending job will be replaced, as
+        necessary.</para>
+
+        <para>If <literal>replace-irreversibly</literal> is specified,
+        operate like <literal>replace</literal>, but also mark the new
+        jobs as irreversible. This prevents future conflicting
+        transactions from replacing these jobs (or even being enqueued
+        while the irreversible jobs are still pending). Irreversible
+        jobs can still be cancelled using the <command>cancel</command>
+        command.</para>
+
+        <para><literal>isolate</literal> is only valid for start
+        operations and causes all other units to be stopped when the
+        specified unit is started. This mode is always used when the
+        <command>isolate</command> command is used.</para>
+
+        <para><literal>flush</literal> will cause all queued jobs to
+        be canceled when the new job is enqueued.</para>
+
+        <para>If <literal>ignore-dependencies</literal> is specified,
+        then all unit dependencies are ignored for this new job and
+        the operation is executed immediately. If passed, no required
+        units of the unit passed will be pulled in, and no ordering
+        dependencies will be honored. This is mostly a debugging and
+        rescue tool for the administrator and should not be used by
+        applications.</para>
+
+        <para><literal>ignore-requirements</literal> is similar to
+        <literal>ignore-dependencies</literal>, but only causes the
+        requirement dependencies to be ignored, the ordering
+        dependencies will still be honoured.</para>
+        </listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fail</option></term>
+
+        <listitem>
+          <para>Shorthand for <option>--job-mode=</option>fail.</para>
+          <para>When used with the <command>kill</command> command,
+          if no units were killed, the operation results in an error.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-i</option></term>
+        <term><option>--ignore-inhibitors</option></term>
+
+        <listitem>
+          <para>When system shutdown or a sleep state is requested,
+          ignore inhibitor locks. Applications can establish inhibitor
+          locks to avoid that certain important operations (such as CD
+          burning or suchlike) are interrupted by system shutdown or a
+          sleep state. Any user may take these locks and privileged
+          users may override these locks. If any locks are taken,
+          shutdown and sleep state requests will normally fail
+          (regardless of whether privileged or not) and a list of active locks
+          is printed. However, if <option>--ignore-inhibitors</option>
+          is specified, the locks are ignored and not printed, and the
+          operation attempted anyway, possibly requiring additional
+          privileges.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem>
+          <para>Suppress printing of the results of various commands
+          and also the hints about truncated log lines. This does not
+          suppress output of commands for which the printed output is
+          the only result (like <command>show</command>). Errors are
+          always printed.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem>
+          <para>Do not synchronously wait for the requested operation
+          to finish. If this is not specified, the job will be
+          verified, enqueued and <command>systemctl</command> will
+          wait until the unit's start-up is completed. By passing this
+          argument, it is only verified and enqueued.</para>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+
+      <!-- we do not document -failed here, as it has been made
+           redundant by -state=failed, which it predates. To keep
+           things simple, we only document the new switch, while
+           keeping the old one around for compatibility only. -->
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem>
+          <para>Do not send wall message before halt, power-off,
+          reboot.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--global</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command> and
+          <command>disable</command>, operate on the global user
+          configuration directory, thus enabling or disabling a unit
+          file globally for all future logins of all users.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-reload</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command> and
+          <command>disable</command>, do not implicitly reload daemon
+          configuration after executing the changes.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem>
+          <para>When used with <command>start</command> and related
+          commands, disables asking for passwords. Background services
+          may require input of a password or passphrase string, for
+          example to unlock system hard disks or cryptographic
+          certificates. Unless this option is specified and the
+          command is invoked from a terminal,
+          <command>systemctl</command> will query the user on the
+          terminal for the necessary secrets. Use this option to
+          switch this behavior off. In this case, the password must be
+          supplied by some other means (for example graphical password
+          agents) or the service might fail. This also disables
+          querying the user for authentication for privileged
+          operations.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-who=</option></term>
+
+        <listitem>
+          <para>When used with <command>kill</command>, choose which
+          processes to send a signal to. Must be one of
+          <option>main</option>, <option>control</option> or
+          <option>all</option> to select whether to kill only the main
+          process, the control process or all processes of the
+          unit. The main process of the unit is the one that defines
+          the life-time of it. A control process of a unit is one that
+          is invoked by the manager to induce state changes of it. For
+          example, all processes started due to the
+          <varname>ExecStartPre=</varname>,
+          <varname>ExecStop=</varname> or
+          <varname>ExecReload=</varname> settings of service units are
+          control processes. Note that there is only one control
+          process per unit at a time, as only one state change is
+          executed at a time. For services of type
+          <varname>Type=forking</varname>, the initial process started
+          by the manager for <varname>ExecStart=</varname> is a
+          control process, while the process ultimately forked off by
+          that one is then considered the main process of the unit (if
+          it can be determined). This is different for service units
+          of other types, where the process forked off by the manager
+          for <varname>ExecStart=</varname> is always the main process
+          itself. A service unit consists of zero or one main process,
+          zero or one control process plus any number of additional
+          processes. Not all unit types manage processes of these
+          types however. For example, for mount units, control processes
+          are defined (which are the invocations of
+          <filename>&MOUNT_PATH;</filename> and
+          <filename>&UMOUNT_PATH;</filename>), but no main process
+          is defined. If omitted, defaults to
+          <option>all</option>.</para>
+        </listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-s</option></term>
+        <term><option>--signal=</option></term>
+
+        <listitem>
+          <para>When used with <command>kill</command>, choose which
+          signal to send to selected processes. Must be one of the
+          well-known signal specifiers such as <constant>SIGTERM</constant>, <constant>SIGINT</constant> or
+          <constant>SIGSTOP</constant>. If omitted, defaults to
+          <option>SIGTERM</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-f</option></term>
+        <term><option>--force</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command>, overwrite
+          any existing conflicting symlinks.</para>
+
+          <para>When used with <command>halt</command>,
+          <command>poweroff</command>, <command>reboot</command> or
+          <command>kexec</command>, execute the selected operation
+          without shutting down all units. However, all processes will
+          be killed forcibly and all file systems are unmounted or
+          remounted read-only. This is hence a drastic but relatively
+          safe option to request an immediate reboot. If
+          <option>--force</option> is specified twice for these
+          operations, they will be executed immediately without
+          terminating any processes or unmounting any file
+          systems. Warning: specifying <option>--force</option> twice
+          with any of these operations might result in data
+          loss.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--message=</option></term>
+
+        <listitem>
+          <para>When used with <command>halt</command>,
+          <command>poweroff</command>, <command>reboot</command> or
+          <command>kexec</command>, set a short message explaining the reason
+          for the operation. The message will be logged together with the
+          default shutdown message.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--now</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command>, the units
+          will also be started. When used with <command>disable</command> or
+          <command>mask</command>, the units will also be stopped. The start
+          or stop operation is only carried out when the respective enable or
+          disable operation has been successful.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=</option></term>
+
+        <listitem>
+          <para>When used with
+          <command>enable</command>/<command>disable</command>/<command>is-enabled</command>
+          (and related commands), use an alternate root path when
+          looking for unit files.</para>
+        </listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--runtime</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command>,
+          <command>disable</command>, <command>edit</command>,
+          (and related commands), make changes only temporarily, so
+          that they are lost on the next reboot. This will have the
+          effect that changes are not made in subdirectories of
+          <filename>/etc</filename> but in <filename>/run</filename>,
+          with identical immediate effects, however, since the latter
+          is lost on reboot, the changes are lost too.</para>
+
+          <para>Similarly, when used with
+          <command>set-property</command>, make changes only
+          temporarily, so that they are lost on the next
+          reboot.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--preset-mode=</option></term>
+
+        <listitem>
+          <para>Takes one of <literal>full</literal> (the default),
+          <literal>enable-only</literal>,
+          <literal>disable-only</literal>. When used with the
+          <command>preset</command> or <command>preset-all</command>
+          commands, controls whether units shall be disabled and
+          enabled according to the preset rules, or only enabled, or
+          only disabled.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--lines=</option></term>
+
+        <listitem>
+          <para>When used with <command>status</command>, controls the
+          number of journal lines to show, counting from the most
+          recent ones. Takes a positive integer argument. Defaults to
+          10.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o</option></term>
+        <term><option>--output=</option></term>
+
+        <listitem>
+          <para>When used with <command>status</command>, controls the
+          formatting of the journal entries that are shown. For the
+          available choices, see
+          <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          Defaults to <literal>short</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--firmware-setup</option></term>
+
+        <listitem>
+          <para>When used with the <command>reboot</command> command,
+          indicate to the system's firmware to boot into setup
+          mode. Note that this is currently only supported on some EFI
+          systems and only if the system was booted in EFI
+          mode.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--plain</option></term>
+
+        <listitem>
+          <para>When used with <command>list-dependencies</command>,
+          <command>list-units</command> or <command>list-machines</command>, the
+          the output is printed as a list instead of a tree, and the bullet
+          circles are omitted.</para>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <refsect2>
+      <title>Unit Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-units <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
+
+          <listitem>
+            <para>List known units (subject to limitations specified
+            with <option>-t</option>). If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only
+            units matching one of them are shown.</para>
+
+            <para>This is the default command.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>list-sockets <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
+
+          <listitem>
+            <para>List socket units ordered by listening address.
+            If one or more <replaceable>PATTERN</replaceable>s are
+            specified, only socket units matching one of them are
+            shown. Produces output similar to
+            <programlisting>
+LISTEN           UNIT                        ACTIVATES
+/dev/initctl     systemd-initctl.socket      systemd-initctl.service
+...
+[::]:22          sshd.socket                 sshd.service
+kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+
+5 sockets listed.</programlisting>
+            Note: because the addresses might contains spaces, this output
+            is not suitable for programmatic consumption.
+            </para>
+
+            <para>See also the options <option>--show-types</option>,
+            <option>--all</option>, and <option>--state=</option>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>list-timers <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
+
+          <listitem>
+            <para>List timer units ordered by the time they elapse
+            next. If one or more <replaceable>PATTERN</replaceable>s
+            are specified, only units matching one of them are shown.
+            </para>
+
+            <para>See also the options <option>--all</option> and
+            <option>--state=</option>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>start <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Start (activate) one or more units specified on the
+            command line.</para>
+
+            <para>Note that glob patterns operate on the set of primary names of currently loaded units. Units which
+            are not active and are not in a failed state usually are not loaded, and will not be matched by any
+            pattern. In addition, in case of instantiated units, systemd is often unaware of the instance name until
+            the instance has been started. Therefore, using glob patterns with <command>start</command> has limited
+            usefulness. Also, secondary alias names of units are not considered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>stop <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Stop (deactivate) one or more units specified on the
+            command line.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>reload <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Asks all units listed on the command line to reload
+            their configuration. Note that this will reload the
+            service-specific configuration, not the unit configuration
+            file of systemd. If you want systemd to reload the
+            configuration file of a unit, use the
+            <command>daemon-reload</command> command. In other words:
+            for the example case of Apache, this will reload Apache's
+            <filename>httpd.conf</filename> in the web server, not the
+            <filename>apache.service</filename> systemd unit
+            file.</para>
+
+            <para>This command should not be confused with the
+            <command>daemon-reload</command> command.</para>
+          </listitem>
+
+        </varlistentry>
+        <varlistentry>
+          <term><command>restart <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Restart one or more units specified on the command
+            line. If the units are not running yet, they will be
+            started.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>try-restart <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Restart one or more units specified on the command
+            line if the units are running. This does nothing if units are not
+            running.</para>
+            <!-- Note that we don't document condrestart here, as that is just compatibility support, and we generally
+                 don't document that. -->
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>reload-or-restart <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Reload one or more units if they support it. If not,
+            restart them instead. If the units are not running yet, they
+            will be started.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>try-reload-or-restart <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Reload one or more units if they support it. If not,
+            restart them instead. This does nothing if the units are not
+            running.</para>
+            <!-- Note that we don't document force-reload here, as that is just compatibility support, and we generally
+                 don't document that. -->
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>isolate <replaceable>NAME</replaceable></command></term>
+
+          <listitem>
+            <para>Start the unit specified on the command line and its
+            dependencies and stop all others. If a unit name with no
+            extension is given, an extension of
+            <literal>.target</literal> will be assumed.</para>
+
+            <para>This is similar to changing the runlevel in a
+            traditional init system. The <command>isolate</command>
+            command will immediately stop processes that are not enabled
+            in the new unit, possibly including the graphical
+            environment or terminal you are currently using.</para>
+
+            <para>Note that this is allowed only on units where
+            <option>AllowIsolate=</option> is enabled. See
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>kill <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Send a signal to one or more processes of the
+            unit. Use <option>--kill-who=</option> to select which
+            process to kill. Use <option>--signal=</option> to select
+            the signal to send.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>is-active <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Check whether any of the specified units are active
+            (i.e. running). Returns an exit code
+            <constant>0</constant> if at least one is active, or
+            non-zero otherwise. Unless <option>--quiet</option> is
+            specified, this will also print the current unit state to
+            standard output.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>is-failed <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Check whether any of the specified units are in a
+            "failed" state. Returns an exit code
+            <constant>0</constant> if at least one has failed,
+            non-zero otherwise. Unless <option>--quiet</option> is
+            specified, this will also print the current unit state to
+            standard output.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>status</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...]</optional></term>
+
+          <listitem>
+            <para>Show terse runtime status information about one or
+            more units, followed by most recent log data from the
+            journal. If no units are specified, show system status. If
+            combined with <option>--all</option>, also show the status of
+            all units (subject to limitations specified with
+            <option>-t</option>). If a PID is passed, show information
+            about the unit the process belongs to.</para>
+
+            <para>This function is intended to generate human-readable
+            output. If you are looking for computer-parsable output,
+            use <command>show</command> instead. By default, this
+            function only shows 10 lines of output and ellipsizes
+            lines to fit in the terminal window. This can be changed
+            with <option>--lines</option> and <option>--full</option>,
+            see above. In addition, <command>journalctl
+            --unit=<replaceable>NAME</replaceable></command> or
+            <command>journalctl
+            --user-unit=<replaceable>NAME</replaceable></command> use
+            a similar filter for messages and might be more
+            convenient.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>show</command> <optional><replaceable>PATTERN</replaceable>...|<replaceable>JOB</replaceable>...</optional></term>
+
+          <listitem>
+            <para>Show properties of one or more units, jobs, or the
+            manager itself. If no argument is specified, properties of
+            the manager will be shown. If a unit name is specified,
+            properties of the unit is shown, and if a job ID is
+            specified, properties of the job is shown. By default, empty
+            properties are suppressed. Use <option>--all</option> to
+            show those too. To select specific properties to show, use
+            <option>--property=</option>. This command is intended to be
+            used whenever computer-parsable output is required. Use
+            <command>status</command> if you are looking for formatted
+            human-readable output.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>cat <replaceable>PATTERN</replaceable>...</command></term>
+
+          <listitem>
+            <para>Show backing files of one or more units. Prints the
+            "fragment" and "drop-ins" (source files) of units. Each
+            file is preceded by a comment which includes the file
+            name.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>set-property <replaceable>NAME</replaceable> <replaceable>ASSIGNMENT</replaceable>...</command></term>
+
+          <listitem>
+            <para>Set the specified unit properties at runtime where
+            this is supported. This allows changing configuration
+            parameter properties such as resource control settings at
+            runtime. Not all properties may be changed at runtime, but
+            many resource control settings (primarily those in
+            <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+            may. The changes are applied instantly, and stored on disk
+            for future boots, unless <option>--runtime</option> is
+            passed, in which case the settings only apply until the
+            next reboot. The syntax of the property assignment follows
+            closely the syntax of assignments in unit files.</para>
+
+            <para>Example: <command>systemctl set-property foobar.service CPUShares=777</command></para>
+
+            <para>If the specified unit appears to be inactive, the
+            changes will be only stored on disk as described
+            previously hence they will be effective when the unit will
+            be started.</para>
+
+            <para>Note that this command allows changing multiple
+            properties at the same time, which is preferable over
+            setting them individually. Like unit file configuration
+            settings, assigning the empty list to list parameters will
+            reset the list.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>help <replaceable>PATTERN</replaceable>...|<replaceable>PID</replaceable>...</command></term>
+
+          <listitem>
+            <para>Show manual pages for one or more units, if
+            available. If a PID is given, the manual pages for the unit
+            the process belongs to are shown.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>reset-failed [<replaceable>PATTERN</replaceable>...]</command></term>
+
+          <listitem>
+            <para>Reset the <literal>failed</literal> state of the
+            specified units, or if no unit name is passed, reset the state of all
+            units. When a unit fails in some way (i.e. process exiting
+            with non-zero error code, terminating abnormally or timing
+            out), it will automatically enter the
+            <literal>failed</literal> state and its exit code and status
+            is recorded for introspection by the administrator until the
+            service is restarted or reset with this command.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <command>list-dependencies</command>
+            <optional><replaceable>NAME</replaceable></optional>
+          </term>
+
+          <listitem>
+            <para>Shows units required and wanted by the specified
+            unit. This recursively lists units following the
+            <varname>Requires=</varname>,
+            <varname>Requisite=</varname>,
+            <varname>ConsistsOf=</varname>,
+            <varname>Wants=</varname>, <varname>BindsTo=</varname>
+            dependencies. If no unit is specified,
+            <filename>default.target</filename> is implied.</para>
+
+            <para>By default, only target units are recursively
+            expanded. When <option>--all</option> is passed, all other
+            units are recursively expanded as well.</para>
+
+            <para>Options <option>--reverse</option>,
+            <option>--after</option>, <option>--before</option>
+            may be used to change what types of dependencies
+            are shown.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Unit File Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-unit-files <optional><replaceable>PATTERN...</replaceable></optional></command></term>
+
+          <listitem>
+            <para>List installed unit files and their enablement state
+            (as reported by <command>is-enabled</command>). If one or
+            more <replaceable>PATTERN</replaceable>s are specified,
+            only units whose filename (just the last component of the
+            path) matches one of them are shown.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>enable <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Enable one or more unit files or unit file instances,
+            as specified on the command line. This will create a number
+            of symlinks as encoded in the <literal>[Install]</literal>
+            sections of the unit files. After the symlinks have been
+            created, the systemd configuration is reloaded (in a way that
+            is equivalent to <command>daemon-reload</command>) to ensure
+            the changes are taken into account immediately. Note that
+            this does <emphasis>not</emphasis> have the effect of also
+            starting any of the units being enabled. If this
+            is desired, either <option>--now</option> should be used
+            together with this command, or an additional <command>start</command>
+            command must be invoked for the unit. Also note that, in case of
+            instance enablement, symlinks named the same as instances
+            are created in the install location, however they all point to the
+            same template unit file.</para>
+
+            <para>This command will print the actions executed. This
+            output may be suppressed by passing <option>--quiet</option>.
+            </para>
+
+            <para>Note that this operation creates only the suggested
+            symlinks for the units. While this command is the
+            recommended way to manipulate the unit configuration
+            directory, the administrator is free to make additional
+            changes manually by placing or removing symlinks in the
+            directory. This is particularly useful to create
+            configurations that deviate from the suggested default
+            installation. In this case, the administrator must make sure
+            to invoke <command>daemon-reload</command> manually as
+            necessary to ensure the changes are taken into account.
+            </para>
+
+            <para>Enabling units should not be confused with starting
+            (activating) units, as done by the <command>start</command>
+            command. Enabling and starting units is orthogonal: units
+            may be enabled without being started and started without
+            being enabled. Enabling simply hooks the unit into various
+            suggested places (for example, so that the unit is
+            automatically started on boot or when a particular kind of
+            hardware is plugged in). Starting actually spawns the daemon
+            process (in case of service units), or binds the socket (in
+            case of socket units), and so on.</para>
+
+            <para>Depending on whether <option>--system</option>,
+            <option>--user</option>, <option>--runtime</option>,
+            or <option>--global</option> is specified, this enables the unit
+            for the system, for the calling user only, for only this boot of
+            the system, or for all future logins of all users, or only this
+            boot.  Note that in the last case, no systemd daemon
+            configuration is reloaded.</para>
+
+            <para>Using <command>enable</command> on masked units
+            results in an error.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>disable <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Disables one or more units. This removes all symlinks
+            to the specified unit files from the unit configuration
+            directory, and hence undoes the changes made by
+            <command>enable</command>. Note however that this removes
+            all symlinks to the unit files (i.e. including manual
+            additions), not just those actually created by
+            <command>enable</command>. This call implicitly reloads the
+            systemd daemon configuration after completing the disabling
+            of the units. Note that this command does not implicitly
+            stop the units that are being disabled. If this is desired, either
+            <option>--now</option> should be used together with this command, or
+            an additional <command>stop</command> command should be executed
+            afterwards.</para>
+
+            <para>This command will print the actions executed. This
+            output may be suppressed by passing <option>--quiet</option>.
+            </para>
+
+            <para>This command honors <option>--system</option>,
+            <option>--user</option>, <option>--runtime</option> and
+            <option>--global</option> in a similar way as
+            <command>enable</command>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>reenable <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Reenable one or more unit files, as specified on the
+            command line. This is a combination of
+            <command>disable</command> and <command>enable</command> and
+            is useful to reset the symlinks a unit is enabled with to
+            the defaults configured in the <literal>[Install]</literal>
+            section of the unit file.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>preset <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Reset the enable/disable status one or more unit files, as specified on
+            the command line, to the defaults configured in the preset policy files. This
+            has the same effect as <command>disable</command> or
+            <command>enable</command>, depending how the unit is listed in the preset
+            files.</para>
+
+            <para>Use <option>--preset-mode=</option> to control whether units shall be
+            enabled and disabled, or only enabled, or only disabled.</para>
+
+            <para>If the unit carries no install information, it will be silently ignored
+            by this command.</para>
+
+            <para>For more information on the preset policy format, see
+            <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+            For more information on the concept of presets, please consult the
+            <ulink url="http://freedesktop.org/wiki/Software/systemd/Preset">Preset</ulink>
+            document.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>preset-all</command></term>
+
+          <listitem>
+            <para>Resets all installed unit files to the defaults
+            configured in the preset policy file (see above).</para>
+
+            <para>Use <option>--preset-mode=</option> to control
+            whether units shall be enabled and disabled, or only
+            enabled, or only disabled.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>is-enabled <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Checks whether any of the specified unit files are
+            enabled (as with <command>enable</command>). Returns an
+            exit code of 0 if at least one is enabled, non-zero
+            otherwise. Prints the current enable status (see table).
+            To suppress this output, use <option>--quiet</option>.
+            </para>
+
+            <table>
+              <title>
+                <command>is-enabled</command> output
+              </title>
+
+              <tgroup cols='3'>
+                <thead>
+                  <row>
+                    <entry>Name</entry>
+                    <entry>Description</entry>
+                    <entry>Exit Code</entry>
+                  </row>
+                </thead>
+                <tbody>
+                  <row>
+                    <entry><literal>enabled</literal></entry>
+                    <entry morerows='1'>Enabled via <filename>.wants/</filename>, <filename>.requires/</filename> or alias symlinks (permanently in <filename>/etc/systemd/system/</filename>, or transiently in <filename>/run/systemd/system/</filename>).</entry>
+                    <entry morerows='1'>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>enabled-runtime</literal></entry>
+                  </row>
+                  <row>
+                    <entry><literal>linked</literal></entry>
+                    <entry morerows='1'>Made available through one or more symlinks to the unit file (permanently in <filename>/etc/systemd/system/</filename> or transiently in <filename>/run/systemd/system/</filename>), even though the unit file might reside outside of the unit file search path.</entry>
+                    <entry morerows='1'>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>linked-runtime</literal></entry>
+                  </row>
+                  <row>
+                    <entry><literal>masked</literal></entry>
+                    <entry morerows='1'>Completely disabled, so that any start operation on it fails (permanently in <filename>/etc/systemd/system/</filename> or transiently in <filename>/run/systemd/systemd/</filename>).</entry>
+                    <entry morerows='1'>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>masked-runtime</literal></entry>
+                  </row>
+                  <row>
+                    <entry><literal>static</literal></entry>
+                    <entry>The unit file is not enabled, and has no provisions for enabling in the <literal>[Install]</literal> unit file section.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>indirect</literal></entry>
+                    <entry>The unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the <literal>[Install]</literal> unit file section, listing other unit files that might be enabled.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>disabled</literal></entry>
+                    <entry>The unit file is not enabled, but contains an <literal>[Install]</literal> section with installation instructions.</entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>generated</literal></entry>
+                    <entry>The unit file was generated dynamically via a generator tool. See <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Generated unit files may not be enabled, they are enabled implicitly by their generator.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>transient</literal></entry>
+                    <entry>The unit file has been created dynamically with the runtime API. Transient units may not be enabled.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>bad</literal></entry>
+                    <entry>The unit file is invalid or another error occurred. Note that <command>is-enabled</command> will not actually return this state, but print an error message instead. However the unit file listing printed by <command>list-unit-files</command> might show it.</entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </table>
+
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>mask <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Mask one or more unit files, as specified on the
+            command line. This will link these units to
+            <filename>/dev/null</filename>, making it impossible to
+            start them. This is a stronger version of
+            <command>disable</command>, since it prohibits all kinds of
+            activation of the unit, including enablement and manual
+            activation. Use this option with care. This honors the
+            <option>--runtime</option> option to only mask temporarily
+            until the next reboot of the system. The <option>--now</option>
+            option can be used to ensure that the units are also stopped.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>unmask <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Unmask one or more unit files, as specified on the
+            command line. This will undo the effect of
+            <command>mask</command>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>link <replaceable>FILENAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Link a unit file that is not in the unit file search
+            paths into the unit file search path. This requires an
+            absolute path to a unit file. The effect of this can be
+            undone with <command>disable</command>. The effect of this
+            command is that a unit file is available for
+            <command>start</command> and other commands although it
+            is not installed directly in the unit search path.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>revert <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Revert one or more unit files to their vendor versions. This command removes drop-in configuration
+            files that modify the specified units, as well as any user-configured unit file that overrides a matching
+            vendor supplied unit file. Specifically, for a unit <literal>foo.service</literal> the matching directories
+            <literal>foo.service.d/</literal> with all their contained files are removed, both below the persistent and
+            runtime configuration directories (i.e. below <filename>/etc/systemd/system</filename> and
+            <filename>/run/systemd/system</filename>); if the unit file has a vendor-supplied version (i.e. a unit file
+            located below <filename>/usr</filename>) any matching peristent or runtime unit file that overrides it is
+            removed, too. Note that if a unit file has no vendor-supplied version (i.e. is only defined below
+            <filename>/etc/systemd/system</filename> or <filename>/run/systemd/system</filename>, but not in a unit
+            file stored below <filename>/usr</filename>), then it is not removed. Also, if a unit is masked, it is
+            unmasked.</para>
+
+            <para>Effectively, this command may be used to undo all changes made with <command>systemctl
+            edit</command>, <command>systemctl set-property</command> and <command>systemctl mask</command> and puts
+            the original unit file with its settings back in effect.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>add-wants <replaceable>TARGET</replaceable>
+          <replaceable>NAME</replaceable>...</command></term>
+          <term><command>add-requires <replaceable>TARGET</replaceable>
+          <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Adds <literal>Wants=</literal> or <literal>Requires=</literal>
+            dependencies, respectively, to the specified
+            <replaceable>TARGET</replaceable> for one or more units. </para>
+
+            <para>This command honors <option>--system</option>,
+            <option>--user</option>, <option>--runtime</option> and
+            <option>--global</option> in a way similar to
+            <command>enable</command>.</para>
+
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>edit <replaceable>NAME</replaceable>...</command></term>
+
+          <listitem>
+            <para>Edit a drop-in snippet or a whole replacement file if
+            <option>--full</option> is specified, to extend or override the
+            specified unit.</para>
+
+            <para>Depending on whether <option>--system</option> (the default),
+            <option>--user</option>, or <option>--global</option> is specified,
+            this command creates a drop-in file for each unit either for the system,
+            for the calling user, or for all futures logins of all users. Then,
+            the editor (see the "Environment" section below) is invoked on
+            temporary files which will be written to the real location if the
+            editor exits successfully.</para>
+
+            <para>If <option>--full</option> is specified, this will copy the
+            original units instead of creating drop-in files.</para>
+
+            <para>If <option>--runtime</option> is specified, the changes will
+            be made temporarily in <filename>/run</filename> and they will be
+            lost on the next reboot.</para>
+
+            <para>If the temporary file is empty upon exit, the modification of
+            the related unit is canceled.</para>
+
+            <para>After the units have been edited, systemd configuration is
+            reloaded (in a way that is equivalent to <command>daemon-reload</command>).
+            </para>
+
+            <para>Note that this command cannot be used to remotely edit units
+            and that you cannot temporarily edit units which are in
+            <filename>/etc</filename>, since they take precedence over
+            <filename>/run</filename>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>get-default</command></term>
+
+          <listitem>
+            <para>Return the default target to boot into. This returns
+            the target unit name <filename>default.target</filename>
+            is aliased (symlinked) to.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>set-default <replaceable>NAME</replaceable></command></term>
+
+          <listitem>
+            <para>Set the default target to boot into. This sets
+            (symlinks) the <filename>default.target</filename> alias
+            to the given target unit.</para>
+          </listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Machine Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-machines <optional><replaceable>PATTERN</replaceable>...</optional></command></term>
+
+          <listitem>
+            <para>List the host and all running local containers with
+            their state. If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only
+            containers matching one of them are shown.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Job Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-jobs <optional><replaceable>PATTERN...</replaceable></optional></command></term>
+
+          <listitem>
+            <para>List jobs that are in progress. If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only
+            jobs for units matching one of them are shown.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>cancel <replaceable>JOB</replaceable>...</command></term>
+
+          <listitem>
+            <para>Cancel one or more jobs specified on the command line
+            by their numeric job IDs. If no job ID is specified, cancel
+            all pending jobs.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Environment Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>show-environment</command></term>
+
+          <listitem>
+            <para>Dump the systemd manager environment block. The
+            environment block will be dumped in straight-forward form
+            suitable for sourcing into a shell script. This environment
+            block will be passed to all processes the manager
+            spawns.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>set-environment <replaceable>VARIABLE=VALUE</replaceable>...</command></term>
+
+          <listitem>
+            <para>Set one or more systemd manager environment variables,
+            as specified on the command line.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>unset-environment <replaceable>VARIABLE</replaceable>...</command></term>
+
+          <listitem>
+            <para>Unset one or more systemd manager environment
+            variables. If only a variable name is specified, it will be
+            removed regardless of its value. If a variable and a value
+            are specified, the variable is only removed if it has the
+            specified value.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>
+            <command>import-environment</command>
+            <optional><replaceable>VARIABLE...</replaceable></optional>
+          </term>
+
+          <listitem>
+            <para>Import all, one or more environment variables set on
+            the client into the systemd manager environment block. If
+            no arguments are passed, the entire environment block is
+            imported. Otherwise, a list of one or more environment
+            variable names should be passed, whose client-side values
+            are then imported into the manager's environment
+            block.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Manager Lifecycle Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>daemon-reload</command></term>
+
+          <listitem>
+            <para>Reload the systemd manager configuration. This will
+            rerun all generators (see
+            <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+            reload all unit files, and recreate the entire dependency
+            tree. While the daemon is being reloaded, all sockets
+            systemd listens on behalf of user configuration will stay
+            accessible.</para>
+
+            <para>This command should not be confused with the
+            <command>reload</command> command.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>daemon-reexec</command></term>
+
+          <listitem>
+            <para>Reexecute the systemd manager. This will serialize the
+            manager state, reexecute the process and deserialize the
+            state again. This command is of little use except for
+            debugging and package upgrades. Sometimes, it might be
+            helpful as a heavy-weight <command>daemon-reload</command>.
+            While the daemon is being reexecuted, all sockets systemd listening
+            on behalf of user configuration will stay accessible.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>System Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>is-system-running</command></term>
+
+          <listitem>
+            <para>Checks whether the system is operational. This
+            returns success (exit code 0) when the system is fully up
+            and running, specifically not in startup, shutdown or
+            maintenance mode, and with no failed services. Failure is
+            returned otherwise (exit code non-zero). In addition, the
+            current state is printed in a short string to standard
+            output, see the table below. Use <option>--quiet</option> to
+            suppress this output.</para>
+
+            <table>
+              <title><command>is-system-running</command> output</title>
+              <tgroup cols='3'>
+                <colspec colname='name'/>
+                <colspec colname='description'/>
+                <colspec colname='exit-code'/>
+                <thead>
+                  <row>
+                    <entry>Name</entry>
+                    <entry>Description</entry>
+                    <entry>Exit Code</entry>
+                  </row>
+                </thead>
+                <tbody>
+                  <row>
+                    <entry><varname>initializing</varname></entry>
+                    <entry><para>Early bootup, before
+                    <filename>basic.target</filename> is reached
+                    or the <varname>maintenance</varname> state entered.
+                    </para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>starting</varname></entry>
+                    <entry><para>Late bootup, before the job queue
+                    becomes idle for the first time, or one of the
+                    rescue targets are reached.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>running</varname></entry>
+                    <entry><para>The system is fully
+                    operational.</para></entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>degraded</varname></entry>
+                    <entry><para>The system is operational but one or more
+                    units failed.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>maintenance</varname></entry>
+                    <entry><para>The rescue or emergency target is
+                    active.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>stopping</varname></entry>
+                    <entry><para>The manager is shutting
+                    down.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>offline</varname></entry>
+                    <entry><para>The manager is not
+                    running. Specifically, this is the operational
+                    state if an incompatible program is running as
+                    system manager (PID 1).</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>unknown</varname></entry>
+                    <entry><para>The operational state could not be
+                    determined, due to lack of resources or another
+                    error cause.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </table>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>default</command></term>
+
+          <listitem>
+            <para>Enter default mode. This is mostly equivalent to
+            <command>isolate default.target</command>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>rescue</command></term>
+
+          <listitem>
+            <para>Enter rescue mode. This is mostly equivalent to
+            <command>isolate rescue.target</command>, but also prints a
+            wall message to all users.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>emergency</command></term>
+
+          <listitem>
+            <para>Enter emergency mode. This is mostly equivalent to
+            <command>isolate emergency.target</command>, but also prints
+            a wall message to all users.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>halt</command></term>
+
+          <listitem>
+            <para>Shut down and halt the system. This is mostly equivalent to
+            <command>start halt.target --job-mode=replace-irreversibly</command>, but also
+            prints a wall message to all users.  If combined with
+            <option>--force</option>, shutdown of all running services is
+            skipped, however all processes are killed and all file
+            systems are unmounted or mounted read-only, immediately
+            followed by the system halt.  If <option>--force</option> is
+            specified twice, the operation is immediately executed
+            without terminating any processes or unmounting any file
+            systems. This may result in data loss.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>poweroff</command></term>
+
+          <listitem>
+            <para>Shut down and power-off the system. This is mostly
+            equivalent to <command>start poweroff.target --job-mode=replace-irreversibly</command>,
+            but also prints a wall message to all users. If combined with
+            <option>--force</option>, shutdown of all running services is
+            skipped, however all processes are killed and all file
+            systems are unmounted or mounted read-only, immediately
+            followed by the powering off. If <option>--force</option> is
+            specified twice, the operation is immediately executed
+            without terminating any processes or unmounting any file
+            systems. This may result in data loss.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>reboot <optional><replaceable>arg</replaceable></optional></command></term>
+
+          <listitem>
+            <para>Shut down and reboot the system. This is mostly
+            equivalent to <command>start reboot.target --job-mode=replace-irreversibly</command>,
+            but also prints a wall message to all users. If combined with
+            <option>--force</option>, shutdown of all running services is
+            skipped, however all processes are killed and all file
+            systems are unmounted or mounted read-only, immediately
+            followed by the reboot. If <option>--force</option> is
+            specified twice, the operation is immediately executed
+            without terminating any processes or unmounting any file
+            systems. This may result in data loss.</para>
+
+            <para>If the optional argument
+            <replaceable>arg</replaceable> is given, it will be passed
+            as the optional argument to the
+            <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+            system call. The value is architecture and firmware
+            specific. As an example, <literal>recovery</literal> might
+            be used to trigger system recovery, and
+            <literal>fota</literal> might be used to trigger a
+            <quote>firmware over the air</quote> update.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>kexec</command></term>
+
+          <listitem>
+            <para>Shut down and reboot the system via kexec. This is
+            mostly equivalent to <command>start kexec.target --job-mode=replace-irreversibly</command>,
+            but also prints a wall message to all users. If combined
+            with <option>--force</option>, shutdown of all running
+            services is skipped, however all processes are killed and
+            all file systems are unmounted or mounted read-only,
+            immediately followed by the reboot.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>exit <optional><replaceable>EXIT_CODE</replaceable></optional></command></term>
+
+          <listitem>
+            <para>Ask the systemd manager to quit. This is only
+            supported for user service managers (i.e. in conjunction
+            with the <option>--user</option> option) or in containers
+            and is equivalent to <command>poweroff</command> otherwise.</para>
+
+            <para>The systemd manager can exit with a non-zero exit
+            code if the optional argument
+            <replaceable>EXIT_CODE</replaceable> is given.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>switch-root <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></command></term>
+
+          <listitem>
+            <para>Switches to a different root directory and executes a
+            new system manager process below it. This is intended for
+            usage in initial RAM disks ("initrd"), and will transition
+            from the initrd's system manager process (a.k.a. "init"
+            process) to the main system manager process. This call takes two
+            arguments: the directory that is to become the new root directory, and
+            the path to the new system manager binary below it to
+            execute as PID 1. If the latter is omitted or the empty
+            string, a systemd binary will automatically be searched for
+            and used as init. If the system manager path is omitted or
+            equal to the empty string, the state of the initrd's system
+            manager process is passed to the main system manager, which
+            allows later introspection of the state of the services
+            involved in the initrd boot.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>suspend</command></term>
+
+          <listitem>
+            <para>Suspend the system. This will trigger activation of
+            the special <filename>suspend.target</filename> target.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>hibernate</command></term>
+
+          <listitem>
+            <para>Hibernate the system. This will trigger activation of
+            the special <filename>hibernate.target</filename> target.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>hybrid-sleep</command></term>
+
+          <listitem>
+            <para>Hibernate and suspend the system. This will trigger
+            activation of the special
+            <filename>hybrid-sleep.target</filename> target.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Parameter Syntax</title>
+
+      <para>Unit commands listed above take either a single unit name (designated as <replaceable>NAME</replaceable>),
+      or multiple unit specifications (designated as <replaceable>PATTERN</replaceable>...). In the first case, the
+      unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"),
+      systemctl will append a suitable suffix, <literal>.service</literal> by default, and a type-specific suffix in
+      case of commands which operate only on specific unit types. For example,
+      <programlisting># systemctl start sshd</programlisting> and
+      <programlisting># systemctl start sshd.service</programlisting>
+      are equivalent, as are
+      <programlisting># systemctl isolate default</programlisting>
+      and
+      <programlisting># systemctl isolate default.target</programlisting>
+      Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute)
+      paths to mount unit names.
+      <programlisting># systemctl status /dev/sda
+# systemctl status /home</programlisting>
+      are equivalent to:
+      <programlisting># systemctl status dev-sda.device
+# systemctl status home.mount</programlisting>
+      In the second case, shell-style globs will be matched against the primary names of all currently loaded units;
+      literal unit names, with or without a suffix, will be treated as in the first case. This means that literal unit
+      names always refer to exactly one unit, but globs may match zero units and this is not considered an
+      error.</para>
+
+      <para>Glob patterns use
+      <citerefentry project='man-pages'><refentrytitle>fnmatch</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      so normal shell-style globbing rules are used, and
+      <literal>*</literal>, <literal>?</literal>,
+      <literal>[]</literal> may be used. See
+      <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for more details. The patterns are matched against the primary names of
+      currently loaded units, and patterns which do not match anything
+      are silently skipped. For example:
+      <programlisting># systemctl stop sshd@*.service</programlisting>
+      will stop all <filename>sshd@.service</filename> instances. Note that alias names of units, and units that aren't
+      loaded are not considered for glob expansion.
+      </para>
+
+      <para>For unit file commands, the specified <replaceable>NAME</replaceable> should be the name of the unit file
+      (possibly abbreviated, see above), or the absolute path to the unit file:
+      <programlisting># systemctl enable foo.service</programlisting>
+      or
+      <programlisting># systemctl link /path/to/foo.service</programlisting>
+      </para>
+    </refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_EDITOR</varname></term>
+
+        <listitem><para>Editor to use when editing units; overrides
+        <varname>$EDITOR</varname> and <varname>$VISUAL</varname>. If neither
+        <varname>$SYSTEMD_EDITOR</varname> nor <varname>$EDITOR</varname> nor
+        <varname>$VISUAL</varname> are present or if it is set to an empty
+        string or if their execution failed, systemctl will try to execute well
+        known editors in this order:
+        <citerefentry project='die-net'><refentrytitle>editor</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>nano</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>vim</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>vi</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+    <xi:include href="less-variables.xml" xpointer="pager"/>
+    <xi:include href="less-variables.xml" xpointer="less"/>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemctl/systemd-halt.service.xml b/src/grp-system/systemctl/systemd-halt.service.xml
new file mode 100644
index 0000000000..c94e2a1820
--- /dev/null
+++ b/src/grp-system/systemctl/systemd-halt.service.xml
@@ -0,0 +1,118 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd-halt.service">
+
+  <refentryinfo>
+    <title>systemd-halt.service</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-halt.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-halt.service</refname>
+    <refname>systemd-poweroff.service</refname>
+    <refname>systemd-reboot.service</refname>
+    <refname>systemd-kexec.service</refname>
+    <refname>systemd-shutdown</refname>
+    <refpurpose>System shutdown logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-halt.service</filename></para>
+    <para><filename>systemd-poweroff.service</filename></para>
+    <para><filename>systemd-reboot.service</filename></para>
+    <para><filename>systemd-kexec.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-shutdown</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-halt.service</filename> is a system
+    service that is pulled in by <filename>halt.target</filename> and
+    is responsible for the actual system halt. Similarly,
+    <filename>systemd-poweroff.service</filename> is pulled in by
+    <filename>poweroff.target</filename>,
+    <filename>systemd-reboot.service</filename> by
+    <filename>reboot.target</filename> and
+    <filename>systemd-kexec.service</filename> by
+    <filename>kexec.target</filename> to execute the respective
+    actions.</para>
+
+    <para>When these services are run, they ensure that PID 1 is
+    replaced by the
+    <filename>/usr/lib/systemd/systemd-shutdown</filename> tool which
+    is then responsible for the actual shutdown. Before shutting down,
+    this binary will try to unmount all remaining file systems,
+    disable all remaining swap devices, detach all remaining storage
+    devices and kill all remaining processes.</para>
+
+    <para>It is necessary to have this code in a separate binary
+    because otherwise rebooting after an upgrade might be broken — the
+    running PID 1 could still depend on libraries which are not
+    available any more, thus keeping the file system busy, which then
+    cannot be re-mounted read-only.</para>
+
+    <para>Immediately before executing the actual system
+    halt/poweroff/reboot/kexec <filename>systemd-shutdown</filename>
+    will run all executables in
+    <filename>/usr/lib/systemd/system-shutdown/</filename> and pass
+    one arguments to them: either <literal>halt</literal>,
+    <literal>poweroff</literal>, <literal>reboot</literal> or
+    <literal>kexec</literal>, depending on the chosen action. All
+    executables in this directory are executed in parallel, and
+    execution of the action is not continued before all executables
+    finished.</para>
+
+    <para>Note that <filename>systemd-halt.service</filename> (and the
+    related units) should never be executed directly. Instead, trigger
+    system shutdown with a command such as <literal>systemctl
+    halt</literal> or suchlike.</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>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemctl/telinit.xml b/src/grp-system/systemctl/telinit.xml
new file mode 100644
index 0000000000..02d31fbd46
--- /dev/null
+++ b/src/grp-system/systemctl/telinit.xml
@@ -0,0 +1,179 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="telinit"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>telinit</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>telinit</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>telinit</refname>
+    <refpurpose>Change SysV runlevel</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>telinit <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>telinit</command> may be used to change the SysV
+    system runlevel. Since the concept of SysV runlevels is obsolete
+    the runlevel requests will be transparently translated into
+    systemd unit activation requests.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem><para>Do not send wall message before
+        reboot/halt/power-off.</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>0</command></term>
+
+        <listitem><para>Power-off the machine. This is translated into
+        an activation request for <filename>poweroff.target</filename>
+        and is equivalent to <command>systemctl
+        poweroff</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>6</command></term>
+
+        <listitem><para>Reboot the machine. This is translated into an
+        activation request for <filename>reboot.target</filename> and
+        is equivalent to <command>systemctl
+        reboot</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>2</command></term>
+        <term><command>3</command></term>
+        <term><command>4</command></term>
+        <term><command>5</command></term>
+
+        <listitem><para>Change the SysV runlevel. This is translated
+        into an activation request for
+        <filename>runlevel2.target</filename>,
+        <filename>runlevel3.target</filename>, ... and is equivalent
+        to <command>systemctl isolate runlevel2.target</command>,
+        <command>systemctl isolate runlevel3.target</command>,
+        ...</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>1</command></term>
+        <term><command>s</command></term>
+        <term><command>S</command></term>
+
+        <listitem><para>Change into system rescue mode. This is
+        translated into an activation request for
+        <filename>rescue.target</filename> and is equivalent to
+        <command>systemctl rescue</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>q</command></term>
+        <term><command>Q</command></term>
+
+        <listitem><para>Reload daemon configuration. This is
+        equivalent to <command>systemctl
+        daemon-reload</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>u</command></term>
+        <term><command>U</command></term>
+
+        <listitem><para>Serialize state, reexecute daemon and
+        deserialize state again. This is equivalent to
+        <command>systemctl daemon-reexec</command>.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <para>This is a legacy command available for compatibility only.
+    It should not be used anymore, as the concept of runlevels is
+    obsolete.</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 project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd-system.conf.xml b/src/grp-system/systemd/systemd-system.conf.xml
new file mode 100644
index 0000000000..8833e73c72
--- /dev/null
+++ b/src/grp-system/systemd/systemd-system.conf.xml
@@ -0,0 +1,394 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd-system.conf"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd-system.conf</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-system.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-system.conf</refname>
+    <refname>system.conf.d</refname>
+    <refname>systemd-user.conf</refname>
+    <refname>user.conf.d</refname>
+    <refpurpose>System and session service manager configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/system.conf</filename>,
+    <filename>/etc/systemd/system.conf.d/*.conf</filename>,
+    <filename>/run/systemd/system.conf.d/*.conf</filename>,
+    <filename>/usr/lib/systemd/system.conf.d/*.conf</filename></para>
+    <para><filename>/etc/systemd/user.conf</filename>,
+    <filename>/etc/systemd/user.conf.d/*.conf</filename>,
+    <filename>/run/systemd/user.conf.d/*.conf</filename>,
+    <filename>/usr/lib/systemd/user.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>When run as a system instance, systemd interprets the
+    configuration file <filename>system.conf</filename> and the files
+    in <filename>system.conf.d</filename> directories; when run as a
+    user instance, systemd interprets the configuration file
+    <filename>user.conf</filename> and the files in
+    <filename>user.conf.d</filename> directories. These configuration
+    files contain a few settings controlling basic manager
+    operations.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    <literal>[Manager]</literal> section:</para>
+
+    <variablelist class='systemd-directives'>
+
+      <varlistentry>
+        <term><varname>LogLevel=</varname></term>
+        <term><varname>LogTarget=</varname></term>
+        <term><varname>LogColor=</varname></term>
+        <term><varname>LogLocation=</varname></term>
+        <term><varname>DumpCore=yes</varname></term>
+        <term><varname>CrashChangeVT=no</varname></term>
+        <term><varname>CrashShell=no</varname></term>
+        <term><varname>CrashReboot=no</varname></term>
+        <term><varname>ShowStatus=yes</varname></term>
+        <term><varname>DefaultStandardOutput=journal</varname></term>
+        <term><varname>DefaultStandardError=inherit</varname></term>
+
+        <listitem><para>Configures various parameters of basic manager
+        operation. These options may be overridden by the respective
+        command line arguments. See
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about these command line
+        arguments.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUAffinity=</varname></term>
+
+        <listitem><para>Configures the initial CPU affinity for the
+        init process. Takes a list of CPU indices or ranges separated
+        by either whitespace or commas. CPU ranges are specified by
+        the lower and upper CPU indices separated by a
+        dash.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>JoinControllers=cpu,cpuacct net_cls,netprio</varname></term>
+
+        <listitem><para>Configures controllers that shall be mounted
+        in a single hierarchy. By default, systemd will mount all
+        controllers which are enabled in the kernel in individual
+        hierarchies, with the exception of those listed in this
+        setting. Takes a space-separated list of comma-separated
+        controller names, in order to allow multiple joined
+        hierarchies. Defaults to 'cpu,cpuacct'. Pass an empty string
+        to ensure that systemd mounts all controllers in separate
+        hierarchies.</para>
+
+        <para>Note that this option is only applied once, at very
+        early boot. If you use an initial RAM disk (initrd) that uses
+        systemd, it might hence be necessary to rebuild the initrd if
+        this option is changed, and make sure the new configuration
+        file is included in it. Otherwise, the initrd might mount the
+        controller hierarchies in a different configuration than
+        intended, and the main system cannot remount them
+        anymore.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeWatchdogSec=</varname></term>
+        <term><varname>ShutdownWatchdogSec=</varname></term>
+
+        <listitem><para>Configure the hardware watchdog at runtime and
+        at reboot. Takes a timeout value in seconds (or in other time
+        units if suffixed with <literal>ms</literal>,
+        <literal>min</literal>, <literal>h</literal>,
+        <literal>d</literal>, <literal>w</literal>). If
+        <varname>RuntimeWatchdogSec=</varname> is set to a non-zero
+        value, the watchdog hardware
+        (<filename>/dev/watchdog</filename>) will be programmed to
+        automatically reboot the system if it is not contacted within
+        the specified timeout interval. The system manager will ensure
+        to contact it at least once in half the specified timeout
+        interval. This feature requires a hardware watchdog device to
+        be present, as it is commonly the case in embedded and server
+        systems. Not all hardware watchdogs allow configuration of the
+        reboot timeout, in which case the closest available timeout is
+        picked. <varname>ShutdownWatchdogSec=</varname> may be used to
+        configure the hardware watchdog when the system is asked to
+        reboot. It works as a safety net to ensure that the reboot
+        takes place even if a clean reboot attempt times out. By
+        default <varname>RuntimeWatchdogSec=</varname> defaults to 0
+        (off), and <varname>ShutdownWatchdogSec=</varname> to 10min.
+        These settings have no effect if a hardware watchdog is not
+        available.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CapabilityBoundingSet=</varname></term>
+
+        <listitem><para>Controls which capabilities to include in the
+        capability bounding set for PID 1 and its children. See
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details. Takes a whitespace-separated list of capability
+        names as read by
+        <citerefentry project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Capabilities listed will be included in the bounding set, all
+        others are removed. If the list of capabilities is prefixed
+        with ~, all but the listed capabilities will be included, the
+        effect of the assignment inverted. Note that this option also
+        affects the respective capabilities in the effective,
+        permitted and inheritable capability sets. The capability
+        bounding set may also be individually configured for units
+        using the <varname>CapabilityBoundingSet=</varname> directive
+        for units, but note that capabilities dropped for PID 1 cannot
+        be regained in individual units, they are lost for
+        good.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallArchitectures=</varname></term>
+
+        <listitem><para>Takes a space-separated list of architecture
+        identifiers. Selects from which architectures system calls may
+        be invoked on this system. This may be used as an effective
+        way to disable invocation of non-native binaries system-wide,
+        for example to prohibit execution of 32-bit x86 binaries on
+        64-bit x86-64 systems. This option operates system-wide, and
+        acts similar to the
+        <varname>SystemCallArchitectures=</varname> setting of unit
+        files, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. This setting defaults to the empty list, in which
+        case no filtering of system calls based on architecture is
+        applied. Known architecture identifiers are
+        <literal>x86</literal>, <literal>x86-64</literal>,
+        <literal>x32</literal>, <literal>arm</literal> and the special
+        identifier <literal>native</literal>. The latter implicitly
+        maps to the native architecture of the system (or more
+        specifically, the architecture the system manager was compiled
+        for). Set this setting to <literal>native</literal> to
+        prohibit execution of any non-native binaries. When a binary
+        executes a system call of an architecture that is not listed
+        in this setting, it will be immediately terminated with the
+        SIGSYS signal.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimerSlackNSec=</varname></term>
+
+        <listitem><para>Sets the timer slack in nanoseconds for PID 1,
+        which is inherited by all executed processes, unless
+        overridden individually, for example with the
+        <varname>TimerSlackNSec=</varname> setting in service units
+        (for details see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        The timer slack controls the accuracy of wake-ups triggered by
+        system timers. See
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for more information. Note that in contrast to most other time
+        span definitions this parameter takes an integer value in
+        nano-seconds if no unit is specified. The usual time units are
+        understood too.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultTimerAccuracySec=</varname></term>
+
+        <listitem><para>Sets the default accuracy of timer units. This
+        controls the global default for the
+        <varname>AccuracySec=</varname> setting of timer units, see
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. <varname>AccuracySec=</varname> set in individual
+        units override the global default for the specific unit.
+        Defaults to 1min. Note that the accuracy of timer units is
+        also affected by the configured timer slack for PID 1, see
+        <varname>TimerSlackNSec=</varname> above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultTimeoutStartSec=</varname></term>
+        <term><varname>DefaultTimeoutStopSec=</varname></term>
+        <term><varname>DefaultRestartSec=</varname></term>
+
+        <listitem><para>Configures the default timeouts for starting
+        and stopping of units, as well as the default time to sleep
+        between automatic restarts of units, as configured per-unit in
+        <varname>TimeoutStartSec=</varname>,
+        <varname>TimeoutStopSec=</varname> and
+        <varname>RestartSec=</varname> (for services, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on the per-unit settings). For non-service units,
+        <varname>DefaultTimeoutStartSec=</varname> sets the default
+        <varname>TimeoutSec=</varname>
+        value. <varname>DefaultTimeoutStartSec=</varname> and
+        <varname>DefaultTimeoutStopSec=</varname> default to
+        90s. <varname>DefaultRestartSec=</varname> defaults to
+        100ms.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultStartLimitIntervalSec=</varname></term>
+        <term><varname>DefaultStartLimitBurst=</varname></term>
+
+        <listitem><para>Configure the default unit start rate
+        limiting, as configured per-service by
+        <varname>StartLimitIntervalSec=</varname> and
+        <varname>StartLimitBurst=</varname>. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on the per-service settings.
+        <varname>DefaultStartLimitIntervalSec=</varname> defaults to
+        10s. <varname>DefaultStartLimitBurst=</varname> defaults to
+        5.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultEnvironment=</varname></term>
+
+        <listitem><para>Sets manager environment variables passed to
+        all executed processes. Takes a space-separated list of
+        variable assignments. See
+        <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about environment variables.</para>
+
+        <para>Example:
+
+        <programlisting>DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6"</programlisting>
+
+        Sets three variables
+        <literal>VAR1</literal>,
+        <literal>VAR2</literal>,
+        <literal>VAR3</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultCPUAccounting=</varname></term>
+        <term><varname>DefaultBlockIOAccounting=</varname></term>
+        <term><varname>DefaultMemoryAccounting=</varname></term>
+        <term><varname>DefaultTasksAccounting=</varname></term>
+
+        <listitem><para>Configure the default resource accounting
+        settings, as configured per-unit by
+        <varname>CPUAccounting=</varname>,
+        <varname>BlockIOAccounting=</varname>,
+        <varname>MemoryAccounting=</varname> and
+        <varname>TasksAccounting=</varname>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on the per-unit
+        settings. <varname>DefaulTasksAccounting=</varname> defaults
+        to on, the other three settings to off.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultTasksMax=</varname></term>
+
+        <listitem><para>Configure the default value for the per-unit
+        <varname>TasksMax=</varname> setting. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. This setting applies to all unit types that
+        support resource control settings, with the exception of slice
+        units. Defaults to 512.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultLimitCPU=</varname></term>
+        <term><varname>DefaultLimitFSIZE=</varname></term>
+        <term><varname>DefaultLimitDATA=</varname></term>
+        <term><varname>DefaultLimitSTACK=</varname></term>
+        <term><varname>DefaultLimitCORE=</varname></term>
+        <term><varname>DefaultLimitRSS=</varname></term>
+        <term><varname>DefaultLimitNOFILE=</varname></term>
+        <term><varname>DefaultLimitAS=</varname></term>
+        <term><varname>DefaultLimitNPROC=</varname></term>
+        <term><varname>DefaultLimitMEMLOCK=</varname></term>
+        <term><varname>DefaultLimitLOCKS=</varname></term>
+        <term><varname>DefaultLimitSIGPENDING=</varname></term>
+        <term><varname>DefaultLimitMSGQUEUE=</varname></term>
+        <term><varname>DefaultLimitNICE=</varname></term>
+        <term><varname>DefaultLimitRTPRIO=</varname></term>
+        <term><varname>DefaultLimitRTTIME=</varname></term>
+
+        <listitem><para>These settings control various default
+        resource limits for units. See
+        <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. The resource limit is possible to specify in two formats,
+        <option>value</option> to set soft and hard limits to the same value,
+        or <option>soft:hard</option> to set both limits individually (e.g. DefaultLimitAS=4G:16G).
+        Use the string <varname>infinity</varname> to
+        configure no limit on a specific resource. The multiplicative
+        suffixes K (=1024), M (=1024*1024) and so on for G, T, P and E
+        may be used for resource limits measured in bytes
+        (e.g. DefaultLimitAS=16G). For the limits referring to time values,
+        the usual time units ms, s, min, h and so on may be used (see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). Note that if no time unit is specified for
+        <varname>DefaultLimitCPU=</varname> the default unit of seconds is
+        implied, while for <varname>DefaultLimitRTTIME=</varname> the default
+        unit of microseconds is implied. Also, note that the effective
+        granularity of the limits might influence their
+        enforcement. For example, time limits specified for
+        <varname>DefaultLimitCPU=</varname> will be rounded up implicitly to
+        multiples of 1s. These  settings may be overridden in individual units
+        using the corresponding LimitXXX= directives. Note that these resource
+        limits are only defaults for units, they are not applied to PID 1
+        itself.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.automount.xml b/src/grp-system/systemd/systemd.automount.xml
new file mode 100644
index 0000000000..a43dc981bd
--- /dev/null
+++ b/src/grp-system/systemd/systemd.automount.xml
@@ -0,0 +1,173 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.automount">
+  <refentryinfo>
+    <title>systemd.automount</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.automount</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.automount</refname>
+    <refpurpose>Automount unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>automount</replaceable>.automount</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.automount</literal> encodes information about a file
+    system automount point controlled and supervised by
+    systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The automount specific configuration options
+    are configured in the [Automount] section.</para>
+
+    <para>Automount units must be named after the automount directories they control. Example: the automount point
+    <filename noindex='true'>/home/lennart</filename> must be configured in a unit file
+    <filename>home-lennart.automount</filename>. For details about the escaping logic used to convert a file system
+    path to a unit name see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note that
+    automount units cannot be templated, nor is it possible to add multiple names to an automount unit by creating
+    additional symlinks to its unit file.</para>
+
+    <para>For each automount unit file a matching mount unit file (see
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details) must exist which is activated when the automount path
+    is accessed. Example: if an automount unit
+    <filename>home-lennart.automount</filename> is active and the user
+    accesses <filename>/home/lennart</filename> the mount unit
+    <filename>home-lennart.mount</filename> will be activated.</para>
+
+    <para>Automount units may be used to implement on-demand mounting
+    as well as parallelized mounting of file systems.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>If an automount unit is beneath another mount unit in the
+    file system hierarchy, both a requirement and an ordering
+    dependency between both units are created automatically.</para>
+
+    <para>An implicit <varname>Before=</varname> dependency is created
+    between an automount unit and the mount unit it activates.</para>
+
+    <para>Automount units acquire automatic <varname>Before=</varname> and <varname>Conflicts=</varname> on
+    <filename>umount.target</filename> in order to be stopped during shutdown, unless
+    <varname>DefaultDependencies=no</varname> is set in the <literal>[Unit]</literal> section.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title><filename>fstab</filename></title>
+
+    <para>Automount units may either be configured via unit files, or
+    via <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details).</para>
+
+    <para>For details how systemd parses
+    <filename>/etc/fstab</filename> see
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>If an automount point is configured in both
+    <filename>/etc/fstab</filename> and a unit file, the configuration
+    in the latter takes precedence.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Automount files must include an [Automount] section, which
+    carries information about the file system automount points it
+    supervises. The options specific to the [Automount] section of
+    automount units are the following:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>Where=</varname></term>
+        <listitem><para>Takes an absolute path of a directory of the
+        automount point. If the automount point does not exist at time
+        that the automount point is installed, it is created. This
+        string must be reflected in the unit filename. (See above.)
+        This option is mandatory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+        <listitem><para>Directories of automount points (and any
+        parent directories) are automatically created if needed. This
+        option specifies the file system access mode used when
+        creating these directories. Takes an access mode in octal
+        notation. Defaults to 0755.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TimeoutIdleSec=</varname></term>
+        <listitem><para>Configures an idle timeout. Once the mount has been
+        idle for the specified time, systemd will attempt to unmount. Takes a
+        unit-less value in seconds, or a time span value such as "5min 20s".
+        Pass 0 to disable the timeout logic. The timeout is disabled by
+        default.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>automount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.device.xml b/src/grp-system/systemd/systemd.device.xml
new file mode 100644
index 0000000000..effed098dd
--- /dev/null
+++ b/src/grp-system/systemd/systemd.device.xml
@@ -0,0 +1,182 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.device">
+  <refentryinfo>
+    <title>systemd.device</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.device</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.device</refname>
+    <refpurpose>Device unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>device</replaceable>.device</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.device</literal> encodes information about a device unit
+    as exposed in the
+    sysfs/<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    device tree.</para>
+
+    <para>This unit type has no specific options. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic
+    <literal>[Unit]</literal> and <literal>[Install]</literal>
+    sections. A separate <literal>[Device]</literal> section does not
+    exist, since no device-specific options may be configured.</para>
+
+    <para>systemd will dynamically create device units for all kernel
+    devices that are marked with the "systemd" udev tag (by default
+    all block and network devices, and a few others). This may be used
+    to define dependencies between devices and other units. To tag a
+    udev device, use <literal>TAG+="systemd"</literal> in the udev
+    rules file, see
+    <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for details.</para>
+
+    <para>Device units are named after the <filename>/sys</filename>
+    and <filename>/dev</filename> paths they control. Example: the
+    device <filename noindex='true'>/dev/sda5</filename> is exposed in
+    systemd as <filename>dev-sda5.device</filename>. For details about
+    the escaping logic used to convert a file system path to a unit
+    name see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Many unit types automatically acquire dependencies on device
+    units of devices they require. For example,
+    <filename>.socket</filename> unit acquire dependencies on the
+    device units of the network interface specified in
+    <varname>BindToDevice=</varname>. Similar, swap and mount units
+    acquire dependencies on the units encapsulating their backing
+    block devices.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The udev Database</title>
+
+    <para>The settings of device units may either be configured via
+    unit files, or directly from the udev database (which is
+    recommended). The following udev device properties are understood
+    by systemd:</para>
+
+    <variablelist class='udev-directives'>
+      <varlistentry>
+        <term><varname>SYSTEMD_WANTS=</varname></term>
+        <term><varname>SYSTEMD_USER_WANTS=</varname></term>
+        <listitem><para>Adds dependencies of type
+        <varname>Wants</varname> from the device unit to all listed
+        units. The first form is used by the system systemd instance,
+        the second by user systemd instances. Those settings may be
+        used to activate arbitrary units when a specific device
+        becomes available.</para>
+
+        <para>Note that this and the other tags are not taken into
+        account unless the device is tagged with the
+        <literal>systemd</literal> string in the udev database,
+        because otherwise the device is not exposed as a systemd unit
+        (see above).</para>
+
+        <para>Note that systemd will only act on
+        <varname>Wants</varname> dependencies when a device first
+        becomes active. It will not act on them if they are added to
+        devices that are already active. Use
+        <varname>SYSTEMD_READY=</varname> (see below) to influence on
+        which udev event to trigger the dependencies.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSTEMD_ALIAS=</varname></term>
+        <listitem><para>Adds an additional alias name to the device
+        unit. This must be an absolute path that is automatically
+        transformed into a unit name. (See above.)</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSTEMD_READY=</varname></term>
+        <listitem><para>If set to 0, systemd will consider this device
+        unplugged even if it shows up in the udev tree. If this
+        property is unset or set to 1, the device will be considered
+        plugged if it is visible in the udev tree. This property has
+        no influence on the behavior when a device disappears from the
+        udev tree.</para>
+
+        <para>This option is useful to support devices that initially
+        show up in an uninitialized state in the tree, and for which a
+        <literal>changed</literal> event is generated the moment they
+        are fully set up. Note that <varname>SYSTEMD_WANTS=</varname>
+        (see above) is not acted on as long as
+        <varname>SYSTEMD_READY=0</varname> is set for a
+        device.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ID_MODEL_FROM_DATABASE=</varname></term>
+        <term><varname>ID_MODEL=</varname></term>
+
+        <listitem><para>If set, this property is used as description
+        string for the device unit.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.exec.xml b/src/grp-system/systemd/systemd.exec.xml
new file mode 100644
index 0000000000..3cf6de8256
--- /dev/null
+++ b/src/grp-system/systemd/systemd.exec.xml
@@ -0,0 +1,1475 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.exec">
+  <refentryinfo>
+    <title>systemd.exec</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.exec</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.exec</refname>
+    <refpurpose>Execution environment configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename>,
+    <filename><replaceable>socket</replaceable>.socket</filename>,
+    <filename><replaceable>mount</replaceable>.mount</filename>,
+    <filename><replaceable>swap</replaceable>.swap</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Unit configuration files for services, sockets, mount
+    points, and swap devices share a subset of configuration options
+    which define the execution environment of spawned
+    processes.</para>
+
+    <para>This man page lists the configuration options shared by
+    these four unit types. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files, and
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    and
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information on the specific unit configuration files. The
+    execution specific configuration options are configured in the
+    [Service], [Socket], [Mount], or [Swap] sections, depending on the
+    unit type.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>A few execution parameters result in additional, automatic
+    dependencies to be added.</para>
+
+    <para>Units with <varname>WorkingDirectory=</varname> or
+    <varname>RootDirectory=</varname> set automatically gain
+    dependencies of type <varname>Requires=</varname> and
+    <varname>After=</varname> on all mount units required to access
+    the specified paths. This is equivalent to having them listed
+    explicitly in <varname>RequiresMountsFor=</varname>.</para>
+
+    <para>Similar, units with <varname>PrivateTmp=</varname> enabled
+    automatically get mount unit dependencies for all mounts
+    required to access <filename>/tmp</filename> and
+    <filename>/var/tmp</filename>.</para>
+
+    <para>Units whose standard output or error output is connected to <option>journal</option>, <option>syslog</option>
+    or <option>kmsg</option> (or their combinations with console output, see below) automatically acquire dependencies
+    of type <varname>After=</varname> on <filename>systemd-journald.socket</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>WorkingDirectory=</varname></term>
+
+        <listitem><para>Takes an absolute directory path, or the
+        special value <literal>~</literal>. Sets the working directory
+        for executed processes. If set to <literal>~</literal>, the
+        home directory of the user specified in
+        <varname>User=</varname> is used. If not set, defaults to the
+        root directory when systemd is running as a system instance
+        and the respective user's home directory if run as user. If
+        the setting is prefixed with the <literal>-</literal>
+        character, a missing working directory is not considered
+        fatal. Note that setting this parameter might result in
+        additional dependencies to be added to the unit (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootDirectory=</varname></term>
+
+        <listitem><para>Takes an absolute directory path. Sets the
+        root directory for executed processes, with the <citerefentry
+        project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        system call. If this is used, it must be ensured that the
+        process binary and all its auxiliary files are available in
+        the <function>chroot()</function> jail. Note that setting this
+        parameter might result in additional dependencies to be added
+        to the unit (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>User=</varname></term>
+        <term><varname>Group=</varname></term>
+
+        <listitem><para>Sets the Unix user or group that the processes
+        are executed as, respectively. Takes a single user or group
+        name or ID as argument. If no group is set, the default group
+        of the user is chosen.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SupplementaryGroups=</varname></term>
+
+        <listitem><para>Sets the supplementary Unix groups the
+        processes are executed as. This takes a space-separated list
+        of group names or IDs. This option may be specified more than
+        once, in which case all listed groups are set as supplementary
+        groups. When the empty string is assigned, the list of
+        supplementary groups is reset, and all assignments prior to
+        this one will have no effect. In any way, this option does not
+        override, but extends the list of supplementary groups
+        configured in the system group database for the
+        user.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Nice=</varname></term>
+
+        <listitem><para>Sets the default nice level (scheduling
+        priority) for executed processes. Takes an integer between -20
+        (highest priority) and 19 (lowest priority). See
+        <citerefentry><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OOMScoreAdjust=</varname></term>
+
+        <listitem><para>Sets the adjustment level for the
+        Out-Of-Memory killer for executed processes. Takes an integer
+        between -1000 (to disable OOM killing for this process) and
+        1000 (to make killing of this process under memory pressure
+        very likely). See <ulink
+        url="https://www.kernel.org/doc/Documentation/filesystems/proc.txt">proc.txt</ulink>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOSchedulingClass=</varname></term>
+
+        <listitem><para>Sets the I/O scheduling class for executed
+        processes. Takes an integer between 0 and 3 or one of the
+        strings <option>none</option>, <option>realtime</option>,
+        <option>best-effort</option> or <option>idle</option>. See
+        <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOSchedulingPriority=</varname></term>
+
+        <listitem><para>Sets the I/O scheduling priority for executed
+        processes. Takes an integer between 0 (highest priority) and 7
+        (lowest priority). The available priorities depend on the
+        selected I/O scheduling class (see above). See
+        <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUSchedulingPolicy=</varname></term>
+
+        <listitem><para>Sets the CPU scheduling policy for executed
+        processes. Takes one of
+        <option>other</option>,
+        <option>batch</option>,
+        <option>idle</option>,
+        <option>fifo</option> or
+        <option>rr</option>. See
+        <citerefentry><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUSchedulingPriority=</varname></term>
+
+        <listitem><para>Sets the CPU scheduling priority for executed
+        processes. The available priority range depends on the
+        selected CPU scheduling policy (see above). For real-time
+        scheduling policies an integer between 1 (lowest priority) and
+        99 (highest priority) can be used. See
+        <citerefentry><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUSchedulingResetOnFork=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, elevated
+        CPU scheduling priorities and policies will be reset when the
+        executed processes fork, and can hence not leak into child
+        processes. See
+        <citerefentry><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUAffinity=</varname></term>
+
+        <listitem><para>Controls the CPU affinity of the executed
+        processes. Takes a list of CPU indices or ranges separated by
+        either whitespace or commas. CPU ranges are specified by the
+        lower and upper CPU indices separated by a dash.
+        This option may be specified more than once, in which case the
+        specified CPU affinity masks are merged. If the empty string
+        is assigned, the mask is reset, all assignments prior to this
+        will have no effect. See
+        <citerefentry><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UMask=</varname></term>
+
+        <listitem><para>Controls the file mode creation mask. Takes an
+        access mode in octal notation. See
+        <citerefentry><refentrytitle>umask</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. Defaults to 0022.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Environment=</varname></term>
+
+        <listitem><para>Sets environment variables for executed
+        processes. Takes a space-separated list of variable
+        assignments. This option may be specified more than once, in
+        which case all listed variables will be set. If the same
+        variable is set twice, the later setting will override the
+        earlier setting. If the empty string is assigned to this
+        option, the list of environment variables is reset, all prior
+        assignments have no effect. Variable expansion is not
+        performed inside the strings, however, specifier expansion is
+        possible. The $ character has no special meaning. If you need
+        to assign a value containing spaces to a variable, use double
+        quotes (") for the assignment.</para>
+
+        <para>Example:
+        <programlisting>Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"</programlisting>
+        gives three variables <literal>VAR1</literal>,
+        <literal>VAR2</literal>, <literal>VAR3</literal>
+        with the values <literal>word1 word2</literal>,
+        <literal>word3</literal>, <literal>$word 5 6</literal>.
+        </para>
+
+        <para>
+        See
+        <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about environment variables.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>EnvironmentFile=</varname></term>
+        <listitem><para>Similar to <varname>Environment=</varname> but
+        reads the environment variables from a text file. The text
+        file should contain new-line-separated variable assignments.
+        Empty lines, lines without an <literal>=</literal> separator,
+        or lines starting with ; or # will be ignored,
+        which may be used for commenting. A line ending with a
+        backslash will be concatenated with the following one,
+        allowing multiline variable definitions. The parser strips
+        leading and trailing whitespace from the values of
+        assignments, unless you use double quotes (").</para>
+
+        <para>The argument passed should be an absolute filename or
+        wildcard expression, optionally prefixed with
+        <literal>-</literal>, which indicates that if the file does
+        not exist, it will not be read and no error or warning message
+        is logged. This option may be specified more than once in
+        which case all specified files are read. If the empty string
+        is assigned to this option, the list of file to read is reset,
+        all prior assignments have no effect.</para>
+
+        <para>The files listed with this directive will be read
+        shortly before the process is executed (more specifically,
+        after all processes from a previous unit state terminated.
+        This means you can generate these files in one unit state, and
+        read it with this option in the next).</para>
+
+        <para>Settings from these
+        files override settings made with
+        <varname>Environment=</varname>. If the same variable is set
+        twice from these files, the files will be read in the order
+        they are specified and the later setting will override the
+        earlier setting.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassEnvironment=</varname></term>
+
+        <listitem><para>Pass environment variables from the systemd system
+        manager to executed processes. Takes a space-separated list of variable
+        names. This option may be specified more than once, in which case all
+        listed variables will be set. If the empty string is assigned to this
+        option, the list of environment variables is reset, all prior
+        assignments have no effect. Variables that are not set in the system
+        manager will not be passed and will be silently ignored.</para>
+
+        <para>Variables passed from this setting are overridden by those passed
+        from <varname>Environment=</varname> or
+        <varname>EnvironmentFile=</varname>.</para>
+
+        <para>Example:
+        <programlisting>PassEnvironment=VAR1 VAR2 VAR3</programlisting>
+        passes three variables <literal>VAR1</literal>,
+        <literal>VAR2</literal>, <literal>VAR3</literal>
+        with the values set for those variables in PID1.</para>
+
+        <para>
+        See
+        <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about environment variables.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StandardInput=</varname></term>
+        <listitem><para>Controls where file descriptor 0 (STDIN) of
+        the executed processes is connected to. Takes one of
+        <option>null</option>,
+        <option>tty</option>,
+        <option>tty-force</option>,
+        <option>tty-fail</option> or
+        <option>socket</option>.</para>
+
+        <para>If <option>null</option> is selected, standard input
+        will be connected to <filename>/dev/null</filename>, i.e. all
+        read attempts by the process will result in immediate
+        EOF.</para>
+
+        <para>If <option>tty</option> is selected, standard input is
+        connected to a TTY (as configured by
+        <varname>TTYPath=</varname>, see below) and the executed
+        process becomes the controlling process of the terminal. If
+        the terminal is already being controlled by another process,
+        the executed process waits until the current controlling
+        process releases the terminal.</para>
+
+        <para><option>tty-force</option> is similar to
+        <option>tty</option>, but the executed process is forcefully
+        and immediately made the controlling process of the terminal,
+        potentially removing previous controlling processes from the
+        terminal.</para>
+
+        <para><option>tty-fail</option> is similar to
+        <option>tty</option> but if the terminal already has a
+        controlling process start-up of the executed process
+        fails.</para>
+
+        <para>The <option>socket</option> option is only valid in
+        socket-activated services, and only when the socket
+        configuration file (see
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details) specifies a single socket only. If this option is
+        set, standard input will be connected to the socket the
+        service was activated from, which is primarily useful for
+        compatibility with daemons designed for use with the
+        traditional
+        <citerefentry project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        daemon.</para>
+
+        <para>This setting defaults to
+        <option>null</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StandardOutput=</varname></term>
+        <listitem><para>Controls where file descriptor 1 (STDOUT) of
+        the executed processes is connected to. Takes one of
+        <option>inherit</option>,
+        <option>null</option>,
+        <option>tty</option>,
+        <option>journal</option>,
+        <option>syslog</option>,
+        <option>kmsg</option>,
+        <option>journal+console</option>,
+        <option>syslog+console</option>,
+        <option>kmsg+console</option> or
+        <option>socket</option>.</para>
+
+        <para><option>inherit</option> duplicates the file descriptor
+        of standard input for standard output.</para>
+
+        <para><option>null</option> connects standard output to
+        <filename>/dev/null</filename>, i.e. everything written to it
+        will be lost.</para>
+
+        <para><option>tty</option> connects standard output to a tty
+        (as configured via <varname>TTYPath=</varname>, see below). If
+        the TTY is used for output only, the executed process will not
+        become the controlling process of the terminal, and will not
+        fail or wait for other processes to release the
+        terminal.</para>
+
+        <para><option>journal</option> connects standard output with
+        the journal which is accessible via
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        Note that everything that is written to syslog or kmsg (see
+        below) is implicitly stored in the journal as well, the
+        specific two options listed below are hence supersets of this
+        one.</para>
+
+        <para><option>syslog</option> connects standard output to the
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        system syslog service, in addition to the journal. Note that
+        the journal daemon is usually configured to forward everything
+        it receives to syslog anyway, in which case this option is no
+        different from <option>journal</option>.</para>
+
+        <para><option>kmsg</option> connects standard output with the
+        kernel log buffer which is accessible via
+        <citerefentry project='man-pages'><refentrytitle>dmesg</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        in addition to the journal. The journal daemon might be
+        configured to send all logs to kmsg anyway, in which case this
+        option is no different from <option>journal</option>.</para>
+
+        <para><option>journal+console</option>,
+        <option>syslog+console</option> and
+        <option>kmsg+console</option> work in a similar way as the
+        three options above but copy the output to the system console
+        as well.</para>
+
+        <para><option>socket</option> connects standard output to a
+        socket acquired via socket activation. The semantics are
+        similar to the same option of
+        <varname>StandardInput=</varname>.</para>
+
+        <para>If the standard output (or error output, see below) of a unit is connected to the journal, syslog or the
+        kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname> on
+        <filename>systemd-journald.socket</filename> (also see the automatic dependencies section above).</para>
+
+        <para>This setting defaults to the value set with
+        <option>DefaultStandardOutput=</option> in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        which defaults to <option>journal</option>. Note that setting
+        this parameter might result in additional dependencies to be
+        added to the unit (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StandardError=</varname></term>
+        <listitem><para>Controls where file descriptor 2 (STDERR) of
+        the executed processes is connected to. The available options
+        are identical to those of <varname>StandardOutput=</varname>,
+        with one exception: if set to <option>inherit</option> the
+        file descriptor used for standard output is duplicated for
+        standard error. This setting defaults to the value set with
+        <option>DefaultStandardError=</option> in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        which defaults to <option>inherit</option>. Note that setting
+        this parameter might result in additional dependencies to be
+        added to the unit (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYPath=</varname></term>
+        <listitem><para>Sets the terminal device node to use if
+        standard input, output, or error are connected to a TTY (see
+        above). Defaults to
+        <filename>/dev/console</filename>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTYReset=</varname></term>
+        <listitem><para>Reset the terminal device specified with
+        <varname>TTYPath=</varname> before and after execution.
+        Defaults to <literal>no</literal>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTYVHangup=</varname></term>
+        <listitem><para>Disconnect all clients which have opened the
+        terminal device specified with <varname>TTYPath=</varname>
+        before and after execution. Defaults to
+        <literal>no</literal>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTYVTDisallocate=</varname></term>
+        <listitem><para>If the terminal device specified with
+        <varname>TTYPath=</varname> is a virtual console terminal, try
+        to deallocate the TTY before and after execution. This ensures
+        that the screen and scrollback buffer is cleared. Defaults to
+        <literal>no</literal>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>SyslogIdentifier=</varname></term>
+        <listitem><para>Sets the process name to prefix log lines sent
+        to the logging system or the kernel log buffer with. If not
+        set, defaults to the process name of the executed process.
+        This option is only useful when
+        <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to
+        <option>syslog</option>, <option>journal</option> or
+        <option>kmsg</option> (or to the same settings in combination
+        with <option>+console</option>).</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>SyslogFacility=</varname></term>
+        <listitem><para>Sets the syslog facility to use when logging
+        to syslog. One of <option>kern</option>,
+        <option>user</option>, <option>mail</option>,
+        <option>daemon</option>, <option>auth</option>,
+        <option>syslog</option>, <option>lpr</option>,
+        <option>news</option>, <option>uucp</option>,
+        <option>cron</option>, <option>authpriv</option>,
+        <option>ftp</option>, <option>local0</option>,
+        <option>local1</option>, <option>local2</option>,
+        <option>local3</option>, <option>local4</option>,
+        <option>local5</option>, <option>local6</option> or
+        <option>local7</option>. See
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details. This option is only useful when
+        <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to
+        <option>syslog</option>. Defaults to
+        <option>daemon</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>SyslogLevel=</varname></term>
+        <listitem><para>The default syslog level to use when logging to
+        syslog or the kernel log buffer. One of
+        <option>emerg</option>,
+        <option>alert</option>,
+        <option>crit</option>,
+        <option>err</option>,
+        <option>warning</option>,
+        <option>notice</option>,
+        <option>info</option>,
+        <option>debug</option>. See
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details. This option is only useful when
+        <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to
+        <option>syslog</option> or <option>kmsg</option>. Note that
+        individual lines output by the daemon might be prefixed with a
+        different log level which can be used to override the default
+        log level specified here. The interpretation of these prefixes
+        may be disabled with <varname>SyslogLevelPrefix=</varname>,
+        see below. For details, see
+        <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+
+        Defaults to
+        <option>info</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SyslogLevelPrefix=</varname></term>
+        <listitem><para>Takes a boolean argument. If true and
+        <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to
+        <option>syslog</option>, <option>kmsg</option> or
+        <option>journal</option>, log lines written by the executed
+        process that are prefixed with a log level will be passed on
+        to syslog with this log level set but the prefix removed. If
+        set to false, the interpretation of these prefixes is disabled
+        and the logged lines are passed on as-is. For details about
+        this prefixing see
+        <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Defaults to true.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimerSlackNSec=</varname></term>
+        <listitem><para>Sets the timer slack in nanoseconds for the
+        executed processes. The timer slack controls the accuracy of
+        wake-ups triggered by timers. See
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for more information. Note that in contrast to most other time
+        span definitions this parameter takes an integer value in
+        nano-seconds if no unit is specified. The usual time units are
+        understood too.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LimitCPU=</varname></term>
+        <term><varname>LimitFSIZE=</varname></term>
+        <term><varname>LimitDATA=</varname></term>
+        <term><varname>LimitSTACK=</varname></term>
+        <term><varname>LimitCORE=</varname></term>
+        <term><varname>LimitRSS=</varname></term>
+        <term><varname>LimitNOFILE=</varname></term>
+        <term><varname>LimitAS=</varname></term>
+        <term><varname>LimitNPROC=</varname></term>
+        <term><varname>LimitMEMLOCK=</varname></term>
+        <term><varname>LimitLOCKS=</varname></term>
+        <term><varname>LimitSIGPENDING=</varname></term>
+        <term><varname>LimitMSGQUEUE=</varname></term>
+        <term><varname>LimitNICE=</varname></term>
+        <term><varname>LimitRTPRIO=</varname></term>
+        <term><varname>LimitRTTIME=</varname></term>
+        <listitem><para>Set soft and hard limits on various resources for executed processes. See
+        <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for details on
+        the resource limit concept. Resource limits may be specified in two formats: either as single value to set a
+        specific soft and hard limit to the same value, or as colon-separated pair <option>soft:hard</option> to set
+        both limits individually (e.g. <literal>LimitAS=4G:16G</literal>).  Use the string <varname>infinity</varname>
+        to configure no limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base
+        1024) may be used for resource limits measured in bytes (e.g. LimitAS=16G). For the limits referring to time
+        values, the usual time units ms, s, min, h and so on may be used (see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details). Note that if no time unit is specified for <varname>LimitCPU=</varname> the default unit of seconds
+        is implied, while for <varname>LimitRTTIME=</varname> the default unit of microseconds is implied. Also, note
+        that the effective granularity of the limits might influence their enforcement. For example, time limits
+        specified for <varname>LimitCPU=</varname> will be rounded up implicitly to multiples of 1s. For
+        <varname>LimitNICE=</varname> the value may be specified in two syntaxes: if prefixed with <literal>+</literal>
+        or <literal>-</literal>, the value is understood as regular Linux nice value in the range -20..19. If not
+        prefixed like this the value is understood as raw resource limit parameter in the range 0..40 (with 0 being
+        equivalent to 1).</para>
+
+        <para>Note that most process resource limits configured with
+        these options are per-process, and processes may fork in order
+        to acquire a new set of resources that are accounted
+        independently of the original process, and may thus escape
+        limits set. Also note that <varname>LimitRSS=</varname> is not
+        implemented on Linux, and setting it has no effect. Often it
+        is advisable to prefer the resource controls listed in
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        over these per-process limits, as they apply to services as a
+        whole, may be altered dynamically at runtime, and are
+        generally more expressive. For example,
+        <varname>MemoryLimit=</varname> is a more powerful (and
+        working) replacement for <varname>LimitRSS=</varname>.</para>
+
+        <table>
+          <title>Limit directives and their equivalent with ulimit</title>
+
+          <tgroup cols='3'>
+            <colspec colname='directive' />
+            <colspec colname='equivalent' />
+            <colspec colname='unit' />
+            <thead>
+              <row>
+                <entry>Directive</entry>
+                <entry>ulimit equivalent</entry>
+                <entry>Unit</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>LimitCPU=</entry>
+                <entry>ulimit -t</entry>
+                <entry>Seconds</entry>
+              </row>
+              <row>
+                <entry>LimitFSIZE=</entry>
+                <entry>ulimit -f</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitDATA=</entry>
+                <entry>ulimit -d</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitSTACK=</entry>
+                <entry>ulimit -s</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitCORE=</entry>
+                <entry>ulimit -c</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitRSS=</entry>
+                <entry>ulimit -m</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitNOFILE=</entry>
+                <entry>ulimit -n</entry>
+                <entry>Number of File Descriptors</entry>
+              </row>
+              <row>
+                <entry>LimitAS=</entry>
+                <entry>ulimit -v</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitNPROC=</entry>
+                <entry>ulimit -u</entry>
+                <entry>Number of Processes</entry>
+              </row>
+              <row>
+                <entry>LimitMEMLOCK=</entry>
+                <entry>ulimit -l</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitLOCKS=</entry>
+                <entry>ulimit -x</entry>
+                <entry>Number of Locks</entry>
+              </row>
+              <row>
+                <entry>LimitSIGPENDING=</entry>
+                <entry>ulimit -i</entry>
+                <entry>Number of Queued Signals</entry>
+              </row>
+              <row>
+                <entry>LimitMSGQUEUE=</entry>
+                <entry>ulimit -q</entry>
+                <entry>Bytes</entry>
+              </row>
+              <row>
+                <entry>LimitNICE=</entry>
+                <entry>ulimit -e</entry>
+                <entry>Nice Level</entry>
+              </row>
+              <row>
+                <entry>LimitRTPRIO=</entry>
+                <entry>ulimit -r</entry>
+                <entry>Realtime Priority</entry>
+              </row>
+              <row>
+                <entry>LimitRTTIME=</entry>
+                <entry>No equivalent</entry>
+                <entry>Microseconds</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PAMName=</varname></term>
+        <listitem><para>Sets the PAM service name to set up a session
+        as. If set, the executed process will be registered as a PAM
+        session under the specified service name. This is only useful
+        in conjunction with the <varname>User=</varname> setting. If
+        not set, no PAM session will be opened for the executed
+        processes. See
+        <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CapabilityBoundingSet=</varname></term>
+
+        <listitem><para>Controls which capabilities to include in the capability bounding set for the executed
+        process. See <citerefentry
+        project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details. Takes a whitespace-separated list of capability names as read by <citerefentry
+        project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        e.g. <constant>CAP_SYS_ADMIN</constant>, <constant>CAP_DAC_OVERRIDE</constant>,
+        <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will be included in the bounding set, all others are
+        removed. If the list of capabilities is prefixed with <literal>~</literal>, all but the listed capabilities
+        will be included, the effect of the assignment inverted. Note that this option also affects the respective
+        capabilities in the effective, permitted and inheritable capability sets. If this option is not used, the
+        capability bounding set is not modified on process execution, hence no limits on the capabilities of the
+        process are enforced. This option may appear more than once, in which case the bounding sets are merged. If the
+        empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior
+        settings have no effect.  If set to <literal>~</literal> (without any further argument), the bounding set is
+        reset to the full set of available capabilities, also undoing any previous settings.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AmbientCapabilities=</varname></term>
+
+        <listitem><para>Controls which capabilities to include in the
+        ambient capability set for the executed process. Takes a
+        whitespace-separated list of capability names as read by
+        <citerefentry project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        e.g. <constant>CAP_SYS_ADMIN</constant>,
+        <constant>CAP_DAC_OVERRIDE</constant>,
+        <constant>CAP_SYS_PTRACE</constant>. This option may appear more than
+        once in which case the ambient capability sets are merged.
+        If the list of capabilities is prefixed with <literal>~</literal>, all
+        but the listed capabilities will be included, the effect of the
+        assignment inverted. If the empty string is
+        assigned to this option, the ambient capability set is reset to
+        the empty capability set, and all prior settings have no effect.
+        If set to <literal>~</literal> (without any further argument), the
+        ambient capability set is reset to the full set of available
+        capabilities, also undoing any previous settings. Note that adding
+        capabilities to ambient capability set adds them to the process's
+        inherited capability set.
+        </para><para>
+        Ambient capability sets are useful if you want to execute a process
+        as a non-privileged user but still want to give it some capabilities.
+        Note that in this case option <constant>keep-caps</constant> is
+        automatically added to <varname>SecureBits=</varname> to retain the
+        capabilities over the user change.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SecureBits=</varname></term>
+        <listitem><para>Controls the secure bits set for the executed
+        process. Takes a space-separated combination of options from
+        the following list:
+        <option>keep-caps</option>,
+        <option>keep-caps-locked</option>,
+        <option>no-setuid-fixup</option>,
+        <option>no-setuid-fixup-locked</option>,
+        <option>noroot</option>, and
+        <option>noroot-locked</option>.
+        This option may appear more than once, in which case the secure
+        bits are ORed. If the empty string is assigned to this option,
+        the bits are reset to 0. See
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReadWriteDirectories=</varname></term>
+        <term><varname>ReadOnlyDirectories=</varname></term>
+        <term><varname>InaccessibleDirectories=</varname></term>
+
+        <listitem><para>Sets up a new file system namespace for
+        executed processes. These options may be used to limit access
+        a process might have to the main file system hierarchy. Each
+        setting takes a space-separated list of absolute directory
+        paths. Directories listed in
+        <varname>ReadWriteDirectories=</varname> are accessible from
+        within the namespace with the same access rights as from
+        outside. Directories listed in
+        <varname>ReadOnlyDirectories=</varname> are accessible for
+        reading only, writing will be refused even if the usual file
+        access controls would permit this. Directories listed in
+        <varname>InaccessibleDirectories=</varname> will be made
+        inaccessible for processes inside the namespace, and may not
+        countain any other mountpoints, including those specified by
+        <varname>ReadWriteDirectories=</varname> or
+        <varname>ReadOnlyDirectories=</varname>.
+        Note that restricting access with these options does not extend
+        to submounts of a directory that are created later on. These
+        options may be specified more than once, in which case all
+        directories listed will have limited access from within the
+        namespace. If the empty string is assigned to this option, the
+        specific list is reset, and all prior assignments have no
+        effect.</para>
+        <para>Paths in
+        <varname>ReadOnlyDirectories=</varname>
+        and
+        <varname>InaccessibleDirectories=</varname>
+        may be prefixed with
+        <literal>-</literal>, in which case
+        they will be ignored when they do not
+        exist. Note that using this
+        setting will disconnect propagation of
+        mounts from the service to the host
+        (propagation in the opposite direction
+        continues to work). This means that
+        this setting may not be used for
+        services which shall be able to
+        install mount points in the main mount
+        namespace.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateTmp=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a
+        new file system namespace for the executed processes and
+        mounts private <filename>/tmp</filename> and
+        <filename>/var/tmp</filename> directories inside it that is
+        not shared by processes outside of the namespace. This is
+        useful to secure access to temporary files of the process, but
+        makes sharing between processes via <filename>/tmp</filename>
+        or <filename>/var/tmp</filename> impossible. If this is
+        enabled, all temporary files created by a service in these
+        directories will be removed after the service is stopped.
+        Defaults to false. It is possible to run two or more units
+        within the same private <filename>/tmp</filename> and
+        <filename>/var/tmp</filename> namespace by using the
+        <varname>JoinsNamespaceOf=</varname> directive, see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. Note that using this setting will disconnect
+        propagation of mounts from the service to the host
+        (propagation in the opposite direction continues to work).
+        This means that this setting may not be used for services
+        which shall be able to install mount points in the main mount
+        namespace.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateDevices=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a
+        new /dev namespace for the executed processes and only adds
+        API pseudo devices such as <filename>/dev/null</filename>,
+        <filename>/dev/zero</filename> or
+        <filename>/dev/random</filename> (as well as the pseudo TTY
+        subsystem) to it, but no physical devices such as
+        <filename>/dev/sda</filename>. This is useful to securely turn
+        off physical device access by the executed process. Defaults
+        to false. Enabling this option will also remove
+        <constant>CAP_MKNOD</constant> from the capability bounding
+        set for the unit (see above), and set
+        <varname>DevicePolicy=closed</varname> (see
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details). Note that using this setting will disconnect
+        propagation of mounts from the service to the host
+        (propagation in the opposite direction continues to work).
+        This means that this setting may not be used for services
+        which shall be able to install mount points in the main mount
+        namespace. The /dev namespace will be mounted read-only and 'noexec'.
+        The latter may break old programs which try to set up executable
+        memory by using <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        of <filename>/dev/zero</filename> instead of using <constant>MAP_ANON</constant>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateNetwork=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a
+        new network namespace for the executed processes and
+        configures only the loopback network device
+        <literal>lo</literal> inside it. No other network devices will
+        be available to the executed process. This is useful to
+        securely turn off network access by the executed process.
+        Defaults to false. It is possible to run two or more units
+        within the same private network namespace by using the
+        <varname>JoinsNamespaceOf=</varname> directive, see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. Note that this option will disconnect all socket
+        families from the host, this includes AF_NETLINK and AF_UNIX.
+        The latter has the effect that AF_UNIX sockets in the abstract
+        socket namespace will become unavailable to the processes
+        (however, those located in the file system will continue to be
+        accessible).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectSystem=</varname></term>
+
+        <listitem><para>Takes a boolean argument or
+        <literal>full</literal>. If true, mounts the
+        <filename>/usr</filename> and <filename>/boot</filename>
+        directories read-only for processes invoked by this unit. If
+        set to <literal>full</literal>, the <filename>/etc</filename>
+        directory is mounted read-only, too. This setting ensures that
+        any modification of the vendor-supplied operating system (and
+        optionally its configuration) is prohibited for the service.
+        It is recommended to enable this setting for all long-running
+        services, unless they are involved with system updates or need
+        to modify the operating system in other ways. Note however
+        that processes retaining the CAP_SYS_ADMIN capability can undo
+        the effect of this setting. This setting is hence particularly
+        useful for daemons which have this capability removed, for
+        example with <varname>CapabilityBoundingSet=</varname>.
+        Defaults to off.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectHome=</varname></term>
+
+        <listitem><para>Takes a boolean argument or
+        <literal>read-only</literal>. If true, the directories
+        <filename>/home</filename>, <filename>/root</filename> and
+        <filename>/run/user</filename>
+        are made inaccessible and empty for processes invoked by this
+        unit. If set to <literal>read-only</literal>, the three
+        directories are made read-only instead. It is recommended to
+        enable this setting for all long-running services (in
+        particular network-facing ones), to ensure they cannot get
+        access to private user data, unless the services actually
+        require access to the user's private data. Note however that
+        processes retaining the CAP_SYS_ADMIN capability can undo the
+        effect of this setting. This setting is hence particularly
+        useful for daemons which have this capability removed, for
+        example with <varname>CapabilityBoundingSet=</varname>.
+        Defaults to off.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MountFlags=</varname></term>
+
+        <listitem><para>Takes a mount propagation flag:
+        <option>shared</option>, <option>slave</option> or
+        <option>private</option>, which control whether mounts in the
+        file system namespace set up for this unit's processes will
+        receive or propagate mounts or unmounts. See
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. Defaults to <option>shared</option>. Use
+        <option>shared</option> to ensure that mounts and unmounts are
+        propagated from the host to the container and vice versa. Use
+        <option>slave</option> to run processes so that none of their
+        mounts and unmounts will propagate to the host. Use
+        <option>private</option> to also ensure that no mounts and
+        unmounts from the host will propagate into the unit processes'
+        namespace. Note that <option>slave</option> means that file
+        systems mounted on the host might stay mounted continuously in
+        the unit's namespace, and thus keep the device busy. Note that
+        the file system namespace related options
+        (<varname>PrivateTmp=</varname>,
+        <varname>PrivateDevices=</varname>,
+        <varname>ProtectSystem=</varname>,
+        <varname>ProtectHome=</varname>,
+        <varname>ReadOnlyDirectories=</varname>,
+        <varname>InaccessibleDirectories=</varname> and
+        <varname>ReadWriteDirectories=</varname>) require that mount
+        and unmount propagation from the unit's file system namespace
+        is disabled, and hence downgrade <option>shared</option> to
+        <option>slave</option>. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UtmpIdentifier=</varname></term>
+
+        <listitem><para>Takes a four character identifier string for
+        an <citerefentry
+        project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        and wtmp entry for this service. This should only be
+        set for services such as <command>getty</command>
+        implementations (such as <citerefentry
+        project='die-net'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+        where utmp/wtmp entries must be created and cleared before and
+        after execution, or for services that shall be executed as if
+        they were run by a <command>getty</command> process (see
+        below). If the configured string is longer than four
+        characters, it is truncated and the terminal four characters
+        are used. This setting interprets %I style string
+        replacements. This setting is unset by default, i.e. no
+        utmp/wtmp entries are created or cleaned up for this
+        service.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+         <term><varname>UtmpMode=</varname></term>
+
+         <listitem><para>Takes one of <literal>init</literal>,
+         <literal>login</literal> or <literal>user</literal>. If
+         <varname>UtmpIdentifier=</varname> is set, controls which
+         type of <citerefentry
+         project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>/wtmp
+         entries for this service are generated. This setting has no
+         effect unless <varname>UtmpIdentifier=</varname> is set
+         too. If <literal>init</literal> is set, only an
+         <constant>INIT_PROCESS</constant> entry is generated and the
+         invoked process must implement a
+         <command>getty</command>-compatible utmp/wtmp logic. If
+         <literal>login</literal> is set, first an
+         <constant>INIT_PROCESS</constant> entry, followed by a
+         <constant>LOGIN_PROCESS</constant> entry is generated. In
+         this case, the invoked process must implement a <citerefentry
+         project='die-net'><refentrytitle>login</refentrytitle><manvolnum>1</manvolnum></citerefentry>-compatible
+         utmp/wtmp logic. If <literal>user</literal> is set, first an
+         <constant>INIT_PROCESS</constant> entry, then a
+         <constant>LOGIN_PROCESS</constant> entry and finally a
+         <constant>USER_PROCESS</constant> entry is generated. In this
+         case, the invoked process may be any process that is suitable
+         to be run as session leader. Defaults to
+         <literal>init</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SELinuxContext=</varname></term>
+
+        <listitem><para>Set the SELinux security context of the
+        executed process. If set, this will override the automated
+        domain transition. However, the policy still needs to
+        authorize the transition. This directive is ignored if SELinux
+        is disabled. If prefixed by <literal>-</literal>, all errors
+        will be ignored. See
+        <citerefentry project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AppArmorProfile=</varname></term>
+
+        <listitem><para>Takes a profile name as argument. The process
+        executed by the unit will switch to this profile when started.
+        Profiles must already be loaded in the kernel, or the unit
+        will fail. This result in a non operation if AppArmor is not
+        enabled. If prefixed by <literal>-</literal>, all errors will
+        be ignored. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SmackProcessLabel=</varname></term>
+
+        <listitem><para>Takes a <option>SMACK64</option> security
+        label as argument. The process executed by the unit will be
+        started under this label and SMACK will decide whether the
+        process is allowed to run or not, based on it. The process
+        will continue to run under the label specified here unless the
+        executable has its own <option>SMACK64EXEC</option> label, in
+        which case the process will transition to run under that
+        label. When not specified, the label that systemd is running
+        under is used. This directive is ignored if SMACK is
+        disabled.</para>
+
+        <para>The value may be prefixed by <literal>-</literal>, in
+        which case all errors will be ignored. An empty value may be
+        specified to unset previous assignments.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IgnoreSIGPIPE=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, causes
+        <constant>SIGPIPE</constant> to be ignored in the executed
+        process. Defaults to true because <constant>SIGPIPE</constant>
+        generally is useful only in shell pipelines.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NoNewPrivileges=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, ensures
+        that the service process and all its children can never gain
+        new privileges. This option is more powerful than the
+        respective secure bits flags (see above), as it also prohibits
+        UID changes of any kind. This is the simplest, most effective
+        way to ensure that a process and its children can never
+        elevate privileges again.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallFilter=</varname></term>
+
+        <listitem><para>Takes a space-separated list of system call
+        names. If this setting is used, all system calls executed by
+        the unit processes except for the listed ones will result in
+        immediate process termination with the
+        <constant>SIGSYS</constant> signal (whitelisting). If the
+        first character of the list is <literal>~</literal>, the
+        effect is inverted: only the listed system calls will result
+        in immediate process termination (blacklisting). If running in
+        user mode, or in system mode, but without the
+        <constant>CAP_SYS_ADMIN</constant> capabiblity (e.g. setting
+        <varname>User=nobody</varname>),
+        <varname>NoNewPrivileges=yes</varname> is implied. This
+        feature makes use of the Secure Computing Mode 2 interfaces of
+        the kernel ('seccomp filtering') and is useful for enforcing a
+        minimal sandboxing environment. Note that the
+        <function>execve</function>,
+        <function>rt_sigreturn</function>,
+        <function>sigreturn</function>,
+        <function>exit_group</function>, <function>exit</function>
+        system calls are implicitly whitelisted and do not need to be
+        listed explicitly. This option may be specified more than once,
+        in which case the filter masks are merged. If the empty string
+        is assigned, the filter is reset, all prior assignments will
+        have no effect.</para>
+
+        <para>If you specify both types of this option (i.e.
+        whitelisting and blacklisting), the first encountered will
+        take precedence and will dictate the default action
+        (termination or approval of a system call). Then the next
+        occurrences of this option will add or delete the listed
+        system calls from the set of the filtered system calls,
+        depending of its type and the default action. (For example, if
+        you have started with a whitelisting of
+        <function>read</function> and <function>write</function>, and
+        right after it add a blacklisting of
+        <function>write</function>, then <function>write</function>
+        will be removed from the set.) </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallErrorNumber=</varname></term>
+
+        <listitem><para>Takes an <literal>errno</literal> error number
+        name to return when the system call filter configured with
+        <varname>SystemCallFilter=</varname> is triggered, instead of
+        terminating the process immediately. Takes an error name such
+        as <constant>EPERM</constant>, <constant>EACCES</constant> or
+        <constant>EUCLEAN</constant>. When this setting is not used,
+        or when the empty string is assigned, the process will be
+        terminated immediately when the filter is
+        triggered.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallArchitectures=</varname></term>
+
+        <listitem><para>Takes a space-separated list of architecture
+        identifiers to include in the system call filter. The known
+        architecture identifiers are <constant>x86</constant>,
+        <constant>x86-64</constant>, <constant>x32</constant>,
+        <constant>arm</constant> as well as the special identifier
+        <constant>native</constant>. Only system calls of the
+        specified architectures will be permitted to processes of this
+        unit. This is an effective way to disable compatibility with
+        non-native architectures for processes, for example to
+        prohibit execution of 32-bit x86 binaries on 64-bit x86-64
+        systems. The special <constant>native</constant> identifier
+        implicitly maps to the native architecture of the system (or
+        more strictly: to the architecture the system manager is
+        compiled for). If running in user mode, or in system mode,
+        but without the <constant>CAP_SYS_ADMIN</constant>
+        capabiblity (e.g. setting <varname>User=nobody</varname>),
+        <varname>NoNewPrivileges=yes</varname> is implied. Note
+        that setting this option to a non-empty list implies that
+        <constant>native</constant> is included too. By default, this
+        option is set to the empty list, i.e. no architecture system
+        call filtering is applied.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictAddressFamilies=</varname></term>
+
+        <listitem><para>Restricts the set of socket address families
+        accessible to the processes of this unit. Takes a
+        space-separated list of address family names to whitelist,
+        such as
+        <constant>AF_UNIX</constant>,
+        <constant>AF_INET</constant> or
+        <constant>AF_INET6</constant>. When
+        prefixed with <constant>~</constant> the listed address
+        families will be applied as blacklist, otherwise as whitelist.
+        Note that this restricts access to the
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        system call only. Sockets passed into the process by other
+        means (for example, by using socket activation with socket
+        units, see
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+        are unaffected. Also, sockets created with
+        <function>socketpair()</function> (which creates connected
+        AF_UNIX sockets only) are unaffected. Note that this option
+        has no effect on 32-bit x86 and is ignored (but works
+        correctly on x86-64). If running in user mode, or in system
+        mode, but without the <constant>CAP_SYS_ADMIN</constant>
+        capabiblity (e.g. setting <varname>User=nobody</varname>),
+        <varname>NoNewPrivileges=yes</varname> is implied. By
+        default, no restriction applies, all address families are
+        accessible to processes. If assigned the empty string, any
+        previous list changes are undone.</para>
+
+        <para>Use this option to limit exposure of processes to remote
+        systems, in particular via exotic network protocols. Note that
+        in most cases, the local <constant>AF_UNIX</constant> address
+        family should be included in the configured whitelist as it is
+        frequently used for local communication, including for
+        <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        logging.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Personality=</varname></term>
+
+        <listitem><para>Controls which kernel architecture <citerefentry
+        project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> shall report,
+        when invoked by unit processes. Takes one of the architecture identifiers <constant>x86</constant>,
+        <constant>x86-64</constant>, <constant>ppc</constant>, <constant>ppc-le</constant>, <constant>ppc64</constant>,
+        <constant>ppc64-le</constant>, <constant>s390</constant> or <constant>s390x</constant>. Which personality
+        architectures are supported depends on the system architecture. Usually the 64bit versions of the various
+        system architectures support their immediate 32bit personality architecture counterpart, but no others. For
+        example, <constant>x86-64</constant> systems support the <constant>x86-64</constant> and
+        <constant>x86</constant> personalities but no others. The personality feature is useful when running 32-bit
+        services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the
+        personality of the host system's kernel.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeDirectory=</varname></term>
+        <term><varname>RuntimeDirectoryMode=</varname></term>
+
+        <listitem><para>Takes a list of directory names. If set, one
+        or more directories by the specified names will be created
+        below <filename>/run</filename> (for system services) or below
+        <varname>$XDG_RUNTIME_DIR</varname> (for user services) when
+        the unit is started, and removed when the unit is stopped. The
+        directories will have the access mode specified in
+        <varname>RuntimeDirectoryMode=</varname>, and will be owned by
+        the user and group specified in <varname>User=</varname> and
+        <varname>Group=</varname>. Use this to manage one or more
+        runtime directories of the unit and bind their lifetime to the
+        daemon runtime. The specified directory names must be
+        relative, and may not include a <literal>/</literal>, i.e.
+        must refer to simple directories to create or remove. This is
+        particularly useful for unprivileged daemons that cannot
+        create runtime directories in <filename>/run</filename> due to
+        lack of privileges, and to make sure the runtime directory is
+        cleaned up automatically after use. For runtime directories
+        that require more complex or different configuration or
+        lifetime guarantees, please consider using
+        <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment variables in spawned processes</title>
+
+    <para>Processes started by the system are executed in a clean
+    environment in which select variables listed below are set. System
+    processes started by systemd do not inherit variables from PID 1,
+    but processes started by user systemd instances inherit all
+    environment variables from the user systemd instance.
+    </para>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$PATH</varname></term>
+
+        <listitem><para>Colon-separated list of directories to use
+        when launching executables. Systemd uses a fixed value of
+        <filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename>:<filename>/sbin</filename>:<filename>/bin</filename>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$LANG</varname></term>
+
+        <listitem><para>Locale. Can be set in
+        <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        or on the kernel command line (see
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and
+        <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$USER</varname></term>
+        <term><varname>$LOGNAME</varname></term>
+        <term><varname>$HOME</varname></term>
+        <term><varname>$SHELL</varname></term>
+
+        <listitem><para>User name (twice), home directory, and the
+        login shell. The variables are set for the units that have
+        <varname>User=</varname> set, which includes user
+        <command>systemd</command> instances. See
+        <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_RUNTIME_DIR</varname></term>
+
+        <listitem><para>The directory for volatile state. Set for the
+        user <command>systemd</command> instance, and also in user
+        sessions. See
+        <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_SESSION_ID</varname></term>
+        <term><varname>$XDG_SEAT</varname></term>
+        <term><varname>$XDG_VTNR</varname></term>
+
+        <listitem><para>The identifier of the session, the seat name,
+        and virtual terminal of the session. Set by
+        <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for login sessions. <varname>$XDG_SEAT</varname> and
+        <varname>$XDG_VTNR</varname> will only be set when attached to
+        a seat and a tty.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$MAINPID</varname></term>
+
+        <listitem><para>The PID of the units main process if it is
+        known. This is only set for control processes as invoked by
+        <varname>ExecReload=</varname> and similar. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$MANAGERPID</varname></term>
+
+        <listitem><para>The PID of the user <command>systemd</command>
+        instance, set for processes spawned by it. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$LISTEN_FDS</varname></term>
+        <term><varname>$LISTEN_PID</varname></term>
+        <term><varname>$LISTEN_FDNAMES</varname></term>
+
+        <listitem><para>Information about file descriptors passed to a
+        service for socket activation. See
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$NOTIFY_SOCKET</varname></term>
+
+        <listitem><para>The socket
+        <function>sd_notify()</function> talks to. See
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$WATCHDOG_PID</varname></term>
+        <term><varname>$WATCHDOG_USEC</varname></term>
+
+        <listitem><para>Information about watchdog keep-alive notifications. See
+        <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$TERM</varname></term>
+
+        <listitem><para>Terminal type, set only for units connected to
+        a terminal (<varname>StandardInput=tty</varname>,
+        <varname>StandardOutput=tty</varname>, or
+        <varname>StandardError=tty</varname>). See
+        <citerefentry project='man-pages'><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Additional variables may be configured by the following
+    means: for processes spawned in specific units, use the
+    <varname>Environment=</varname>, <varname>EnvironmentFile=</varname>
+    and <varname>PassEnvironment=</varname> options above; to specify
+    variables globally, use <varname>DefaultEnvironment=</varname>
+    (see
+    <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+    or the kernel option <varname>systemd.setenv=</varname> (see
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
+    Additional variables may also be set through PAM,
+    cf. <citerefentry project='man-pages'><refentrytitle>pam_env</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</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>journalctl</refentrytitle><manvolnum>8</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.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.generator.xml b/src/grp-system/systemd/systemd.generator.xml
new file mode 100644
index 0000000000..4b80dab108
--- /dev/null
+++ b/src/grp-system/systemd/systemd.generator.xml
@@ -0,0 +1,348 @@
+<?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;
+]>
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2015 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.generator">
+  <refentryinfo>
+    <title>systemd.generator</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.generator</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.generator</refname>
+    <refpurpose>Systemd unit generators</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>/path/to/generator</command>
+      <arg choice="plain"><replaceable>normal-dir</replaceable></arg>
+      <arg choice="plain"><replaceable>early-dir</replaceable></arg>
+      <arg choice="plain"><replaceable>late-dir</replaceable></arg>
+    </cmdsynopsis>
+
+    <para>
+      <literallayout><filename>/run/systemd/system-generators/*</filename>
+<filename>/etc/systemd/system-generators/*</filename>
+<filename>/usr/local/lib/systemd/system-generators/*</filename>
+<filename>&systemgeneratordir;/*</filename></literallayout>
+    </para>
+
+    <para>
+      <literallayout><filename>/run/systemd/user-generators/*</filename>
+<filename>/etc/systemd/user-generators/*</filename>
+<filename>/usr/local/lib/systemd/user-generators/*</filename>
+<filename>&usergeneratordir;/*</filename></literallayout>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para>Generators are small binaries that live in
+    <filename>&usergeneratordir;/</filename> and other directories
+    listed above.
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    will execute those binaries very early at bootup and at
+    configuration reload time — before unit files are loaded.
+    Generators can dynamically generate unit files or create symbolic
+    links to unit files to add additional dependencies, thus extending
+    or overriding existing definitions. Their main purpose is to
+    convert configuration files that are not native unit files
+    dynamically into native unit files.</para>
+
+    <para>Generators are loaded from a set of paths determined during
+    compilation, as listed above. System and user generators are loaded
+    from directories with names ending in
+    <filename>system-generators/</filename> and
+    <filename>user-generators/</filename>, respectively. Generators
+    found in directories listed earlier override the ones with the
+    same name in directories lower in the list. A symlink to
+    <filename>/dev/null</filename> or an empty file can be used to
+    mask a generator, thereby preventing it from running. Please note
+    that the order of the two directories with the highest priority is
+    reversed with respect to the unit load path, and generators in
+    <filename>/run</filename> overwrite those in
+    <filename>/etc</filename>.</para>
+
+    <para>After installing new generators or updating the
+    configuration, <command>systemctl daemon-reload</command> may be
+    executed. This will delete the previous configuration created by
+    generators, re-run all generators, and cause
+    <command>systemd</command> to reload units from disk. See
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for more information.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Writing generators</title>
+
+    <para>Generators are invoked with three arguments: paths to
+    runtime directories where generators can place their generated
+    unit files or symlinks.</para>
+
+    <orderedlist>
+      <listitem>
+        <para><parameter>normal-dir</parameter></para>
+        <para>argv[1] may be used to override unit files in
+        <filename>/usr</filename>, but not those in
+        <filename>/etc</filename>. This means that unit files placed
+        in this directory take precedence over vendor unit
+        configuration but not over native user/administrator unit
+        configuration.</para>
+      </listitem>
+
+      <listitem>
+        <para><parameter>early-dir</parameter></para>
+        <para>argv[2] may be used to override unit files in
+        <filename>/usr</filename> and in
+        <filename>/etc</filename>. This means that unit files placed
+        in this directory take precedence over all configuration,
+        both vendor and user/administrator.</para>
+      </listitem>
+
+      <listitem>
+        <para><parameter>late-dir</parameter></para>
+        <para>argv[3] may be used to extend the unit file tree without
+        overriding any other unit files. Any native configuration
+        files supplied by the vendor or user/administrator take
+        precedence over the generated ones placed in this directory.
+        </para>
+      </listitem>
+    </orderedlist>
+
+    <refsect2>
+      <title>Notes</title>
+
+      <itemizedlist>
+        <listitem>
+          <para>
+            All generators are executed in parallel. That means all
+            executables are started at the very same time and need to
+            be able to cope with this parallelism.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Generators are run very early at boot and cannot rely on
+            any external services. They may not talk to any other
+            process. That includes simple things such as logging to
+            <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+            or <command>systemd</command> itself (this means: no
+            <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!.
+            Non-essential file systems like
+            <filename>/var</filename> and <filename>/home</filename>
+            are mounted after generators have run. Generators
+            can however rely on the most basic kernel functionality to be
+            available, including a mounted <filename>/sys</filename>,
+            <filename>/proc</filename>, <filename>/dev</filename>,
+            <filename>/usr</filename>.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Units written by generators are removed when the configuration
+            is reloaded. That means the lifetime of the generated
+            units is closely bound to the reload cycles of
+            <command>systemd</command> itself.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Generators should only be used to generate unit files, not
+            any other kind of configuration. Due to the lifecycle
+            logic mentioned above, generators are not a good fit to
+            generate dynamic configuration for other services. If you
+            need to generate dynamic configuration for other services,
+            do so in normal services you order before the service in
+            question.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Since
+            <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            is not available (see above), log messages have to be
+            written to <filename>/dev/kmsg</filename> instead.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            It is a good idea to use the
+            <varname>SourcePath=</varname> directive in generated unit
+            files to specify the source configuration file you are
+            generating the unit from. This makes things more easily
+            understood by the user and also has the benefit that
+            systemd can warn the user about configuration files that
+            changed on disk but have not been read yet by systemd.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Generators may write out dynamic unit files or just hook
+            unit files into other units with the usual
+            <filename>.wants/</filename> or
+            <filename>.requires/</filename> symlinks. Often, it is
+            nicer to simply instantiate a template unit file from
+            <filename>/usr</filename> with a generator instead of
+            writing out entirely dynamic unit files. Of course, this
+            works only if a single parameter is to be used.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            If you are careful, you can implement generators in shell
+            scripts. We do recommend C code however, since generators
+            are executed synchronously and hence delay the
+            entire boot if they are slow.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>Regarding overriding semantics: there are two rules we
+          try to follow when thinking about the overriding semantics:
+          </para>
+
+          <orderedlist numeration="lowerroman">
+            <listitem>
+              <para>User configuration should override vendor
+              configuration. This (mostly) means that stuff from
+              <filename>/etc</filename> should override stuff from
+              <filename>/usr</filename>.</para>
+            </listitem>
+
+            <listitem>
+              <para>Native configuration should override non-native
+              configuration. This (mostly) means that stuff you
+              generate should never override native unit files for the
+              same purpose.</para>
+            </listitem>
+          </orderedlist>
+
+          <para>Of these two rules the first rule is probably the more
+          important one and breaks the second one sometimes. Hence,
+          when deciding whether to user argv[1], argv[2], or argv[3],
+          your default choice should probably be argv[1].</para>
+        </listitem>
+
+        <listitem>
+          <para>
+            Instead of heading off now and writing all kind of
+            generators for legacy configuration file formats, please
+            think twice! It is often a better idea to just deprecate
+            old stuff instead of keeping it artificially alive.
+          </para>
+        </listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>systemd-fstab-generator</title>
+
+      <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      converts <filename>/etc/fstab</filename> into native mount
+      units. It uses argv[1] as location to place the generated unit
+      files in order to allow the user to override
+      <filename>/etc/fstab</filename> with her own native unit files,
+      but also to ensure that <filename>/etc/fstab</filename>
+      overrides any vendor default from <filename>/usr</filename>.
+      </para>
+
+      <para>After editing <filename>/etc/fstab</filename>, the user
+      should invoke <command>systemctl daemon-reload</command>. This
+      will re-run all generators and cause <command>systemd</command>
+      to reload units from disk. To actually mount new directories
+      added to <filename>fstab</filename>, <command>systemctl start
+      <replaceable>/path/to/mountpoint</replaceable></command> or
+      <command>systemctl start local-fs.target</command> may be used.
+      </para>
+    </example>
+
+    <example>
+      <title>systemd-system-update-generator</title>
+
+      <para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      temporarily redirects <filename>default.target</filename> to
+      <filename>system-update.target</filename> if a system update is
+      scheduled. Since this needs to override the default user
+      configuration for <filename>default.target</filename>, it uses
+      argv[2]. For details about this logic, see
+      <ulink url="http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates">Implementing
+      Offline System Updates</ulink>.</para>
+    </example>
+
+    <example>
+      <title>Debugging a generator</title>
+
+      <programlisting>dir=$(mktemp -d)
+SYSTEMD_LOG_LEVEL=debug &systemgeneratordir;/systemd-fstab-generator \
+        "$dir" "$dir" "$dir"
+find $dir</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/src/grp-system/systemd/systemd.journal-fields.xml b/src/grp-system/systemd/systemd.journal-fields.xml
new file mode 100644
index 0000000000..494f97aad1
--- /dev/null
+++ b/src/grp-system/systemd/systemd.journal-fields.xml
@@ -0,0 +1,525 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.journal-fields">
+
+  <refentryinfo>
+    <title>systemd.journal-fields</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.journal-fields</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.journal-fields</refname>
+    <refpurpose>Special journal fields</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Entries in the journal resemble an environment block in
+    their syntax but with fields that can include binary data.
+    Primarily, fields are formatted UTF-8 text strings, and binary
+    formatting is used only where formatting as UTF-8 text strings
+    makes little sense. New fields may freely be defined by
+    applications, but a few fields have special meaning. All fields
+    with special meanings are optional. In some cases, fields may
+    appear more than once per entry.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>User Journal Fields</title>
+
+    <para>User fields are fields that are directly passed from clients
+    and stored in the journal.</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>MESSAGE=</varname></term>
+        <listitem>
+          <para>The human-readable message string for this entry. This
+          is supposed to be the primary text shown to the user. It is
+          usually not translated (but might be in some cases), and is
+          not supposed to be parsed for metadata.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MESSAGE_ID=</varname></term>
+        <listitem>
+          <para>A 128-bit message identifier ID for recognizing
+          certain message types, if this is desirable. This should
+          contain a 128-bit ID formatted as a lower-case hexadecimal
+          string, without any separating dashes or suchlike. This is
+          recommended to be a UUID-compatible ID, but this is not
+          enforced, and formatted differently. Developers can generate
+          a new ID for this purpose with <command>journalctl
+          <option>--new-id</option></command>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PRIORITY=</varname></term>
+        <listitem>
+          <para>A priority value between 0 (<literal>emerg</literal>)
+          and 7 (<literal>debug</literal>) formatted as a decimal
+          string. This field is compatible with syslog's priority
+          concept.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CODE_FILE=</varname></term>
+        <term><varname>CODE_LINE=</varname></term>
+        <term><varname>CODE_FUNC=</varname></term>
+        <listitem>
+          <para>The code location generating this message, if known.
+          Contains the source filename, the line number and the
+          function name.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ERRNO=</varname></term>
+        <listitem>
+          <para>The low-level Unix error number causing this entry, if
+          any. Contains the numeric value of
+          <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          formatted as a decimal string.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSLOG_FACILITY=</varname></term>
+        <term><varname>SYSLOG_IDENTIFIER=</varname></term>
+        <term><varname>SYSLOG_PID=</varname></term>
+        <listitem>
+          <para>Syslog compatibility fields containing the facility
+          (formatted as decimal string), the identifier string (i.e.
+          "tag"), and the client PID. (Note that the tag is usually
+          derived from glibc's
+          <varname>program_invocation_short_name</varname> variable,
+          see
+          <citerefentry project='die-net'><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para>
+        </listitem>
+
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Trusted Journal Fields</title>
+
+    <para>Fields prefixed with an underscore are trusted fields, i.e.
+    fields that are implicitly added by the journal and cannot be
+    altered by client code.</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>_PID=</varname></term>
+        <term><varname>_UID=</varname></term>
+        <term><varname>_GID=</varname></term>
+        <listitem>
+          <para>The process, user, and group ID of the process the
+          journal entry originates from formatted as a decimal
+          string.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_COMM=</varname></term>
+        <term><varname>_EXE=</varname></term>
+        <term><varname>_CMDLINE=</varname></term>
+        <listitem>
+          <para>The name, the executable path, and the command line of
+          the process the journal entry originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_CAP_EFFECTIVE=</varname></term>
+        <listitem>
+          <para>The effective
+          <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          of the process the journal entry originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_AUDIT_SESSION=</varname></term>
+        <term><varname>_AUDIT_LOGINUID=</varname></term>
+        <listitem>
+          <para>The session and login UID of the process the journal
+          entry originates from, as maintained by the kernel audit
+          subsystem.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SYSTEMD_CGROUP=</varname></term>
+        <term><varname>_SYSTEMD_SESSION=</varname></term>
+        <term><varname>_SYSTEMD_UNIT=</varname></term>
+        <term><varname>_SYSTEMD_USER_UNIT=</varname></term>
+        <term><varname>_SYSTEMD_OWNER_UID=</varname></term>
+        <term><varname>_SYSTEMD_SLICE=</varname></term>
+
+        <listitem>
+          <para>The control group path in the systemd hierarchy, the
+          systemd session ID (if any), the systemd unit name (if any),
+          the systemd user session unit name (if any), the owner UID
+          of the systemd session (if any) and the systemd slice unit
+          of the process the journal entry originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SELINUX_CONTEXT=</varname></term>
+        <listitem>
+          <para>The SELinux security context (label) of the process
+          the journal entry originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>The earliest trusted timestamp of the message, if any
+          is known that is different from the reception time of the
+          journal. This is the time in microseconds since the epoch
+          UTC, formatted as a decimal string.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_BOOT_ID=</varname></term>
+        <listitem>
+          <para>The kernel boot ID for the boot the message was
+          generated in, formatted as a 128-bit hexadecimal
+          string.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_MACHINE_ID=</varname></term>
+        <listitem>
+          <para>The machine ID of the originating host, as available
+          in
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_HOSTNAME=</varname></term>
+        <listitem>
+          <para>The name of the originating host.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_TRANSPORT=</varname></term>
+        <listitem>
+          <para>How the entry was received by the journal service.
+          Valid transports are:
+          </para>
+          <variablelist>
+            <varlistentry>
+              <term>
+                <option>audit</option>
+              </term>
+              <listitem>
+                <para>for those read from the kernel audit subsystem
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>driver</option>
+              </term>
+              <listitem>
+                <para>for internally generated messages
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>syslog</option>
+              </term>
+              <listitem>
+                <para>for those received via the local syslog socket
+                with the syslog protocol
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>journal</option>
+              </term>
+              <listitem>
+                <para>for those received via the native journal
+                protocol
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>stdout</option>
+              </term>
+              <listitem>
+                <para>for those read from a service's standard output
+                or error output
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>kernel</option>
+              </term>
+              <listitem>
+                <para>for those read from the kernel
+                </para>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Journal Fields</title>
+
+    <para>Kernel fields are fields that are used by messages
+    originating in the kernel and stored in the journal.</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>_KERNEL_DEVICE=</varname></term>
+        <listitem>
+          <para>The kernel device name. If the entry is associated to
+          a block device, the major and minor of the device node,
+          separated by <literal>:</literal> and prefixed by
+          <literal>b</literal>. Similar for character devices but
+          prefixed by <literal>c</literal>. For network devices, this
+          is the interface index prefixed by <literal>n</literal>. For
+          all other devices, this is the subsystem name prefixed by
+          <literal>+</literal>, followed by <literal>:</literal>,
+          followed by the kernel device name.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_KERNEL_SUBSYSTEM=</varname></term>
+        <listitem>
+          <para>The kernel subsystem name.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_UDEV_SYSNAME=</varname></term>
+        <listitem>
+          <para>The kernel device name as it shows up in the device
+          tree below <filename>/sys</filename>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_UDEV_DEVNODE=</varname></term>
+        <listitem>
+          <para>The device node path of this device in
+          <filename>/dev</filename>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_UDEV_DEVLINK=</varname></term>
+        <listitem>
+          <para>Additional symlink names pointing to the device node
+          in <filename>/dev</filename>. This field is frequently set
+          more than once per entry.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Fields to log on behalf of a different program</title>
+
+    <para>Fields in this section are used by programs to specify that
+    they are logging on behalf of another program or unit.
+    </para>
+
+    <para>Fields used by the <command>systemd-coredump</command>
+    coredump kernel helper:
+    </para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>COREDUMP_UNIT=</varname></term>
+        <term><varname>COREDUMP_USER_UNIT=</varname></term>
+        <listitem>
+          <para>Used to annotate messages containing coredumps from
+          system and session units. See
+          <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Privileged programs (currently UID 0) may attach
+    <varname>OBJECT_PID=</varname> to a message. This will instruct
+    <command>systemd-journald</command> to attach additional fields on
+    behalf of the caller:</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>OBJECT_PID=<replaceable>PID</replaceable></varname></term>
+        <listitem>
+          <para>PID of the program that this message pertains to.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OBJECT_UID=</varname></term>
+        <term><varname>OBJECT_GID=</varname></term>
+        <term><varname>OBJECT_COMM=</varname></term>
+        <term><varname>OBJECT_EXE=</varname></term>
+        <term><varname>OBJECT_CMDLINE=</varname></term>
+        <term><varname>OBJECT_AUDIT_SESSION=</varname></term>
+        <term><varname>OBJECT_AUDIT_LOGINUID=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_CGROUP=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_SESSION=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_OWNER_UID=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_UNIT=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_USER_UNIT=</varname></term>
+        <listitem>
+          <para>These are additional fields added automatically by
+          <command>systemd-journald</command>. Their meaning is the
+          same as
+          <varname>_UID=</varname>,
+          <varname>_GID=</varname>,
+          <varname>_COMM=</varname>,
+          <varname>_EXE=</varname>,
+          <varname>_CMDLINE=</varname>,
+          <varname>_AUDIT_SESSION=</varname>,
+          <varname>_AUDIT_LOGINUID=</varname>,
+          <varname>_SYSTEMD_CGROUP=</varname>,
+          <varname>_SYSTEMD_SESSION=</varname>,
+          <varname>_SYSTEMD_UNIT=</varname>,
+          <varname>_SYSTEMD_USER_UNIT=</varname>, and
+          <varname>_SYSTEMD_OWNER_UID=</varname>
+          as described above, except that the process identified by
+          <replaceable>PID</replaceable> is described, instead of the
+          process which logged the message.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Address Fields</title>
+
+    <para>During serialization into external formats, such as the
+    <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/export">Journal
+    Export Format</ulink> or the <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/json">Journal
+    JSON Format</ulink>, the addresses of journal entries are
+    serialized into fields prefixed with double underscores. Note that
+    these are not proper fields when stored in the journal but for
+    addressing metadata of entries. They cannot be written as part of
+    structured log entries via calls such as
+    <citerefentry><refentrytitle>sd_journal_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    They may also not be used as matches for
+    <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry></para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>__CURSOR=</varname></term>
+        <listitem>
+          <para>The cursor for the entry. A cursor is an opaque text
+          string that uniquely describes the position of an entry in
+          the journal and is portable across machines, platforms and
+          journal files.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>__REALTIME_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>The wallclock time
+          (<constant>CLOCK_REALTIME</constant>) at the point in time
+          the entry was received by the journal, in microseconds since
+          the epoch UTC, formatted as a decimal string. This has
+          different properties from
+          <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is
+          usually a bit later but more likely to be monotonic.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>__MONOTONIC_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>The monotonic time
+          (<constant>CLOCK_MONOTONIC</constant>) at the point in time
+          the entry was received by the journal in microseconds,
+          formatted as a decimal string. To be useful as an address
+          for the entry, this should be combined with the boot ID in
+          <literal>_BOOT_ID=</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.kill.xml b/src/grp-system/systemd/systemd.kill.xml
new file mode 100644
index 0000000000..13b7ab14df
--- /dev/null
+++ b/src/grp-system/systemd/systemd.kill.xml
@@ -0,0 +1,189 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2012 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.kill">
+  <refentryinfo>
+    <title>systemd.kill</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.kill</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.kill</refname>
+    <refpurpose>Process killing procedure
+    configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename>,
+    <filename><replaceable>socket</replaceable>.socket</filename>,
+    <filename><replaceable>mount</replaceable>.mount</filename>,
+    <filename><replaceable>swap</replaceable>.swap</filename>,
+    <filename><replaceable>scope</replaceable>.scope</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Unit configuration files for services, sockets, mount
+    points, swap devices and scopes share a subset of configuration
+    options which define the killing procedure of processes belonging
+    to the unit.</para>
+
+    <para>This man page lists the configuration options shared by
+    these five unit types. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options shared by all unit configuration files, and
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information on the configuration file options specific to
+    each unit type.</para>
+
+    <para>The kill procedure configuration options are configured in
+    the [Service], [Socket], [Mount] or [Swap] section, depending on
+    the unit type.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>KillMode=</varname></term>
+        <listitem><para>Specifies how processes of this unit shall be
+        killed. One of
+        <option>control-group</option>,
+        <option>process</option>,
+        <option>mixed</option>,
+        <option>none</option>.</para>
+
+        <para>If set to <option>control-group</option>, all remaining
+        processes in the control group of this unit will be killed on
+        unit stop (for services: after the stop command is executed,
+        as configured with <varname>ExecStop=</varname>). If set to
+        <option>process</option>, only the main process itself is
+        killed. If set to <option>mixed</option>, the
+        <constant>SIGTERM</constant> signal (see below) is sent to the
+        main process while the subsequent <constant>SIGKILL</constant>
+        signal (see below) is sent to all remaining processes of the
+        unit's control group. If set to <option>none</option>, no
+        process is killed. In this case, only the stop command will be
+        executed on unit stop, but no process be killed otherwise.
+        Processes remaining alive after stop are left in their control
+        group and the control group continues to exist after stop
+        unless it is empty.</para>
+
+        <para>Processes will first be terminated via
+        <constant>SIGTERM</constant> (unless the signal to send is
+        changed via <varname>KillSignal=</varname>). Optionally, this
+        is immediately followed by a <constant>SIGHUP</constant> (if
+        enabled with <varname>SendSIGHUP=</varname>). If then, after a
+        delay (configured via the <varname>TimeoutStopSec=</varname>
+        option), processes still remain, the termination request is
+        repeated with the <constant>SIGKILL</constant> signal (unless
+        this is disabled via the <varname>SendSIGKILL=</varname>
+        option). See
+        <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for more information.</para>
+
+        <para>Defaults to
+        <option>control-group</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KillSignal=</varname></term>
+        <listitem><para>Specifies which signal to use when killing a
+        service. This controls the signal that is sent as first step
+        of shutting down a unit (see above), and is usually followed
+        by <constant>SIGKILL</constant> (see above and below). For a
+        list of valid signals, see
+        <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        Defaults to <constant>SIGTERM</constant>. </para>
+
+        <para>Note that, right after sending the signal specified in
+        this setting, systemd will always send
+        <constant>SIGCONT</constant>, to ensure that even suspended
+        tasks can be terminated cleanly.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendSIGHUP=</varname></term>
+        <listitem><para>Specifies whether to send
+        <constant>SIGHUP</constant> to remaining processes immediately
+        after sending the signal configured with
+        <varname>KillSignal=</varname>. This is useful to indicate to
+        shells and shell-like programs that their connection has been
+        severed. Takes a boolean value. Defaults to "no".
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendSIGKILL=</varname></term>
+        <listitem><para>Specifies whether to send
+        <constant>SIGKILL</constant> to remaining processes after a
+        timeout, if the normal shutdown procedure left processes of
+        the service around. Takes a boolean value. Defaults to "yes".
+        </para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </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>journalctl</refentrytitle><manvolnum>8</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.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.link.xml b/src/grp-system/systemd/systemd.link.xml
new file mode 100644
index 0000000000..d5b4d1038d
--- /dev/null
+++ b/src/grp-system/systemd/systemd.link.xml
@@ -0,0 +1,477 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2014 Tom Gundersen
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.link">
+  <refentryinfo>
+    <title>systemd.link</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Tom</firstname>
+        <surname>Gundersen</surname>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.link</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.link</refname>
+    <refpurpose>Network device configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>link</replaceable>.link</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Network link configuration is performed by the
+    <command>net_setup_link</command> udev builtin.</para>
+
+    <para>The link files are read from the files located in the system
+    network directory <filename>/usr/lib/systemd/network</filename>,
+    the volatile runtime network directory
+    <filename>/run/systemd/network</filename>, and the local
+    administration network directory
+    <filename>/etc/systemd/network</filename>. Link files must have
+    the extension <filename>.link</filename>; other extensions are
+    ignored. All link files are collectively sorted and processed in
+    lexical order, regardless of the directories in which they live.
+    However, files with identical filenames replace each other. Files
+    in <filename>/etc</filename> have the highest priority, files in
+    <filename>/run</filename> take precedence over files with the same
+    name in <filename>/usr/lib</filename>. This can be used to
+    override a system-supplied link file with a local file if needed.
+    As a special case, an empty file (file size 0) or symlink with the
+    same name pointing to <filename>/dev/null</filename> disables the
+    configuration file entirely (it is "masked").</para>
+
+    <para>The link file contains a <literal>[Match]</literal> section,
+    which determines if a given link file may be applied to a given
+    device, as well as a <literal>[Link]</literal> section specifying
+    how the device should be configured. The first (in lexical order)
+    of the link files that matches a given device is applied. Note
+    that a default file <filename>99-default.link</filename> is
+    shipped by the system, any user-supplied
+    <filename>.link</filename> should hence have a lexically earlier
+    name to be considered at all.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for diagnosing problems with <filename>.link</filename> files.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Match] Section Options</title>
+
+    <para>A link file is said to match a device if each of the entries
+    in the <literal>[Match]</literal> section matches, or if the
+    section is empty. The following keys are accepted:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>The hardware address.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>OriginalName=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching
+          the device name, as exposed by the udev property
+          "INTERFACE". This can not be used to match on names that have
+          already been changed from userspace. Caution is advised when matching on
+          kernel-assigned names, as they are known to be unstable
+          between reboots.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Path=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching
+          the persistent path, as exposed by the udev property
+          <literal>ID_PATH</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Driver=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching
+          the driver currently bound to the device,
+          as exposed by the udev property <literal>DRIVER</literal>
+          of its parent device, or if that is not set, the
+          driver as exposed by <literal>ethtool -i</literal>
+          of the device itself.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching
+          the device type, as exposed by the udev
+          property <literal>DEVTYPE</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Host=</varname></term>
+        <listitem>
+          <para>Matches against the hostname or machine
+          ID of the host. See <literal>ConditionHost=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Virtualization=</varname></term>
+        <listitem>
+          <para>Checks whether the system is executed in
+          a virtualized environment and optionally test
+          whether it is a specific implementation. See
+          <literal>ConditionVirtualization=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KernelCommandLine=</varname></term>
+        <listitem>
+          <para>Checks whether a specific kernel command line option
+          is set (or if prefixed with the exclamation mark unset). See
+          <literal>ConditionKernelCommandLine=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Architecture=</varname></term>
+        <listitem>
+          <para>Checks whether the system is running on a specific
+          architecture. See <literal>ConditionArchitecture=</literal>
+          in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Link] Section Options</title>
+
+    <para>The <literal>[Link]</literal> section accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Description=</varname></term>
+        <listitem>
+          <para>A description of the device.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Alias=</varname></term>
+        <listitem>
+          <para>The <literal>ifalias</literal> is set to this
+          value.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddressPolicy=</varname></term>
+        <listitem>
+          <para>The policy by which the MAC address should be set. The
+          available policies are:
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><literal>persistent</literal></term>
+              <listitem>
+                <para>If the hardware has a persistent MAC address, as
+                most hardware should, and if it is used by the kernel,
+                nothing is done. Otherwise, a new MAC address is
+                generated which is guaranteed to be the same on every
+                boot for the given machine and the given device, but
+                which is otherwise random. This feature depends on ID_NET_NAME_*
+                properties to exist for the link. On hardware where these
+                properties are not set, the generation of a persistent MAC address
+                will fail.</para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>random</literal></term>
+              <listitem>
+                <para>If the kernel is using a random MAC address,
+                nothing is done. Otherwise, a new address is randomly
+                generated each time the device appears, typically at
+                boot. Either way, the random address will have the
+                <literal>unicast</literal> and
+                <literal>locally administered</literal> bits set.</para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>none</literal></term>
+              <listitem>
+                <para>Keeps the MAC address assigned by the kernel.</para>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>The MAC address to use, if no
+          <literal>MACAddressPolicy=</literal>
+          is specified.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>NamePolicy=</varname></term>
+        <listitem>
+          <para>An ordered, space-separated list of policies by which
+          the interface name should be set.
+          <literal>NamePolicy</literal> may be disabled by specifying
+          <literal>net.ifnames=0</literal> on the kernel command line.
+          Each of the policies may fail, and the first successful one
+          is used. The name is not set directly, but is exported to
+          udev as the property <literal>ID_NET_NAME</literal>, which
+          is, by default, used by a udev rule to set
+          <literal>NAME</literal>. If the name has already been set by
+          userspace, no renaming is performed. The available policies
+          are:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><literal>kernel</literal></term>
+              <listitem>
+                <para>If the kernel claims that the name it has set
+                for a device is predictable, then no renaming is
+                performed.</para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>database</literal></term>
+              <listitem>
+                <para>The name is set based on entries in the udev's
+                Hardware Database with the key
+                <literal>ID_NET_NAME_FROM_DATABASE</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>onboard</literal></term>
+              <listitem>
+                <para>The name is set based on information given by
+                the firmware for on-board devices, as exported by the
+                udev property <literal>ID_NET_NAME_ONBOARD</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>slot</literal></term>
+              <listitem>
+                <para>The name is set based on information given by
+                the firmware for hot-plug devices, as exported by the
+                udev property <literal>ID_NET_NAME_SLOT</literal>.
+                </para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>path</literal></term>
+              <listitem>
+                <para>The name is set based on the device's physical
+                location, as exported by the udev property
+                <literal>ID_NET_NAME_PATH</literal>.</para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>mac</literal></term>
+              <listitem>
+                <para>The name is set based on the device's persistent
+                MAC address, as exported by the udev property
+                <literal>ID_NET_NAME_MAC</literal>.</para>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Name=</varname></term>
+        <listitem>
+          <para>The interface name to use in case all the
+          policies specified in
+          <varname>NamePolicy=</varname> fail, or in case
+          <varname>NamePolicy=</varname> is missing or
+          disabled.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>The maximum transmission unit in bytes to set for the
+          device. The usual suffixes K, M, G, are supported and are
+          understood to the base of 1024.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>BitsPerSecond=</varname></term>
+        <listitem>
+          <para>The speed to set for the device, the value is rounded
+          down to the nearest Mbps. The usual suffixes K, M, G, are
+          supported and are understood to the base of 1000.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Duplex=</varname></term>
+        <listitem>
+          <para>The duplex mode to set for the device. The accepted
+          values are <literal>half</literal> and
+          <literal>full</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>WakeOnLan=</varname></term>
+        <listitem>
+          <para>The Wake-on-LAN policy to set for the device. The
+          supported values are:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><literal>phy</literal></term>
+              <listitem>
+                <para>Wake on PHY activity.</para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>magic</literal></term>
+              <listitem>
+                <para>Wake on receipt of a magic packet.
+                </para>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><literal>off</literal></term>
+              <listitem>
+                <para>Never wake.</para>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>/usr/lib/systemd/network/99-default.link</title>
+
+      <para>The link file <filename>99-default.link</filename> that is
+      shipped with systemd defines the default naming policy for
+      links.</para>
+
+      <programlisting>[Link]
+NamePolicy=kernel database onboard slot path
+MACAddressPolicy=persistent</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/10-dmz.link</title>
+
+      <para>This example assigns the fixed name
+      <literal>dmz0</literal> to the interface with the MAC address
+      00:a0:de:63:7a:e6:</para>
+
+      <programlisting>[Match]
+MACAddress=00:a0:de:63:7a:e6
+
+[Link]
+Name=dmz0</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/10-internet.link</title>
+
+      <para>This example assigns the fixed name
+      <literal>internet0</literal> to the interface with the device
+      path <literal>pci-0000:00:1a.0-*</literal>:</para>
+
+      <programlisting>[Match]
+Path=pci-0000:00:1a.0-*
+
+[Link]
+Name=internet0</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-wireless.link</title>
+
+      <para>Here's an overly complex example that shows the use of a large number of [Match] and [Link] settings.</para>
+
+      <programlisting>[Match]
+MACAddress=12:34:56:78:9a:bc
+Driver=brcmsmac
+Path=pci-0000:02:00.0-*
+Type=wlan
+Virtualization=no
+Host=my-laptop
+Architecture=x86-64
+
+[Link]
+Name=wireless0
+MTUBytes=1450
+BitsPerSecond=10M
+WakeOnLan=magic
+MACAddress=cb:a9:87:65:43:21</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry>
+        <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum>
+      </citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.mount.xml b/src/grp-system/systemd/systemd.mount.xml
new file mode 100644
index 0000000000..66cddd72e0
--- /dev/null
+++ b/src/grp-system/systemd/systemd.mount.xml
@@ -0,0 +1,406 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.mount">
+  <refentryinfo>
+    <title>systemd.mount</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.mount</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.mount</refname>
+    <refpurpose>Mount unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>mount</replaceable>.mount</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.mount</literal> encodes information about a file system
+    mount point controlled and supervised by systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The mount specific configuration options are
+    configured in the [Mount] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the
+    <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    binary is executed in, and in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way the processes are terminated, and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for the processes of the
+    service. Note that the User= and Group= options are not
+    particularly useful for mount units specifying a
+    <literal>Type=</literal> option or using configuration not
+    specified in <filename>/etc/fstab</filename>;
+    <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    will refuse options that are not listed in
+    <filename>/etc/fstab</filename> if it is not run as UID 0.</para>
+
+    <para>Mount units must be named after the mount point directories they control. Example: the mount point <filename
+    noindex='true'>/home/lennart</filename> must be configured in a unit file <filename>home-lennart.mount</filename>.
+    For details about the escaping logic used to convert a file system path to a unit name, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.  Note that mount
+    units cannot be templated, nor is possible to add multiple names to a mount unit by creating additional symlinks to
+    it.</para>
+
+    <para>Optionally, a mount unit may be accompanied by an automount
+    unit, to allow on-demand or parallelized mounting. See
+    <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Mount points created at runtime (independently of unit files
+    or <filename>/etc/fstab</filename>) will be monitored by systemd
+    and appear like any other mount unit in systemd. See
+    <filename>/proc/self/mountinfo</filename> description in
+    <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Some file systems have special semantics as API file systems
+    for kernel-to-userspace and userspace-to-userspace interfaces. Some
+    of them may not be changed via mount units, and cannot be
+    disabled. For a longer discussion see <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems">API
+    File Systems</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>If a mount unit is beneath another mount unit in the file
+    system hierarchy, both a requirement dependency and an ordering
+    dependency between both units are created automatically.</para>
+
+    <para>Block device backed file systems automatically gain
+    <varname>BindsTo=</varname> and <varname>After=</varname> type
+    dependencies on the device unit encapsulating the block
+    device (see below).</para>
+
+    <para>If traditional file system quota is enabled for a mount
+    unit, automatic <varname>Wants=</varname> and
+    <varname>Before=</varname> dependencies on
+    <filename>systemd-quotacheck.service</filename> and
+    <filename>quotaon.service</filename> are added.</para>
+
+    <para>For mount units with <varname>DefaultDependencies=yes</varname> in the <literal>[Unit]</literal> section (the
+    default) a couple additional dependencies are added. Mount units referring to local file systems automatically gain
+    an <varname>After=</varname> dependency on <filename>local-fs-pre.target</filename>. Network mount units
+    automatically acquire <varname>After=</varname> dependencies on <filename>remote-fs-pre.target</filename>,
+    <filename>network.target</filename> and <filename>network-online.target</filename>. Towards the latter a
+    <varname>Wants=</varname> unit is added as well. Mount units referring to local and network file systems are
+    distinguished by their file system type specification. In some cases this is not sufficient (for example network
+    block device based mounts, such as iSCSI), in which case <option>_netdev</option> may be added to the mount option
+    string of the unit, which forces systemd to consider the mount unit a network mount. Mount units (regardless if
+    local or network) also acquire automatic <varname>Before=</varname> and <varname>Conflicts=</varname> on
+    <filename>umount.target</filename> in order to be stopped during shutdown.</para>
+
+    <para>Additional implicit dependencies may be added as result of
+    execution and resource control parameters as documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>fstab</filename></title>
+
+    <para>Mount units may either be configured via unit files, or via
+    <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details). Mounts listed in <filename>/etc/fstab</filename>
+    will be converted into native units dynamically at boot and when
+    the configuration of the system manager is reloaded. In general,
+    configuring mount points through <filename>/etc/fstab</filename>
+    is the preferred approach. See
+    <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for details about the conversion.</para>
+
+    <para>The NFS mount option <option>bg</option> for NFS background mounts
+    as documented in <citerefentry><refentrytitle>nfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    is not supported in <filename>/etc/fstab</filename> entries. The systemd mount option <option>nofail</option>
+    provides similar functionality and should be used instead.</para>
+
+    <para>When reading <filename>/etc/fstab</filename> a few special
+    mount options are understood by systemd which influence how
+    dependencies are created for mount points. systemd will create a
+    dependency of type <varname>Wants=</varname> or
+    <option>Requires</option> (see option <option>nofail</option>
+    below), from either <filename>local-fs.target</filename> or
+    <filename>remote-fs.target</filename>, depending whether the file
+    system is local or remote.</para>
+
+    <variablelist class='fstab-options'>
+
+      <varlistentry>
+        <term><option>x-systemd.requires=</option></term>
+
+        <listitem><para>Configures a <varname>Requires=</varname> and
+        an <varname>After=</varname> dependency between the created
+        mount unit and another systemd unit, such as a device or mount
+        unit. The argument should be a unit name, or an absolute path
+        to a device node or mount point.  This option may be specified
+        more than once. This option is particularly useful for mount
+        point declarations that need an additional device to be around
+        (such as an external journal device for journal file systems)
+        or an additional mount to be in place (such as an overlay file
+        system that merges multiple mount points). See
+        <varname>After=</varname> and <varname>Requires=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.requires-mounts-for=</option></term>
+
+        <listitem><para>Configures a
+        <varname>RequiresMountsFor=</varname> dependency between the
+        created mount unit and other mount units. The argument must be
+        an absolute path. This option may be specified more than once.
+        See <varname>RequiresMountsFor=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+       </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.automount</option></term>
+
+        <listitem><para>An automount unit will be created for the file
+        system. See
+        <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.idle-timeout=</option></term>
+
+        <listitem><para>Configures the idle timeout of the
+        automount unit. See <varname>TimeoutIdleSec=</varname> in
+        <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.device-timeout=</option></term>
+
+        <listitem><para>Configure how long systemd should wait for a
+        device to show up before giving up on an entry from
+        <filename>/etc/fstab</filename>. Specify a time in seconds or
+        explicitly append a unit such as <literal>s</literal>,
+        <literal>min</literal>, <literal>h</literal>,
+        <literal>ms</literal>.</para>
+
+        <para>Note that this option can only be used in
+        <filename>/etc/fstab</filename>, and will be
+        ignored when part of the <varname>Options=</varname>
+        setting in a unit file.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>noauto</option></term>
+        <term><option>auto</option></term>
+
+        <listitem><para>With <option>noauto</option>, this mount will
+        not be added as a dependency for
+        <filename>local-fs.target</filename> or
+        <filename>remote-fs.target</filename>. This means that it will
+        not be mounted automatically during boot, unless it is pulled
+        in by some other unit. The <option>auto</option> option has the
+        opposite meaning and is the default.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>nofail</option></term>
+
+        <listitem><para>With <option>nofail</option>, this mount will
+        be only wanted, not required, by
+        <filename>local-fs.target</filename> or
+        <filename>remote-fs.target</filename>. This means that the
+        boot will continue even if this mount point is not mounted
+        successfully.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-initrd.mount</option></term>
+
+        <listitem><para>An additional filesystem to be mounted in the
+        initramfs. See <filename>initrd-fs.target</filename>
+        description in
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>If a mount point is configured in both
+    <filename>/etc/fstab</filename> and a unit file that is stored
+    below <filename>/usr</filename>, the former will take precedence.
+    If the unit file is stored below <filename>/etc</filename>, it
+    will take precedence. This means: native unit files take
+    precedence over traditional configuration files, but this is
+    superseded by the rule that configuration in
+    <filename>/etc</filename> will always take precedence over
+    configuration in <filename>/usr</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Mount files must include a [Mount] section, which carries
+    information about the file system mount points it supervises. A
+    number of options that may be used in this section are shared with
+    other unit types. These options are documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Mount] section of mount units are the
+    following:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>What=</varname></term>
+        <listitem><para>Takes an absolute path of a device node, file
+        or other resource to mount. See
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details. If this refers to a device node, a dependency on
+        the respective device unit is automatically created. (See
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.) This option is
+        mandatory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Where=</varname></term>
+        <listitem><para>Takes an absolute path of a directory of the
+        mount point. If the mount point does not exist at the time of
+        mounting, it is created. This string must be reflected in the
+        unit filename. (See above.) This option is
+        mandatory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+        <listitem><para>Takes a string for the file system type. See
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details. This setting is optional.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Options=</varname></term>
+
+        <listitem><para>Mount options to use when mounting. This takes
+        a comma-separated list of options. This setting is
+        optional.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SloppyOptions=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, parsing of
+        the options specified in <varname>Options=</varname> is
+        relaxed, and unknown mount options are tolerated. This
+        corresponds with
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+        <parameter>-s</parameter> switch. Defaults to
+        off.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+        <listitem><para>Directories of mount points (and any parent
+        directories) are automatically created if needed. This option
+        specifies the file system access mode used when creating these
+        directories. Takes an access mode in octal notation. Defaults
+        to 0755.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>Configures the time to wait for the mount
+        command to finish. If a command does not exit within the
+        configured time, the mount will be considered failed and be
+        shut down again. All commands still running will be terminated
+        forcibly via <constant>SIGTERM</constant>, and after another
+        delay of this time with <constant>SIGKILL</constant>. (See
+        <option>KillMode=</option> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass 0 to disable the timeout logic. The
+        default value is set from the manager configuration file's
+        <varname>DefaultTimeoutStart=</varname>
+        variable.</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Check
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more settings.</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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.netdev.xml b/src/grp-system/systemd/systemd.netdev.xml
new file mode 100644
index 0000000000..8d12c305d2
--- /dev/null
+++ b/src/grp-system/systemd/systemd.netdev.xml
@@ -0,0 +1,1116 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Tom Gundersen
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.netdev" conditional='ENABLE_NETWORKD'>
+
+  <refentryinfo>
+    <title>systemd.network</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Tom</firstname>
+        <surname>Gundersen</surname>
+        <email>teg@jklm.no</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.netdev</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.netdev</refname>
+    <refpurpose>Virtual Network Device configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>netdev</replaceable>.netdev</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Network setup is performed by
+    <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>Virtual Network Device files must have the extension
+    <filename>.netdev</filename>; other extensions are ignored.
+    Virtual network devices are created as soon as networkd is
+    started. If a netdev with the specified name already exists,
+    networkd will use that as-is rather than create its own. Note that
+    the settings of the pre-existing netdev will not be changed by
+    networkd.</para>
+
+    <para>The <filename>.netdev</filename> files are read from the
+    files located in the system network directory
+    <filename>/usr/lib/systemd/network</filename>, the volatile
+    runtime network directory
+    <filename>/run/systemd/network</filename> and the local
+    administration network directory
+    <filename>/etc/systemd/network</filename>. All configuration files
+    are collectively sorted and processed in lexical order, regardless
+    of the directories in which they live. However, files with
+    identical filenames replace each other. Files in
+    <filename>/etc</filename> have the highest priority, files in
+    <filename>/run</filename> take precedence over files with the same
+    name in <filename>/usr/lib</filename>. This can be used to
+    override a system-supplied configuration file with a local file if
+    needed. As a special case, an empty file (file size 0) or symlink
+    with the same name pointing to <filename>/dev/null</filename>
+    disables the configuration file entirely (it is "masked").</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Supported netdev kinds</title>
+
+    <para>The following kinds of virtual network devices may be
+    configured in <filename>.netdev</filename> files:</para>
+
+    <table>
+      <title>Supported kinds of virtual network devices</title>
+
+      <tgroup cols='2'>
+        <colspec colname='kind' />
+        <colspec colname='explanation' />
+        <thead><row>
+          <entry>Kind</entry>
+          <entry>Description</entry>
+        </row></thead>
+        <tbody>
+          <row><entry><varname>bond</varname></entry>
+          <entry>A bond device is an aggregation of all its slave devices. See <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">Linux Ethernet Bonding Driver HOWTO</ulink> for details.Local configuration</entry></row>
+
+          <row><entry><varname>bridge</varname></entry>
+          <entry>A bridge device is a software switch, and each of its slave devices and the bridge itself are ports of the switch.</entry></row>
+
+          <row><entry><varname>dummy</varname></entry>
+          <entry>A dummy device drops all packets sent to it.</entry></row>
+
+          <row><entry><varname>gre</varname></entry>
+          <entry>A Level 3 GRE tunnel over IPv4. See <ulink url="https://tools.ietf.org/html/rfc2784">RFC 2784</ulink> for details.</entry></row>
+
+          <row><entry><varname>gretap</varname></entry>
+          <entry>A Level 2 GRE tunnel over IPv4.</entry></row>
+
+          <row><entry><varname>ip6gre</varname></entry>
+          <entry>A Level 3 GRE tunnel over IPv6.</entry></row>
+
+          <row><entry><varname>ip6tnl</varname></entry>
+          <entry>An IPv4 or IPv6 tunnel over IPv6</entry></row>
+
+          <row><entry><varname>ip6gretap</varname></entry>
+          <entry>An Level 2 GRE tunnel over IPv6.</entry></row>
+
+          <row><entry><varname>ipip</varname></entry>
+          <entry>An IPv4 over IPv4 tunnel.</entry></row>
+
+          <row><entry><varname>ipvlan</varname></entry>
+          <entry>An ipvlan device is a stacked device which receives packets from its underlying device based on IP address filtering.</entry></row>
+
+          <row><entry><varname>macvlan</varname></entry>
+          <entry>A macvlan device is a stacked device which receives packets from its underlying device based on MAC address filtering.</entry></row>
+
+          <row><entry><varname>macvtap</varname></entry>
+          <entry>A macvtap device is a stacked device which receives packets from its underlying device based on MAC address filtering.</entry></row>
+
+          <row><entry><varname>sit</varname></entry>
+          <entry>An IPv6 over IPv4 tunnel.</entry></row>
+
+          <row><entry><varname>tap</varname></entry>
+          <entry>A persistent Level 2 tunnel between a network device and a device node.</entry></row>
+
+          <row><entry><varname>tun</varname></entry>
+          <entry>A persistent Level 3 tunnel between a network device and a device node.</entry></row>
+
+          <row><entry><varname>veth</varname></entry>
+          <entry>An Ethernet tunnel between a pair of network devices.</entry></row>
+
+          <row><entry><varname>vlan</varname></entry>
+          <entry>A VLAN is a stacked device which receives packets from its underlying device based on VLAN tagging. See <ulink url="http://www.ieee802.org/1/pages/802.1Q.html">IEEE 802.1Q</ulink> for details.</entry></row>
+
+          <row><entry><varname>vti</varname></entry>
+          <entry>An IPv4 over IPSec tunnel.</entry></row>
+
+          <row><entry><varname>vti6</varname></entry>
+          <entry>An IPv6 over IPSec tunnel.</entry></row>
+
+          <row><entry><varname>vxlan</varname></entry>
+          <entry>A virtual extensible LAN (vxlan), for connecting Cloud computing deployments.</entry></row>
+        </tbody>
+      </tgroup>
+    </table>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Match] Section Options</title>
+
+    <para>A virtual network device is only created if the
+    <literal>[Match]</literal> section matches the current
+    environment, or if the section is empty. The following keys are
+    accepted:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Host=</varname></term>
+        <listitem>
+          <para>Matches against the hostname or machine ID of the
+          host. See <literal>ConditionHost=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Virtualization=</varname></term>
+        <listitem>
+          <para>Checks whether the system is executed in a virtualized
+          environment and optionally test whether it is a specific
+          implementation. See
+          <literal>ConditionVirtualization=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KernelCommandLine=</varname></term>
+        <listitem>
+          <para>Checks whether a specific kernel command line option
+          is set (or if prefixed with the exclamation mark unset). See
+          <literal>ConditionKernelCommandLine=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Architecture=</varname></term>
+        <listitem>
+          <para>Checks whether the system is running on a specific
+          architecture. See <literal>ConditionArchitecture=</literal> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[NetDev] Section Options</title>
+
+      <para>The <literal>[NetDev]</literal> section accepts the
+      following keys:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Description=</varname></term>
+          <listitem>
+            <para>A free-form description of the netdev.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Name=</varname></term>
+          <listitem>
+            <para>The interface name used when creating the netdev.
+            This option is compulsory.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Kind=</varname></term>
+          <listitem>
+            <para>The netdev kind. This option is compulsory. See the
+            <literal>Supported netdev kinds</literal> section for the
+            valid keys.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MTUBytes=</varname></term>
+          <listitem>
+            <para>The maximum transmission unit in bytes to set for
+            the device. The usual suffixes K, M, G, are supported and
+            are understood to the base of 1024. This key is not
+            currently supported for <literal>tun</literal> or
+            <literal>tap</literal> devices.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MACAddress=</varname></term>
+          <listitem>
+            <para>The MAC address to use for the device. If none is
+            given, one is generated based on the interface name and
+            the
+            <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+            This key is not currently supported for
+            <literal>tun</literal> or <literal>tap</literal> devices.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+    <refsect1>
+    <title>[Bridge] Section Options</title>
+
+      <para>The <literal>[Bridge]</literal> section only applies for
+      netdevs of kind <literal>bridge</literal>, and accepts the
+      following keys:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>HelloTimeSec=</varname></term>
+          <listitem>
+            <para>HelloTimeSec specifies the number of seconds between two hello packets
+            sent out by the root bridge and the designated bridges. Hello packets are
+            used to communicate information about the topology throughout the entire
+            bridged local area network.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MaxAgeSec=</varname></term>
+          <listitem>
+            <para>MaxAgeSec specifies the number of seconds of maximum message age.
+            If the last seen (received) hello packet is more than this number of
+            seconds old, the bridge in question will start the takeover procedure
+            in attempt to become the Root Bridge itself.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>ForwardDelaySec=</varname></term>
+          <listitem>
+            <para>ForwardDelaySec specifies the number of seconds spent in each
+            of the Listening and Learning states before the Forwarding state is entered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MulticastQuerier=</varname></term>
+          <listitem>
+            <para>A boolean. This setting controls the IFLA_BR_MCAST_QUERIER option in the kernel.
+            If enabled, the kernel will send general ICMP queries from a zero source address.
+            This feature should allow faster convergence on startup, but it causes some
+            multicast-aware switches to misbehave and disrupt forwarding of multicast packets.
+            When unset, the kernel's default setting applies.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MulticastSnooping=</varname></term>
+          <listitem>
+            <para>A boolean. This setting controls the IFLA_BR_MCAST_SNOOPING option in the kernel.
+            If enabled, IGMP snooping monitors the Internet Group Management Protocol (IGMP) traffic
+            between hosts and multicast routers. When unset, the kernel's default setting applies.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[VLAN] Section Options</title>
+
+      <para>The <literal>[VLAN]</literal> section only applies for
+      netdevs of kind <literal>vlan</literal>, and accepts the
+      following key:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Id=</varname></term>
+          <listitem>
+            <para>The VLAN ID to use. An integer in the range 0–4094.
+            This option is compulsory.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[MACVLAN] Section Options</title>
+
+    <para>The <literal>[MACVLAN]</literal> section only applies for
+    netdevs of kind <literal>macvlan</literal>, and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>The MACVLAN mode to use. The supported options are
+          <literal>private</literal>,
+          <literal>vepa</literal>,
+          <literal>bridge</literal>, and
+          <literal>passthru</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+    <refsect1>
+    <title>[MACVTAP] Section Options</title>
+
+    <para>The <literal>[MACVTAP]</literal> section applies for
+    netdevs of kind <literal>macvtap</literal> and accepts the
+    same key as <literal>[MACVLAN]</literal>.</para>
+
+    </refsect1>
+
+  <refsect1>
+    <title>[IPVLAN] Section Options</title>
+
+    <para>The <literal>[IPVLAN]</literal> section only applies for
+    netdevs of kind <literal>ipvlan</literal>, and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+          <listitem>
+            <para>The IPVLAN mode to use. The supported options are
+            <literal>L2</literal> and <literal>L3</literal>.
+            </para>
+          </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[VXLAN] Section Options</title>
+    <para>The <literal>[VXLAN]</literal> section only applies for
+    netdevs of kind <literal>vxlan</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Id=</varname></term>
+        <listitem>
+          <para>The VXLAN ID to use.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Group=</varname></term>
+        <listitem>
+          <para>An assigned multicast group IP address.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TOS=</varname></term>
+        <listitem>
+          <para>The Type Of Service byte value for a vxlan interface.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTL=</varname></term>
+        <listitem>
+          <para>A fixed Time To Live N on Virtual eXtensible Local
+          Area Network packets. N is a number in the range 1–255. 0
+          is a special value meaning that packets inherit the TTL
+          value.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MacLearning=</varname></term>
+        <listitem>
+          <para>A boolean. When true, enables dynamic MAC learning
+          to discover remote MAC addresses.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FDBAgeingSec=</varname></term>
+        <listitem>
+          <para>The lifetime of Forwarding Database entry learnt by
+          the kernel, in seconds.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MaximumFDBEntries=</varname></term>
+        <listitem>
+          <para>Configures maximum number of FDB entries.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ARPProxy=</varname></term>
+        <listitem>
+          <para>A boolean. When true, enables ARP proxying.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>L2MissNotification=</varname></term>
+        <listitem>
+          <para>A boolean. When true, enables netlink LLADDR miss
+          notifications.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>L3MissNotification=</varname></term>
+        <listitem>
+          <para>A boolean. When true, enables netlink IP address miss
+          notifications.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RouteShortCircuit=</varname></term>
+        <listitem>
+          <para>A boolean. When true, route short circuiting is turned
+          on.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDPCheckSum=</varname></term>
+        <listitem>
+          <para>A boolean. When true, transmitting UDP checksums when doing VXLAN/IPv4 is turned on.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumTx=</varname></term>
+        <listitem>
+          <para>A boolean. When true, sending zero checksums in VXLAN/IPv6 is turned on.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroCheckSumRx=</varname></term>
+        <listitem>
+          <para>A boolean. When true, receiving zero checksums in VXLAN/IPv6 is turned on.</para>
+        </listitem>
+      </varlistentry>
+    <varlistentry>
+      <term><varname>GroupPolicyExtension=</varname></term>
+      <listitem>
+        <para>A boolean. When true, it enables Group Policy VXLAN extension security label mechanism
+        across network peers based on VXLAN. For details about the Group Policy VXLAN, see the
+        <ulink url="https://tools.ietf.org/html/draft-smith-vxlan-group-policy">
+        VXLAN Group Policy </ulink> document. Defaults to false.</para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term><varname>DestinationPort=</varname></term>
+      <listitem>
+        <para>Configures the default destination UDP port on a per-device basis.
+        If destination port is not specified then Linux kernel default will be used.
+        Set destination port 4789 to get the IANA assigned value,
+        and destination port 0 to get default values.</para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term><varname>PortRange=</varname></term>
+        <listitem>
+          <para>Configures VXLAN port range. VXLAN bases source
+          UDP port based on flow to help the receiver to be able
+          to load balance based on outer header flow. It
+          restricts the port range to the normal UDP local
+          ports, and allows overriding via configuration.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>[Tunnel] Section Options</title>
+
+    <para>The <literal>[Tunnel]</literal> section only applies for
+    netdevs of kind
+    <literal>ipip</literal>,
+    <literal>sit</literal>,
+    <literal>gre</literal>,
+    <literal>gretap</literal>,
+    <literal>ip6gre</literal>,
+    <literal>ip6gretap</literal>,
+    <literal>vti</literal>,
+    <literal>vti6</literal>, and
+    <literal>ip6tnl</literal> and accepts
+    the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Local=</varname></term>
+        <listitem>
+          <para>A static local address for tunneled packets. It must
+          be an address on another interface of this host.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Remote=</varname></term>
+        <listitem>
+          <para>The remote endpoint of the tunnel.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TOS=</varname></term>
+        <listitem>
+          <para>The Type Of Service byte value for a tunnel interface.
+          For details about the TOS, see the
+          <ulink url="http://tools.ietf.org/html/rfc1349"> Type of
+          Service in the Internet Protocol Suite </ulink> document.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTL=</varname></term>
+        <listitem>
+          <para>A fixed Time To Live N on tunneled packets. N is a
+          number in the range 1–255. 0 is a special value meaning that
+          packets inherit the TTL value. The default value for IPv4
+          tunnels is: inherit. The default value for IPv6 tunnels is
+          64.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DiscoverPathMTU=</varname></term>
+        <listitem>
+          <para>A boolean. When true, enables Path MTU Discovery on
+          the tunnel.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>IPv6FlowLabel=</varname></term>
+        <listitem>
+          <para>Configures the 20-bit flow label (see <ulink url="https://tools.ietf.org/html/rfc6437">
+          RFC 6437</ulink>) field in the IPv6 header (see <ulink url="https://tools.ietf.org/html/rfc2460">
+          RFC 2460</ulink>), which is used by a node to label packets of a flow.
+          It is only used for IPv6 tunnels.
+          A flow label of zero is used to indicate packets that have
+          not been labeled.
+          It can be configured to a value in the range 0–0xFFFFF, or be
+          set to <literal>inherit</literal>, in which case the original flowlabel is used.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>CopyDSCP=</varname></term>
+        <listitem>
+          <para>A boolean. When true, the Differentiated Service Code
+          Point (DSCP) field will be copied to the inner header from
+          outer header during the decapsulation of an IPv6 tunnel
+          packet. DSCP is a field in an IP packet that enables different
+          levels of service to be assigned to network traffic.
+          Defaults to <literal>no</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>EncapsulationLimit=</varname></term>
+        <listitem>
+          <para>The Tunnel Encapsulation Limit option specifies how many additional
+          levels of encapsulation are permitted to be prepended to the packet.
+          For example, a Tunnel Encapsulation Limit option containing a limit
+          value of zero means that a packet carrying that option may not enter
+          another tunnel before exiting the current tunnel.
+          (see <ulink url="https://tools.ietf.org/html/rfc2473#section-4.1.1"> RFC 2473</ulink>).
+          The valid range is 0–255 and <literal>none</literal>. Defaults to 4.
+        </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>An <literal>ip6tnl</literal> tunnel can be in one of three
+          modes
+          <literal>ip6ip6</literal> for IPv6 over IPv6,
+          <literal>ipip6</literal> for IPv4 over IPv6 or
+          <literal>any</literal> for either.
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>[Peer] Section Options</title>
+
+      <para>The <literal>[Peer]</literal> section only applies for
+      netdevs of kind <literal>veth</literal> and accepts the
+      following keys:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Name=</varname></term>
+          <listitem>
+            <para>The interface name used when creating the netdev.
+            This option is compulsory.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MACAddress=</varname></term>
+          <listitem>
+            <para>The peer MACAddress, if not set, it is generated in
+            the same way as the MAC address of the main
+            interface.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>[Tun] Section Options</title>
+
+    <para>The <literal>[Tun]</literal> section only applies for
+    netdevs of kind <literal>tun</literal>, and accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>OneQueue=</varname></term>
+        <listitem><para>Takes a boolean argument. Configures whether
+        all packets are queued at the device (enabled), or a fixed
+        number of packets are queued at the device and the rest at the
+        <literal>qdisc</literal>. Defaults to
+        <literal>no</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MultiQueue=</varname></term>
+        <listitem><para>Takes a boolean argument. Configures whether
+        to use multiple file descriptors (queues) to parallelize
+        packets sending and receiving. Defaults to
+        <literal>no</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PacketInfo=</varname></term>
+        <listitem><para>Takes a boolean argument. Configures whether
+        packets should be prepended with four extra bytes (two flag
+        bytes and two protocol bytes). If disabled, it indicates that
+        the packets will be pure IP packets. Defaults to
+        <literal>no</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>VNetHeader=</varname></term>
+        <listitem><para>Takes a boolean argument. Configures
+        IFF_VNET_HDR flag for a tap device. It allows sending
+        and receiving larger Generic Segmentation Offload (GSO)
+        packets. This may increase throughput significantly.
+        Defaults to
+        <literal>no</literal>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>User=</varname></term>
+        <listitem><para>User to grant access to the
+        <filename>/dev/net/tun</filename> device.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Group=</varname></term>
+        <listitem><para>Group to grant access to the
+        <filename>/dev/net/tun</filename> device.</para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Tap] Section Options</title>
+
+    <para>The <literal>[Tap]</literal> section only applies for
+    netdevs of kind <literal>tap</literal>, and accepts the same keys
+    as the <literal>[Tun]</literal> section.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Bond] Section Options</title>
+
+    <para>The <literal>[Bond]</literal> section accepts the following
+    key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>Specifies one of the bonding policies. The default is
+          <literal>balance-rr</literal> (round robin). Possible values are
+          <literal>balance-rr</literal>,
+          <literal>active-backup</literal>,
+          <literal>balance-xor</literal>,
+          <literal>broadcast</literal>,
+          <literal>802.3ad</literal>,
+          <literal>balance-tlb</literal>, and
+          <literal>balance-alb</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TransmitHashPolicy=</varname></term>
+        <listitem>
+          <para>Selects the transmit hash policy to use for slave
+          selection in balance-xor, 802.3ad, and tlb modes. Possible
+          values are
+          <literal>layer2</literal>,
+          <literal>layer3+4</literal>,
+          <literal>layer2+3</literal>,
+          <literal>encap2+3</literal>,
+          <literal>802.3ad</literal>, and
+          <literal>encap3+4</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LACPTransmitRate=</varname></term>
+        <listitem>
+          <para>Specifies the rate with which link partner transmits
+          Link Aggregation Control Protocol Data Unit packets in
+          802.3ad mode. Possible values are <literal>slow</literal>,
+          which requests partner to transmit LACPDUs every 30 seconds,
+          and <literal>fast</literal>, which requests partner to
+          transmit LACPDUs every second. The default value is
+          <literal>slow</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MIIMonitorSec=</varname></term>
+        <listitem>
+          <para>Specifies the frequency that Media Independent
+          Interface link monitoring will occur. A value of zero
+          disables MII link monitoring. This value is rounded down to
+          the nearest millisecond. The default value is 0.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UpDelaySec=</varname></term>
+        <listitem>
+          <para>Specifies the delay before a link is enabled after a
+          link up status has been detected. This value is rounded down
+          to a multiple of MIIMonitorSec. The default value is
+          0.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DownDelaySec=</varname></term>
+        <listitem>
+          <para>Specifies the delay before a link is disabled after a
+          link down status has been detected. This value is rounded
+          down to a multiple of MIIMonitorSec. The default value is
+          0.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LearnPacketIntervalSec=</varname></term>
+        <listitem>
+          <para>Specifies the number of seconds between instances where the bonding
+          driver sends learning packets to each slave peer switch.
+          The valid range is 1–0x7fffffff; the default value is 1. This option
+          has an effect only for the balance-tlb and balance-alb modes.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AdSelect=</varname></term>
+        <listitem>
+          <para>Specifies the 802.3ad aggregation selection logic to use. Possible values are
+          <literal>stable</literal>,
+          <literal>bandwidth</literal> and
+          <literal>count</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FailOverMACPolicy=</varname></term>
+        <listitem>
+          <para>Specifies whether the active-backup mode should set all slaves to
+          the same MAC address at the time of enslavement or, when enabled, to perform special handling of the
+          bond's MAC address in accordance with the selected policy. The default policy is none.
+          Possible values are
+          <literal>none</literal>,
+          <literal>active</literal> and
+          <literal>follow</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPValidate=</varname></term>
+        <listitem>
+          <para>Specifies whether or not ARP probes and replies should be
+          validated in any mode that supports ARP monitoring, or whether
+          non-ARP traffic should be filtered (disregarded) for link
+          monitoring purposes. Possible values are
+          <literal>none</literal>,
+          <literal>active</literal>,
+          <literal>backup</literal> and
+          <literal>all</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPIntervalSec=</varname></term>
+        <listitem>
+          <para>Specifies the ARP link monitoring frequency in milliseconds.
+          A value of 0 disables ARP monitoring. The default value is 0.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPIPTargets=</varname></term>
+        <listitem>
+          <para>Specifies the IP addresses to use as ARP monitoring peers when
+          ARPIntervalSec is greater than 0. These are the targets of the ARP request
+          sent to determine the health of the link to the targets.
+          Specify these values in IPv4 dotted decimal format. At least one IP
+          address must be given for ARP monitoring to function. The
+          maximum number of targets that can be specified is 16. The
+          default value is no IP addresses.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPAllTargets=</varname></term>
+        <listitem>
+          <para>Specifies the quantity of ARPIPTargets that must be reachable
+          in order for the ARP monitor to consider a slave as being up.
+          This option affects only active-backup mode for slaves with
+          ARPValidate enabled. Possible values are
+          <literal>any</literal> and
+          <literal>all</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrimaryReselectPolicy=</varname></term>
+        <listitem>
+          <para>Specifies the reselection policy for the primary slave.  This
+          affects how the primary slave is chosen to become the active slave
+          when failure of the active slave or recovery of the primary slave
+          occurs. This option is designed to prevent flip-flopping between
+          the primary slave and other slaves.  Possible values are
+          <literal>always</literal>,
+          <literal>better</literal> and
+          <literal>failure</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ResendIGMP=</varname></term>
+        <listitem>
+          <para>Specifies the number of IGMP membership reports to be issued after
+          a failover event. One membership report is issued immediately after
+          the failover, subsequent packets are sent in each 200ms interval.
+          The valid range is 0–255. Defaults to 1. A value of 0
+          prevents the IGMP membership report from being issued in response
+          to the failover event.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PacketsPerSlave=</varname></term>
+        <listitem>
+          <para>Specify the number of packets to transmit through a slave before
+            moving to the next one. When set to 0, then a slave is chosen at
+            random. The valid range is 0–65535. Defaults to 1. This option
+            only has effect when in balance-rr mode.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>GratuitousARP=</varname></term>
+        <listitem>
+          <para>Specify the number of peer notifications (gratuitous ARPs and
+            unsolicited IPv6 Neighbor Advertisements) to be issued after a
+            failover event.  As soon as the link is up on the new slave,
+            a peer notification is sent on the  bonding device and each
+            VLAN sub-device.  This is repeated at each link monitor interval
+            (ARPIntervalSec or MIIMonitorSec, whichever is active) if the number is
+            greater than 1. The valid range is 0–255. The default value is 1.
+            These options affect only the active-backup mode.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllSlavesActive=</varname></term>
+        <listitem>
+          <para>A boolean. Specifies that duplicate frames (received on inactive ports)
+          should be dropped when false, or delivered when true. Normally, bonding will drop
+          duplicate frames (received on inactive ports), which is desirable for
+          most users. But there are some times it is nice to allow duplicate
+          frames to be delivered. The default value is false (drop duplicate frames
+          received on inactive ports).
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MinLinks=</varname></term>
+        <listitem>
+          <para>Specifies the minimum number of links that must be active before
+          asserting carrier. The default value is 0.
+          </para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>For more detail information see
+    <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">
+    Linux Ethernet Bonding Driver HOWTO</ulink></para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+    <example>
+      <title>/etc/systemd/network/25-bridge.netdev</title>
+
+      <programlisting>[NetDev]
+Name=bridge0
+Kind=bridge</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-vlan1.netdev</title>
+
+      <programlisting>[Match]
+Virtualization=no
+
+[NetDev]
+Name=vlan1
+Kind=vlan
+
+[VLAN]
+Id=1</programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-ipip.netdev</title>
+      <programlisting>[NetDev]
+Name=ipip-tun
+Kind=ipip
+MTUBytes=1480
+
+[Tunnel]
+Local=192.168.223.238
+Remote=192.169.224.239
+TTL=64</programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-tap.netdev</title>
+      <programlisting>[NetDev]
+Name=tap-test
+Kind=tap
+
+[Tap]
+MultiQueue=true
+PacketInfo=true</programlisting> </example>
+
+    <example>
+      <title>/etc/systemd/network/25-sit.netdev</title>
+      <programlisting>[NetDev]
+Name=sit-tun
+Kind=sit
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+Remote=10.65.223.239</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-gre.netdev</title>
+      <programlisting>[NetDev]
+Name=gre-tun
+Kind=gre
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+Remote=10.65.223.239</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-vti.netdev</title>
+
+      <programlisting>[NetDev]
+Name=vti-tun
+Kind=vti
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+Remote=10.65.223.239</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-veth.netdev</title>
+      <programlisting>[NetDev]
+Name=veth-test
+Kind=veth
+
+[Peer]
+Name=veth-peer</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-bond.netdev</title>
+      <programlisting>[NetDev]
+Name=bond1
+Kind=bond
+
+[Bond]
+Mode=802.3ad
+TransmitHashPolicy=layer3+4
+MIIMonitorSec=1s
+LACPTransmitRate=fast
+</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-dummy.netdev</title>
+      <programlisting>[NetDev]
+Name=dummy-test
+Kind=dummy
+MACAddress=12:34:56:78:9a:bc</programlisting>
+    </example>
+
+  </refsect1>
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.network.xml b/src/grp-system/systemd/systemd.network.xml
new file mode 100644
index 0000000000..821e22aff8
--- /dev/null
+++ b/src/grp-system/systemd/systemd.network.xml
@@ -0,0 +1,1205 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Tom Gundersen
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.network" conditional='ENABLE_NETWORKD'>
+
+  <refentryinfo>
+    <title>systemd.network</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Tom</firstname>
+        <surname>Gundersen</surname>
+        <email>teg@jklm.no</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.network</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.network</refname>
+    <refpurpose>Network configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>network</replaceable>.network</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Network setup is performed by
+    <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>Network files must have the extension
+    <filename>.network</filename>; other extensions are ignored.
+    Networks are applied to links whenever the links appear.</para>
+
+    <para>The <filename>.network</filename> files are read from the
+    files located in the system network directory
+    <filename>/usr/lib/systemd/network</filename>, the volatile
+    runtime network directory
+    <filename>/run/systemd/network</filename> and the local
+    administration network directory
+    <filename>/etc/systemd/network</filename>. All configuration files
+    are collectively sorted and processed in lexical order, regardless
+    of the directories in which they live. However, files with
+    identical filenames replace each other. Files in
+    <filename>/etc</filename> have the highest priority, files in
+    <filename>/run</filename> take precedence over files with the same
+    name in <filename>/usr/lib</filename>. This can be used to
+    override a system-supplied configuration file with a local file if
+    needed. As a special case, an empty file (file size 0) or symlink
+    with the same name pointing to <filename>/dev/null</filename>
+    disables the configuration file entirely (it is "masked").</para>
+
+    <para>Note that an interface without any static IPv6 addresses configured, and neither DHCPv6 nor IPv6LL enabled,
+    shall be considered to have no IPv6 support. IPv6 will be automatically disabled for that interface by writing "1"
+    to <filename>/proc/sys/net/ipv6/conf/<replaceable>ifname</replaceable>/disable_ipv6</filename>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Match] Section Options</title>
+
+      <para>The network file contains a <literal>[Match]</literal>
+      section, which determines if a given network file may be applied
+      to a given device; and a <literal>[Network]</literal> section
+      specifying how the device should be configured. The first (in
+      lexical order) of the network files that matches a given device
+      is applied, all later files are ignored, even if they match as
+      well.</para>
+
+      <para>A network file is said to match a device if each of the
+      entries in the <literal>[Match]</literal> section matches, or if
+      the section is empty. The following keys are accepted:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>MACAddress=</varname></term>
+          <listitem>
+            <para>The hardware address of the interface (use full colon-delimited hexadecimal, e.g.,
+            01:23:45:67:89:ab).</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Path=</varname></term>
+          <listitem>
+            <para>A whitespace-separated list of shell-style globs
+            matching the persistent path, as exposed by the udev
+            property <literal>ID_PATH</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Driver=</varname></term>
+          <listitem>
+            <para>A whitespace-separated list of shell-style globs
+            matching the driver currently bound to the device, as
+            exposed by the udev property <literal>DRIVER</literal>
+            of its parent device, or if that is not set the driver
+            as exposed by <literal>ethtool -i</literal> of the
+            device itself.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Type=</varname></term>
+          <listitem>
+            <para>A whitespace-separated list of shell-style globs
+            matching the device type, as exposed by the udev property
+            <literal>DEVTYPE</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Name=</varname></term>
+          <listitem>
+            <para>A whitespace-separated list of shell-style globs
+            matching the device name, as exposed by the udev property
+            <literal>INTERFACE</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Host=</varname></term>
+          <listitem>
+            <para>Matches against the hostname or machine ID of the
+            host. See <literal>ConditionHost=</literal> in
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Virtualization=</varname></term>
+          <listitem>
+            <para>Checks whether the system is executed in a virtualized
+            environment and optionally test whether it is a specific
+            implementation. See <literal>ConditionVirtualization=</literal> in
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>KernelCommandLine=</varname></term>
+          <listitem>
+            <para>Checks whether a specific kernel command line option is
+            set (or if prefixed with the exclamation mark unset). See
+            <literal>ConditionKernelCommandLine=</literal> in
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Architecture=</varname></term>
+          <listitem>
+            <para>Checks whether the system is running on a specific
+            architecture. See <literal>ConditionArchitecture=</literal> in
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.
+            </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Link] Section Options</title>
+
+    <para> The <literal>[Link]</literal> section accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>The hardware address to set for the device.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>The maximum transmission unit in bytes to set for the
+          device. The usual suffixes K, M, G, are supported and are
+          understood to the base of 1024.</para>
+          <para>Note that if IPv6 is enabled on the interface, and the MTU is chosen
+          below 1280 (the minimum MTU for IPv6) it will automatically be increased to this value.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Network] Section Options</title>
+
+      <para>The <literal>[Network]</literal> section accepts the following keys:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Description=</varname></term>
+          <listitem>
+            <para>A description of the device. This is only used for
+            presentation purposes.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DHCP=</varname></term>
+          <listitem>
+            <para>Enables DHCPv4 and/or DHCPv6 client support. Accepts
+            <literal>yes</literal>, <literal>no</literal>,
+            <literal>ipv4</literal>, or <literal>ipv6</literal>.</para>
+
+            <para>Note that DHCPv6 will by default be triggered by Router
+            Advertisement, if that is enabled, regardless of this parameter.
+            By enabling DHCPv6 support explicitly, the DHCPv6 client will
+            be started regardless of the presence of routers on the link,
+            or what flags the routers pass. See
+            <literal>IPv6AcceptRouterAdvertisements=</literal>.</para>
+
+            <para>Furthermore, note that by default the domain name
+            specified through DHCP is not used for name resolution.
+            See option <option>UseDomains=</option> below.</para>
+
+            <para>See the <literal>[DHCP]</literal> section below for further configuration options for the DHCP client
+            support.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DHCPServer=</varname></term>
+          <listitem>
+            <para>A boolean. Enables DHCPv4 server support. Defaults
+            to <literal>no</literal>. Further settings for the DHCP
+            server may be set in the <literal>[DHCPServer]</literal>
+            section described below.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>LinkLocalAddressing=</varname></term>
+          <listitem>
+            <para>Enables link-local address autoconfiguration. Accepts
+            <literal>yes</literal>, <literal>no</literal>,
+            <literal>ipv4</literal>, or <literal>ipv6</literal>. Defaults to
+            <literal>ipv6</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPv4LLRoute=</varname></term>
+          <listitem>
+            <para>A boolean. When true, sets up the route needed for
+            non-IPv4LL hosts to communicate with IPv4LL-only hosts. Defaults
+            to false.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPv6Token=</varname></term>
+          <listitem>
+            <para>An IPv6 address with the top 64 bits unset. When set, indicates the
+            64-bit interface part of SLAAC IPv6 addresses for this link. Note that
+            the token is only ever used for SLAAC, and not for DHCPv6 addresses, even
+            in the case DHCP is requested by router advertisement. By default, the
+            token is autogenerated.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>LLMNR=</varname></term>
+          <listitem>
+            <para>A boolean or <literal>resolve</literal>. When true,
+            enables <ulink
+            url="https://tools.ietf.org/html/rfc4795">Link-Local
+            Multicast Name Resolution</ulink> on the link. When set to
+            <literal>resolve</literal>, only resolution is enabled,
+            but not host registration and announcement. Defaults to
+            true. This setting is read by
+            <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MulticastDNS=</varname></term>
+          <listitem>
+            <para>A boolean or <literal>resolve</literal>. When true,
+            enables <ulink
+            url="https://tools.ietf.org/html/rfc6762">Multicast
+            DNS</ulink> support on the link. When set to
+            <literal>resolve</literal>, only resolution is enabled,
+            but not host or service registration and
+            announcement. Defaults to false. This setting is read by
+            <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DNSSEC=</varname></term>
+          <listitem>
+            <para>A boolean or
+            <literal>allow-downgrade</literal>. When true, enables
+            <ulink
+            url="https://tools.ietf.org/html/rfc4033">DNSSEC</ulink>
+            DNS validation support on the link. When set to
+            <literal>allow-downgrade</literal>, compatibility with
+            non-DNSSEC capable networks is increased, by automatically
+            turning off DNSEC in this case. This option defines a
+            per-interface setting for
+            <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s
+            global <varname>DNSSEC=</varname> option. Defaults to
+            false. This setting is read by
+            <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DNSSECNegativeTrustAnchors=</varname></term>
+          <listitem><para>A space-separated list of DNSSEC negative
+          trust anchor domains. If specified and DNSSEC is enabled,
+          look-ups done via the interface's DNS server will be subject
+          to the list of negative trust anchors, and not require
+          authentication for the specified domains, or anything below
+          it. Use this to disable DNSSEC authentication for specific
+          private domains, that cannot be proven valid using the
+          Internet DNS hierarchy. Defaults to the empty list. This
+          setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>LLDP=</varname></term>
+          <listitem>
+            <para>Controls support for Ethernet LLDP packet reception. LLDP is a link-layer protocol commonly
+            implemented on professional routers and bridges which announces which physical port a system is connected
+            to, as well as other related data. Accepts a boolean or the special value
+            <literal>routers-only</literal>. When true, incoming LLDP packets are accepted and a database of all LLDP
+            neighbors maintained. If <literal>routers-only</literal> is set only LLDP data of various types of routers
+            is collected and LLDP data about other types of devices ignored (such as stations, telephones and
+            others). If false, LLDP reception is disabled. Defaults to <literal>routers-only</literal>. Use
+            <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to query the
+            collected neighbor data. LLDP is only available on Ethernet links. See <varname>EmitLLDP=</varname> below
+            for enabling LLDP packet emission from the local system.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>EmitLLDP=</varname></term>
+          <listitem>
+            <para>Controls support for Ethernet LLDP packet emission. Accepts a boolean parameter or the special values
+            <literal>nearest-bridge</literal>, <literal>non-tpmr-bridge</literal> and
+            <literal>customer-bridge</literal>.  Defaults to false, which turns off LLDP packet emission. If not false,
+            a short LLDP packet with information about the local system is sent out in regular intervals on the
+            link. The LLDP packet will contain information about the local host name, the local machine ID (as stored
+            in <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>) and the
+            local interface name, as well as the pretty hostname of the system (as set in
+            <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>). LLDP
+            emission is only available on Ethernet links. Note that this setting passes data suitable for
+            identification of host to the network and should thus not be enabled on untrusted networks, where such
+            identification data should not be made available. Use this option to permit other systems to identify on
+            which interfaces they are connected to this system. The three special values control propagation of the
+            LLDP packets. The <literal>nearest-bridge</literal> setting permits propagation only to the nearest
+            connected bridge, <literal>non-tpmr-bridge</literal> permits propagation across Two-Port MAC Relays, but
+            not any other bridges, and <literal>customer-bridge</literal> permits propagation until a customer bridge
+            is reached. For details about these concepts, see <ulink
+            url="http://standards.ieee.org/getieee802/download/802.1AB-2009.pdf">IEEE 802.1AB-2009</ulink>. Note that
+            configuring this setting to true is equivalent to <literal>nearest-bridge</literal>, the recommended and
+            most restricted level of propagation. See <varname>LLDP=</varname> above for an option to enable LLDP
+            reception.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>BindCarrier=</varname></term>
+          <listitem>
+            <para>A link name or a list of link names. When set, controls the behavior of the current
+            link. When all links in the list are in an operational down state, the current link is brought
+            down. When at least one link has carrier, the current interface is brought up.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Address=</varname></term>
+          <listitem>
+            <para>A static IPv4 or IPv6 address and its prefix length,
+            separated by a <literal>/</literal> character. Specify
+            this key more than once to configure several addresses.
+            The format of the address must be as described in
+            <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+            This is a short-hand for an [Address] section only
+            containing an Address key (see below). This option may be
+            specified more than once.
+            </para>
+
+            <para>If the specified address is 0.0.0.0 (for IPv4) or
+            [::] (for IPv6), a new address range of the requested size
+            is automatically allocated from a system-wide pool of
+            unused ranges. The allocated range is checked against all
+            current network interfaces and all known network
+            configuration files to avoid address range conflicts. The
+            default system-wide pool consists of 192.168.0.0/16,
+            172.16.0.0/12 and 10.0.0.0/8 for IPv4, and fc00::/7 for
+            IPv6. This functionality is useful to manage a large
+            number of dynamically created network interfaces with the
+            same network configuration and automatic address range
+            assignment.</para>
+
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Gateway=</varname></term>
+          <listitem>
+            <para>The gateway address, which must be in the format
+            described in
+            <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+            This is a short-hand for a [Route] section only containing
+            a Gateway key. This option may be specified more than
+            once.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DNS=</varname></term>
+          <listitem>
+            <para>A DNS server address, which must be in the format
+            described in
+            <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+            This option may be specified more than once. This setting is read by
+            <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Domains=</varname></term>
+          <listitem>
+            <para>The domains used for DNS host name resolution on this link. Takes a list of DNS domain names which
+            are used as search suffixes for extending single-label host names (host names containing no dots) to become
+            fully qualified domain names (FQDNs). If a single-label host name is resolved on this interface, each of
+            the specified search domains are appended to it in turn, converting it into a fully qualified domain name,
+            until one of them may be successfully resolved.</para>
+
+            <para>The specified domains are also used for routing of DNS queries: look-ups for host names ending in the
+            domains specified here are preferably routed to the DNS servers configured for this interface. If a domain
+            name is prefixed with <literal>~</literal>, the domain name becomes a pure "routing" domain, is used for
+            DNS query routing purposes only and is not used in the described domain search logic. By specifying a
+            routing domain of <literal>~.</literal> (the tilde indicating definition of a routing domain, the dot
+            referring to the DNS root domain which is the implied suffix of all valid DNS names) it is possible to
+            route all DNS traffic preferably to the DNS server specified for this interface. The route domain logic is
+            particularly useful on multi-homed hosts with DNS servers serving particular private DNS zones on each
+            interface.</para>
+
+            <para>This setting is read by
+            <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>NTP=</varname></term>
+          <listitem>
+            <para>An NTP server address. This option may be specified more than once. This setting is read by
+            <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPForward=</varname></term>
+          <listitem><para>Configures IP packet forwarding for the
+          system. If enabled, incoming packets on any network
+          interface will be forwarded to any other interfaces
+          according to the routing table. Takes either a boolean
+          argument, or the values <literal>ipv4</literal> or
+          <literal>ipv6</literal>, which only enable IP packet
+          forwarding for the specified address family.  This controls
+          the <filename>net.ipv4.ip_forward</filename> and
+          <filename>net.ipv6.conf.all.forwarding</filename> sysctl
+          options of the network interface (see <ulink
+          url="https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt">ip-sysctl.txt</ulink>
+          for details about sysctl options). Defaults to
+          <literal>no</literal>.</para>
+
+          <para>Note: this setting controls a global kernel option,
+          and does so one way only: if a network that has this setting
+          enabled is set up the global setting is turned on.  However,
+          it is never turned off again, even after all networks with
+          this setting enabled are shut down again.</para>
+
+          <para>To allow IP packet forwarding only between specific
+          network interfaces use a firewall.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPMasquerade=</varname></term>
+          <listitem><para>Configures IP masquerading for the network
+          interface. If enabled, packets forwarded from the network
+          interface will be appear as coming from the local host.
+          Takes a boolean argument. Implies
+          <varname>IPForward=ipv4</varname>. Defaults to
+          <literal>no</literal>.</para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPv6PrivacyExtensions=</varname></term>
+          <listitem><para>Configures use of stateless temporary
+          addresses that change over time (see <ulink
+          url="https://tools.ietf.org/html/rfc4941">RFC 4941</ulink>,
+          Privacy Extensions for Stateless Address Autoconfiguration
+          in IPv6). Takes a boolean or the special values
+          <literal>prefer-public</literal> and
+          <literal>kernel</literal>. When true, enables the privacy
+          extensions and prefers temporary addresses over public
+          addresses. When <literal>prefer-public</literal>, enables the
+          privacy extensions, but prefers public addresses over
+          temporary addresses. When false, the privacy extensions
+          remain disabled. When <literal>kernel</literal>, the kernel's
+          default setting will be left in place.  Defaults to
+          <literal>no</literal>.</para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPv6AcceptRouterAdvertisements=</varname></term>
+          <listitem><para>Force the setting of the <filename>accept_ra</filename>
+          (router advertisements) setting for the interface.
+          When unset, the kernel default is used, and router
+          advertisements are accepted only when local forwarding
+          is disabled for that interface.
+          When router advertisements are accepted, they will
+          trigger the start of the DHCPv6 client if the relevant
+          flags are passed, or if no routers are found on the link.
+          Takes a boolean. If true, router advertisements are
+          accepted, when false, router advertisements are ignored,
+          independently of the local forwarding state.</para>
+
+          <para>See
+          <ulink url="https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt">ip-sysctl.txt</ulink>
+          in the kernel documentation, but note that systemd's
+          setting of <constant>1</constant> corresponds to
+          kernel's setting of <constant>2</constant>.</para>
+        </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPv6DuplicateAddressDetection=</varname></term>
+          <listitem><para>Configures the amount of IPv6 Duplicate
+          Address Detection (DAD) probes to send. Defaults to unset.
+        </para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>IPv6HopLimit=</varname></term>
+          <listitem><para>Configures IPv6 Hop Limit. For each router that
+          forwards the packet, the hop limit is decremented by 1. When the
+          hop limit field reaches zero, the packet is discarded.
+          Defaults to unset.
+        </para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>ProxyARP=</varname></term>
+          <listitem><para>A boolean. Configures proxy ARP. Proxy ARP is the technique in which one host,
+          usually a router, answers ARP requests intended for another machine. By "faking" its identity,
+          the router accepts responsibility for routing packets to the "real" destination. (see <ulink
+          url="https://tools.ietf.org/html/rfc1027">RFC 1027</ulink>.
+          Defaults to unset.
+        </para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Bridge=</varname></term>
+          <listitem>
+            <para>The name of the bridge to add the link to.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Bond=</varname></term>
+          <listitem>
+            <para>The name of the bond to add the link to.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>VLAN=</varname></term>
+          <listitem>
+            <para>The name of a VLAN to create on the link. This
+            option may be specified more than once.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MACVLAN=</varname></term>
+          <listitem>
+            <para>The name of a MACVLAN to create on the link. This
+            option may be specified more than once.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>VXLAN=</varname></term>
+          <listitem>
+            <para>The name of a VXLAN to create on the link. This
+            option may be specified more than once.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Tunnel=</varname></term>
+          <listitem>
+            <para>The name of a Tunnel to create on the link. This
+            option may be specified more than once.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Address] Section Options</title>
+
+      <para>An <literal>[Address]</literal> section accepts the
+      following keys. Specify several <literal>[Address]</literal>
+      sections to configure several addresses.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Address=</varname></term>
+          <listitem>
+            <para>As in the <literal>[Network]</literal> section. This
+            key is mandatory.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Peer=</varname></term>
+          <listitem>
+            <para>The peer address in a point-to-point connection.
+            Accepts the same format as the <literal>Address</literal>
+            key.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Broadcast=</varname></term>
+          <listitem>
+            <para>The broadcast address, which must be in the format
+            described in
+            <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+            This key only applies to IPv4 addresses. If it is not
+            given, it is derived from the <literal>Address</literal>
+            key.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Label=</varname></term>
+          <listitem>
+            <para>An address label.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>PreferredLifetime=</varname></term>
+          <listitem>
+            <para>Allows the default "preferred lifetime" of the address to be overridden.
+            Only three settings are accepted: <literal>forever</literal> or <literal>infinity</literal>
+            which is the default and means that the address never expires, and <literal>0</literal> which means
+            that the address is considered immediately "expired" and will not be used,
+            unless explicitly requested. A setting of PreferredLifetime=0 is useful for
+            addresses which are added to be used only by a specific application,
+            which is then configured to use them explicitly.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Route] Section Options</title>
+      <para>The <literal>[Route]</literal> section accepts the
+      following keys. Specify several <literal>[Route]</literal>
+      sections to configure several routes.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Gateway=</varname></term>
+          <listitem>
+            <para>As in the <literal>[Network]</literal> section.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Destination=</varname></term>
+          <listitem>
+            <para>The destination prefix of the route. Possibly
+            followed by a slash and the prefix length. If omitted, a
+            full-length host route is assumed.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Source=</varname></term>
+          <listitem>
+            <para>The source prefix of the route. Possibly followed by
+            a slash and the prefix length. If omitted, a full-length
+            host route is assumed.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Metric=</varname></term>
+          <listitem>
+            <para>The metric of the route (an unsigned integer).</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Scope=</varname></term>
+          <listitem>
+            <para>The scope of the route, which can be <literal>global</literal>,
+            <literal>link</literal> or <literal>host</literal>. Defaults to
+            <literal>global</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>PreferredSource=</varname></term>
+          <listitem>
+            <para>The preferred source address of the route. The address
+            must be in the format described in
+            <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Table=<replaceable>num</replaceable></varname></term>
+          <listitem>
+          <para>The table identifier for the route (a number between 1 and 4294967295, or 0 to unset).
+          The table can be retrieved using <command>ip route show table <replaceable>num</replaceable></command>.
+          </para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCP] Section Options</title>
+      <para>The <literal>[DHCP]</literal> section configures the
+      DHCPv4 and DHCP6 client, if it is enabled with the
+      <varname>DHCP=</varname> setting described above:</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>UseDNS=</varname></term>
+          <listitem>
+            <para>When true (the default), the DNS servers received
+            from the DHCP server will be used and take precedence over
+            any statically configured ones.</para>
+
+            <para>This corresponds to the <option>nameserver</option>
+            option in <citerefentry
+            project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>UseNTP=</varname></term>
+          <listitem>
+            <para>When true (the default), the NTP servers received
+            from the DHCP server will be used by systemd-timesyncd
+            and take precedence over any statically configured ones.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>UseMTU=</varname></term>
+          <listitem>
+            <para>When true, the interface maximum transmission unit
+            from the DHCP server will be used on the current link.
+            Defaults to false.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>SendHostname=</varname></term>
+          <listitem>
+            <para>When true (the default), the machine's hostname will
+            be sent to the DHCP server.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>UseHostname=</varname></term>
+          <listitem>
+            <para>When true (the default), the hostname received from
+            the DHCP server will be set as the transient hostname of the system
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+        <term><varname>Hostname=</varname></term>
+        <listitem>
+          <para>Use this value for the hostname which is sent to the
+          DHCP server, instead of machine's hostname.</para>
+        </listitem>
+      </varlistentry>
+        <varlistentry>
+          <term><varname>UseDomains=</varname></term>
+          <listitem>
+            <para>Takes a boolean argument, or the special value <literal>route</literal>. When true, the domain name
+            received from the DHCP server will be used as DNS search domain over this link, similar to the effect of
+            the <option>Domains=</option> setting. If set to <literal>route</literal>, the domain name received from
+            the DHCP server will be used for routing DNS queries only, but not for searching, similar to the effect of
+            the <option>Domains=</option> setting when the argument is prefixed with <literal>~</literal>. Defaults to
+            false.</para>
+
+            <para>It is recommended to enable this option only on trusted networks, as setting this affects resolution
+            of all host names, in particular to single-label names. It is generally safer to use the supplied domain
+            only as routing domain, rather than as search domain, in order to not have it affect local resolution of
+            single-label names.</para>
+
+            <para>When set to true, this setting corresponds to the <option>domain</option> option in <citerefentry
+            project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>UseRoutes=</varname></term>
+          <listitem>
+            <para>When true (the default), the static routes will be
+            requested from the DHCP server and added to the routing
+            table with a metric of 1024.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>UseTimezone=</varname></term>
+
+          <listitem><para>When true, the timezone received from the
+          DHCP server will be set as timezone of the local
+          system. Defaults to <literal>no</literal>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>CriticalConnection=</varname></term>
+          <listitem>
+            <para>When true, the connection will never be torn down
+            even if the DHCP lease expires. This is contrary to the
+            DHCP specification, but may be the best choice if, say,
+            the root filesystem relies on this connection. Defaults to
+            false.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ClientIdentifier=</varname></term>
+          <listitem>
+            <para>The DHCPv4 client identifier to use. Either <literal>mac</literal> to use the MAC address of the link
+            or <literal>duid</literal> (the default, see below) to use a RFC4361-compliant Client ID.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VendorClassIdentifier=</varname></term>
+          <listitem>
+            <para>The vendor class identifier used to identify vendor
+            type and configuration.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>DUIDType=</varname></term>
+          <listitem>
+            <para>Override the global <varname>DUIDType</varname> setting for this network. See
+            <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for a description of possible values.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>DUIDRawData=</varname></term>
+          <listitem>
+            <para>Override the global <varname>DUIDRawData</varname> setting for this network. See
+            <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for a description of possible values.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>IAID=</varname></term>
+          <listitem>
+            <para>The DHCP Identity Association Identifier (IAID) for the interface, a 32-bit unsigned integer.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>RequestBroadcast=</varname></term>
+          <listitem>
+            <para>Request the server to use broadcast messages before
+            the IP address has been configured. This is necessary for
+            devices that cannot receive RAW packets, or that cannot
+            receive packets at all before an IP address has been
+            configured. On the other hand, this must not be enabled on
+            networks where broadcasts are filtered out.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>RouteMetric=</varname></term>
+          <listitem>
+            <para>Set the routing metric for routes specified by the
+            DHCP server.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect1>
+
+  <refsect1>
+    <title>[DHCPServer] Section Options</title>
+    <para>The <literal>[DHCPServer]</literal> section contains
+    settings for the DHCP server, if enabled via the
+    <varname>DHCPServer=</varname> option described above:</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>PoolOffset=</varname></term>
+        <term><varname>PoolSize=</varname></term>
+
+        <listitem><para>Configures the pool of addresses to hand out. The pool
+        is a contiguous sequence of IP addresses in the subnet configured for
+        the server address, which does not include the subnet nor the broadcast
+        address. <varname>PoolOffset=</varname> takes the offset of the pool
+        from the start of subnet, or zero to use the default value.
+        <varname>PoolSize=</varname> takes the number of IP addresses in the
+        pool or zero to use the default value. By default, the pool starts at
+        the first address after the subnet address and takes up the rest of
+        the subnet, excluding the broadcast address. If the pool includes
+        the server address (the default), this is reserved and not handed
+        out to clients.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultLeaseTimeSec=</varname></term>
+        <term><varname>MaxLeaseTimeSec=</varname></term>
+
+        <listitem><para>Control the default and maximum DHCP lease
+        time to pass to clients. These settings take time values in seconds or
+        another common time unit, depending on the suffix. The default
+        lease time is used for clients that did not ask for a specific
+        lease time. If a client asks for a lease time longer than the
+        maximum lease time, it is automatically shortened to the
+        specified time. The default lease time defaults to 1h, the
+        maximum lease time to 12h. Shorter lease times are beneficial
+        if the configuration data in DHCP leases changes frequently
+        and clients shall learn the new settings with shorter
+        latencies. Longer lease times reduce the generated DHCP
+        network traffic.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitDNS=</varname></term>
+        <term><varname>DNS=</varname></term>
+
+        <listitem><para>Configures whether the DHCP leases handed out
+        to clients shall contain DNS server information. The
+        <varname>EmitDNS=</varname> setting takes a boolean argument
+        and defaults to <literal>yes</literal>. The DNS servers to
+        pass to clients may be configured with the
+        <varname>DNS=</varname> option, which takes a list of IPv4
+        addresses. If the <varname>EmitDNS=</varname> option is
+        enabled but no servers configured, the servers are
+        automatically propagated from an "uplink" interface that has
+        appropriate servers set. The "uplink" interface is determined
+        by the default route of the system with the highest
+        priority. Note that this information is acquired at the time
+        the lease is handed out, and does not take uplink interfaces
+        into account that acquire DNS or NTP server information at a
+        later point. DNS server propagation does not take
+        <filename>/etc/resolv.conf</filename> into account. Also, note
+        that the leases are not refreshed if the uplink network
+        configuration changes. To ensure clients regularly acquire the
+        most current uplink DNS server information, it is thus
+        advisable to shorten the DHCP lease time via
+        <varname>MaxLeaseTimeSec=</varname> described
+        above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitNTP=</varname></term>
+        <term><varname>NTP=</varname></term>
+
+        <listitem><para>Similar to the <varname>EmitDNS=</varname> and
+        <varname>DNS=</varname> settings described above, these
+        settings configure whether and what NTP server information
+        shall be emitted as part of the DHCP lease. The same syntax,
+        propagation semantics and defaults apply as for
+        <varname>EmitDNS=</varname> and
+        <varname>DNS=</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitRouter=</varname></term>
+
+        <listitem><para>Similar to the <varname>EmitDNS=</varname>
+        setting described above, this setting configures whether the
+        DHCP lease should contain the router option. The same syntax,
+        propagation semantics and defaults apply as for
+        <varname>EmitDNS=</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitTimezone=</varname></term>
+        <term><varname>Timezone=</varname></term>
+
+        <listitem><para>Configures whether the DHCP leases handed out
+        to clients shall contain timezone information. The
+        <varname>EmitTimezone=</varname> setting takes a boolean
+        argument and defaults to <literal>yes</literal>. The
+        <varname>Timezone=</varname> setting takes a timezone string
+        (such as <literal>Europe/Berlin</literal> or
+        <literal>UTC</literal>) to pass to clients. If no explicit
+        timezone is set, the system timezone of the local host is
+        propagated, as determined by the
+        <filename>/etc/localtime</filename> symlink.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Bridge] Section Options</title>
+      <para>The <literal>[Bridge]</literal> section accepts the
+      following keys.</para>
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>UnicastFlood=</varname></term>
+          <listitem>
+            <para>A boolean. Controls whether the bridge should flood
+            traffic for which an FDB entry is missing and the destination
+            is unknown through this port. Defaults to on.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>HairPin=</varname></term>
+          <listitem>
+            <para>A boolean. Configures whether traffic may be sent back
+            out of the port on which it was received. By default, this
+            flag is false, and the bridge will not forward traffic back
+            out of the receiving port.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>UseBPDU=</varname></term>
+          <listitem>
+            <para>A boolean. Configures whether STP Bridge Protocol Data Units will be
+            processed by the bridge port. Defaults to yes.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>FastLeave=</varname></term>
+          <listitem>
+            <para>A boolean. This flag allows the bridge to immediately stop multicast
+            traffic on a port that receives an IGMP Leave message. It is only used with
+            IGMP snooping if enabled on the bridge. Defaults to off.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>AllowPortToBeRoot=</varname></term>
+          <listitem>
+            <para>A boolean. Configures whether a given port is allowed to
+            become a root port. Only used when STP is enabled on the bridge.
+            Defaults to on.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Cost=</varname></term>
+          <listitem>
+            <para>Sets the "cost" of sending packets of this interface.
+            Each port in a bridge may have a different speed and the cost
+            is used to decide which link to use. Faster interfaces
+            should have lower costs.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>[BridgeFDB] Section Options</title>
+      <para>The <literal>[BridgeFDB]</literal> section manages the
+      forwarding database table of a port and accepts the following
+      keys. Specify several <literal>[BridgeFDB]</literal> sections to
+      configure several static MAC table entries.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>MACAddress=</varname></term>
+          <listitem>
+            <para>As in the <literal>[Network]</literal> section. This
+            key is mandatory.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>VLANId=</varname></term>
+          <listitem>
+            <para>The VLAN ID for the new static MAC table entry. If
+            omitted, no VLAN ID info is appended to the new static MAC
+            table entry.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+    <example>
+      <title>/etc/systemd/network/50-static.network</title>
+
+      <programlisting>[Match]
+Name=enp2s0
+
+[Network]
+Address=192.168.0.15/24
+Gateway=192.168.0.1</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/80-dhcp.network</title>
+
+      <programlisting>[Match]
+Name=en*
+
+[Network]
+DHCP=yes</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-bridge-static.network</title>
+
+      <programlisting>[Match]
+Name=bridge0
+
+[Network]
+Address=192.168.0.15/24
+Gateway=192.168.0.1
+DNS=192.168.0.1</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-bridge-slave-interface.network</title>
+
+      <programlisting>[Match]
+Name=enp2s0
+
+[Network]
+Bridge=bridge0</programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-ipip.network</title>
+
+      <programlisting>[Match]
+Name=em1
+
+[Network]
+Tunnel=ipip-tun</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-sit.network</title>
+
+      <programlisting>[Match]
+Name=em1
+
+[Network]
+Tunnel=sit-tun</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-gre.network</title>
+
+      <programlisting>[Match]
+Name=em1
+
+[Network]
+Tunnel=gre-tun</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-vti.network</title>
+
+      <programlisting>[Match]
+Name=em1
+
+[Network]
+Tunnel=vti-tun</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-bond.network</title>
+
+      <programlisting>[Match]
+Name=bond1
+
+[Network]
+DHCP=yes
+</programlisting>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.nspawn.xml b/src/grp-system/systemd/systemd.nspawn.xml
new file mode 100644
index 0000000000..3683412c14
--- /dev/null
+++ b/src/grp-system/systemd/systemd.nspawn.xml
@@ -0,0 +1,454 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!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;
+]>
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2015 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.nspawn">
+
+  <refentryinfo>
+    <title>systemd.nspawn</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.nspawn</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.nspawn</refname>
+    <refpurpose>Container settings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para>
+    <para><filename>/run/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para>
+    <para><filename>/var/lib/machines/<replaceable>machine</replaceable>.nspawn</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>An nspawn container settings file (suffix
+    <filename>.nspawn</filename>) encodes additional runtime
+    information about a local container, and is searched, read and
+    used by
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    when starting a container. Files of this type are named after the
+    containers they define settings for. They are optional, and only
+    required for containers whose execution environment shall differ
+    from the defaults. Files of this type mostly contain settings that
+    may also be set on the <command>systemd-nspawn</command> command
+    line, and make it easier to persistently attach specific settings
+    to specific containers. The syntax of these files is inspired by
+    <filename>.desktop</filename> files following the <ulink
+    url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG
+    Desktop Entry Specification</ulink>, which in turn are inspired by
+    Microsoft Windows <filename>.ini</filename> files.</para>
+
+    <para>Boolean arguments used in these settings files can be
+    written in various formats. For positive settings, the strings
+    <option>1</option>, <option>yes</option>, <option>true</option>
+    and <option>on</option> are equivalent. For negative settings, the
+    strings <option>0</option>, <option>no</option>,
+    <option>false</option> and <option>off</option> are
+    equivalent.</para>
+
+    <para>Empty lines and lines starting with # or ; are
+    ignored. This may be used for commenting. Lines ending
+    in a backslash are concatenated with the following
+    line while reading and the backslash is replaced by a
+    space character. This may be used to wrap long lines.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title><filename>.nspawn</filename> File Discovery</title>
+
+    <para>Files are searched by appending the
+    <filename>.nspawn</filename> suffix to the machine name of the
+    container, as specified with the <option>--machine=</option>
+    switch of <command>systemd-nspawn</command>, or derived from the
+    directory or image file name. This file is first searched in
+    <filename>/etc/systemd/nspawn/</filename> and
+    <filename>/run/systemd/nspawn/</filename>. If found in these
+    directories, its settings are read and all of them take full effect
+    (but are possibly overridden by corresponding command line
+    arguments). If not found, the file will then be searched next to
+    the image file or in the immediate parent of the root directory of
+    the container. If the file is found there, only a subset of the
+    settings will take effect however. All settings that possibly
+    elevate privileges or grant additional access to resources of the
+    host (such as files or directories) are ignored. To which options
+    this applies is documented below.</para>
+
+    <para>Persistent settings files created and maintained by the
+    administrator (and thus trusted) should be placed in
+    <filename>/etc/systemd/nspawn/</filename>, while automatically
+    downloaded (and thus potentially untrusted) settings files are
+    placed in <filename>/var/lib/machines/</filename> instead (next to
+    the container images), where their security impact is limited. In
+    order to add privileged settings to <filename>.nspawn</filename>
+    files acquired from the image vendor, it is recommended to copy the
+    settings files into <filename>/etc/systemd/nspawn/</filename> and
+    edit them there, so that the privileged options become
+    available. The precise algorithm for how the files are searched and
+    interpreted may be configured with
+    <command>systemd-nspawn</command>'s <option>--settings=</option>
+    switch, see
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Exec] Section Options</title>
+
+    <para>Settings files may include an <literal>[Exec]</literal>
+    section, which carries various execution parameters:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><varname>Boot=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If enabled, <command>systemd-nspawn</command>
+        will automatically search for an <filename>init</filename> executable and invoke it. In this case, the
+        specified parameters using <varname>Parameters=</varname> are passed as additional arguments to the
+        <filename>init</filename> process. This setting corresponds to the <option>--boot</option> switch on the
+        <command>systemd-nspawn</command> command line. This option may not be combined with
+        <varname>ProcessTwo=yes</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProcessTwo=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If enabled, the specified program is run as
+        PID 2. A stub init process is run as PID 1. This setting corresponds to the <option>--as-pid2</option> switch
+        on the <command>systemd-nspawn</command> command line. This option may not be combined with
+        <varname>Boot=yes</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Parameters=</varname></term>
+
+        <listitem><para>Takes a space-separated list of
+        arguments. This is either a command line, beginning with the
+        binary name to execute, or – if <varname>Boot=</varname> is
+        enabled – the list of arguments to pass to the init
+        process. This setting corresponds to the command line
+        parameters passed on the <command>systemd-nspawn</command>
+        command line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Environment=</varname></term>
+
+        <listitem><para>Takes an environment variable assignment
+        consisting of key and value, separated by
+        <literal>=</literal>. Sets an environment variable for the
+        main process invoked in the container. This setting may be
+        used multiple times to set multiple environment variables. It
+        corresponds to the <option>--setenv=</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>User=</varname></term>
+
+        <listitem><para>Takes a UNIX user name. Specifies the user
+        name to invoke the main process of the container as. This user
+        must be known in the container's user database. This
+        corresponds to the <option>--user=</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WorkingDirectory=</varname></term>
+
+        <listitem><para>Selects the working directory for the process invoked in the container. Expects an absolute
+        path in the container's file system namespace. This corresponds to the <option>--chdir=</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Capability=</varname></term>
+        <term><varname>DropCapability=</varname></term>
+
+        <listitem><para>Takes a space-separated list of Linux process
+        capabilities (see
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). The <varname>Capability=</varname> setting
+        specifies additional capabilities to pass on top of the
+        default set of capabilities. The
+        <varname>DropCapability=</varname> setting specifies
+        capabilities to drop from the default set. These settings
+        correspond to the <option>--capability=</option> and
+        <option>--drop-capability=</option> command line
+        switches. Note that <varname>Capability=</varname> is a
+        privileged setting, and only takes effect in
+        <filename>.nspawn</filename> files in
+        <filename>/etc/systemd/nspawn/</filename> and
+        <filename>/run/system/nspawn/</filename> (see above). On the
+        other hand, <varname>DropCapability=</varname> takes effect in
+        all cases.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KillSignal=</varname></term>
+
+        <listitem><para>Specify the process signal to send to the
+        container's PID 1 when nspawn itself receives SIGTERM, in
+        order to trigger an orderly shutdown of the container.
+        Defaults to SIGRTMIN+3 if <option>Boot=</option> is used
+        (on systemd-compatible init systems SIGRTMIN+3 triggers an
+        orderly shutdown). For a list of valid signals, see
+        <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Personality=</varname></term>
+
+        <listitem><para>Configures the kernel personality for the
+        container. This is equivalent to the
+        <option>--personality=</option> switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MachineID=</varname></term>
+
+        <listitem><para>Configures the 128-bit machine ID (UUID) to pass to
+        the container. This is equivalent to the
+        <option>--uuid=</option> command line switch. This option is
+        privileged (see above). </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateUsers=</varname></term>
+
+        <listitem><para>Configures support for usernamespacing. This is equivalent to the
+        <option>--private-users=</option> command line switch, and takes the same options. This option is privileged
+        (see above). </para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Files] Section Options</title>
+
+    <para>Settings files may include a <literal>[Files]</literal>
+    section, which carries various parameters configuring the file
+    system of the container:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><varname>ReadOnly=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If
+        specified, the container will be run with a read-only file
+        system. This setting corresponds to the
+        <option>--read-only</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Volatile=</varname></term>
+
+        <listitem><para>Takes a boolean argument, or the special value
+        <literal>state</literal>. This configures whether to run the
+        container with volatile state and/or configuration. This
+        option is equivalent to <option>--volatile=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options
+        supported.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Bind=</varname></term>
+        <term><varname>BindReadOnly=</varname></term>
+
+        <listitem><para>Adds a bind mount from the host into the
+        container. Takes a single path, a pair of two paths separated
+        by a colon, or a triplet of two paths plus an option string
+        separated by colons. This option may be used multiple times to
+        configure multiple bind mounts. This option is equivalent to
+        the command line switches <option>--bind=</option> and
+        <option>--bind-ro=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options supported. This setting
+        is privileged (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TemporaryFileSystem=</varname></term>
+
+        <listitem><para>Adds a <literal>tmpfs</literal> mount to the
+        container. Takes a path or a pair of path and option string,
+        separated by a colon. This option may be used multiple times to
+        configure multiple <literal>tmpfs</literal> mounts. This
+        option is equivalent to the command line switch
+        <option>--tmpfs=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options supported. This setting
+        is privileged (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateUsersChown=</varname></term>
+
+        <listitem><para>Configures whether the ownership of the files and directories in the container tree shall be
+        adjusted to the UID/GID range used, if necessary and user namespacing is enabled. This is equivalent to the
+        <option>--private-users-chown</option> command line switch. This option is privileged (see
+        above). </para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Network] Section Options</title>
+
+    <para>Settings files may include a <literal>[Network]</literal>
+    section, which carries various parameters configuring the network
+    connectivity of the container:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><varname>Private=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If
+        enabled, the container will run in its own network namespace
+        and not share network interfaces and configuration with the
+        host. This setting corresponds to the
+        <option>--private-network</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VirtualEthernet=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Configures whether
+        to create a virtual Ethernet connection
+        (<literal>veth</literal>) between host and the container. This
+        setting implies <varname>Private=yes</varname>. This setting
+        corresponds to the <option>--network-veth</option> command
+        line switch. This option is privileged (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VirtualEthernetExtra=</varname></term>
+
+        <listitem><para>Takes a colon-separated pair of interface
+        names. Configures an additional virtual Ethernet connection
+        (<literal>veth</literal>) between host and the container. The
+        first specified name is the interface name on the host, the
+        second the interface name in the container. The latter may be
+        omitted in which case it is set to the same name as the host
+        side interface. This setting implies
+        <varname>Private=yes</varname>. This setting corresponds to
+        the <option>--network-veth-extra=</option> command line
+        switch, and maybe be used multiple times. It is independent of
+        <varname>VirtualEthernet=</varname>. This option is privileged
+        (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Interface=</varname></term>
+
+        <listitem><para>Takes a space-separated list of interfaces to
+        add to the container. This option corresponds to the
+        <option>--network-interface=</option> command line switch and
+        implies <varname>Private=yes</varname>. This option is
+        privileged (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MACVLAN=</varname></term>
+        <term><varname>IPVLAN=</varname></term>
+
+        <listitem><para>Takes a space-separated list of interfaces to
+        add MACLVAN or IPVLAN interfaces to, which are then added to
+        the container. These options correspond to the
+        <option>--network-macvlan=</option> and
+        <option>--network-ipvlan=</option> command line switches and
+        imply <varname>Private=yes</varname>. These options are
+        privileged (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Bridge=</varname></term>
+
+        <listitem><para>Takes an interface name. This setting implies
+        <varname>VirtualEthernet=yes</varname> and
+        <varname>Private=yes</varname> and has the effect that the
+        host side of the created virtual Ethernet link is connected to
+        the specified bridge interface. This option corresponds to the
+        <option>--network-bridge=</option> command line switch. This
+        option is privileged (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Zone=</varname></term>
+
+        <listitem><para>Takes a network zone name. This setting implies <varname>VirtualEthernet=yes</varname> and
+        <varname>Private=yes</varname> and has the effect that the host side of the created virtual Ethernet link is
+        connected to an automatically managed bridge interface named after the passed argument, prefixed with
+        <literal>vz-</literal>. This option corresponds to the <option>--network-zone=</option> command line
+        switch. This option is privileged (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+
+        <listitem><para>Exposes a TCP or UDP port of the container on
+        the host. This option corresponds to the
+        <option>--port=</option> command line switch, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for the precise syntax of the argument this option takes. This
+        option is privileged (see above).</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.offline-updates.xml b/src/grp-system/systemd/systemd.offline-updates.xml
new file mode 100644
index 0000000000..946234ad90
--- /dev/null
+++ b/src/grp-system/systemd/systemd.offline-updates.xml
@@ -0,0 +1,169 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Lennart Poettering
+  Copyright 2016 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.offline-updates">
+  <refentryinfo>
+    <title>systemd.offline-updates</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.offline-updates</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.offline-updates</refname>
+    <refpurpose>Implementation of offline updates in systemd</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Implementing Offline System Updates</title>
+
+    <para>This man page describes how to implement "offline" system updates with systemd. By "offline"
+    OS updates we mean package installations and updates that are run with the system booted into a
+    special system update mode, in order to avoid problems related to conflicts of libraries and
+    services that are currently running with those on disk. This document is inspired by this
+    <ulink url="https://wiki.gnome.org/Design/OS/SoftwareUpdates">GNOME design whiteboard</ulink>.
+    </para>
+
+    <para>The logic:</para>
+
+    <orderedlist>
+      <listitem>
+        <para>The package manager prepares system updates by downloading all (RPM or DEB or
+        whatever) packages to update off-line in a special directory
+        <filename noindex="true">/var/lib/system-update</filename> (or
+        another directory of the package/upgrade manager's choice).</para>
+      </listitem>
+
+      <listitem>
+        <para>When the user OK'ed the update, the symlink <filename>/system-update</filename> is
+        created that points to <filename noindex="true">/var/lib/system-update</filename> (or
+        wherever the directory with the upgrade files is located) and the system is rebooted. This
+        symlink is in the root directory, since we need to check for it very early at boot, at a
+        time where <filename>/var</filename> is not available yet.</para>
+      </listitem>
+
+      <listitem>
+        <para>Very early in the new boot
+        <citerefentry><refentrytitle>systemd-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        checks whether <filename>/system-update</filename> exists. If so, it (temporarily and for
+        this boot only) redirects (i.e. symlinks) <filename>default.target</filename> to
+        <filename>system-update.target</filename>, a special target that is pulls in the base system
+        (i.e. <filename>sysinit.target</filename>, so that all file systems are mounted but little
+        else) and the system update units.</para>
+      </listitem>
+
+      <listitem>
+        <para>The system now continues to boot into <filename>default.target</filename>, and thus
+        into <filename>system-update.target</filename>. This target pulls in the system update unit,
+        which starts the system update script after all file systems have been mounted.</para>
+      </listitem>
+
+      <listitem>
+        <para>As the first step, the update script should check if the
+        <filename>/system-update</filename> symlink points to the the location used by that update
+        script. In case it does not exists or points to a different location, the script must exit
+        without error. It is possible for multiple update services to be installed, and for multiple
+        update scripts to be launched in parallel, and only the one that corresponds to the tool
+        that <emphasis>created</emphasis> the symlink before reboot should perform any actions. It
+        is unsafe to run multiple updates in parallel.</para>
+      </listitem>
+
+      <listitem>
+        <para>The update script should now do its job. If applicable and possible, it should
+        create a file system snapshot, then install all packages.
+        After completion (regardless whether the update succeeded or failed) the machine
+        must be rebooted, for example by calling <command>systemctl reboot</command>.
+        In addition, on failure the script should revert to the old file system snapshot
+        (without the symlink).</para>
+      </listitem>
+
+      <listitem>
+        <para>The system is rebooted. Since the <filename>/system-update</filename> symlink is gone,
+        the generator won't redirect <filename>default.target</filename> after reboot and the
+        system now boots into the default target again.</para>
+      </listitem>
+    </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Recommendations</title>
+
+    <orderedlist>
+      <listitem>
+        <para>To make things a bit more robust we recommend hooking the update script into
+        <filename>system-update.target</filename> via a <filename noindex='true'>.wants/</filename>
+        symlink in the distribution package, rather than depending on <command>systemctl
+        enable</command> in the postinst scriptlets of your package. More specifically, for your
+        update script create a .service file, without [Install] section, and then add a symlink like
+        <filename noindex='true'>/usr/lib/systemd/system-update.target.wants/foobar.service</filename>
+        → <filename noindex='true'>../foobar.service</filename> to your package.</para>
+      </listitem>
+
+      <listitem>
+        <para>Make sure to remove the <filename>/system-update</filename> symlink as early as
+        possible in the update script to avoid reboot loops in case the update fails.</para>
+      </listitem>
+
+      <listitem>
+        <para>Use <varname>FailureAction=reboot</varname> in the service file for your update script
+        to ensure that a reboot is automatically triggered if the update fails.
+        <varname>FailureAction=</varname> makes sure that the specified unit is activated if your
+        script exits uncleanly (by non-zero error code, or signal/coredump). If your script succeeds
+        you should trigger the reboot in your own code, for example by invoking logind's
+        <command>Reboot()</command> call or calling <command>systemct reboot</command>. See
+        <ulink url="http://www.freedesktop.org/wiki/Software/systemd/logind">logind dbus API</ulink>
+        for details.</para>
+      </listitem>
+
+      <listitem>
+        <para>The update service should declare <varname>DefaultDependencies=false</varname>,
+        and pull in any services it requires explicitly.</para>
+      </listitem>
+    </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>See also</title>
+
+    <para>
+      <ulink url="http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/">Implementing Offline System Updates</ulink>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>dnf.plugin.system-upgrade</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/src/grp-system/systemd/systemd.path.xml b/src/grp-system/systemd/systemd.path.xml
new file mode 100644
index 0000000000..7200c8fe27
--- /dev/null
+++ b/src/grp-system/systemd/systemd.path.xml
@@ -0,0 +1,202 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.path">
+  <refentryinfo>
+    <title>systemd.path</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.path</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.path</refname>
+    <refpurpose>Path unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>path</replaceable>.path</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.path</literal> encodes information about a path
+    monitored by systemd, for path-based activation.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The path specific configuration options are
+    configured in the [Path] section.</para>
+
+    <para>For each path file, a matching unit file must exist,
+    describing the unit to activate when the path changes. By default,
+    a service by the same name as the path (except for the suffix) is
+    activated. Example: a path file <filename>foo.path</filename>
+    activates a matching service <filename>foo.service</filename>. The
+    unit to activate may be controlled by <varname>Unit=</varname>
+    (see below).</para>
+
+    <para>Internally, path units use the
+    <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    API to monitor file systems. Due to that, it suffers by the same
+    limitations as inotify, and for example cannot be used to monitor
+    files or directories changed by other machines on remote NFS file
+    systems.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>If a path unit is beneath another mount unit in the file
+    system hierarchy, both a requirement and an ordering dependency
+    between both units are created automatically.</para>
+
+    <para>An implicit <varname>Before=</varname> dependency is added
+    between a path unit and the unit it is supposed to activate.</para>
+
+    <para>Unless <varname>DefaultDependencies=false</varname> in the <literal>[Unit]</literal> section is used, path
+    units will implicitly have dependencies of type <varname>Before=</varname> on <filename>paths.target</filename>,
+    dependencies of type <varname>After=</varname> and <varname>Requires=</varname> on
+    <filename>sysinit.target</filename>, and have dependencies of type <varname>Conflicts=</varname> and
+    <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that path units are terminated
+    cleanly prior to system shutdown. Only path units involved with early boot or late system shutdown should disable
+    this option.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Path files must include a [Path] section, which carries
+    information about the path(s) it monitors. The options specific to
+    the [Path] section of path units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>PathExists=</varname></term>
+        <term><varname>PathExistsGlob=</varname></term>
+        <term><varname>PathChanged=</varname></term>
+        <term><varname>PathModified=</varname></term>
+        <term><varname>DirectoryNotEmpty=</varname></term>
+
+        <listitem><para>Defines paths to monitor for certain changes:
+        <varname>PathExists=</varname> may be used to watch the mere
+        existence of a file or directory. If the file specified
+        exists, the configured unit is activated.
+        <varname>PathExistsGlob=</varname> works similar, but checks
+        for the existence of at least one file matching the globbing
+        pattern specified. <varname>PathChanged=</varname> may be used
+        to watch a file or directory and activate the configured unit
+        whenever it changes. It is not activated on every write to the
+        watched file but it is activated if the file which was open
+        for writing gets closed. <varname>PathModified=</varname> is
+        similar, but additionally it is activated also on simple
+        writes to the watched file.
+        <varname>DirectoryNotEmpty=</varname> may be used to watch a
+        directory and activate the configured unit whenever it
+        contains at least one file.</para>
+
+        <para>The arguments of these directives must be absolute file
+        system paths.</para>
+
+        <para>Multiple directives may be combined, of the same and of
+        different types, to watch multiple paths. If the empty string
+        is assigned to any of these options, the list of paths to
+        watch is reset, and any prior assignments of these options
+        will not have any effect.</para>
+
+        <para>If a path already exists (in case of
+        <varname>PathExists=</varname> and
+        <varname>PathExistsGlob=</varname>) or a directory already is
+        not empty (in case of <varname>DirectoryNotEmpty=</varname>)
+        at the time the path unit is activated, then the configured
+        unit is immediately activated as well. Something similar does
+        not apply to <varname>PathChanged=</varname> and
+        <varname>PathModified=</varname>.</para>
+
+        <para>If the path itself or any of the containing directories
+        are not accessible, <command>systemd</command> will watch for
+        permission changes and notice that conditions are satisfied
+        when permissions allow that. </para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Unit=</varname></term>
+
+        <listitem><para>The unit to activate when any of the
+        configured paths changes. The argument is a unit name, whose
+        suffix is not <literal>.path</literal>. If not specified, this
+        value defaults to a service that has the same name as the path
+        unit, except for the suffix. (See above.) It is recommended
+        that the unit name that is activated and the unit name of the
+        path unit are named identical, except for the
+        suffix.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MakeDirectory=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, the
+        directories to watch are created before watching. This option
+        is ignored for <varname>PathExists=</varname> settings.
+        Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+
+        <listitem><para>If <varname>MakeDirectory=</varname> is
+        enabled, use the mode specified here to create the directories
+        in question. Takes an access mode in octal notation. Defaults
+        to <option>0755</option>.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.preset.xml b/src/grp-system/systemd/systemd.preset.xml
new file mode 100644
index 0000000000..b7164014f0
--- /dev/null
+++ b/src/grp-system/systemd/systemd.preset.xml
@@ -0,0 +1,189 @@
+<?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">
+<!--
+  This file is part of systemd.
+
+  Copyright 2011 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+<refentry id="systemd.preset">
+
+  <refentryinfo>
+    <title>systemd.preset</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.preset</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.preset</refname>
+    <refpurpose>Service enablement presets</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/system-preset/*.preset</filename></para>
+    <para><filename>/run/systemd/system-preset/*.preset</filename></para>
+    <para><filename>/usr/lib/systemd/system-preset/*.preset</filename></para>
+    <para><filename>/etc/systemd/user-preset/*.preset</filename></para>
+    <para><filename>/run/systemd/user-preset/*.preset</filename></para>
+    <para><filename>/usr/lib/systemd/user-preset/*.preset</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Preset files may be used to encode policy which units shall
+    be enabled by default and which ones shall be disabled. They are
+    read by <command>systemctl preset</command> (for more information
+    see
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+    which uses this information to enable or disable a unit according
+    to preset policy. <command>systemctl preset</command> is used by
+    the post install scriptlets of RPM packages (or other OS package
+    formats), to enable/disable specific units by default on package
+    installation, enforcing distribution, spin or administrator preset
+    policy. This allows choosing a certain set of units to be
+    enabled/disabled even before installing the actual package.</para>
+
+    <para>For more information on the preset logic please have a look
+    at the <ulink
+    url="http://freedesktop.org/wiki/Software/systemd/Preset">Presets</ulink>
+    document.</para>
+
+    <para>It is not recommended to ship preset files within the
+    respective software packages implementing the units, but rather
+    centralize them in a distribution or spin default policy, which
+    can be amended by administrator policy.</para>
+
+    <para>If no preset files exist, <command>systemctl
+    preset</command> will enable all units that are installed by
+    default. If this is not desired and all units shall rather be
+    disabled, it is necessary to ship a preset file with a single,
+    catchall "<filename>disable *</filename>" line. (See example 1,
+    below.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Preset File Format</title>
+
+    <para>The preset files contain a list of directives consisting of
+    either the word <literal>enable</literal> or
+    <literal>disable</literal> followed by a space and a unit name
+    (possibly with shell style wildcards), separated by newlines.
+    Empty lines and lines whose first non-whitespace character is # or
+    ; are ignored.</para>
+
+    <para>Two different directives are understood:
+    <literal>enable</literal> may be used to enable units by default,
+    <literal>disable</literal> to disable units by default.</para>
+
+    <para>If multiple lines apply to a unit name, the first matching
+    one takes precedence over all others.</para>
+
+    <para>Each preset file shall be named in the style of
+    <filename>&lt;priority&gt;-&lt;policy-name&gt;.preset</filename>. Files
+    in <filename>/etc/</filename> override files with the same name in
+    <filename>/usr/lib/</filename> and <filename>/run/</filename>.
+    Files in <filename>/run/</filename> override files with the same
+    name in <filename>/usr/lib/</filename>. Packages should install
+    their preset files in <filename>/usr/lib/</filename>. Files in
+    <filename>/etc/</filename> are reserved for the local
+    administrator, who may use this logic to override the preset files
+    installed by vendor packages. All preset files are sorted by their
+    filename in lexicographic order, regardless of which of the
+    directories they reside in. If multiple files specify the same
+    unit name, the entry in the file with the lexicographically
+    earliest name will be applied. It is recommended to prefix all
+    filenames with a two-digit number and a dash, to simplify the
+    ordering of the files.</para>
+
+    <para>If the administrator wants to disable a preset file supplied
+    by the vendor, the recommended way is to place a symlink to
+    <filename>/dev/null</filename> in
+    <filename>/etc/systemd/system-preset/</filename> bearing the same
+    filename.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Default off example <filename>/usr/lib/systemd/system-preset/99-default.preset</filename>:</title>
+
+      <programlisting>disable *</programlisting>
+    </example>
+
+    <para>This disables all units. Due to the filename prefix
+    <literal>99-</literal>, it will be read last and hence can easily
+    be overridden by spin or administrator preset policy or
+    suchlike.</para>
+
+    <example>
+      <title>A GNOME spin example <filename>/usr/lib/systemd/system-preset/50-gnome.preset</filename>:</title>
+
+      <programlisting>enable gdm.service
+enable colord.service
+enable accounts-daemon.service
+enable avahi-daemon.*</programlisting>
+
+    </example>
+
+    <para>This enables the three mentioned units, plus all
+    <filename>avahi-daemon</filename> regardless of which unit type. A
+    file like this could be useful for inclusion in a GNOME spin of a
+    distribution. It will ensure that the units necessary for GNOME
+    are properly enabled as they are installed. It leaves all other
+    units untouched, and subject to other (later) preset files, for
+    example like the one from the first example above.</para>
+
+    <example>
+      <title>Administrator policy <filename>/etc/systemd/system-preset/00-lennart.preset</filename>:</title>
+
+      <programlisting>enable httpd.service
+enable sshd.service
+enable postfix.service
+disable *</programlisting>
+    </example>
+
+    <para>This enables three specific services and disables all
+    others. This is useful for administrators to specifically select
+    the units to enable, and disable all others. Due to the filename
+    prefix <literal>00-</literal> it will be read early and hence
+    overrides all other preset policy files.</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-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.resource-control.xml b/src/grp-system/systemd/systemd.resource-control.xml
new file mode 100644
index 0000000000..066f2cc19b
--- /dev/null
+++ b/src/grp-system/systemd/systemd.resource-control.xml
@@ -0,0 +1,628 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.resource-control">
+  <refentryinfo>
+    <title>systemd.resource-control</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.resource-control</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.resource-control</refname>
+    <refpurpose>Resource control unit settings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para>
+      <filename><replaceable>slice</replaceable>.slice</filename>,
+      <filename><replaceable>scope</replaceable>.scope</filename>,
+      <filename><replaceable>service</replaceable>.service</filename>,
+      <filename><replaceable>socket</replaceable>.socket</filename>,
+      <filename><replaceable>mount</replaceable>.mount</filename>,
+      <filename><replaceable>swap</replaceable>.swap</filename>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Unit configuration files for services, slices, scopes,
+    sockets, mount points, and swap devices share a subset of
+    configuration options for resource control of spawned
+    processes. Internally, this relies on the Control Groups
+    kernel concept for organizing processes in a hierarchical tree of
+    named groups for the purpose of resource management.</para>
+
+    <para>This man page lists the configuration options shared by
+    those six unit types. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files, and
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.scope</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.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    and
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information on the specific unit configuration files. The
+    resource control configuration options are configured in the
+    [Slice], [Scope], [Service], [Socket], [Mount], or [Swap]
+    sections, depending on the unit type.</para>
+
+    <para>See the <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
+    Control Group Interfaces</ulink> for an introduction on how to make
+    use of resource control APIs from programs.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Units with the <varname>Slice=</varname> setting set get
+    automatic <varname>Requires=</varname> and
+    <varname>After=</varname> dependencies on the specified slice
+    unit.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Unified and Legacy Control Group Hierarchies</title>
+
+    <para>Unified control group hierarchy is the new version of kernel control group interface. Depending on the
+    resource type, there are differences in resource control capabilities.  Also, because of interface changes, some
+    resource types have a separate set of options on the unified hierarchy.</para>
+
+    <para>
+      <variablelist>
+        <varlistentry>
+          <term><option>IO</option></term>
+          <listitem>
+            <para><varname>IO</varname> prefixed settings are superset of and replace <varname>BlockIO</varname>
+            prefixed ones. On unified hierarchy, IO resource control also applies to buffered writes.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </para>
+
+    <para>To ease the transition, there is best-effort translation between the two versions of settings. If all
+    settings of a unit for a given resource type are for the other hierarchy type, the settings are translated and
+    applied. If there are any valid settings for the hierarchy in use, all translations are disabled for the resource
+    type. Mixing the two types of settings on a unit can lead to confusing results.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Units of the types listed above can have settings
+    for resource control configuration:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>CPUAccounting=</varname></term>
+
+        <listitem>
+          <para>Turn on CPU usage accounting for this unit. Takes a
+          boolean argument. Note that turning on CPU accounting for
+          one unit will also implicitly turn it on for all units
+          contained in the same slice and for all its parent slices
+          and the units contained therein. The system default for this
+          setting may be controlled with
+          <varname>DefaultCPUAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUShares=<replaceable>weight</replaceable></varname></term>
+        <term><varname>StartupCPUShares=<replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>Assign the specified CPU time share weight to the
+          processes executed. These options take an integer value and
+          control the <literal>cpu.shares</literal> control group
+          attribute. The allowed range is 2 to 262144. Defaults to
+          1024. For details about this control group attribute, see
+          <ulink
+          url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt">sched-design-CFS.txt</ulink>.
+          The available CPU time is split up among all units within
+          one slice relative to their CPU time share weight.</para>
+
+          <para>While <varname>StartupCPUShares=</varname> only
+          applies to the startup phase of the system,
+          <varname>CPUShares=</varname> applies to normal runtime of
+          the system, and if the former is not set also to the startup
+          phase. Using <varname>StartupCPUShares=</varname> allows
+          prioritizing specific services at boot-up differently than
+          during normal runtime.</para>
+
+          <para>These options imply
+          <literal>CPUAccounting=true</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUQuota=</varname></term>
+
+        <listitem>
+          <para>Assign the specified CPU time quota to the processes
+          executed. Takes a percentage value, suffixed with "%". The
+          percentage specifies how much CPU time the unit shall get at
+          maximum, relative to the total CPU time available on one
+          CPU. Use values &gt; 100% for allotting CPU time on more than
+          one CPU. This controls the
+          <literal>cpu.cfs_quota_us</literal> control group
+          attribute. For details about this control group attribute,
+          see <ulink
+          url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt">sched-design-CFS.txt</ulink>.</para>
+
+          <para>Example: <varname>CPUQuota=20%</varname> ensures that
+          the executed processes will never get more than 20% CPU time
+          on one CPU.</para>
+
+          <para>Implies <literal>CPUAccounting=true</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryAccounting=</varname></term>
+
+        <listitem>
+          <para>Turn on process and kernel memory accounting for this
+          unit. Takes a boolean argument. Note that turning on memory
+          accounting for one unit will also implicitly turn it on for
+          all units contained in the same slice and for all its parent
+          slices and the units contained therein. The system default
+          for this setting may be controlled with
+          <varname>DefaultMemoryAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryLimit=<replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>Specify the limit on maximum memory usage of the
+          executed processes. The limit specifies how much process and
+          kernel memory can be used by tasks in this unit. Takes a
+          memory size in bytes. If the value is suffixed with K, M, G
+          or T, the specified memory size is parsed as Kilobytes,
+          Megabytes, Gigabytes, or Terabytes (with the base 1024),
+          respectively. If assigned the special value
+          <literal>infinity</literal>, no memory limit is applied. This
+          controls the <literal>memory.limit_in_bytes</literal>
+          control group attribute. For details about this control
+          group attribute, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt">memory.txt</ulink>.</para>
+
+          <para>Implies <literal>MemoryAccounting=true</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TasksAccounting=</varname></term>
+
+        <listitem>
+          <para>Turn on task accounting for this unit. Takes a
+          boolean argument. If enabled, the system manager will keep
+          track of the number of tasks in the unit. The number of
+          tasks accounted this way includes both kernel threads and
+          userspace processes, with each thread counting
+          individually. Note that turning on tasks accounting for one
+          unit will also implicitly turn it on for all units contained
+          in the same slice and for all its parent slices and the
+          units contained therein. The system default for this setting
+          may be controlled with
+          <varname>DefaultTasksAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TasksMax=<replaceable>N</replaceable></varname></term>
+
+        <listitem>
+          <para>Specify the maximum number of tasks that may be
+          created in the unit. This ensures that the number of tasks
+          accounted for the unit (see above) stays below a specific
+          limit. If assigned the special value
+          <literal>infinity</literal>, no tasks limit is applied. This
+          controls the <literal>pids.max</literal> control group
+          attribute. For details about this control group attribute,
+          see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt">pids.txt</ulink>.</para>
+
+          <para>Implies <literal>TasksAccounting=true</literal>. The
+          system default for this setting may be controlled with
+          <varname>DefaultTasksMax=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOAccounting=</varname></term>
+
+        <listitem>
+          <para>Turn on Block I/O accounting for this unit, if the unified control group hierarchy is used on the
+          system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly
+          turn it on for all units contained in the same slice and all for its parent slices and the units contained
+          therein. The system default for this setting may be controlled with <varname>DefaultIOAccounting=</varname>
+          in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <para>This setting is supported only if the unified control group hierarchy is used. Use
+          <varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOWeight=<replaceable>weight</replaceable></varname></term>
+        <term><varname>StartupIOWeight=<replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>Set the default overall block I/O weight for the executed processes, if the unified control group
+          hierarchy is used on the system. Takes a single weight value (between 1 and 10000) to set the default block
+          I/O weight. This controls the <literal>io.weight</literal> control group attribute, which defaults to
+          100. For details about this control group attribute, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.  The available I/O
+          bandwidth is split up among all units within one slice relative to their block I/O weight.</para>
+
+          <para>While <varname>StartupIOWeight=</varname> only applies
+          to the startup phase of the system,
+          <varname>IOWeight=</varname> applies to the later runtime of
+          the system, and if the former is not set also to the startup
+          phase. This allows prioritizing specific services at boot-up
+          differently than during runtime.</para>
+
+          <para>Implies <literal>IOAccounting=true</literal>.</para>
+
+          <para>This setting is supported only if the unified control group hierarchy is used. Use
+          <varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname> on systems using the legacy
+          control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>Set the per-device overall block I/O weight for the executed processes, if the unified control group
+          hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify
+          the device specific weight value, between 1 and 10000. (Example: "/dev/sda 1000"). The file path may be
+          specified as path to a block device node or as any other file, in which case the backing block device of the
+          file system of the file is determined. This controls the <literal>io.weight</literal> control group
+          attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices. For
+          details about this control group attribute, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para>
+
+          <para>Implies <literal>IOAccounting=true</literal>.</para>
+
+          <para>This setting is supported only if the unified control group hierarchy is used. Use
+          <varname>BlockIODeviceWeight=</varname> on systems using the legacy control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOReadBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+        <term><varname>IOWriteBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified
+          control group hierarchy is used on the system. This limit is not work-conserving and the executed processes
+          are not allowed to use more even if the device has idle capacity.  Takes a space-separated pair of a file
+          path and a bandwidth value (in bytes per second) to specify the device specific bandwidth. The file path may
+          be a path to a block device node, or as any other file in which case the backing block device of the file
+          system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
+          "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the <literal>io.max</literal> control
+          group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details
+          about this control group attribute, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.
+          </para>
+
+          <para>Implies <literal>IOAccounting=true</literal>.</para>
+
+          <para>This setting is supported only if the unified control group hierarchy is used. Use
+          <varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOReadIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term>
+        <term><varname>IOWriteIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term>
+
+        <listitem>
+          <para>Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the
+          unified control group hierarchy is used on the system. This limit is not work-conserving and the executed
+          processes are not allowed to use more even if the device has idle capacity.  Takes a space-separated pair of
+          a file path and an IOPS value to specify the device specific IOPS. The file path may be a path to a block
+          device node, or as any other file in which case the backing block device of the file system of the file is
+          used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS,
+          GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example:
+          "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the <literal>io.max</literal> control
+          group attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about
+          this control group attribute, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.
+          </para>
+
+          <para>Implies <literal>IOAccounting=true</literal>.</para>
+
+          <para>This setting is supported only if the unified control group hierarchy is used.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BlockIOAccounting=</varname></term>
+
+        <listitem>
+          <para>Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the
+          system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly
+          turn it on for all units contained in the same slice and all for its parent slices and the units contained
+          therein. The system default for this setting may be controlled with
+          <varname>DefaultBlockIOAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <para>This setting is supported only if the legacy control group hierarchy is used. Use
+          <varname>IOAccounting=</varname> on systems using the unified control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BlockIOWeight=<replaceable>weight</replaceable></varname></term>
+        <term><varname>StartupBlockIOWeight=<replaceable>weight</replaceable></varname></term>
+
+        <listitem><para>Set the default overall block I/O weight for the executed processes, if the legacy control
+        group hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default
+        block I/O weight. This controls the <literal>blkio.weight</literal> control group attribute, which defaults to
+        500. For details about this control group attribute, see <ulink
+        url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
+        The available I/O bandwidth is split up among all units within one slice relative to their block I/O
+        weight.</para>
+
+        <para>While <varname>StartupBlockIOWeight=</varname> only
+        applies to the startup phase of the system,
+        <varname>BlockIOWeight=</varname> applies to the later runtime
+        of the system, and if the former is not set also to the
+        startup phase. This allows prioritizing specific services at
+        boot-up differently than during runtime.</para>
+
+        <para>Implies
+        <literal>BlockIOAccounting=true</literal>.</para>
+
+        <para>This setting is supported only if the legacy control group hierarchy is used. Use
+        <varname>IOWeight=</varname> and <varname>StartupIOWeight=</varname> on systems using the unified control group
+        hierarchy.</para>
+
+      </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BlockIODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>Set the per-device overall block I/O weight for the executed processes, if the legacy control group
+          hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify
+          the device specific weight value, between 10 and 1000. (Example: "/dev/sda 500"). The file path may be
+          specified as path to a block device node or as any other file, in which case the backing block device of the
+          file system of the file is determined. This controls the <literal>blkio.weight_device</literal> control group
+          attribute, which defaults to 1000. Use this option multiple times to set weights for multiple devices. For
+          details about this control group attribute, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.</para>
+
+          <para>Implies
+          <literal>BlockIOAccounting=true</literal>.</para>
+
+          <para>This setting is supported only if the legacy control group hierarchy is used. Use
+          <varname>IODeviceWeight=</varname> on systems using the unified control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BlockIOReadBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+        <term><varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control
+          group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in
+          bytes per second) to specify the device specific bandwidth. The file path may be a path to a block device
+          node, or as any other file in which case the backing block device of the file system of the file is used. If
+          the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes, Megabytes,
+          Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
+          "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the
+          <literal>blkio.throttle.read_bps_device</literal> and <literal>blkio.throttle.write_bps_device</literal>
+          control group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For
+          details about these control group attributes, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
+          </para>
+
+          <para>Implies
+          <literal>BlockIOAccounting=true</literal>.</para>
+
+          <para>This setting is supported only if the legacy control group hierarchy is used. Use
+          <varname>IOReadBandwidthMax=</varname> and <varname>IOWriteBandwidthMax=</varname> on systems using the
+          unified control group hierarchy.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DeviceAllow=</varname></term>
+
+        <listitem>
+          <para>Control access to specific device nodes by the
+          executed processes. Takes two space-separated strings: a
+          device node specifier followed by a combination of
+          <constant>r</constant>, <constant>w</constant>,
+          <constant>m</constant> to control
+          <emphasis>r</emphasis>eading, <emphasis>w</emphasis>riting,
+          or creation of the specific device node(s) by the unit
+          (<emphasis>m</emphasis>knod), respectively. This controls
+          the <literal>devices.allow</literal> and
+          <literal>devices.deny</literal> control group
+          attributes. For details about these control group
+          attributes, see <ulink
+          url="https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt">devices.txt</ulink>.</para>
+
+          <para>The device node specifier is either a path to a device
+          node in the file system, starting with
+          <filename>/dev/</filename>, or a string starting with either
+          <literal>char-</literal> or <literal>block-</literal>
+          followed by a device group name, as listed in
+          <filename>/proc/devices</filename>. The latter is useful to
+          whitelist all current and future devices belonging to a
+          specific device group at once. The device group is matched
+          according to file name globbing rules, you may hence use the
+          <literal>*</literal> and <literal>?</literal>
+          wildcards. Examples: <filename>/dev/sda5</filename> is a
+          path to a device node, referring to an ATA or SCSI block
+          device. <literal>char-pts</literal> and
+          <literal>char-alsa</literal> are specifiers for all pseudo
+          TTYs and all ALSA sound devices,
+          respectively. <literal>char-cpu/*</literal> is a specifier
+          matching all CPU related device groups.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DevicePolicy=auto|closed|strict</varname></term>
+
+        <listitem>
+          <para>
+            Control the policy for allowing device access:
+          </para>
+          <variablelist>
+            <varlistentry>
+              <term><option>strict</option></term>
+              <listitem>
+                <para>means to only allow types of access that are
+                explicitly specified.</para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><option>closed</option></term>
+              <listitem>
+                <para>in addition, allows access to standard pseudo
+                devices including
+                <filename>/dev/null</filename>,
+                <filename>/dev/zero</filename>,
+                <filename>/dev/full</filename>,
+                <filename>/dev/random</filename>, and
+                <filename>/dev/urandom</filename>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><option>auto</option></term>
+              <listitem>
+                <para>
+                  in addition, allows access to all devices if no
+                  explicit <varname>DeviceAllow=</varname> is present.
+                  This is the default.
+                </para>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Slice=</varname></term>
+
+        <listitem>
+          <para>The name of the slice unit to place the unit
+          in. Defaults to <filename>system.slice</filename> for all
+          non-instantiated units of all unit types (except for slice
+          units themselves see below). Instance units are by default
+          placed in a subslice of <filename>system.slice</filename>
+          that is named after the template name.</para>
+
+          <para>This option may be used to arrange systemd units in a
+          hierarchy of slices each of which might have resource
+          settings applied.</para>
+
+          <para>For units of type slice, the only accepted value for
+          this setting is the parent slice. Since the name of a slice
+          unit implies the parent slice, it is hence redundant to ever
+          set this parameter directly for slice units.</para>
+
+          <para>Special care should be taken when relying on the default slice assignment in templated service units
+          that have <varname>DefaultDependencies=no</varname> set, see
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, section
+          "Automatic Dependencies" for details.</para>
+
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Delegate=</varname></term>
+
+        <listitem>
+          <para>Turns on delegation of further resource control
+          partitioning to processes of the unit. For unprivileged
+          services (i.e. those using the <varname>User=</varname>
+          setting), this allows processes to create a subhierarchy
+          beneath its control group path. For privileged services and
+          scopes, this ensures the processes will have all control
+          group controllers enabled.</para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <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.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      The documentation for control groups and specific controllers in the Linux kernel:
+      <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>,
+      <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/cpuacct.txt">cpuacct.txt</ulink>,
+      <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt">memory.txt</ulink>,
+      <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.
+    </para>
+  </refsect1>
+</refentry>
diff --git a/src/grp-system/systemd/systemd.scope.xml b/src/grp-system/systemd/systemd.scope.xml
new file mode 100644
index 0000000000..f69b2ef635
--- /dev/null
+++ b/src/grp-system/systemd/systemd.scope.xml
@@ -0,0 +1,108 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.scope">
+  <refentryinfo>
+    <title>systemd.scope</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.scope</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.scope</refname>
+    <refpurpose>Scope unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>scope</replaceable>.scope</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Scope units are not configured via unit configuration files,
+    but are only created programmatically using the bus interfaces of
+    systemd. They are named similar to filenames. A unit whose name
+    ends in <literal>.scope</literal> refers to a scope unit. Scopes
+    units manage a set of system processes. Unlike service units, scope
+    units manage externally created processes, and do not fork off
+    processes on its own.</para>
+
+    <para>The main purpose of scope units is grouping worker processes
+    of a system service for organization and for managing resources.</para>
+
+    <para><command>systemd-run <option>--scope</option></command> may
+    be used to easily launch a command in a new scope unit from the
+    command line.</para>
+
+    <para>See the <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
+    Control Group Interfaces</ulink> for an introduction on how to make
+    use of scope units from programs.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Unless <varname>DefaultDependencies=false</varname>
+    is used, scope units will implicitly have dependencies of
+    type <varname>Conflicts=</varname> and
+    <varname>Before=</varname> on
+    <filename>shutdown.target</filename>. These ensure
+    that scope units are removed prior to system
+    shutdown. Only scope units involved with early boot or
+    late system shutdown should disable this option.
+    </para>
+
+    <para>Additional implicit dependencies may be added as result of
+    resource control parameters as documented in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.service.xml b/src/grp-system/systemd/systemd.service.xml
new file mode 100644
index 0000000000..6641dfed4f
--- /dev/null
+++ b/src/grp-system/systemd/systemd.service.xml
@@ -0,0 +1,1352 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.service">
+  <refentryinfo>
+    <title>systemd.service</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.service</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.service</refname>
+    <refpurpose>Service unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <filename>.service</filename> encodes information about a process
+    controlled and supervised by systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic
+    <literal>[Unit]</literal> and <literal>[Install]</literal>
+    sections. The service specific configuration options are
+    configured in the <literal>[Service]</literal> section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the commands are executed
+    in, and in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way the processes of the service are terminated,
+    and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for the processes of the
+    service.</para>
+
+    <para>If a service is requested under a certain name but no unit
+    configuration file is found, systemd looks for a SysV init script
+    by the same name (with the <filename>.service</filename> suffix
+    removed) and dynamically creates a service unit from that script.
+    This is useful for compatibility with SysV. Note that this
+    compatibility is quite comprehensive but not 100%. For details
+    about the incompatibilities, see the <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
+    with SysV</ulink> document.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Services with <varname>Type=dbus</varname> set automatically
+    acquire dependencies of type <varname>Requires=</varname> and
+    <varname>After=</varname> on
+    <filename>dbus.socket</filename>.</para>
+
+    <para>Socket activated service are automatically ordered after
+    their activated <filename>.socket</filename> units via an
+    automatic <varname>After=</varname> dependency.</para>
+
+    <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> is set to
+    <option>false</option>, service units will implicitly have dependencies of type <varname>Requires=</varname> and
+    <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
+    <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
+    <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
+    basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
+    boot or late system shutdown should disable this option.</para>
+
+    <para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
+    default a per-template slice unit (see
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
+    template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
+    together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
+    template unit, and either define your own per-template slice unit file that also sets
+    <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
+    in the template unit. Also see
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Additional implicit dependencies may be added as result of
+    execution and resource control parameters as documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Service files must include a <literal>[Service]</literal>
+    section, which carries information about the service and the
+    process it supervises. A number of options that may be used in
+    this section are shared with other unit types. These options are
+    documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the <literal>[Service]</literal> section
+    of service units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+
+        <listitem><para>Configures the process start-up type for this
+        service unit. One of
+        <option>simple</option>,
+        <option>forking</option>,
+        <option>oneshot</option>,
+        <option>dbus</option>,
+        <option>notify</option> or
+        <option>idle</option>.</para>
+
+        <para>If set to <option>simple</option> (the default if
+        neither <varname>Type=</varname> nor
+        <varname>BusName=</varname>, but <varname>ExecStart=</varname>
+        are specified), it is expected that the process configured
+        with <varname>ExecStart=</varname> is the main process of the
+        service. In this mode, if the process offers functionality to
+        other processes on the system, its communication channels
+        should be installed before the daemon is started up (e.g.
+        sockets set up by systemd, via socket activation), as systemd
+        will immediately proceed starting follow-up units.</para>
+
+        <para>If set to <option>forking</option>, it is expected that
+        the process configured with <varname>ExecStart=</varname> will
+        call <function>fork()</function> as part of its start-up. The
+        parent process is expected to exit when start-up is complete
+        and all communication channels are set up. The child continues
+        to run as the main daemon process. This is the behavior of
+        traditional UNIX daemons. If this setting is used, it is
+        recommended to also use the <varname>PIDFile=</varname>
+        option, so that systemd can identify the main process of the
+        daemon. systemd will proceed with starting follow-up units as
+        soon as the parent process exits.</para>
+
+        <para>Behavior of <option>oneshot</option> is similar to
+        <option>simple</option>; however, it is expected that the
+        process has to exit before systemd starts follow-up units.
+        <varname>RemainAfterExit=</varname> is particularly useful for
+        this type of service. This is the implied default if neither
+        <varname>Type=</varname> or <varname>ExecStart=</varname> are
+        specified.</para>
+
+        <para>Behavior of <option>dbus</option> is similar to
+        <option>simple</option>; however, it is expected that the
+        daemon acquires a name on the D-Bus bus, as configured by
+        <varname>BusName=</varname>. systemd will proceed with
+        starting follow-up units after the D-Bus bus name has been
+        acquired. Service units with this option configured implicitly
+        gain dependencies on the <filename>dbus.socket</filename>
+        unit. This type is the default if <varname>BusName=</varname>
+        is specified.</para>
+
+        <para>Behavior of <option>notify</option> is similar to
+        <option>simple</option>; however, it is expected that the
+        daemon sends a notification message via
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        or an equivalent call when it has finished starting up.
+        systemd will proceed with starting follow-up units after this
+        notification message has been sent. If this option is used,
+        <varname>NotifyAccess=</varname> (see below) should be set to
+        open access to the notification socket provided by systemd. If
+        <varname>NotifyAccess=</varname> is not set, it will be
+        implicitly set to <option>main</option>. Note that currently
+        <varname>Type=</varname><option>notify</option> will not work
+        if used in combination with
+        <varname>PrivateNetwork=</varname><option>yes</option>.</para>
+
+        <para>Behavior of <option>idle</option> is very similar to
+        <option>simple</option>; however, actual execution of the
+        service binary is delayed until all jobs are dispatched. This
+        may be used to avoid interleaving of output of shell services
+        with the status output on the console.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemainAfterExit=</varname></term>
+
+        <listitem><para>Takes a boolean value that specifies whether
+        the service shall be considered active even when all its
+        processes exited. Defaults to <option>no</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>GuessMainPID=</varname></term>
+
+        <listitem><para>Takes a boolean value that specifies whether
+        systemd should try to guess the main PID of a service if it
+        cannot be determined reliably. This option is ignored unless
+        <option>Type=forking</option> is set and
+        <option>PIDFile=</option> is unset because for the other types
+        or with an explicitly configured PID file, the main PID is
+        always known. The guessing algorithm might come to incorrect
+        conclusions if a daemon consists of more than one process. If
+        the main PID cannot be determined, failure detection and
+        automatic restarting of a service will not work reliably.
+        Defaults to <option>yes</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PIDFile=</varname></term>
+
+        <listitem><para>Takes an absolute file name pointing to the
+        PID file of this daemon. Use of this option is recommended for
+        services where <varname>Type=</varname> is set to
+        <option>forking</option>. systemd will read the PID of the
+        main process of the daemon after start-up of the service.
+        systemd will not write to the file configured here, although
+        it will remove the file after the service has shut down if it
+        still exists.
+        </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BusName=</varname></term>
+
+        <listitem><para>Takes a D-Bus bus name that this service is
+        reachable as. This option is mandatory for services where
+        <varname>Type=</varname> is set to
+        <option>dbus</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStart=</varname></term>
+        <listitem><para>Commands with their arguments that are
+        executed when this service is started. The value is split into
+        zero or more command lines according to the rules described
+        below (see section "Command Lines" below).
+        </para>
+
+        <para>When <varname>Type=</varname> is not
+        <option>oneshot</option>, only one command may and must be
+        given. When <varname>Type=oneshot</varname> is used, zero or
+        more commands may be specified. This can be specified by
+        providing multiple command lines in the same directive, or
+        alternatively, this directive may be specified more than once
+        with the same effect. If the empty string is assigned to this
+        option, the list of commands to start is reset, prior
+        assignments of this option will have no effect. If no
+        <varname>ExecStart=</varname> is specified, then the service
+        must have <varname>RemainAfterExit=yes</varname> set.</para>
+
+        <para>For each of the specified commands, the first argument
+        must be an absolute path to an executable. Optionally, if this
+        file name is prefixed with <literal>@</literal>, the second
+        token will be passed as <literal>argv[0]</literal> to the
+        executed process, followed by the further arguments specified.
+        If the absolute filename is prefixed with
+        <literal>-</literal>, an exit code of the command normally
+        considered a failure (i.e. non-zero exit status or abnormal
+        exit due to signal) is ignored and considered success. If both
+        <literal>-</literal> and <literal>@</literal> are used, they
+        can appear in either order.</para>
+
+        <para>If more than one command is specified, the commands are
+        invoked sequentially in the order they appear in the unit
+        file. If one of the commands fails (and is not prefixed with
+        <literal>-</literal>), other lines are not executed, and the
+        unit is considered failed.</para>
+
+        <para>Unless <varname>Type=forking</varname> is set, the
+        process started via this command line will be considered the
+        main process of the daemon.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStartPre=</varname></term>
+        <term><varname>ExecStartPost=</varname></term>
+        <listitem><para>Additional commands that are executed before
+        or after the command in <varname>ExecStart=</varname>,
+        respectively. Syntax is the same as for
+        <varname>ExecStart=</varname>, except that multiple command
+        lines are allowed and the commands are executed one after the
+        other, serially.</para>
+
+        <para>If any of those commands (not prefixed with
+        <literal>-</literal>) fail, the rest are not executed and the
+        unit is considered failed.</para>
+
+        <para><varname>ExecStart=</varname> commands are only run after
+        all <varname>ExecStartPre=</varname> commands that were not prefixed
+        with a <literal>-</literal> exit successfully.</para>
+
+        <para><varname>ExecStartPost=</varname> commands are only run after
+        the service has started successfully, as determined by <varname>Type=</varname>
+        (i.e. the process has been started for <varname>Type=simple</varname>
+        or <varname>Type=idle</varname>, the process exits successfully for
+        <varname>Type=oneshot</varname>, the initial process exits successfully
+        for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent
+        for <varname>Type=notify</varname>, or the <varname>BusName=</varname>
+        has been taken for <varname>Type=dbus</varname>).</para>
+
+        <para>Note that <varname>ExecStartPre=</varname> may not be
+        used to start long-running processes. All processes forked
+        off by processes invoked via <varname>ExecStartPre=</varname> will
+        be killed before the next service process is run.</para>
+
+        <para>Note that if any of the commands specified in <varname>ExecStartPre=</varname>,
+        <varname>ExecStart=</varname>, or <varname>ExecStartPost=</varname> fail (and are not prefixed with
+        <literal>-</literal>, see above) or time out before the service is fully up, execution continues with commands
+        specified in <varname>ExecStopPost=</varname>, the commands in <varname>ExecStop=</varname> are skipped.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecReload=</varname></term>
+        <listitem><para>Commands to execute to trigger a configuration
+        reload in the service. This argument takes multiple command
+        lines, following the same scheme as described for
+        <varname>ExecStart=</varname> above. Use of this setting is
+        optional. Specifier and environment variable substitution is
+        supported here following the same scheme as for
+        <varname>ExecStart=</varname>.</para>
+
+        <para>One additional, special environment variable is set: if
+        known, <varname>$MAINPID</varname> is set to the main process
+        of the daemon, and may be used for command lines like the
+        following:</para>
+
+        <programlisting>/bin/kill -HUP $MAINPID</programlisting>
+
+        <para>Note however that reloading a daemon by sending a signal
+        (as with the example line above) is usually not a good choice,
+        because this is an asynchronous operation and hence not
+        suitable to order reloads of multiple services against each
+        other. It is strongly recommended to set
+        <varname>ExecReload=</varname> to a command that not only
+        triggers a configuration reload of the daemon, but also
+        synchronously waits for it to complete.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStop=</varname></term>
+        <listitem><para>Commands to execute to stop the service
+        started via <varname>ExecStart=</varname>. This argument takes
+        multiple command lines, following the same scheme as described
+        for <varname>ExecStart=</varname> above. Use of this setting
+        is optional. After the commands configured in this option are
+        run, all processes remaining for a service are terminated
+        according to the <varname>KillMode=</varname> setting (see
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        If this option is not specified, the process is terminated by
+        sending the signal specified in <varname>KillSignal=</varname>
+        when service stop is requested. Specifier and environment
+        variable substitution is supported (including
+        <varname>$MAINPID</varname>, see above).</para>
+
+        <para>Note that it is usually not sufficient to specify a
+        command for this setting that only asks the service to
+        terminate (for example, by queuing some form of termination
+        signal for it), but does not wait for it to do so. Since the
+        remaining processes of the services are killed using
+        <constant>SIGKILL</constant> immediately after the command
+        exited, this would not result in a clean stop. The specified
+        command should hence be a synchronous operation, not an
+        asynchronous one.</para>
+
+        <para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service
+        started successfully first. They are not invoked if the service was never started at all, or in case its
+        start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
+        <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
+        <literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
+        service failed to start up correctly and is shut down again.</para>
+
+        <para>It is recommended to use this setting for commands that communicate with the service requesting clean
+        termination. When the commands specified with this option are executed it should be assumed that the service is
+        still fully up and is able to react correctly to all commands. For post-mortem clean-up steps use
+        <varname>ExecStopPost=</varname> instead.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStopPost=</varname></term>
+        <listitem><para>Additional commands that are executed after the service is stopped. This includes cases where
+        the commands configured in <varname>ExecStop=</varname> were used, where the service does not have any
+        <varname>ExecStop=</varname> defined, or where the service exited unexpectedly. This argument takes multiple
+        command lines, following the same scheme as described for <varname>ExecStart=</varname>. Use of these settings
+        is optional. Specifier and environment variable substitution is supported. Note that – unlike
+        <varname>ExecStop=</varname> – commands specified with this setting are invoked when a service failed to start
+        up correctly and is shut down again.</para>
+
+        <para>It is recommended to use this setting for clean-up operations that shall be executed even when the
+        service failed to start up correctly. Commands configured with this setting need to be able to operate even if
+        the service failed starting up half-way and left incompletely initialized data around. As the service's
+        processes have been terminated already when the commands specified with this setting are executed they should
+        not attempt to communicate with them.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartSec=</varname></term>
+        <listitem><para>Configures the time to sleep before restarting
+        a service (as configured with <varname>Restart=</varname>).
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Defaults to 100ms.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutStartSec=</varname></term>
+        <listitem><para>Configures the time to wait for start-up. If a
+        daemon service does not signal start-up completion within the
+        configured time, the service will be considered failed and
+        will be shut down again. Takes a unit-less value in seconds,
+        or a time span value such as "5min 20s". Pass
+        <literal>infinity</literal> to disable the timeout logic. Defaults to
+        <varname>DefaultTimeoutStartSec=</varname> from the manager
+        configuration file, except when
+        <varname>Type=oneshot</varname> is used, in which case the
+        timeout is disabled by default (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutStopSec=</varname></term>
+        <listitem><para>Configures the time to wait for stop. If a
+        service is asked to stop, but does not terminate in the
+        specified time, it will be terminated forcibly via
+        <constant>SIGTERM</constant>, and after another timeout of
+        equal duration with <constant>SIGKILL</constant> (see
+        <varname>KillMode=</varname> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass <literal>infinity</literal> to disable the
+        timeout logic. Defaults to
+        <varname>DefaultTimeoutStopSec=</varname> from the manager
+        configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>A shorthand for configuring both
+        <varname>TimeoutStartSec=</varname> and
+        <varname>TimeoutStopSec=</varname> to the specified value.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeMaxSec=</varname></term>
+
+        <listitem><para>Configures a maximum time for the service to run. If this is used and the service has been
+        active for longer than the specified time it is terminated and put into a failure state. Note that this setting
+        does not have any effect on <varname>Type=oneshot</varname> services, as they terminate immediately after
+        activation completed. Pass <literal>infinity</literal> (the default) to configure no runtime
+        limit.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WatchdogSec=</varname></term>
+        <listitem><para>Configures the watchdog timeout for a service.
+        The watchdog is activated when the start-up is completed. The
+        service must call
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        regularly with <literal>WATCHDOG=1</literal> (i.e. the
+        "keep-alive ping"). If the time between two such calls is
+        larger than the configured time, then the service is placed in
+        a failed state and it will be terminated with
+        <constant>SIGABRT</constant>. By setting
+        <varname>Restart=</varname> to <option>on-failure</option>,
+        <option>on-watchdog</option>, <option>on-abnormal</option> or
+        <option>always</option>, the service will be automatically
+        restarted. The time configured here will be passed to the
+        executed service process in the
+        <varname>WATCHDOG_USEC=</varname> environment variable. This
+        allows daemons to automatically enable the keep-alive pinging
+        logic if watchdog support is enabled for the service. If this
+        option is used, <varname>NotifyAccess=</varname> (see below)
+        should be set to open access to the notification socket
+        provided by systemd. If <varname>NotifyAccess=</varname> is
+        not set, it will be implicitly set to <option>main</option>.
+        Defaults to 0, which disables this feature. The service can
+        check whether the service manager expects watchdog keep-alive
+        notifications. See
+        <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.
+        <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        may be used to enable automatic watchdog notification support.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Restart=</varname></term>
+        <listitem><para>Configures whether the service shall be
+        restarted when the service process exits, is killed, or a
+        timeout is reached. The service process may be the main
+        service process, but it may also be one of the processes
+        specified with <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>,
+        <varname>ExecStop=</varname>,
+        <varname>ExecStopPost=</varname>, or
+        <varname>ExecReload=</varname>. When the death of the process
+        is a result of systemd operation (e.g. service stop or
+        restart), the service will not be restarted. Timeouts include
+        missing the watchdog "keep-alive ping" deadline and a service
+        start, reload, and stop operation timeouts.</para>
+
+        <para>Takes one of
+        <option>no</option>,
+        <option>on-success</option>,
+        <option>on-failure</option>,
+        <option>on-abnormal</option>,
+        <option>on-watchdog</option>,
+        <option>on-abort</option>, or
+        <option>always</option>.
+        If set to <option>no</option> (the default), the service will
+        not be restarted. If set to <option>on-success</option>, it
+        will be restarted only when the service process exits cleanly.
+        In this context, a clean exit means an exit code of 0, or one
+        of the signals
+        <constant>SIGHUP</constant>,
+        <constant>SIGINT</constant>,
+        <constant>SIGTERM</constant> or
+        <constant>SIGPIPE</constant>, and
+        additionally, exit statuses and signals specified in
+        <varname>SuccessExitStatus=</varname>. If set to
+        <option>on-failure</option>, the service will be restarted
+        when the process exits with a non-zero exit code, is
+        terminated by a signal (including on core dump, but excluding
+        the aforementioned four signals), when an operation (such as
+        service reload) times out, and when the configured watchdog
+        timeout is triggered. If set to <option>on-abnormal</option>,
+        the service will be restarted when the process is terminated
+        by a signal (including on core dump, excluding the
+        aforementioned four signals), when an operation times out, or
+        when the watchdog timeout is triggered. If set to
+        <option>on-abort</option>, the service will be restarted only
+        if the service process exits due to an uncaught signal not
+        specified as a clean exit status. If set to
+        <option>on-watchdog</option>, the service will be restarted
+        only if the watchdog timeout for the service expires. If set
+        to <option>always</option>, the service will be restarted
+        regardless of whether it exited cleanly or not, got terminated
+        abnormally by a signal, or hit a timeout.</para>
+
+        <table>
+          <title>Exit causes and the effect of the <varname>Restart=</varname> settings on them</title>
+
+          <tgroup cols='2'>
+            <colspec colname='path' />
+            <colspec colname='expl' />
+            <thead>
+              <row>
+                <entry>Restart settings/Exit causes</entry>
+                <entry><option>no</option></entry>
+                <entry><option>always</option></entry>
+                <entry><option>on-success</option></entry>
+                <entry><option>on-failure</option></entry>
+                <entry><option>on-abnormal</option></entry>
+                <entry><option>on-abort</option></entry>
+                <entry><option>on-watchdog</option></entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>Clean exit code or signal</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+                <entry/>
+                <entry/>
+                <entry/>
+              </row>
+              <row>
+                <entry>Unclean exit code</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry/>
+                <entry/>
+              </row>
+              <row>
+                <entry>Unclean signal</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+              </row>
+              <row>
+                <entry>Timeout</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+                <entry/>
+              </row>
+              <row>
+                <entry>Watchdog</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>As exceptions to the setting above, the service will not
+        be restarted if the exit code or signal is specified in
+        <varname>RestartPreventExitStatus=</varname> (see below).
+        Also, the services will always be restarted if the exit code
+        or signal is specified in
+        <varname>RestartForceExitStatus=</varname> (see below).</para>
+
+        <para>Setting this to <option>on-failure</option> is the
+        recommended choice for long-running services, in order to
+        increase reliability by attempting automatic recovery from
+        errors. For services that shall be able to terminate on their
+        own choice (and avoid immediate restarting),
+        <option>on-abnormal</option> is an alternative choice.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuccessExitStatus=</varname></term>
+        <listitem><para>Takes a list of exit status definitions that,
+        when returned by the main service process, will be considered
+        successful termination, in addition to the normal successful
+        exit code 0 and the signals <constant>SIGHUP</constant>,
+        <constant>SIGINT</constant>, <constant>SIGTERM</constant>, and
+        <constant>SIGPIPE</constant>. Exit status definitions can
+        either be numeric exit codes or termination signal names,
+        separated by spaces. For example:
+
+        <programlisting>SuccessExitStatus=1 2 8 SIGKILL</programlisting>
+
+        ensures that exit codes 1, 2, 8 and
+        the termination signal <constant>SIGKILL</constant> are
+        considered clean service terminations.
+        </para>
+
+        <para>Note that if a process has a signal handler installed
+        and exits by calling
+        <citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        in response to a signal, the information about the signal is
+        lost. Programs should instead perform cleanup and kill
+        themselves with the same signal instead. See
+        <ulink url="http://www.cons.org/cracauer/sigint.html">Proper
+        handling of SIGINT/SIGQUIT — How to be a proper
+        program</ulink>.</para>
+
+        <para>This option may appear more than once, in which case the
+        list of successful exit statuses is merged. If the empty
+        string is assigned to this option, the list is reset, all
+        prior assignments of this option will have no
+        effect.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartPreventExitStatus=</varname></term>
+        <listitem><para>Takes a list of exit status definitions that,
+        when returned by the main service process, will prevent
+        automatic service restarts, regardless of the restart setting
+        configured with <varname>Restart=</varname>. Exit status
+        definitions can either be numeric exit codes or termination
+        signal names, and are separated by spaces. Defaults to the
+        empty list, so that, by default, no exit status is excluded
+        from the configured restart logic. For example:
+
+        <programlisting>RestartPreventExitStatus=1 6 SIGABRT</programlisting>
+
+        ensures that exit codes 1 and 6 and the termination signal
+        <constant>SIGABRT</constant> will not result in automatic
+        service restarting. This option may appear more than once, in
+        which case the list of restart-preventing statuses is
+        merged. If the empty string is assigned to this option, the
+        list is reset and all prior assignments of this option will
+        have no effect.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartForceExitStatus=</varname></term>
+        <listitem><para>Takes a list of exit status definitions that,
+        when returned by the main service process, will force automatic
+        service restarts, regardless of the restart setting configured
+        with <varname>Restart=</varname>. The argument format is
+        similar to
+        <varname>RestartPreventExitStatus=</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PermissionsStartOnly=</varname></term>
+        <listitem><para>Takes a boolean argument. If true, the
+        permission-related execution options, as configured with
+        <varname>User=</varname> and similar options (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information), are only applied to the process started
+        with
+        <varname>ExecStart=</varname>, and not to the various other
+        <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>,
+        <varname>ExecReload=</varname>,
+        <varname>ExecStop=</varname>, and
+        <varname>ExecStopPost=</varname>
+        commands. If false, the setting is applied to all configured
+        commands the same way. Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootDirectoryStartOnly=</varname></term>
+        <listitem><para>Takes a boolean argument. If true, the root
+        directory, as configured with the
+        <varname>RootDirectory=</varname> option (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information), is only applied to the process started
+        with <varname>ExecStart=</varname>, and not to the various
+        other <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>,
+        <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
+        and <varname>ExecStopPost=</varname> commands. If false, the
+        setting is applied to all configured commands the same way.
+        Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NonBlocking=</varname></term>
+        <listitem><para>Set the <constant>O_NONBLOCK</constant> flag
+        for all file descriptors passed via socket-based activation.
+        If true, all file descriptors >= 3 (i.e. all except stdin,
+        stdout, and stderr) will have the
+        <constant>O_NONBLOCK</constant> flag set and hence are in
+        non-blocking mode. This option is only useful in conjunction
+        with a socket unit, as described in
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NotifyAccess=</varname></term>
+        <listitem><para>Controls access to the service status
+        notification socket, as accessible via the
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        call. Takes one of <option>none</option> (the default),
+        <option>main</option> or <option>all</option>. If
+        <option>none</option>, no daemon status updates are accepted
+        from the service processes, all status update messages are
+        ignored. If <option>main</option>, only service updates sent
+        from the main process of the service are accepted. If
+        <option>all</option>, all services updates from all members of
+        the service's control group are accepted. This option should
+        be set to open access to the notification socket when using
+        <varname>Type=notify</varname> or
+        <varname>WatchdogSec=</varname> (see above). If those options
+        are used but <varname>NotifyAccess=</varname> is not
+        configured, it will be implicitly set to
+        <option>main</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Sockets=</varname></term>
+        <listitem><para>Specifies the name of the socket units this
+        service shall inherit socket file descriptors from when the
+        service is started. Normally, it should not be necessary to use
+        this setting, as all socket file descriptors whose unit shares
+        the same name as the service (subject to the different unit
+        name suffix of course) are passed to the spawned
+        process.</para>
+
+        <para>Note that the same socket file descriptors may be passed
+        to multiple processes simultaneously. Also note that a
+        different service may be activated on incoming socket traffic
+        than the one which is ultimately configured to inherit the
+        socket file descriptors. Or, in other words: the
+        <varname>Service=</varname> setting of
+        <filename>.socket</filename> units does not have to match the
+        inverse of the <varname>Sockets=</varname> setting of the
+        <filename>.service</filename> it refers to.</para>
+
+        <para>This option may appear more than once, in which case the
+        list of socket units is merged. If the empty string is
+        assigned to this option, the list of sockets is reset, and all
+        prior uses of this setting will have no
+        effect.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FailureAction=</varname></term>
+        <listitem><para>Configure the action to take when the service enters a failed state. Takes the same values as
+        the unit setting <varname>StartLimitAction=</varname> and executes the same actions (see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Defaults to
+        <option>none</option>. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FileDescriptorStoreMax=</varname></term>
+        <listitem><para>Configure how many file descriptors may be
+        stored in the service manager for the service using
+        <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
+        <literal>FDSTORE=1</literal> messages. This is useful for
+        implementing service restart schemes where the state is
+        serialized to <filename>/run</filename> and the file
+        descriptors passed to the service manager, to allow restarts
+        without losing state. Defaults to 0, i.e. no file descriptors
+        may be stored in the service manager by default. All file
+        descriptors passed to the service manager from a specific
+        service are passed back to the service's main process on the
+        next service restart. Any file descriptors passed to the
+        service manager are automatically closed when POLLHUP or
+        POLLERR is seen on them, or when the service is fully stopped
+        and no job queued or being executed for it.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>USBFunctionDescriptors=</varname></term>
+        <listitem><para>Configure the location of a file containing
+        <ulink
+        url="https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB
+        FunctionFS</ulink> descriptors, for implementation of USB
+        gadget functions. This is used only in conjunction with a
+        socket unit with <varname>ListenUSBFunction=</varname>
+        configured. The contents of this file are written to the
+        <filename>ep0</filename> file after it is
+        opened.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>USBFunctionStrings=</varname></term>
+        <listitem><para>Configure the location of a file containing
+        USB FunctionFS strings.  Behavior is similar to
+        <varname>USBFunctionDescriptors=</varname>
+        above.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>Check
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more settings.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Command lines</title>
+
+    <para>This section describes command line parsing and
+    variable and specifier substitutions for
+    <varname>ExecStart=</varname>,
+    <varname>ExecStartPre=</varname>,
+    <varname>ExecStartPost=</varname>,
+    <varname>ExecReload=</varname>,
+    <varname>ExecStop=</varname>, and
+    <varname>ExecStopPost=</varname> options.</para>
+
+    <para>Multiple command lines may be concatenated in a single
+    directive by separating them with semicolons (these semicolons
+    must be passed as separate words). Lone semicolons may be escaped
+    as <literal>\;</literal>.</para>
+
+    <para>Each command line is split on whitespace, with the first
+    item being the command to execute, and the subsequent items being
+    the arguments. Double quotes ("...") and single quotes ('...') may
+    be used, in which case everything until the next matching quote
+    becomes part of the same argument. C-style escapes are also
+    supported. The table below contains the list of allowed escape
+    patterns. Only patterns which match the syntax in the table are
+    allowed; others will result in an error, and must be escaped by
+    doubling the backslash. Quotes themselves are removed after
+    parsing and escape sequences substituted. In addition, a trailing
+    backslash (<literal>\</literal>) may be used to merge lines.
+    </para>
+
+    <para>This syntax is intended to be very similar to shell syntax,
+    but only the meta-characters and expansions described in the
+    following paragraphs are understood. Specifically, redirection
+    using
+    <literal>&lt;</literal>,
+    <literal>&lt;&lt;</literal>,
+    <literal>&gt;</literal>, and
+    <literal>&gt;&gt;</literal>, pipes using
+    <literal>|</literal>, running programs in the background using
+    <literal>&amp;</literal>, and <emphasis>other elements of shell
+    syntax are not supported</emphasis>.</para>
+
+    <para>The command to execute must be an absolute path name. It may
+    contain spaces, but control characters are not allowed.</para>
+
+    <para>The command line accepts <literal>%</literal> specifiers as
+    described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    Note that the first argument of the command line (i.e. the program
+    to execute) may not include specifiers.</para>
+
+    <para>Basic environment variable substitution is supported. Use
+    <literal>${FOO}</literal> as part of a word, or as a word of its
+    own, on the command line, in which case it will be replaced by the
+    value of the environment variable including all whitespace it
+    contains, resulting in a single argument. Use
+    <literal>$FOO</literal> as a separate word on the command line, in
+    which case it will be replaced by the value of the environment
+    variable split at whitespace, resulting in zero or more arguments.
+    For this type of expansion, quotes are respected when splitting
+    into words, and afterwards removed.</para>
+
+    <para>Example:</para>
+
+    <programlisting>Environment="ONE=one" 'TWO=two two'
+ExecStart=/bin/echo $ONE $TWO ${TWO}</programlisting>
+
+    <para>This will execute <command>/bin/echo</command> with four
+    arguments: <literal>one</literal>, <literal>two</literal>,
+    <literal>two</literal>, and <literal>two two</literal>.</para>
+
+    <para>Example:</para>
+    <programlisting>Environment=ONE='one' "TWO='two two' too" THREE=
+ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
+ExecStart=/bin/echo $ONE $TWO $THREE</programlisting>
+    <para>This results in <filename>echo</filename> being
+    called twice, the first time with arguments
+    <literal>'one'</literal>,
+    <literal>'two two' too</literal>, <literal></literal>,
+    and the second time with arguments
+    <literal>one</literal>, <literal>two two</literal>,
+    <literal>too</literal>.
+    </para>
+
+    <para>To pass a literal dollar sign, use <literal>$$</literal>.
+    Variables whose value is not known at expansion time are treated
+    as empty strings. Note that the first argument (i.e. the program
+    to execute) may not be a variable.</para>
+
+    <para>Variables to be used in this fashion may be defined through
+    <varname>Environment=</varname> and
+    <varname>EnvironmentFile=</varname>. In addition, variables listed
+    in the section "Environment variables in spawned processes" in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which are considered "static configuration", may be used (this
+    includes e.g. <varname>$USER</varname>, but not
+    <varname>$TERM</varname>).</para>
+
+    <para>Note that shell command lines are not directly supported. If
+    shell command lines are to be used, they need to be passed
+    explicitly to a shell implementation of some kind. Example:</para>
+    <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'</programlisting>
+
+    <para>Example:</para>
+
+    <programlisting>ExecStart=/bin/echo one ; /bin/echo "two two"</programlisting>
+
+    <para>This will execute <command>/bin/echo</command> two times,
+    each time with one argument: <literal>one</literal> and
+    <literal>two two</literal>, respectively. Because two commands are
+    specified, <varname>Type=oneshot</varname> must be used.</para>
+
+    <para>Example:</para>
+
+    <programlisting>ExecStart=/bin/echo / &gt;/dev/null &amp; \; \
+/bin/ls</programlisting>
+
+    <para>This will execute <command>/bin/echo</command>
+    with five arguments: <literal>/</literal>,
+    <literal>&gt;/dev/null</literal>,
+    <literal>&amp;</literal>, <literal>;</literal>, and
+    <literal>/bin/ls</literal>.</para>
+
+    <table>
+      <title>C escapes supported in command lines and environment variables</title>
+      <tgroup cols='2'>
+        <colspec colname='escape' />
+        <colspec colname='meaning' />
+        <thead>
+          <row>
+            <entry>Literal</entry>
+            <entry>Actual value</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><literal>\a</literal></entry>
+            <entry>bell</entry>
+          </row>
+          <row>
+            <entry><literal>\b</literal></entry>
+            <entry>backspace</entry>
+          </row>
+          <row>
+            <entry><literal>\f</literal></entry>
+            <entry>form feed</entry>
+          </row>
+          <row>
+            <entry><literal>\n</literal></entry>
+            <entry>newline</entry>
+          </row>
+          <row>
+            <entry><literal>\r</literal></entry>
+            <entry>carriage return</entry>
+          </row>
+          <row>
+            <entry><literal>\t</literal></entry>
+            <entry>tab</entry>
+          </row>
+          <row>
+            <entry><literal>\v</literal></entry>
+            <entry>vertical tab</entry>
+          </row>
+          <row>
+            <entry><literal>\\</literal></entry>
+            <entry>backslash</entry>
+          </row>
+          <row>
+            <entry><literal>\"</literal></entry>
+            <entry>double quotation mark</entry>
+          </row>
+          <row>
+            <entry><literal>\'</literal></entry>
+            <entry>single quotation mark</entry>
+          </row>
+          <row>
+            <entry><literal>\s</literal></entry>
+            <entry>space</entry>
+          </row>
+          <row>
+            <entry><literal>\x<replaceable>xx</replaceable></literal></entry>
+            <entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry>
+          </row>
+          <row>
+            <entry><literal>\<replaceable>nnn</replaceable></literal></entry>
+            <entry>character number <replaceable>nnn</replaceable> in octal encoding</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Simple service</title>
+
+      <para>The following unit file creates a service that will
+      execute <filename>/usr/sbin/foo-daemon</filename>. Since no
+      <varname>Type=</varname> is specified, the default
+      <varname>Type=</varname><option>simple</option> will be assumed.
+      systemd will assume the unit to be started immediately after the
+      program has begun executing.</para>
+
+      <programlisting>[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Note that systemd assumes here that the process started by
+      systemd will continue running until the service terminates. If
+      the program daemonizes itself (i.e. forks), please use
+      <varname>Type=</varname><option>forking</option> instead.</para>
+
+      <para>Since no <varname>ExecStop=</varname> was specified,
+      systemd will send SIGTERM to all processes started from this
+      service, and after a timeout also SIGKILL. This behavior can be
+      modified, see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details.</para>
+
+      <para>Note that this unit type does not include any type of
+      notification when a service has completed initialization. For
+      this, you should use other unit types, such as
+      <varname>Type=</varname><option>notify</option> if the service
+      understands systemd's notification protocol,
+      <varname>Type=</varname><option>forking</option> if the service
+      can background itself or
+      <varname>Type=</varname><option>dbus</option> if the unit
+      acquires a DBus name once initialization is complete. See
+      below.</para>
+    </example>
+
+    <example>
+      <title>Oneshot service</title>
+
+      <para>Sometimes, units should just execute an action without
+      keeping active processes, such as a filesystem check or a
+      cleanup action on boot. For this,
+      <varname>Type=</varname><option>oneshot</option> exists. Units
+      of this type will wait until the process specified terminates
+      and then fall back to being inactive. The following unit will
+      perform a cleanup action:</para>
+
+      <programlisting>[Unit]
+Description=Cleanup old Foo data
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/foo-cleanup
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Note that systemd will consider the unit to be in the
+      state "starting" until the program has terminated, so ordered
+      dependencies will wait for the program to finish before starting
+      themselves. The unit will revert to the "inactive" state after
+      the execution is done, never reaching the "active" state. That
+      means another request to start the unit will perform the action
+      again.</para>
+
+      <para><varname>Type=</varname><option>oneshot</option> are the
+      only service units that may have more than one
+      <varname>ExecStart=</varname> specified. They will be executed
+      in order until either they are all successful or one of them
+      fails.</para>
+    </example>
+
+    <example>
+      <title>Stoppable oneshot service</title>
+
+      <para>Similarly to the oneshot services, there are sometimes
+      units that need to execute a program to set up something and
+      then execute another to shut it down, but no process remains
+      active while they are considered "started". Network
+      configuration can sometimes fall into this category. Another use
+      case is if a oneshot service shall not be executed each time
+      when they are pulled in as a dependency, but only the first
+      time.</para>
+
+      <para>For this, systemd knows the setting
+      <varname>RemainAfterExit=</varname><option>yes</option>, which
+      causes systemd to consider the unit to be active if the start
+      action exited successfully. This directive can be used with all
+      types, but is most useful with
+      <varname>Type=</varname><option>oneshot</option> and
+      <varname>Type=</varname><option>simple</option>. With
+      <varname>Type=</varname><option>oneshot</option>, systemd waits
+      until the start action has completed before it considers the
+      unit to be active, so dependencies start only after the start
+      action has succeeded. With
+      <varname>Type=</varname><option>simple</option>, dependencies
+      will start immediately after the start action has been
+      dispatched. The following unit provides an example for a simple
+      static firewall.</para>
+
+      <programlisting>[Unit]
+Description=Simple firewall
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/usr/local/sbin/simple-firewall-start
+ExecStop=/usr/local/sbin/simple-firewall-stop
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Since the unit is considered to be running after the start
+      action has exited, invoking <command>systemctl start</command>
+      on that unit again will cause no action to be taken.</para>
+    </example>
+
+    <example>
+      <title>Traditional forking services</title>
+
+      <para>Many traditional daemons/services background (i.e. fork,
+      daemonize) themselves when starting. Set
+      <varname>Type=</varname><option>forking</option> in the
+      service's unit file to support this mode of operation. systemd
+      will consider the service to be in the process of initialization
+      while the original program is still running. Once it exits
+      successfully and at least a process remains (and
+      <varname>RemainAfterExit=</varname><option>no</option>), the
+      service is considered started.</para>
+
+      <para>Often, a traditional daemon only consists of one process.
+      Therefore, if only one process is left after the original
+      process terminates, systemd will consider that process the main
+      process of the service. In that case, the
+      <varname>$MAINPID</varname> variable will be available in
+      <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
+      etc.</para>
+
+      <para>In case more than one process remains, systemd will be
+      unable to determine the main process, so it will not assume
+      there is one. In that case, <varname>$MAINPID</varname> will not
+      expand to anything. However, if the process decides to write a
+      traditional PID file, systemd will be able to read the main PID
+      from there. Please set <varname>PIDFile=</varname> accordingly.
+      Note that the daemon should write that file before finishing
+      with its initialization. Otherwise, systemd might try to read the
+      file before it exists.</para>
+
+      <para>The following example shows a simple daemon that forks and
+      just starts one process in the background:</para>
+
+      <programlisting>[Unit]
+Description=Some simple daemon
+
+[Service]
+Type=forking
+ExecStart=/usr/sbin/my-simple-daemon -d
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Please see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details on how you can influence the way systemd terminates
+      the service.</para>
+    </example>
+
+    <example>
+      <title>DBus services</title>
+
+      <para>For services that acquire a name on the DBus system bus,
+      use <varname>Type=</varname><option>dbus</option> and set
+      <varname>BusName=</varname> accordingly. The service should not
+      fork (daemonize). systemd will consider the service to be
+      initialized once the name has been acquired on the system bus.
+      The following example shows a typical DBus service:</para>
+
+      <programlisting>[Unit]
+Description=Simple DBus service
+
+[Service]
+Type=dbus
+BusName=org.example.simple-dbus-service
+ExecStart=/usr/sbin/simple-dbus-service
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>For <emphasis>bus-activatable</emphasis> services, do not
+      include a <literal>[Install]</literal> section in the systemd
+      service file, but use the <varname>SystemdService=</varname>
+      option in the corresponding DBus service file, for example
+      (<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para>
+
+      <programlisting>[D-BUS Service]
+Name=org.example.simple-dbus-service
+Exec=/usr/sbin/simple-dbus-service
+User=root
+SystemdService=simple-dbus-service.service</programlisting>
+
+      <para>Please see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details on how you can influence the way systemd terminates
+      the service.</para>
+    </example>
+
+    <example>
+      <title>Services that notify systemd about their initialization</title>
+
+      <para><varname>Type=</varname><option>simple</option> services
+      are really easy to write, but have the major disadvantage of
+      systemd not being able to tell when initialization of the given
+      service is complete. For this reason, systemd supports a simple
+      notification protocol that allows daemons to make systemd aware
+      that they are done initializing. Use
+      <varname>Type=</varname><option>notify</option> for this. A
+      typical service file for such a daemon would look like
+      this:</para>
+
+      <programlisting>[Unit]
+Description=Simple notifying service
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/simple-notifying-service
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Note that the daemon has to support systemd's notification
+      protocol, else systemd will think the service has not started yet
+      and kill it after a timeout. For an example of how to update
+      daemons to support this protocol transparently, take a look at
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      systemd will consider the unit to be in the 'starting' state
+      until a readiness notification has arrived.</para>
+
+      <para>Please see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details on how you can influence the way systemd terminates
+      the service.</para>
+    </example>
+  </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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.slice.xml b/src/grp-system/systemd/systemd.slice.xml
new file mode 100644
index 0000000000..eee98d99ee
--- /dev/null
+++ b/src/grp-system/systemd/systemd.slice.xml
@@ -0,0 +1,132 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2013 Zbigniew Jędrzejewski-Szmek
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.slice">
+  <refentryinfo>
+    <title>systemd.slice</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.slice</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.slice</refname>
+    <refpurpose>Slice unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>slice</replaceable>.slice</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.slice</literal> encodes information about a slice which
+    is a concept for hierarchically managing resources of a group of
+    processes. This management is performed by creating a node in the
+    Linux Control Group (cgroup) tree. Units that manage processes
+    (primarily scope and service units) may be assigned to a specific
+    slice. For each slice, certain resource limits may be set that
+    apply to all processes of all units contained in that
+    slice. Slices are organized hierarchically in a tree. The name of
+    the slice encodes the location in the tree. The name consists of a
+    dash-separated series of names, which describes the path to the
+    slice from the root slice. The root slice is named,
+    <filename>-.slice</filename>. Example:
+    <filename>foo-bar.slice</filename> is a slice that is located
+    within <filename>foo.slice</filename>, which in turn is located in
+    the root slice <filename>-.slice</filename>.
+    </para>
+
+    <para>Note that slice units cannot be templated, nor is possible to add multiple names to a slice unit by creating
+    additional symlinks to it.</para>
+
+    <para>By default, service and scope units are placed in
+    <filename>system.slice</filename>, virtual machines and containers
+    registered with
+    <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    are found in <filename>machine.slice</filename>, and user sessions
+    handled by
+    <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    in <filename>user.slice</filename>. See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration
+    files. The common configuration items are configured
+    in the generic [Unit] and [Install] sections. The
+    slice specific configuration options are configured in
+    the [Slice] section. Currently, only generic resource control settings
+    as described in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> are allowed.
+    </para>
+
+    <para>See the <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
+    Control Group Interfaces</ulink> for an introduction on how to make
+    use of slice units from programs.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Slice units automatically gain dependencies of type
+    <varname>After=</varname> and <varname>Requires=</varname> on
+    their immediate parent slice unit.</para>
+
+    <para>Unless <varname>DefaultDependencies=false</varname> is used in the <literal>[Unit]</literal> section, slice
+    units will implicitly have dependencies of type <varname>Conflicts=</varname> and <varname>Before=</varname> on
+    <filename>shutdown.target</filename>. These ensure that slice units are removed prior to system shutdown. Only
+    slice units involved with early boot or late system shutdown should disable this option.
+    </para>
+  </refsect1>
+
+  <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.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.socket.xml b/src/grp-system/systemd/systemd.socket.xml
new file mode 100644
index 0000000000..5bf54d8ef3
--- /dev/null
+++ b/src/grp-system/systemd/systemd.socket.xml
@@ -0,0 +1,860 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.socket">
+  <refentryinfo>
+    <title>systemd.socket</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.socket</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.socket</refname>
+    <refpurpose>Socket unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>socket</replaceable>.socket</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.socket</literal> encodes information about an IPC or
+    network socket or a file system FIFO controlled and supervised by
+    systemd, for socket-based activation.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The socket specific configuration options are
+    configured in the [Socket] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the
+    <option>ExecStartPre=</option>, <option>ExecStartPost=</option>,
+    <option>ExecStopPre=</option> and <option>ExecStopPost=</option>
+    commands are executed in, and in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way the processes are terminated, and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for the processes of the
+    socket.</para>
+
+    <para>For each socket file, a matching service file must exist,
+    describing the service to start on incoming traffic on the socket
+    (see
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about .service files). The name of the
+    .service unit is by default the same as the name of the .socket
+    unit, but can be altered with the <option>Service=</option> option
+    described below. Depending on the setting of the
+    <option>Accept=</option> option described below, this .service
+    unit must either be named like the .socket unit, but with the
+    suffix replaced, unless overridden with <option>Service=</option>;
+    or it must be a template unit named the same way. Example: a
+    socket file <filename>foo.socket</filename> needs a matching
+    service <filename>foo.service</filename> if
+    <option>Accept=false</option> is set. If
+    <option>Accept=true</option> is set, a service template file
+    <filename>foo@.service</filename> must exist from which services
+    are instantiated for each incoming connection.</para>
+
+    <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section is set to
+    <option>false</option>, socket units will implicitly have dependencies of type <varname>Requires=</varname> and
+    <varname>After=</varname> on <filename>sysinit.target</filename> as well as dependencies of type
+    <varname>Conflicts=</varname> and <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure
+    that socket units pull in basic system initialization, and are terminated cleanly prior to system shutdown. Only
+    sockets involved with early boot or late system shutdown should disable this option.</para>
+
+    <para>Socket units will have a <varname>Before=</varname>
+    dependency on the service which they trigger added implicitly. No
+    implicit <varname>WantedBy=</varname> or
+    <varname>RequiredBy=</varname> dependency from the socket to the
+    service is added. This means that the service may be started
+    without the socket, in which case it must be able to open sockets
+    by itself. To prevent this, an explicit
+    <varname>Requires=</varname> dependency may be added.</para>
+
+    <para>Socket units may be used to implement on-demand starting of
+    services, as well as parallelized starting of services. See the
+    blog stories linked at the end for an introduction.</para>
+
+    <para>Note that the daemon software configured for socket
+    activation with socket units needs to be able to accept sockets
+    from systemd, either via systemd's native socket passing interface
+    (see
+    <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for details) or via the traditional
+    <citerefentry project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>-style
+    socket passing (i.e. sockets passed in via standard input and
+    output, using <varname>StandardInput=socket</varname> in the
+    service file).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Socket units automatically gain a <varname>Before=</varname>
+    dependency on the service units they activate.</para>
+
+    <para>Socket units referring to file system paths (such as AF_UNIX
+    sockets or FIFOs) implicitly gain <varname>Requires=</varname> and
+    <varname>After=</varname> dependencies on all mount units
+    necessary to access those paths.</para>
+
+    <para>Socket units using the <varname>BindToDevice=</varname>
+    setting automatically gain a <varname>BindsTo=</varname> and
+    <varname>After=</varname> dependency on the device unit
+    encapsulating the specified network interface.</para>
+
+    <para>If <varname>DefaultDependencies=yes</varname> is set (the
+    default), socket units automatically gain a
+    <varname>Before=</varname> dependency on
+    <filename>sockets.target</filename>. They also gain a pair of
+    <varname>After=</varname> and <varname>Requires=</varname>
+    dependency on <filename>sysinit.target</filename>, and a pair of
+    <varname>Before=</varname> and <varname>Conflicts=</varname>
+    dependencies on <filename>shutdown.target</filename>. These
+    dependencies ensure that the socket unit is started before normal
+    services at boot, and is stopped on shutdown.</para>
+
+    <para>Additional implicit dependencies may be added as result of
+    execution and resource control parameters as documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Socket files must include a [Socket] section, which carries
+    information about the socket or FIFO it supervises. A number of
+    options that may be used in this section are shared with other
+    unit types. These options are documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Socket] section of socket units are
+    the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>ListenStream=</varname></term>
+        <term><varname>ListenDatagram=</varname></term>
+        <term><varname>ListenSequentialPacket=</varname></term>
+        <listitem><para>Specifies an address to listen on for a stream
+        (<constant>SOCK_STREAM</constant>), datagram
+        (<constant>SOCK_DGRAM</constant>), or sequential packet
+        (<constant>SOCK_SEQPACKET</constant>) socket, respectively.
+        The address can be written in various formats:</para>
+
+        <para>If the address starts with a slash
+        (<literal>/</literal>), it is read as file system socket in
+        the <constant>AF_UNIX</constant> socket family.</para>
+
+        <para>If the address starts with an at symbol
+        (<literal>@</literal>), it is read as abstract namespace
+        socket in the <constant>AF_UNIX</constant> family. The
+        <literal>@</literal> is replaced with a
+        <constant>NUL</constant> character before binding. For
+        details, see
+        <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <para>If the address string is a single number, it is read as
+        port number to listen on via IPv6. Depending on the value of
+        <varname>BindIPv6Only=</varname> (see below) this might result
+        in the service being available via both IPv6 and IPv4
+        (default) or just via IPv6.
+        </para>
+
+        <para>If the address string is a string in the format
+        v.w.x.y:z, it is read as IPv4 specifier for listening on an
+        address v.w.x.y on a port z.</para>
+
+        <para>If the address string is a string in the format [x]:y,
+        it is read as IPv6 address x on a port y. Note that this might
+        make the service available via IPv4, too, depending on the
+        <varname>BindIPv6Only=</varname> setting (see below).
+        </para>
+
+        <para>Note that <constant>SOCK_SEQPACKET</constant> (i.e.
+        <varname>ListenSequentialPacket=</varname>) is only available
+        for <constant>AF_UNIX</constant> sockets.
+        <constant>SOCK_STREAM</constant> (i.e.
+        <varname>ListenStream=</varname>) when used for IP sockets
+        refers to TCP sockets, <constant>SOCK_DGRAM</constant> (i.e.
+        <varname>ListenDatagram=</varname>) to UDP.</para>
+
+        <para>These options may be specified more than once, in which
+        case incoming traffic on any of the sockets will trigger
+        service activation, and all listed sockets will be passed to
+        the service, regardless of whether there is incoming traffic
+        on them or not. If the empty string is assigned to any of
+        these options, the list of addresses to listen on is reset,
+        all prior uses of any of these options will have no
+        effect.</para>
+
+        <para>It is also possible to have more than one socket unit
+        for the same service when using <varname>Service=</varname>,
+        and the service will receive all the sockets configured in all
+        the socket units. Sockets configured in one unit are passed in
+        the order of configuration, but no ordering between socket
+        units is specified.</para>
+
+        <para>If an IP address is used here, it is often desirable to
+        listen on it before the interface it is configured on is up
+        and running, and even regardless of whether it will be up and
+        running at any point. To deal with this, it is recommended to
+        set the <varname>FreeBind=</varname> option described
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenFIFO=</varname></term>
+        <listitem><para>Specifies a file system FIFO to listen on.
+        This expects an absolute file system path as argument.
+        Behavior otherwise is very similar to the
+        <varname>ListenDatagram=</varname> directive
+        above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenSpecial=</varname></term>
+        <listitem><para>Specifies a special file in the file system to
+        listen on. This expects an absolute file system path as
+        argument. Behavior otherwise is very similar to the
+        <varname>ListenFIFO=</varname> directive above. Use this to
+        open character device nodes as well as special files in
+        <filename>/proc</filename> and
+        <filename>/sys</filename>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenNetlink=</varname></term>
+        <listitem><para>Specifies a Netlink family to create a socket
+        for to listen on. This expects a short string referring to the
+        <constant>AF_NETLINK</constant> family name (such as
+        <varname>audit</varname> or <varname>kobject-uevent</varname>)
+        as argument, optionally suffixed by a whitespace followed by a
+        multicast group integer. Behavior otherwise is very similar to
+        the <varname>ListenDatagram=</varname> directive
+        above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenMessageQueue=</varname></term>
+        <listitem><para>Specifies a POSIX message queue name to listen
+        on. This expects a valid message queue name (i.e. beginning
+        with /). Behavior otherwise is very similar to the
+        <varname>ListenFIFO=</varname> directive above. On Linux
+        message queue descriptors are actually file descriptors and
+        can be inherited between processes.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenUSBFunction=</varname></term>
+        <listitem><para>Specifies a <ulink
+        url="https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB
+        FunctionFS</ulink> endpoint location to listen on, for
+        implementation of USB gadget functions. This expects an
+        absolute file system path as the argument. Behavior otherwise
+        is very similar to the <varname>ListenFIFO=</varname>
+        directive above. Use this to open the FunctionFS endpoint
+        <filename>ep0</filename>. When using this option, the
+        activated service has to have the
+        <varname>USBFunctionDescriptors=</varname> and
+        <varname>USBFunctionStrings=</varname> options set.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketProtocol=</varname></term>
+        <listitem><para>Takes a one of <option>udplite</option>
+        or <option>sctp</option>. Specifies a socket protocol
+        (<constant>IPPROTO_UDPLITE</constant>) UDP-Lite
+        (<constant>IPPROTO_SCTP</constant>) SCTP socket respectively. </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindIPv6Only=</varname></term>
+        <listitem><para>Takes a one of <option>default</option>,
+        <option>both</option> or <option>ipv6-only</option>. Controls
+        the IPV6_V6ONLY socket option (see
+        <citerefentry project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). If <option>both</option>, IPv6 sockets bound
+        will be accessible via both IPv4 and IPv6. If
+        <option>ipv6-only</option>, they will be accessible via IPv6
+        only. If <option>default</option> (which is the default,
+        surprise!), the system wide default setting is used, as
+        controlled by
+        <filename>/proc/sys/net/ipv6/bindv6only</filename>, which in
+        turn defaults to the equivalent of
+        <option>both</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Backlog=</varname></term>
+        <listitem><para>Takes an unsigned integer argument. Specifies
+        the number of connections to queue that have not been accepted
+        yet. This setting matters only for stream and sequential
+        packet sockets. See
+        <citerefentry><refentrytitle>listen</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. Defaults to SOMAXCONN (128).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindToDevice=</varname></term>
+        <listitem><para>Specifies a network interface name to bind
+        this socket to. If set, traffic will only be accepted from the
+        specified network interfaces. This controls the
+        SO_BINDTODEVICE socket option (see <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). If this option is used, an automatic dependency
+        from this socket unit on the network interface device unit
+        (<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        is created. Note that setting this parameter might result in
+        additional dependencies to be added to the unit (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketUser=</varname></term>
+        <term><varname>SocketGroup=</varname></term>
+
+        <listitem><para>Takes a UNIX user/group name. When specified,
+        all AF_UNIX sockets and FIFO nodes in the file system are
+        owned by the specified user and group. If unset (the default),
+        the nodes are owned by the root user/group (if run in system
+        context) or the invoking user/group (if run in user context).
+        If only a user is specified but no group, then the group is
+        derived from the user's default group.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketMode=</varname></term>
+        <listitem><para>If listening on a file system socket or FIFO,
+        this option specifies the file system access mode used when
+        creating the file node. Takes an access mode in octal
+        notation. Defaults to 0666.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+        <listitem><para>If listening on a file system socket or FIFO,
+        the parent directories are automatically created if needed.
+        This option specifies the file system access mode used when
+        creating these directories. Takes an access mode in octal
+        notation. Defaults to 0755.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Accept=</varname></term>
+        <listitem><para>Takes a boolean argument. If true, a service
+        instance is spawned for each incoming connection and only the
+        connection socket is passed to it. If false, all listening
+        sockets themselves are passed to the started service unit, and
+        only one service unit is spawned for all connections (also see
+        above). This value is ignored for datagram sockets and FIFOs
+        where a single service unit unconditionally handles all
+        incoming traffic. Defaults to <option>false</option>. For
+        performance reasons, it is recommended to write new daemons
+        only in a way that is suitable for
+        <option>Accept=false</option>. A daemon listening on an
+        <constant>AF_UNIX</constant> socket may, but does not need to,
+        call
+        <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        on the received socket before exiting. However, it must not
+        unlink the socket from a file system. It should not invoke
+        <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        on sockets it got with <varname>Accept=false</varname>, but it
+        may do so for sockets it got with
+        <varname>Accept=true</varname> set. Setting
+        <varname>Accept=true</varname> is mostly useful to allow
+        daemons designed for usage with
+        <citerefentry project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        to work unmodified with systemd socket
+        activation.</para>
+
+        <para>For IPv4 and IPv6 connections, the <varname>REMOTE_ADDR</varname>
+        environment variable will contain the remote IP address, and <varname>REMOTE_PORT</varname>
+        will contain the remote port. This is the same as the format used by CGI.
+        For SOCK_RAW, the port is the IP protocol.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Writable=</varname></term>
+        <listitem><para>Takes a boolean argument. May only be used in
+        conjunction with <varname>ListenSpecial=</varname>. If true,
+        the specified special file is opened in read-write mode, if
+        false, in read-only mode. Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxConnections=</varname></term>
+        <listitem><para>The maximum number of connections to
+        simultaneously run services instances for, when
+        <option>Accept=true</option> is set. If more concurrent
+        connections are coming in, they will be refused until at least
+        one existing connection is terminated. This setting has no
+        effect on sockets configured with
+        <option>Accept=false</option> or datagram sockets. Defaults to
+        64.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAlive=</varname></term>
+        <listitem><para>Takes a boolean argument. If true, the TCP/IP
+        stack will send a keep alive message after 2h (depending on
+        the configuration of
+        <filename>/proc/sys/net/ipv4/tcp_keepalive_time</filename>)
+        for all TCP streams accepted on this socket. This controls the
+        SO_KEEPALIVE socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and the <ulink
+        url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
+        Keepalive HOWTO</ulink> for details.) Defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAliveTimeSec=</varname></term>
+        <listitem><para>Takes time (in seconds) as argument. The connection needs to remain
+        idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE
+        socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and the <ulink
+        url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
+        Keepalive HOWTO</ulink> for details.)
+        Defaults value is 7200 seconds (2 hours).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAliveIntervalSec=</varname></term>
+        <listitem><para>Takes time (in seconds) as argument between
+        individual keepalive probes, if the socket option SO_KEEPALIVE
+        has been set on this socket. This controls
+        the TCP_KEEPINTVL socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and the <ulink
+        url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
+        Keepalive HOWTO</ulink> for details.) Defaults value is 75
+        seconds.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAliveProbes=</varname></term>
+        <listitem><para>Takes an integer as argument. It is the number of
+        unacknowledged probes to send before considering the
+        connection dead and notifying the application layer. This
+        controls the TCP_KEEPCNT socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and the <ulink
+        url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
+        Keepalive HOWTO</ulink> for details.) Defaults value is
+        9.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NoDelay=</varname></term>
+        <listitem><para>Takes a boolean argument. TCP Nagle's
+        algorithm works by combining a number of small outgoing
+        messages, and sending them all at once. This controls the
+        TCP_NODELAY socket option (see
+        <citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+        <listitem><para>Takes an integer argument controlling the
+        priority for all traffic sent from this socket. This controls
+        the SO_PRIORITY socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details.).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DeferAcceptSec=</varname></term>
+
+        <listitem><para>Takes time (in seconds) as argument. If set,
+        the listening process will be awakened only when data arrives
+        on the socket, and not immediately when connection is
+        established. When this option is set, the
+        <constant>TCP_DEFER_ACCEPT</constant> socket option will be
+        used (see
+        <citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+        and the kernel will ignore initial ACK packets without any
+        data. The argument specifies the approximate amount of time
+        the kernel should wait for incoming data before falling back
+        to the normal behavior of honouring empty ACK packets. This
+        option is beneficial for protocols where the client sends the
+        data first (e.g. HTTP, in contrast to SMTP), because the
+        server process will not be woken up unnecessarily before it
+        can take any action.
+        </para>
+
+        <para>If the client also uses the
+        <constant>TCP_DEFER_ACCEPT</constant> option, the latency of
+        the initial connection may be reduced, because the kernel will
+        send data in the final packet establishing the connection (the
+        third packet in the "three-way handshake").</para>
+
+        <para>Disabled by default.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReceiveBuffer=</varname></term>
+        <term><varname>SendBuffer=</varname></term>
+        <listitem><para>Takes an integer argument controlling the
+        receive or send buffer sizes of this socket, respectively.
+        This controls the SO_RCVBUF and SO_SNDBUF socket options (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details.). The usual suffixes K, M, G are supported and
+        are understood to the base of 1024.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPTOS=</varname></term>
+        <listitem><para>Takes an integer argument controlling the IP
+        Type-Of-Service field for packets generated from this socket.
+        This controls the IP_TOS socket option (see
+        <citerefentry project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details.). Either a numeric string or one of
+        <option>low-delay</option>, <option>throughput</option>,
+        <option>reliability</option> or <option>low-cost</option> may
+        be specified.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPTTL=</varname></term>
+        <listitem><para>Takes an integer argument controlling the IPv4
+        Time-To-Live/IPv6 Hop-Count field for packets generated from
+        this socket. This sets the IP_TTL/IPV6_UNICAST_HOPS socket
+        options (see
+        <citerefentry project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and
+        <citerefentry project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details.)</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Mark=</varname></term>
+        <listitem><para>Takes an integer value. Controls the firewall
+        mark of packets generated by this socket. This can be used in
+        the firewall logic to filter packets from this socket. This
+        sets the SO_MARK socket option. See
+        <citerefentry project='die-net'><refentrytitle>iptables</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReusePort=</varname></term>
+        <listitem><para>Takes a boolean value. If true, allows
+        multiple
+        <citerefentry><refentrytitle>bind</refentrytitle><manvolnum>2</manvolnum></citerefentry>s
+        to this TCP or UDP port. This controls the SO_REUSEPORT socket
+        option. See
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SmackLabel=</varname></term>
+        <term><varname>SmackLabelIPIn=</varname></term>
+        <term><varname>SmackLabelIPOut=</varname></term>
+        <listitem><para>Takes a string value. Controls the extended
+        attributes <literal>security.SMACK64</literal>,
+        <literal>security.SMACK64IPIN</literal> and
+        <literal>security.SMACK64IPOUT</literal>, respectively, i.e.
+        the security label of the FIFO, or the security label for the
+        incoming or outgoing connections of the socket, respectively.
+        See <ulink
+        url="https://www.kernel.org/doc/Documentation/security/Smack.txt">Smack.txt</ulink>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SELinuxContextFromNet=</varname></term>
+         <listitem><para>Takes a boolean argument. When true, systemd
+         will attempt to figure out the SELinux label used for the
+         instantiated service from the information handed by the peer
+         over the network. Note that only the security level is used
+         from the information provided by the peer. Other parts of the
+         resulting SELinux context originate from either the target
+         binary that is effectively triggered by socket unit or from
+         the value of the <varname>SELinuxContext=</varname> option.
+         This configuration option only affects sockets with
+         <varname>Accept=</varname> mode set to
+         <literal>true</literal>. Also note that this option is useful
+         only when MLS/MCS SELinux policy is deployed. Defaults to
+         <literal>false</literal>. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PipeSize=</varname></term>
+        <listitem><para>Takes a size in bytes. Controls the pipe
+        buffer size of FIFOs configured in this socket unit. See
+        <citerefentry><refentrytitle>fcntl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. The usual suffixes K, M, G are supported and are
+        understood to the base of 1024.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MessageQueueMaxMessages=</varname>,
+        <varname>MessageQueueMessageSize=</varname></term>
+        <listitem><para>These two settings take integer values and
+        control the mq_maxmsg field or the mq_msgsize field,
+        respectively, when creating the message queue. Note that
+        either none or both of these variables need to be set. See
+        <citerefentry project='die-net'><refentrytitle>mq_setattr</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FreeBind=</varname></term>
+        <listitem><para>Takes a boolean value. Controls whether the
+        socket can be bound to non-local IP addresses. This is useful
+        to configure sockets listening on specific IP addresses before
+        those IP addresses are successfully configured on a network
+        interface. This sets the IP_FREEBIND socket option. For
+        robustness reasons it is recommended to use this option
+        whenever you bind a socket to a specific IP address. Defaults
+        to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Transparent=</varname></term>
+        <listitem><para>Takes a boolean value. Controls the
+        IP_TRANSPARENT socket option. Defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Broadcast=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the
+        SO_BROADCAST socket option, which allows broadcast datagrams
+        to be sent from this socket. Defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassCredentials=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the
+        SO_PASSCRED socket option, which allows
+        <constant>AF_UNIX</constant> sockets to receive the
+        credentials of the sending process in an ancillary message.
+        Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassSecurity=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the
+        SO_PASSSEC socket option, which allows
+        <constant>AF_UNIX</constant> sockets to receive the security
+        context of the sending process in an ancillary message.
+        Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TCPCongestion=</varname></term>
+        <listitem><para>Takes a string value. Controls the TCP
+        congestion algorithm used by this socket. Should be one of
+        "westwood", "veno", "cubic", "lp" or any other available
+        algorithm supported by the IP stack. This setting applies only
+        to stream sockets.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStartPre=</varname></term>
+        <term><varname>ExecStartPost=</varname></term>
+        <listitem><para>Takes one or more command lines, which are
+        executed before or after the listening sockets/FIFOs are
+        created and bound, respectively. The first token of the
+        command line must be an absolute filename, then followed by
+        arguments for the process. Multiple command lines may be
+        specified following the same scheme as used for
+        <varname>ExecStartPre=</varname> of service unit
+        files.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStopPre=</varname></term>
+        <term><varname>ExecStopPost=</varname></term>
+        <listitem><para>Additional commands that are executed before
+        or after the listening sockets/FIFOs are closed and removed,
+        respectively. Multiple command lines may be specified
+        following the same scheme as used for
+        <varname>ExecStartPre=</varname> of service unit
+        files.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>Configures the time to wait for the commands
+        specified in <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>,
+        <varname>ExecStopPre=</varname> and
+        <varname>ExecStopPost=</varname> to finish. If a command does
+        not exit within the configured time, the socket will be
+        considered failed and be shut down again. All commands still
+        running will be terminated forcibly via
+        <constant>SIGTERM</constant>, and after another delay of this
+        time with <constant>SIGKILL</constant>. (See
+        <option>KillMode=</option> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass <literal>0</literal> to disable the
+        timeout logic. Defaults to
+        <varname>DefaultTimeoutStartSec=</varname> from the manager
+        configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Service=</varname></term>
+        <listitem><para>Specifies the service unit name to activate on
+        incoming traffic. This setting is only allowed for sockets
+        with <varname>Accept=no</varname>. It defaults to the service
+        that bears the same name as the socket (with the suffix
+        replaced). In most cases, it should not be necessary to use
+        this option. Note that setting this parameter might result in
+        additional dependencies to be added to the unit (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemoveOnStop=</varname></term>
+        <listitem><para>Takes a boolean argument. If enabled, any file
+        nodes created by this socket unit are removed when it is
+        stopped. This applies to AF_UNIX sockets in the file system,
+        POSIX message queues, FIFOs, as well as any symlinks to them
+        configured with <varname>Symlinks=</varname>. Normally, it
+        should not be necessary to use this option, and is not
+        recommended as services might continue to run after the socket
+        unit has been terminated and it should still be possible to
+        communicate with them via their file system node. Defaults to
+        off.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Symlinks=</varname></term>
+        <listitem><para>Takes a list of file system paths. The
+        specified paths will be created as symlinks to the AF_UNIX
+        socket path or FIFO path of this socket unit. If this setting
+        is used, only one AF_UNIX socket in the file system or one
+        FIFO may be configured for the socket unit. Use this option to
+        manage one or more symlinked alias names for a socket, binding
+        their lifecycle together. Defaults to the empty
+        list.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FileDescriptorName=</varname></term>
+        <listitem><para>Assigns a name to all file descriptors this
+        socket unit encapsulates. This is useful to help activated
+        services identify specific file descriptors, if multiple fds
+        are passed. Services may use the
+        <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        call to acquire the names configured for the received file
+        descriptors. Names may contain any ASCII character, but must
+        exclude control characters and <literal>:</literal>, and must
+        be at most 255 characters in length. If this setting is not
+        used, the file descriptor name defaults to the name of the
+        socket unit, including its <filename>.socket</filename>
+        suffix.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TriggerLimitIntervalSec=</varname></term>
+        <term><varname>TriggerLimitBurst=</varname></term>
+
+        <listitem><para>Configures a limit on how often this socket unit my be activated within a specific time
+        interval. The <varname>TriggerLimitIntervalSec=</varname> may be used to configure the length of the time
+        interval in the usual time units <literal>us</literal>, <literal>ms</literal>, <literal>s</literal>,
+        <literal>min</literal>, <literal>h</literal>, … and defaults to 2s (See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on
+        the various time units understood). The <varname>TriggerLimitBurst=</varname> setting takes a positive integer
+        value and specifies the number of permitted activations per time interval, and defaults to 200 for
+        <varname>Accept=yes</varname> sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20
+        activations per 2s). Set either to 0 to disable any form of trigger rate limiting. If the limit is hit, the
+        socket unit is placed into a failure mode, and will not be connectible anymore until restarted. Note that this
+        limit is enforced before the service activation is enqueued.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>Check
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more settings.</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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      </para>
+      <para>
+        For more extensive descriptions see the "systemd for Developers" series:
+        <ulink url="http://0pointer.de/blog/projects/socket-activation.html">Socket Activation</ulink>,
+        <ulink url="http://0pointer.de/blog/projects/socket-activation2.html">Socket Activation, part II</ulink>,
+        <ulink url="http://0pointer.de/blog/projects/inetd.html">Converting inetd Services</ulink>,
+        <ulink url="http://0pointer.de/blog/projects/socket-activated-containers.html">Socket Activated Internet Services and OS Containers</ulink>.
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.special.xml b/src/grp-system/systemd/systemd.special.xml
new file mode 100644
index 0000000000..26974ed73f
--- /dev/null
+++ b/src/grp-system/systemd/systemd.special.xml
@@ -0,0 +1,935 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.special">
+
+  <refentryinfo>
+    <title>systemd.special</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.special</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.special</refname>
+    <refpurpose>Special systemd units</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>basic.target</filename>,
+    <filename>bluetooth.target</filename>,
+    <filename>ctrl-alt-del.target</filename>,
+    <filename>cryptsetup.target</filename>,
+    <filename>cryptsetup-pre.target</filename>,
+    <filename>dbus.service</filename>,
+    <filename>dbus.socket</filename>,
+    <filename>default.target</filename>,
+    <filename>display-manager.service</filename>,
+    <filename>emergency.target</filename>,
+    <filename>exit.target</filename>,
+    <filename>final.target</filename>,
+    <filename>getty.target</filename>,
+    <filename>graphical.target</filename>,
+    <filename>halt.target</filename>,
+    <filename>hibernate.target</filename>,
+    <filename>hybrid-sleep.target</filename>,
+    <filename>initrd-fs.target</filename>,
+    <filename>kbrequest.target</filename>,
+    <filename>kexec.target</filename>,
+    <filename>local-fs.target</filename>,
+    <filename>local-fs-pre.target</filename>,
+    <filename>multi-user.target</filename>,
+    <filename>network.target</filename>,
+    <filename>network-online.target</filename>,
+    <filename>network-pre.target</filename>,
+    <filename>nss-lookup.target</filename>,
+    <filename>nss-user-lookup.target</filename>,
+    <filename>paths.target</filename>,
+    <filename>poweroff.target</filename>,
+    <filename>printer.target</filename>,
+    <filename>reboot.target</filename>,
+    <filename>remote-fs.target</filename>,
+    <filename>remote-fs-pre.target</filename>,
+    <filename>rescue.target</filename>,
+    <filename>initrd-root-device.target</filename>,
+    <filename>initrd-root-fs.target</filename>,
+    <filename>rpcbind.target</filename>,
+    <filename>runlevel2.target</filename>,
+    <filename>runlevel3.target</filename>,
+    <filename>runlevel4.target</filename>,
+    <filename>runlevel5.target</filename>,
+    <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>,
+    <filename>suspend.target</filename>,
+    <filename>swap.target</filename>,
+    <filename>sysinit.target</filename>,
+    <filename>syslog.socket</filename>,
+    <filename>system-update.target</filename>,
+    <filename>time-sync.target</filename>,
+    <filename>timers.target</filename>,
+    <filename>umount.target</filename>,
+    <filename>-.slice</filename>,
+    <filename>system.slice</filename>,
+    <filename>user.slice</filename>,
+    <filename>machine.slice</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A few units are treated specially by systemd. They have
+    special internal semantics and cannot be renamed.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Special System Units</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>basic.target</filename></term>
+        <listitem>
+          <para>A special target unit covering basic boot-up.</para>
+
+          <para>systemd automatically adds dependencies of the types
+          <varname>Requires=</varname> and <varname>After=</varname>
+          for this target unit to all services (except for those with
+          <varname>DefaultDependencies=no</varname>).</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
+          (symlinked) to <filename>reboot.target</filename>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>cryptsetup.target</filename></term>
+        <listitem>
+          <para>A target that pulls in setup services for all
+          encrypted block devices.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>dbus.service</filename></term>
+        <listitem>
+          <para>A special unit for the D-Bus bus daemon. As soon as
+          this service is fully started up systemd will connect to it
+          and register its service.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>dbus.socket</filename></term>
+        <listitem>
+          <para>A special unit for the D-Bus system bus socket. All
+          units with <varname>Type=dbus</varname> automatically gain a
+          dependency on this unit.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>default.target</filename></term>
+        <listitem>
+          <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>
+
+          <para>The default unit systemd starts at bootup can be
+          overridden with the <varname>systemd.unit=</varname> kernel
+          command line option.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>display-manager.service</filename></term>
+        <listitem>
+          <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>
+      <varlistentry>
+        <term><filename>emergency.target</filename></term>
+        <listitem>
+          <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>
+        <term><filename>final.target</filename></term>
+        <listitem>
+          <para>A special target unit that is used during the shutdown
+          logic and may be used to pull in late services after all
+          normal services are already terminated and all mounts
+          unmounted.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>getty.target</filename></term>
+        <listitem>
+          <para>A special target unit that pulls in statically
+          configured local TTY <filename>getty</filename> instances.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>graphical.target</filename></term>
+        <listitem>
+          <para>A special target unit for setting up a graphical login
+          screen. This pulls in
+          <filename>multi-user.target</filename>.</para>
+
+          <para>Units that are needed for graphical logins shall add
+          <varname>Wants=</varname> dependencies for their unit to
+          this unit (or <filename>multi-user.target</filename>) during
+          installation. This is best configured via
+          <varname>WantedBy=graphical.target</varname> in the unit's
+          <literal>[Install]</literal> section.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>hibernate.target</filename></term>
+        <listitem>
+          <para>A special target unit for hibernating the system. This
+          pulls in <filename>sleep.target</filename>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>hybrid-sleep.target</filename></term>
+        <listitem>
+          <para>A special target unit for hibernating and suspending
+          the system at the same time. This pulls in
+          <filename>sleep.target</filename>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>halt.target</filename></term>
+        <listitem>
+          <para>A special target unit for shutting down and halting
+          the system. Note that this target is distinct from
+          <filename>poweroff.target</filename> in that it generally
+          really just halts the system rather than powering it
+          down.</para>
+
+          <para>Applications wanting to halt the system should start
+          this unit.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>initrd-fs.target</filename></term>
+        <listitem>
+          <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          automatically adds dependencies of type
+          <varname>Before=</varname> to
+          <filename>sysroot-usr.mount</filename> and all mount points
+          found in <filename>/etc/fstab</filename> that have
+          <option>x-initrd.mount</option> and not have
+          <option>noauto</option> mount options set.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>kbrequest.target</filename></term>
+        <listitem>
+          <para>systemd starts this target whenever Alt+ArrowUp is
+          pressed on the console. This is a good candidate to be
+          aliased (symlinked) to
+          <filename>rescue.target</filename>.</para>
+        </listitem>
+      </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>Applications wanting to reboot the system with kexec
+          should start this unit.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>local-fs.target</filename></term>
+        <listitem>
+          <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          automatically adds dependencies of type
+          <varname>Before=</varname> to all mount units that refer to
+          local mount points for this target unit. In addition, it
+          adds dependencies of type <varname>Wants=</varname> to this
+          target unit for those mounts listed in
+          <filename>/etc/fstab</filename> that have the
+          <option>auto</option> mount option set.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>multi-user.target</filename></term>
+        <listitem>
+          <para>A special target unit for setting up a multi-user
+          system (non-graphical). This is pulled in by
+          <filename>graphical.target</filename>.</para>
+
+          <para>Units that are needed for a multi-user system shall
+          add <varname>Wants=</varname> dependencies for their unit to
+          this unit during installation. This is best configured via
+          <varname>WantedBy=multi-user.target</varname> in the unit's
+          <literal>[Install]</literal> section.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>network-online.target</filename></term>
+        <listitem>
+          <para>Units that strictly require a configured network
+          connection should pull in
+          <filename>network-online.target</filename> (via a
+          <varname>Wants=</varname> type dependency) and order
+          themselves after it. This target unit is intended to pull in
+          a service that delays further execution until the network is
+          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="http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">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 provide
+          functionality to other hosts generally do not need to pull
+          this in.</para>
+          </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>paths.target</filename></term>
+        <listitem>
+          <para>A special target unit that sets up all path units (see
+          <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details) that shall be active after boot.</para>
+
+          <para>It is recommended that path units installed by
+          applications get pulled in via <varname>Wants=</varname>
+          dependencies from this unit. This is best configured via a
+          <varname>WantedBy=paths.target</varname> in the path unit's
+          <literal>[Install]</literal> section.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>poweroff.target</filename></term>
+        <listitem>
+          <para>A special target unit for shutting down and powering
+          off the system.</para>
+
+          <para>Applications wanting to power off the system should
+          start this unit.</para>
+
+          <para><filename>runlevel0.target</filename> is an alias for
+          this target unit, for compatibility with SysV.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>reboot.target</filename></term>
+        <listitem>
+          <para>A special target unit for shutting down and rebooting
+          the system.</para>
+
+          <para>Applications wanting to reboot the system should start
+          this unit.</para>
+
+          <para><filename>runlevel6.target</filename> is an alias for
+          this target unit, for compatibility with SysV.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>remote-fs.target</filename></term>
+        <listitem>
+          <para>Similar to <filename>local-fs.target</filename>, but
+          for remote mount points.</para>
+
+          <para>systemd automatically adds dependencies of type
+          <varname>After=</varname> for this target unit to all SysV
+          init script service units with an LSB header referring to
+          the <literal>$remote_fs</literal> facility.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>rescue.target</filename></term>
+        <listitem>
+          <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>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>
+        <term><filename>initrd-root-device.target</filename></term>
+        <listitem>
+          <para>A special initrd target unit that is reached when the root filesystem device is available, but before
+          it has been mounted.
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          automatically setup the appropiate dependencies to make this happen.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>initrd-root-fs.target</filename></term>
+        <listitem>
+          <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          automatically adds dependencies of type
+          <varname>Before=</varname> to the
+          <filename>sysroot.mount</filename> unit, which is generated
+          from the kernel command line.
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>runlevel2.target</filename></term>
+        <term><filename>runlevel3.target</filename></term>
+        <term><filename>runlevel4.target</filename></term>
+        <term><filename>runlevel5.target</filename></term>
+        <listitem>
+          <para>These are targets that are called whenever the SysV
+          compatibility code asks for runlevel 2, 3, 4, 5,
+          respectively. It is a good idea to make this an alias for
+          (i.e. symlink to) <filename>multi-user.target</filename>
+          (for runlevel 2) or <filename>graphical.target</filename>
+          (the others).</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>shutdown.target</filename></term>
+        <listitem>
+          <para>A special target unit that terminates the services on
+          system shutdown.</para>
+
+          <para>Services that shall be terminated on system shutdown
+          shall add <varname>Conflicts=</varname> dependencies to this
+          unit for their service unit, which is implicitly done when
+          <varname>DefaultDependencies=yes</varname> is set (the
+          default).</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>sigpwr.target</filename></term>
+        <listitem>
+          <para>A special target that is started when systemd receives
+          the SIGPWR process signal, which is normally sent by the
+          kernel or UPS daemons when power fails.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>sleep.target</filename></term>
+        <listitem>
+          <para>A special target unit that is pulled in by
+          <filename>suspend.target</filename>,
+          <filename>hibernate.target</filename> and
+          <filename>hybrid-sleep.target</filename> and may be used to
+          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
+          <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details) that shall be active after boot.</para>
+
+          <para>Services that can be socket-activated shall add
+          <varname>Wants=</varname> dependencies to this unit for
+          their socket unit during installation. This is best
+          configured via a <varname>WantedBy=sockets.target</varname>
+          in the socket unit's <literal>[Install]</literal>
+          section.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>suspend.target</filename></term>
+        <listitem>
+          <para>A special target unit for suspending the system. This
+          pulls in <filename>sleep.target</filename>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>swap.target</filename></term>
+        <listitem>
+          <para>Similar to <filename>local-fs.target</filename>, but
+          for swap partitions and swap files.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>sysinit.target</filename></term>
+        <listitem>
+          <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>
+        <term><filename>syslog.socket</filename></term>
+        <listitem>
+          <para>The socket unit syslog implementations should listen
+          on. All userspace log messages will be made available on
+          this socket. For more information about syslog integration,
+          please consult the <ulink
+          url="http://www.freedesktop.org/wiki/Software/systemd/syslog">Syslog
+          Interface</ulink> document.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>system-update.target</filename></term>
+        <listitem>
+          <para>A special target unit that is used for off-line 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 the <ulink
+          url="http://freedesktop.org/wiki/Software/systemd/SystemUpdates">System
+          Updates Specification</ulink>.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>timers.target</filename></term>
+        <listitem>
+          <para>A special target unit that sets up all timer units
+          (see
+          <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details) that shall be active after boot.</para>
+
+          <para>It is recommended that timer units installed by
+          applications get pulled in via <varname>Wants=</varname>
+          dependencies from this unit. This is best configured via
+          <varname>WantedBy=timers.target</varname> in the timer
+          unit's <literal>[Install]</literal> section.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>umount.target</filename></term>
+        <listitem>
+          <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
+          shall add Conflicts dependencies to this unit for their
+          mount unit, which is implicitly done when
+          <varname>DefaultDependencies=yes</varname> is set (the
+          default).</para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Special System Units for Devices</title>
+
+    <para>Some target units are automatically pulled in as devices of
+    certain kinds show up in the system. These may be used to
+    automatically activate various services based on the specific type
+    of the available hardware.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>bluetooth.target</filename></term>
+        <listitem>
+          <para>This target is started automatically as soon as a
+          Bluetooth controller is plugged in or becomes available at
+          boot.</para>
+
+          <para>This may be used to pull in Bluetooth management
+          daemons dynamically when Bluetooth hardware is found.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>printer.target</filename></term>
+        <listitem>
+          <para>This target is started automatically as soon as a
+          printer is plugged in or becomes available at boot.</para>
+
+          <para>This may be used to pull in printer management daemons
+          dynamically when printer hardware is found.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>smartcard.target</filename></term>
+        <listitem>
+          <para>This target is started automatically as soon as a
+          smartcard controller is plugged in or becomes available at
+          boot.</para>
+
+          <para>This may be used to pull in smartcard management
+          daemons dynamically when smartcard hardware is found.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>sound.target</filename></term>
+        <listitem>
+          <para>This target is started automatically as soon as a
+          sound card is plugged in or becomes available at
+          boot.</para>
+
+          <para>This may be used to pull in audio management daemons
+          dynamically when audio hardware is found.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Special Passive System Units </title>
+
+    <para>A number of special system targets are defined that can be
+    used to properly order boot-up of optional services. These targets
+    are generally not part of the initial boot transaction, unless
+    they are explicitly pulled in by one of the implementing services.
+    Note specifically that these <emphasis>passive</emphasis> target
+    units are generally not pulled in by the consumer of a service,
+    but by the provider of the service. This means: a consuming
+    service should order itself after these targets (as appropriate),
+    but not pull it in. A providing service should order itself before
+    these targets (as appropriate) and pull it in (via a
+    <varname>Wants=</varname> type dependency).</para>
+
+    <para>Note that these passive units cannot be started manually,
+    i.e. <literal>systemctl start time-sync.target</literal> will fail
+    with an error. They can only be pulled in by dependency. This is
+    enforced since they exist for ordering purposes only and thus are
+    not useful as only unit within a transaction.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>cryptsetup-pre.target</filename></term>
+        <listitem>
+          <para>This passive target unit may be pulled in by services
+          that want to run before any encrypted block device is set
+          up. All encrypted block devices are set up after this target
+          has been reached. Since the shutdown order is implicitly the
+          reverse start-up order between units, this target is
+          particularly useful to ensure that a service is shut down
+          only after all encrypted block devices are fully
+          stopped.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>local-fs-pre.target</filename></term>
+        <listitem>
+          <para>This target unit is
+          automatically ordered before
+          all local mount points marked
+          with <option>auto</option>
+          (see above). It can be used to
+          execute certain units before
+          all local mounts.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>network.target</filename></term>
+        <listitem>
+          <para>This unit is supposed to indicate when network
+          functionality is available, but it is only very weakly
+          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 —
+          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="http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running
+          Services After the Network is up</ulink> for more
+          information. Also see
+          <filename>network-online.target</filename> described
+          above.</para>
+
+          <para>systemd automatically adds dependencies of type
+          <varname>After=</varname> for this target unit to all SysV
+          init script service units with an LSB header referring to
+          the <literal>$network</literal> facility.</para>
+        </listitem>
+      </varlistentry>
+      <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>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>nss-lookup.target</filename></term>
+        <listitem>
+          <para>A target that should be used as synchronization point
+          for all host/network name service lookups. Note that this is
+          independent of user/group name lookups for which
+          <filename>nss-user-lookup.target</filename> should be used.
+          All services for which the availability of full host/network
+          name resolution is essential should be ordered after this
+          target, but not pull it in. systemd automatically adds
+          dependencies of type <varname>After=</varname> for this
+          target unit to all SysV init script service units with an
+          LSB header referring to the <literal>$named</literal>
+          facility.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>nss-user-lookup.target</filename></term>
+        <listitem>
+          <para>A target that should be used as synchronization point
+          for all user/group name service lookups. Note that this is
+          independent of host/network name lookups for which
+          <filename>nss-lookup.target</filename> should be used. All
+          services for which the availability of the full user/group
+          database is essential should be ordered after this target,
+          but not pull it in. Note that system users are always
+          resolvable, and hence do not require any special ordering
+          against this target.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>remote-fs-pre.target</filename></term>
+        <listitem>
+          <para>This target unit is automatically ordered before all
+          remote mount point units (see above). It can be used to run
+          certain units before the remote mounts are established. Note
+          that this unit is generally not part of the initial
+          transaction, unless the unit that wants to be ordered before
+          all remote mounts pulls it in via a
+          <varname>Wants=</varname> type dependency. If the unit wants
+          to be pulled in by the first remote mount showing up, it
+          should use <filename>network-online.target</filename> (see
+          above).</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>rpcbind.target</filename></term>
+        <listitem>
+          <para>The portmapper/rpcbind pulls in this target and orders
+          itself before it, to indicate its availability. systemd
+          automatically adds dependencies of type
+          <varname>After=</varname> for this target unit to all SysV
+          init script service units with an LSB header referring to
+          the <literal>$portmap</literal> facility.</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>time-sync.target</filename></term>
+        <listitem>
+          <para>Services responsible for synchronizing the system
+          clock from a remote source (such as NTP client
+          implementations) should pull in this target and order
+          themselves before it. All services where correct time is
+          essential should be ordered after this unit, but not pull it
+          in. systemd automatically adds dependencies of type
+          <varname>After=</varname> for this target unit to all SysV
+          init script service units with an LSB header referring to
+          the <literal>$time</literal> facility. </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Special User Units</title>
+
+    <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>timers.target</filename>,
+    <filename>paths.target</filename>,
+    <filename>bluetooth.target</filename>,
+    <filename>printer.target</filename>,
+    <filename>smartcard.target</filename>,
+    <filename>sound.target</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Special Slice Units</title>
+
+    <para>There are four <literal>.slice</literal> units which form
+    the basis of the hierarchy for assignment of resources for
+    services, users, and virtual machines or containers.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>-.slice</filename></term>
+        <listitem>
+          <para>The root slice is the root of the hierarchy. It
+          usually does not contain units directly, but may be used to
+          set defaults for the whole tree.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>system.slice</filename></term>
+        <listitem>
+          <para>By default, all system services started by
+          <command>systemd</command> are found in this slice.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>user.slice</filename></term>
+        <listitem>
+          <para>By default, all user processes and services started on
+          behalf of the user, including the per-user systemd instance
+          are found in this slice.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>machine.slice</filename></term>
+        <listitem>
+          <para>By default, all virtual machines and containers
+          registered with <command>systemd-machined</command> are
+          found in this slice.
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <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 project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.swap.xml b/src/grp-system/systemd/systemd.swap.xml
new file mode 100644
index 0000000000..cf4e1ba839
--- /dev/null
+++ b/src/grp-system/systemd/systemd.swap.xml
@@ -0,0 +1,250 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.swap">
+  <refentryinfo>
+    <title>systemd.swap</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.swap</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.swap</refname>
+    <refpurpose>Swap unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>swap</replaceable>.swap</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.swap</literal> encodes information about a swap device
+    or file for memory paging controlled and supervised by
+    systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The swap specific configuration options are
+    configured in the [Swap] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the <citerefentry
+    project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    binary is executed in, in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way these processes are
+    terminated, and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for these processes of the
+    unit.</para>
+
+    <para>Swap units must be named after the devices or files they control. Example: the swap device <filename
+    noindex='true'>/dev/sda5</filename> must be configured in a unit file <filename>dev-sda5.swap</filename>. For
+    details about the escaping logic used to convert a file system path to a unit name, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note that swap
+    units cannot be templated, nor is possible to add multiple names to a swap unit by creating additional symlinks to
+    it.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>All swap units automatically get the
+    <varname>BindsTo=</varname> and <varname>After=</varname>
+    dependencies on the device units or the mount units of the files
+    they are activated from.</para>
+
+    <para>Swap units with <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section enabled
+    implicitly acquire a <varname>Conflicts=</varname> and an <varname>After=</varname> dependency on
+    <filename>umount.target</filename> so that they are deactivated at shutdown, unless
+    <varname>DefaultDependencies=no</varname> is specified.</para>
+
+    <para>Additional implicit dependencies may be added as result of
+    execution and resource control parameters as documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>fstab</filename></title>
+
+    <para>Swap units may either be configured via unit files, or via
+    <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details). Swaps listed in <filename>/etc/fstab</filename> will
+    be converted into native units dynamically at boot and when the
+    configuration of the system manager is reloaded. See
+    <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for details about the conversion.</para>
+
+    <para>If a swap device or file is configured in both
+    <filename>/etc/fstab</filename> and a unit file, the configuration
+    in the latter takes precedence.</para>
+
+    <para>When reading <filename>/etc/fstab</filename>, a few special
+    options are understood by systemd which influence how dependencies
+    are created for swap units.</para>
+
+    <variablelist class='fstab-options'>
+      <varlistentry>
+        <term><option>noauto</option></term>
+        <term><option>auto</option></term>
+
+        <listitem><para>With <option>noauto</option>, the swap unit
+        will not be added as a dependency for
+        <filename>swap.target</filename>. This means that it will not
+        be activated automatically during boot, unless it is pulled in
+        by some other unit. The <option>auto</option> option has the
+        opposite meaning and is the default.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>nofail</option></term>
+
+        <listitem><para>With <option>nofail</option>, the swap unit
+        will be only wanted, not required by
+        <filename>swap.target</filename>. This means that the boot
+        will continue even if this swap device is not activated
+        successfully.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Swap files must include a [Swap] section, which carries
+    information about the swap device it supervises. A number of
+    options that may be used in this section are shared with other
+    unit types. These options are documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Swap] section of swap units are the
+    following:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>What=</varname></term>
+        <listitem><para>Takes an absolute path of a device node or
+        file to use for paging. See
+        <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details. If this refers to a device node, a dependency on
+        the respective device unit is automatically created. (See
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.) If this refers to a file, a dependency
+        on the respective mount unit is automatically created. (See
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.) This option is
+        mandatory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+
+        <listitem><para>Swap priority to use when activating the swap
+        device or file. This takes an integer. This setting is
+        optional and ignored when the priority is set by <option>pri=</option> in the
+        <varname>Options=</varname> key.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Options=</varname></term>
+
+        <listitem><para>May contain an option string for the swap
+        device. This may be used for controlling discard options among
+        other functionality, if the swap backing device supports the
+        discard or trim operation. (See
+        <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for more information.) </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>Configures the time to wait for the swapon
+        command to finish. If a command does not exit within the
+        configured time, the swap will be considered failed and be
+        shut down again. All commands still running will be terminated
+        forcibly via <constant>SIGTERM</constant>, and after another
+        delay of this time with <constant>SIGKILL</constant>. (See
+        <option>KillMode=</option> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass <literal>0</literal> to disable the
+        timeout logic. Defaults to
+        <varname>DefaultTimeoutStartSec=</varname> from the manager
+        configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Check
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more settings.</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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.target.xml b/src/grp-system/systemd/systemd.target.xml
new file mode 100644
index 0000000000..ab910d75dd
--- /dev/null
+++ b/src/grp-system/systemd/systemd.target.xml
@@ -0,0 +1,103 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.target">
+  <refentryinfo>
+    <title>systemd.target</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.target</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.target</refname>
+    <refpurpose>Target unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>target</replaceable>.target</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.target</literal> encodes information about a target unit
+    of systemd, which is used for grouping units and as well-known
+    synchronization points during start-up.</para>
+
+    <para>This unit type has no specific options. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. A separate [Target] section does not exist,
+    since no target-specific options may be configured.</para>
+
+    <para>Target units do not offer any additional functionality on
+    top of the generic functionality provided by units. They exist
+    merely to group units via dependencies (useful as boot targets),
+    and to establish standardized names for synchronization points
+    used in dependencies between units. Among other things, target
+    units are a more flexible replacement for SysV runlevels in the
+    classic SysV init system. (And for compatibility reasons special
+    target units such as <filename>runlevel3.target</filename> exist
+    which are used by the SysV runlevel compatibility code in systemd.
+    See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for details).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section is set to
+    <option>no</option>, target units will implicitly complement all configured dependencies of type
+    <varname>Wants=</varname>, <varname>Requires=</varname> with dependencies of type <varname>After=</varname>, unless
+    an ordering dependency of any kind between the target and the respective other unit is already in place. Note that
+    this behaviour is disabled if either unit has <varname>DefaultDependencies=no</varname>.</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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.time.xml b/src/grp-system/systemd/systemd.time.xml
new file mode 100644
index 0000000000..ffcac82263
--- /dev/null
+++ b/src/grp-system/systemd/systemd.time.xml
@@ -0,0 +1,313 @@
+<?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">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.time">
+
+  <refentryinfo>
+    <title>systemd.time</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.time</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.time</refname>
+    <refpurpose>Time and date specifications</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>In systemd, timestamps, time spans, and calendar events are
+    displayed and may be specified in closely related syntaxes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Displaying Time Spans</title>
+
+    <para>Time spans refer to time durations. On display, systemd will
+    present time spans as a space-separated series of time values each
+    suffixed by a time unit.</para>
+
+    <programlisting>2h 30min</programlisting>
+
+    <para>All specified time values are meant to be added up. The
+    above hence refers to 150 minutes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Parsing Time Spans</title>
+
+    <para>When parsing, systemd will accept the same time span syntax.
+    Separating spaces may be omitted. The following time units are
+    understood:</para>
+
+    <itemizedlist>
+      <listitem><para>usec, us</para></listitem>
+      <listitem><para>msec, ms</para></listitem>
+      <listitem><para>seconds, second, sec, s</para></listitem>
+      <listitem><para>minutes, minute, min, m</para></listitem>
+      <listitem><para>hours, hour, hr, h</para></listitem>
+      <listitem><para>days, day, d</para></listitem>
+      <listitem><para>weeks, week, w</para></listitem>
+      <listitem><para>months, month, M (defined as 30.44 days)</para></listitem>
+      <listitem><para>years, year, y (define as 365.25 days)</para></listitem>
+    </itemizedlist>
+
+    <para>If no time unit is specified, generally seconds are assumed,
+    but some exceptions exist and are marked as such. In a few cases
+    <literal>ns</literal>, <literal>nsec</literal> is accepted too,
+    where the granularity of the time span allows for this.</para>
+
+    <para>Examples for valid time span specifications:</para>
+
+    <programlisting>2 h
+2hours
+48hr
+1y 12month
+55s500ms
+300ms20s 5day</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Displaying Timestamps</title>
+
+    <para>Timestamps refer to specific, unique points in time. On
+    display, systemd will format these in the local timezone as
+    follows:</para>
+
+    <programlisting>Fri 2012-11-23 23:02:15 CET</programlisting>
+
+    <para>The weekday is printed according to the locale choice of the
+    user.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Parsing Timestamps</title>
+
+    <para>When parsing, systemd will accept a similar syntax, but
+    expects no timezone specification, unless it is given as the
+    literal string "UTC". In this case, the time is considered in UTC,
+    otherwise in the local timezone. The weekday specification is
+    optional, but when the weekday is specified, it must either be in
+    the abbreviated (<literal>Wed</literal>) or non-abbreviated
+    (<literal>Wednesday</literal>) English language form (case does
+    not matter), and is not subject to the locale choice of the user.
+    Either the date, or the time part may be omitted, in which case
+    the current date or 00:00:00, respectively, is assumed. The seconds
+    component of the time may also be omitted, in which case ":00" is
+    assumed. Year numbers may be specified in full or may be
+    abbreviated (omitting the century).</para>
+
+    <para>A timestamp is considered invalid if a weekday is specified
+    and the date does not actually match the specified day of the
+    week.</para>
+
+    <para>When parsing, systemd will also accept a few special
+    placeholders instead of timestamps: <literal>now</literal> may be
+    used to refer to the current time (or of the invocation of the
+    command that is currently executed). <literal>today</literal>,
+    <literal>yesterday</literal>, and <literal>tomorrow</literal> refer to
+    00:00:00 of the current day, the day before, or the next day,
+    respectively.</para>
+
+    <para>When parsing, systemd will also accept relative time
+    specifications. A time span (see above) that is prefixed with
+    <literal>+</literal> is evaluated to the current time plus the
+    specified time span. Correspondingly, a time span that is prefixed
+    with <literal>-</literal> is evaluated to the current time minus
+    the specified time span. Instead of prefixing the time span with
+    <literal>+</literal> or <literal>-</literal>, it may also be
+    suffixed with a space and the word <literal>left</literal> or
+    <literal>ago</literal>.</para>
+
+    <para>Finally, a timespan prefixed with <literal>@</literal> is
+    evaluated relative to the UNIX time epoch 1st Jan, 1970,
+    00:00.</para>
+
+    <para>Examples for valid timestamps and their normalized form
+    (assuming the current time was 2012-11-23 18:15:22 and the timezone
+    was UTC+8, for example TZ=Asia/Shanghai):</para>
+
+    <programlisting>Fri 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13
+    2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13
+2012-11-23 11:12:13 UTC → Fri 2012-11-23 19:12:13
+             2012-11-23 → Fri 2012-11-23 00:00:00
+               12-11-23 → Fri 2012-11-23 00:00:00
+               11:12:13 → Fri 2012-11-23 11:12:13
+       11:12:13.9900009 → Fri 2012-11-23 11:12:13
+                          format_timestamp_us: Fri 2012-11-23 11:12:13.990000
+                  11:12 → Fri 2012-11-23 11:12:00
+                    now → Fri 2012-11-23 18:15:22
+                  today → Fri 2012-11-23 00:00:00
+              today UTC → Fri 2012-11-23 16:00:00
+              yesterday → Fri 2012-11-22 00:00:00
+               tomorrow → Fri 2012-11-24 00:00:00
+               +3h30min → Fri 2012-11-23 21:45:22
+           +3h30min UTC → -EINVAL
+                    -5s → Fri 2012-11-23 18:15:17
+              11min ago → Fri 2012-11-23 18:04:22
+          11min ago UTC → -EINVAL
+            @1395716396 → Tue 2014-03-25 03:59:56</programlisting>
+
+    <para>Note that timestamps printed by systemd will not be parsed
+    correctly by systemd, as the timezone specification is not
+    accepted, and printing timestamps is subject to locale settings
+    for the weekday, while parsing only accepts English weekday
+    names.</para>
+
+    <para>In some cases, systemd will display a relative timestamp
+    (relative to the current time, or the time of invocation of the
+    command) instead or in addition to an absolute timestamp as
+    described above. A relative timestamp is formatted as
+    follows:</para>
+
+    <para>2 months 5 days ago</para>
+
+    <para>Note that any relative timestamp will also parse correctly
+    where a timestamp is expected. (see above)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Calendar Events</title>
+
+    <para>Calendar events may be used to refer to one or more points
+    in time in a single expression. They form a superset of the
+    absolute timestamps explained above:</para>
+
+    <programlisting>Thu,Fri 2012-*-1,5 11:12:13</programlisting>
+
+    <para>The above refers to 11:12:13 of the first or fifth day of
+    any month of the year 2012, but only if that day is a Thursday or
+    Friday.</para>
+
+    <para>The weekday specification is optional. If specified, it
+    should consist of one or more English language weekday names,
+    either in the abbreviated (Wed) or non-abbreviated (Wednesday)
+    form (case does not matter), separated by commas. Specifying two
+    weekdays separated by <literal>-</literal> refers to a range of
+    continuous weekdays. <literal>,</literal> and <literal>-</literal>
+    may be combined freely.</para>
+
+    <para>In the date and time specifications, any component may be
+    specified as <literal>*</literal> in which case any value will
+    match. Alternatively, each component can be specified as a list of
+    values separated by commas. Values may also be suffixed with
+    <literal>/</literal> and a repetition value, which indicates that
+    the value and all values plus multiples of the repetition value
+    are matched.</para>
+
+    <para>The seconds component may contain decimal fractions both in
+    the value and the repetition. All fractions are rounded to 6
+    decimal places.</para>
+
+    <para>Either time or date specification may be omitted, in which
+    case the current day and 00:00:00 is implied, respectively. If the
+    second component is not specified, <literal>:00</literal> is
+    assumed.</para>
+
+    <para>A timezone specification is not expected, unless it is given
+    as the literal string "UTC", similarly to timestamps.</para>
+
+    <para>The special expressions
+    <literal>minutely</literal>,
+    <literal>hourly</literal>, <literal>daily</literal>,
+    <literal>monthly</literal>, <literal>weekly</literal>,
+    <literal>yearly</literal>,
+    <literal>quarterly</literal>,
+    <literal>semiannually</literal> may be used as
+    calendar events which refer to
+    <literal>*-*-* *:*:00</literal>,
+    <literal>*-*-* *:00:00</literal>,
+    <literal>*-*-* 00:00:00</literal>,
+    <literal>*-*-01 00:00:00</literal>,
+    <literal>Mon *-*-* 00:00:00</literal>,
+    <literal>*-01-01 00:00:00</literal>,
+    <literal>*-01,04,07,10-01 00:00:00</literal> and
+    <literal>*-01,07-01 00:00:00</literal>, respectively.
+    </para>
+
+    <para>Examples for valid timestamps and their
+    normalized form:</para>
+
+<programlisting>   Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-* 00:00:00
+     Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
+                   Wed *-1 → Wed *-*-01 00:00:00
+           Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
+                Wed, 17:48 → Wed *-*-* 17:48:00
+Wed-Sat,Tue 12-10-15 1:2:3 → Tue-Sat 2012-10-15 01:02:03
+               *-*-7 0:0:0 → *-*-07 00:00:00
+                     10-15 → *-10-15 00:00:00
+       monday *-12-* 17:00 → Mon *-12-* 17:00:00
+ Mon,Fri *-*-3,1,2 *:30:45 → Mon,Fri *-*-01,02,03 *:30:45
+      12,14,13,12:20,10,30 → *-*-* 12,13,14:10,20,30:00
+ mon,fri *-1/2-1,3 *:30:45 → Mon,Fri *-01/2-01,03 *:30:45
+            03-05 08:05:40 → *-03-05 08:05:40
+                  08:05:40 → *-*-* 08:05:40
+                     05:40 → *-*-* 05:40:00
+    Sat,Sun 12-05 08:05:40 → Sat,Sun *-12-05 08:05:40
+          Sat,Sun 08:05:40 → Sat,Sun *-*-* 08:05:40
+          2003-03-05 05:40 → 2003-03-05 05:40:00
+05:40:23.4200004/3.1700005 → 05:40:23.420000/3.170001
+      2003-03-05 05:40 UTC → 2003-03-05 05:40:00 UTC
+                2003-03-05 → 2003-03-05 00:00:00
+                     03-05 → *-03-05 00:00:00
+                    hourly → *-*-* *:00:00
+                     daily → *-*-* 00:00:00
+                 daily UTC → *-*-* 00:00:00 UTC
+                   monthly → *-*-01 00:00:00
+                    weekly → Mon *-*-* 00:00:00
+                    yearly → *-01-01 00:00:00
+                  annually → *-01-01 00:00:00
+                     *:2/3 → *-*-* *:02/3:00</programlisting>
+
+      <para>Calendar events are used by timer units, see
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details.</para>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.timer.xml b/src/grp-system/systemd/systemd.timer.xml
new file mode 100644
index 0000000000..0fa95e97a8
--- /dev/null
+++ b/src/grp-system/systemd/systemd.timer.xml
@@ -0,0 +1,313 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.timer">
+  <refentryinfo>
+    <title>systemd.timer</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.timer</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.timer</refname>
+    <refpurpose>Timer unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>timer</replaceable>.timer</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.timer</literal> encodes information about a timer
+    controlled and supervised by systemd, for timer-based
+    activation.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The timer specific configuration options are
+    configured in the [Timer] section.</para>
+
+    <para>For each timer file, a matching unit file must exist,
+    describing the unit to activate when the timer elapses. By
+    default, a service by the same name as the timer (except for the
+    suffix) is activated. Example: a timer file
+    <filename>foo.timer</filename> activates a matching service
+    <filename>foo.service</filename>. The unit to activate may be
+    controlled by <varname>Unit=</varname> (see below).</para>
+
+    <para>Note that in case the unit to activate is already active at the time the timer elapses it is not restarted,
+    but simply left running. There is no concept of spawning new service instances in this case. Due to this, services
+    with <varname>RemainAfterExit=</varname> set (which stay around continously even after the service's main process
+    exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and
+    then stay around forever.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Timer units automatically gain a <varname>Before=</varname>
+    dependency on the service they are supposed to activate.</para>
+
+    <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section is set to
+    <option>false</option>, all timer units will implicitly have dependencies of type <varname>Requires=</varname> and
+    <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>Before=</varname>
+    on <filename>timers.target</filename>, as well as <varname>Conflicts=</varname> and <varname>Before=</varname> on
+    <filename>shutdown.target</filename> to ensure that they are stopped cleanly prior to system shutdown.  Timer units
+    with at least one <varname>OnCalendar=</varname> directive will have an additional <varname>After=</varname>
+    dependency on <filename>timer-sync.target</filename> to avoid being started before the system clock has been
+    correctly set. Only timer units involved with early boot or late system shutdown should disable the
+    <varname>DefaultDependencies=</varname> option.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Timer files must include a [Timer] section, which carries
+    information about the timer it defines. The options specific to
+    the [Timer] section of timer units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>OnActiveSec=</varname></term>
+        <term><varname>OnBootSec=</varname></term>
+        <term><varname>OnStartupSec=</varname></term>
+        <term><varname>OnUnitActiveSec=</varname></term>
+        <term><varname>OnUnitInactiveSec=</varname></term>
+
+        <listitem><para>Defines monotonic timers relative to different
+        starting points: <varname>OnActiveSec=</varname> defines a
+        timer relative to the moment the timer itself is activated.
+        <varname>OnBootSec=</varname> defines a timer relative to when
+        the machine was booted up. <varname>OnStartupSec=</varname>
+        defines a timer relative to when systemd was first started.
+        <varname>OnUnitActiveSec=</varname> defines a timer relative
+        to when the unit the timer is activating was last activated.
+        <varname>OnUnitInactiveSec=</varname> defines a timer relative
+        to when the unit the timer is activating was last
+        deactivated.</para>
+
+        <para>Multiple directives may be combined of the same and of
+        different types. For example, by combining
+        <varname>OnBootSec=</varname> and
+        <varname>OnUnitActiveSec=</varname>, it is possible to define
+        a timer that elapses in regular intervals and activates a
+        specific service each time.</para>
+
+        <para>The arguments to the directives are time spans
+        configured in seconds. Example: "OnBootSec=50" means 50s after
+        boot-up. The argument may also include time units. Example:
+        "OnBootSec=5h 30min" means 5 hours and 30 minutes after
+        boot-up. For details about the syntax of time spans, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <para>If a timer configured with <varname>OnBootSec=</varname>
+        or <varname>OnStartupSec=</varname> is already in the past
+        when the timer unit is activated, it will immediately elapse
+        and the configured unit is started. This is not the case for
+        timers defined in the other directives.</para>
+
+        <para>These are monotonic timers, independent of wall-clock
+        time and timezones. If the computer is temporarily suspended,
+        the monotonic clock stops too.</para>
+
+        <para>If the empty string is assigned to any of these options,
+        the list of timers is reset, and all prior assignments will
+        have no effect.</para>
+
+        <para>Note that timers do not necessarily expire at the
+        precise time configured with these settings, as they are
+        subject to the <varname>AccuracySec=</varname> setting
+        below.</para></listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnCalendar=</varname></term>
+
+        <listitem><para>Defines realtime (i.e. wallclock) timers with
+        calendar event expressions. See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for more information on the syntax of calendar event
+        expressions. Otherwise, the semantics are similar to
+        <varname>OnActiveSec=</varname> and related settings.</para>
+
+        <para>Note that timers do not necessarily expire at the
+        precise time configured with this setting, as it is subject to
+        the <varname>AccuracySec=</varname> setting
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AccuracySec=</varname></term>
+
+        <listitem><para>Specify the accuracy the timer shall elapse
+        with. Defaults to 1min. The timer is scheduled to elapse
+        within a time window starting with the time specified in
+        <varname>OnCalendar=</varname>,
+        <varname>OnActiveSec=</varname>,
+        <varname>OnBootSec=</varname>,
+        <varname>OnStartupSec=</varname>,
+        <varname>OnUnitActiveSec=</varname> or
+        <varname>OnUnitInactiveSec=</varname> and ending the time
+        configured with <varname>AccuracySec=</varname> later. Within
+        this time window, the expiry time will be placed at a
+        host-specific, randomized, but stable position that is
+        synchronized between all local timer units. This is done in
+        order to optimize power consumption to suppress unnecessary
+        CPU wake-ups. To get best accuracy, set this option to
+        1us. Note that the timer is still subject to the timer slack
+        configured via
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s
+        <varname>TimerSlackNSec=</varname> setting. See
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. To optimize power consumption, make sure to set
+        this value as high as possible and as low as
+        necessary.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RandomizedDelaySec=</varname></term>
+
+        <listitem><para>Delay the timer by a randomly selected, evenly
+        distributed amount of time between 0 and the specified time
+        value. Defaults to 0, indicating that no randomized delay
+        shall be applied. Each timer unit will determine this delay
+        randomly each time it is started, and the delay will simply be
+        added on top of the next determined elapsing time. This is
+        useful to stretch dispatching of similarly configured timer
+        events over a certain amount time, to avoid that they all fire
+        at the same time, possibly resulting in resource
+        congestion. Note the relation to
+        <varname>AccuracySec=</varname> above: the latter allows the
+        service manager to coalesce timer events within a specified
+        time range in order to minimize wakeups, the former does the
+        opposite: it stretches timer events over a time range, to make
+        it unlikely that they fire simultaneously. If
+        <varname>RandomizedDelaySec=</varname> and
+        <varname>AccuracySec=</varname> are used in conjunction, first
+        the randomized delay is added, and then the result is
+        possibly further shifted to coalesce it with other timer
+        events happening on the system. As mentioned above
+        <varname>AccuracySec=</varname> defaults to 1min and
+        <varname>RandomizedDelaySec=</varname> to 0, thus encouraging
+        coalescing of timer events. In order to optimally stretch
+        timer events over a certain range of time, make sure to set
+        <varname>RandomizedDelaySec=</varname> to a higher value, and
+        <varname>AccuracySec=1us</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Unit=</varname></term>
+
+        <listitem><para>The unit to activate when this timer elapses.
+        The argument is a unit name, whose suffix is not
+        <literal>.timer</literal>. If not specified, this value
+        defaults to a service that has the same name as the timer
+        unit, except for the suffix. (See above.) It is recommended
+        that the unit name that is activated and the unit name of the
+        timer unit are named identically, except for the
+        suffix.</para></listitem>
+      </varlistentry>
+
+
+      <varlistentry>
+        <term><varname>Persistent=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, the time
+        when the service unit was last triggered is stored on disk.
+        When the timer is activated, the service unit is triggered
+        immediately if it would have been triggered at least once
+        during the time when the timer was inactive. This is useful to
+        catch up on missed runs of the service when the machine was
+        off. Note that this setting only has an effect on timers
+        configured with <varname>OnCalendar=</varname>. Defaults
+        to <varname>false</varname>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WakeSystem=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, an elapsing
+        timer will cause the system to resume from suspend, should it
+        be suspended and if the system supports this. Note that this
+        option will only make sure the system resumes on the
+        appropriate times, it will not take care of suspending it
+        again after any work that is to be done is finished. Defaults
+        to <varname>false</varname>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemainAfterElapse=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, an elapsed
+        timer will stay loaded, and its state remains queriable. If
+        false, an elapsed timer unit that cannot elapse anymore is
+        unloaded. Turning this off is particularly useful for
+        transient timer units that shall disappear after they first
+        elapse. Note that this setting has an effect on repeatedly
+        starting a timer unit that only elapses once: if
+        <varname>RemainAfterElapse=</varname> is on, it will not be
+        started again, and is guaranteed to elapse only once. However,
+        if <varname>RemainAfterElapse=</varname> is off, it might be
+        started again if it is already elapsed, and thus be triggered
+        multiple times. Defaults to
+        <varname>yes</varname>.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </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.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.unit.xml b/src/grp-system/systemd/systemd.unit.xml
new file mode 100644
index 0000000000..341789cd47
--- /dev/null
+++ b/src/grp-system/systemd/systemd.unit.xml
@@ -0,0 +1,1484 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!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;
+]>
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd.unit">
+
+  <refentryinfo>
+    <title>systemd.unit</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.unit</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.unit</refname>
+    <refpurpose>Unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename>,
+    <filename><replaceable>socket</replaceable>.socket</filename>,
+    <filename><replaceable>device</replaceable>.device</filename>,
+    <filename><replaceable>mount</replaceable>.mount</filename>,
+    <filename><replaceable>automount</replaceable>.automount</filename>,
+    <filename><replaceable>swap</replaceable>.swap</filename>,
+    <filename><replaceable>target</replaceable>.target</filename>,
+    <filename><replaceable>path</replaceable>.path</filename>,
+    <filename><replaceable>timer</replaceable>.timer</filename>,
+    <filename><replaceable>slice</replaceable>.slice</filename>,
+    <filename><replaceable>scope</replaceable>.scope</filename></para>
+
+    <para><literallayout><filename>/etc/systemd/system/*</filename>
+<filename>/run/systemd/system/*</filename>
+<filename>/usr/lib/systemd/system/*</filename>
+<filename>…</filename>
+    </literallayout></para>
+
+    <para><literallayout><filename>~/.config/systemd/user/*</filename>
+<filename>/etc/systemd/user/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/user/*</filename>
+<filename>/run/systemd/user/*</filename>
+<filename>~/.local/share/systemd/user/*</filename>
+<filename>/usr/lib/systemd/user/*</filename>
+<filename>…</filename>
+    </literallayout></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file encodes information about a
+    service, a socket, a device, a mount point, an automount point, a
+    swap file or partition, a start-up target, a watched file system
+    path, a timer controlled and supervised by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    a resource management slice or
+    a group of externally created processes. The syntax is inspired by
+    <ulink
+    url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG
+    Desktop Entry Specification</ulink> <filename>.desktop</filename>
+    files, which are in turn inspired by Microsoft Windows
+    <filename>.ini</filename> files.</para>
+
+    <para>This man page lists the common configuration options of all
+    the unit types. These options need to be configured in the [Unit]
+    or [Install] sections of the unit files.</para>
+
+    <para>In addition to the generic [Unit] and [Install] sections
+    described here, each unit may have a type-specific section, e.g.
+    [Service] for a service unit. See the respective man pages for
+    more information:
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Various settings are allowed to be specified more than once,
+    in which case the interpretation depends on the setting. Often,
+    multiple settings form a list, and setting to an empty value
+    "resets", which means that previous assignments are ignored. When
+    this is allowed, it is mentioned in the description of the
+    setting. Note that using multiple assignments to the same value
+    makes the unit file incompatible with parsers for the XDG
+    <filename>.desktop</filename> file format.</para>
+
+    <para>Unit files are loaded from a set of paths determined during
+    compilation, described in the next section.</para>
+
+    <para>Unit files may contain additional options on top of those
+    listed here. If systemd encounters an unknown option, it will
+    write a warning log message but continue loading the unit. If an
+    option or section name is prefixed with <option>X-</option>, it is
+    ignored completely by systemd. Options within an ignored section
+    do not need the prefix. Applications may use this to include
+    additional information in the unit files.</para>
+
+    <para>Boolean arguments used in unit files can be written in
+    various formats. For positive settings the strings
+    <option>1</option>, <option>yes</option>, <option>true</option>
+    and <option>on</option> are equivalent. For negative settings, the
+    strings <option>0</option>, <option>no</option>,
+    <option>false</option> and <option>off</option> are
+    equivalent.</para>
+
+    <para>Time span values encoded in unit files can be written in
+    various formats. A stand-alone number specifies a time in seconds.
+    If suffixed with a time unit, the unit is honored. A concatenation
+    of multiple values with units is supported, in which case the
+    values are added up. Example: "50" refers to 50 seconds; "2min
+    200ms" refers to 2 minutes plus 200 milliseconds, i.e. 120200ms.
+    The following time units are understood: s, min, h, d, w, ms, us.
+    For details see
+    <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>Empty lines and lines starting with # or ; are
+    ignored. This may be used for commenting. Lines ending
+    in a backslash are concatenated with the following
+    line while reading and the backslash is replaced by a
+    space character. This may be used to wrap long lines.</para>
+
+    <para>Along with a unit file <filename>foo.service</filename>, the
+    directory <filename>foo.service.wants/</filename> may exist. All
+    unit files symlinked from such a directory are implicitly added as
+    dependencies of type <varname>Wants=</varname> to the unit. This
+    is useful to hook units into the start-up of other units, without
+    having to modify their unit files. For details about the semantics
+    of <varname>Wants=</varname>, see below. The preferred way to
+    create symlinks in the <filename>.wants/</filename> directory of a
+    unit file is with the <command>enable</command> command of the
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool which reads information from the [Install] section of unit
+    files (see below). A similar functionality exists for
+    <varname>Requires=</varname> type dependencies as well, the
+    directory suffix is <filename>.requires/</filename> in this
+    case.</para>
+
+    <para>Along with a unit file <filename>foo.service</filename>, a "drop-in" directory
+    <filename>foo.service.d/</filename> may exist. All files with the suffix <literal>.conf</literal> from this
+    directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings for
+    a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for
+    instantiated units, this logic will first look for the instance <literal>.d/</literal> subdirectory and read its
+    <literal>.conf</literal> files, followed by the template <literal>.d/</literal> subdirectory and the
+    <literal>.conf</literal> files there. Also note that settings from the <literal>[Install]</literal> section are not
+    honoured in drop-in unit files, and have no effect.</para>
+
+    <para>In addition to <filename>/etc/systemd/system</filename>,
+    the drop-in <literal>.conf</literal> files for system services
+    can be placed in <filename>/usr/lib/systemd/system</filename> or
+    <filename>/run/systemd/system</filename> directories. Drop-in
+    files in <filename>/etc</filename> take precedence over those in
+    <filename>/run</filename> which in turn take precedence over
+    those in <filename>/usr/lib</filename>. Drop-in files under any of
+    these directories take precedence over unit files wherever located.
+    (Of course, since <filename>/run</filename> is temporary and
+    <filename>/usr/lib</filename> is for vendors, it is unlikely
+    drop-ins should be used in either of those places.)</para>
+    <!-- Note that we do not document .include here, as we
+         consider it mostly obsolete, and want people to
+         use .d/ drop-ins instead. -->
+
+    <para>Some unit names reflect paths existing in the file system
+    namespace. Example: a device unit
+    <filename>dev-sda.device</filename> refers to a device with the
+    device node <filename noindex='true'>/dev/sda</filename> in the
+    file system namespace. If this applies, a special way to escape
+    the path name is used, so that the result is usable as part of a
+    filename. Basically, given a path, "/" is replaced by "-", and all
+    other characters which are not ASCII alphanumerics are replaced by
+    C-style "\x2d" escapes (except that "_" is never replaced and "."
+    is only replaced when it would be the first character in the
+    escaped path). The root directory "/" is encoded as single dash,
+    while otherwise the initial and ending "/" are removed from all
+    paths during transformation. This escaping is reversible. Properly
+    escaped paths can be generated using the
+    <citerefentry><refentrytitle>systemd-escape</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    command.</para>
+
+    <para>Optionally, units may be instantiated from a
+    template file at runtime. This allows creation of
+    multiple units from a single configuration file. If
+    systemd looks for a unit configuration file, it will
+    first search for the literal unit name in the
+    file system. If that yields no success and the unit
+    name contains an <literal>@</literal> character, systemd will look for a
+    unit template that shares the same name but with the
+    instance string (i.e. the part between the <literal>@</literal> character
+    and the suffix) removed. Example: if a service
+    <filename>getty@tty3.service</filename> is requested
+    and no file by that name is found, systemd will look
+    for <filename>getty@.service</filename> and
+    instantiate a service from that configuration file if
+    it is found.</para>
+
+    <para>To refer to the instance string from within the
+    configuration file you may use the special <literal>%i</literal>
+    specifier in many of the configuration options. See below for
+    details.</para>
+
+    <para>If a unit file is empty (i.e. has the file size 0) or is
+    symlinked to <filename>/dev/null</filename>, its configuration
+    will not be loaded and it appears with a load state of
+    <literal>masked</literal>, and cannot be activated. Use this as an
+    effective way to fully disable a unit, making it impossible to
+    start it even manually.</para>
+
+    <para>The unit file format is covered by the
+    <ulink
+    url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
+    Stability Promise</ulink>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <para>Note that while systemd offers a flexible dependency system
+    between units it is recommended to use this functionality only
+    sparingly and instead rely on techniques such as bus-based or
+    socket-based activation which make dependencies implicit,
+    resulting in a both simpler and more flexible system.</para>
+
+    <para>A number of unit dependencies are automatically established,
+    depending on unit configuration. On top of that, for units with
+    <varname>DefaultDependencies=yes</varname> (the default) a couple
+    of additional dependencies are added. The precise effect of
+    <varname>DefaultDependencies=yes</varname> depends on the unit
+    type (see below).</para>
+
+    <para>If <varname>DefaultDependencies=yes</varname> is set, units
+    that are referenced by other units of type
+    <filename>.target</filename> via a <varname>Wants=</varname> or
+    <varname>Requires=</varname> dependency might automatically gain
+    an <varname>Before=</varname> dependency too. See
+    <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Unit File Load Path</title>
+
+    <para>Unit files are loaded from a set of paths determined during
+    compilation, described in the two tables below. Unit files found
+    in directories listed earlier override files with the same name in
+    directories lower in the list.</para>
+
+    <para>When the variable <varname>$SYSTEMD_UNIT_PATH</varname> is set,
+    the contents of this variable overrides the unit load path. If
+    <varname>$SYSTEMD_UNIT_PATH</varname> ends with an empty component
+    (<literal>:</literal>), the usual unit load path will be appended
+    to the contents of the variable.</para>
+
+    <table>
+      <title>
+        Load path when running in system mode (<option>--system</option>).
+      </title>
+
+      <tgroup cols='2'>
+        <colspec colname='path' />
+        <colspec colname='expl' />
+        <thead>
+          <row>
+      <entry>Path</entry>
+      <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><filename>/etc/systemd/system</filename></entry>
+      <entry>Local configuration</entry>
+          </row>
+          <row>
+      <entry><filename>/run/systemd/system</filename></entry>
+      <entry>Runtime units</entry>
+          </row>
+          <row>
+      <entry><filename>/usr/lib/systemd/system</filename></entry>
+      <entry>Units of installed packages</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table>
+      <title>
+        Load path when running in user mode (<option>--user</option>).
+      </title>
+
+      <tgroup cols='2'>
+        <colspec colname='path' />
+        <colspec colname='expl' />
+        <thead>
+          <row>
+      <entry>Path</entry>
+      <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename></entry>
+      <entry>User configuration (only used when $XDG_CONFIG_HOME is set)</entry>
+          </row>
+          <row>
+      <entry><filename>$HOME/.config/systemd/user</filename></entry>
+      <entry>User configuration (only used when $XDG_CONFIG_HOME is not set)</entry>
+          </row>
+          <row>
+      <entry><filename>/etc/systemd/user</filename></entry>
+      <entry>Local configuration</entry>
+          </row>
+          <row>
+      <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry>
+      <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry>
+          </row>
+          <row>
+      <entry><filename>/run/systemd/user</filename></entry>
+      <entry>Runtime units</entry>
+          </row>
+          <row>
+      <entry><filename>$XDG_DATA_HOME/systemd/user</filename></entry>
+      <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is set)</entry>
+          </row>
+          <row>
+      <entry><filename>$HOME/.local/share/systemd/user</filename></entry>
+      <entry>Units of packages that have been installed in the home directory (only used when $XDG_DATA_HOME is not set)</entry>
+          </row>
+          <row>
+      <entry><filename>/usr/lib/systemd/user</filename></entry>
+      <entry>Units of packages that have been installed system-wide</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Additional units might be loaded into systemd ("linked")
+    from directories not on the unit load path. See the
+    <command>link</command> command for
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    Also, some units are dynamically created via a
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Unit] Section Options</title>
+
+    <para>The unit file may include a [Unit] section, which carries
+    generic information about the unit that is not dependent on the
+    type of unit:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>Description=</varname></term>
+        <listitem><para>A free-form string describing the unit. This
+        is intended for use in UIs to show descriptive information
+        along with the unit name. The description should contain a
+        name that means something to the end user. <literal>Apache2
+        Web Server</literal> is a good example. Bad examples are
+        <literal>high-performance light-weight HTTP server</literal>
+        (too generic) or <literal>Apache2</literal> (too specific and
+        meaningless for people who do not know
+        Apache).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Documentation=</varname></term>
+        <listitem><para>A space-separated list of URIs referencing
+        documentation for this unit or its configuration. Accepted are
+        only URIs of the types <literal>http://</literal>,
+        <literal>https://</literal>, <literal>file:</literal>,
+        <literal>info:</literal>, <literal>man:</literal>. For more
+        information about the syntax of these URIs, see <citerefentry
+        project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        The URIs should be listed in order of relevance, starting with
+        the most relevant. It is a good idea to first reference
+        documentation that explains what the unit's purpose is,
+        followed by how it is configured, followed by any other
+        related documentation. This option may be specified more than
+        once, in which case the specified list of URIs is merged. If
+        the empty string is assigned to this option, the list is reset
+        and all prior assignments will have no
+        effect.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Requires=</varname></term>
+
+        <listitem><para>Configures requirement dependencies on other
+        units. If this unit gets activated, the units listed here will
+        be activated as well. If one of the other units gets
+        deactivated or its activation fails, this unit will be
+        deactivated. This option may be specified more than once or
+        multiple space-separated units may be specified in one option
+        in which case requirement dependencies for all listed names
+        will be created. Note that requirement dependencies do not
+        influence the order in which services are started or stopped.
+        This has to be configured independently with the
+        <varname>After=</varname> or <varname>Before=</varname>
+        options. If a unit <filename>foo.service</filename> requires a
+        unit <filename>bar.service</filename> as configured with
+        <varname>Requires=</varname> and no ordering is configured
+        with <varname>After=</varname> or <varname>Before=</varname>,
+        then both units will be started simultaneously and without any
+        delay between them if <filename>foo.service</filename> is
+        activated. Often, it is a better choice to use
+        <varname>Wants=</varname> instead of
+        <varname>Requires=</varname> in order to achieve a system that
+        is more robust when dealing with failing services.</para>
+
+        <para>Note that dependencies of this type may also be
+        configured outside of the unit configuration file by adding a
+        symlink to a <filename>.requires/</filename> directory
+        accompanying the unit file. For details, see
+        above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Requisite=</varname></term>
+
+        <listitem><para>Similar to <varname>Requires=</varname>.
+        However, if the units listed here are not started already,
+        they will not be started and the transaction will fail
+        immediately. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Wants=</varname></term>
+
+        <listitem><para>A weaker version of
+        <varname>Requires=</varname>. Units listed in this option will
+        be started if the configuring unit is. However, if the listed
+        units fail to start or cannot be added to the transaction,
+        this has no impact on the validity of the transaction as a
+        whole. This is the recommended way to hook start-up of one
+        unit to the start-up of another unit.</para>
+
+        <para>Note that dependencies of this type may also be
+        configured outside of the unit configuration file by adding
+        symlinks to a <filename>.wants/</filename> directory
+        accompanying the unit file. For details, see
+        above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindsTo=</varname></term>
+
+        <listitem><para>Configures requirement dependencies, very
+        similar in style to <varname>Requires=</varname>, however in
+        addition to this behavior, it also declares that this unit is
+        stopped when any of the units listed suddenly disappears.
+        Units can suddenly, unexpectedly disappear if a service
+        terminates on its own choice, a device is unplugged or a mount
+        point unmounted without involvement of
+        systemd.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PartOf=</varname></term>
+
+        <listitem><para>Configures dependencies similar to
+        <varname>Requires=</varname>, but limited to stopping and
+        restarting of units. When systemd stops or restarts the units
+        listed here, the action is propagated to this unit. Note that
+        this is a one-way dependency — changes to this unit do not
+        affect the listed units. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Conflicts=</varname></term>
+
+        <listitem><para>A space-separated list of unit names.
+        Configures negative requirement dependencies. If a unit has a
+        <varname>Conflicts=</varname> setting on another unit,
+        starting the former will stop the latter and vice versa. Note
+        that this setting is independent of and orthogonal to the
+        <varname>After=</varname> and <varname>Before=</varname>
+        ordering dependencies.</para>
+
+        <para>If a unit A that conflicts with a unit B is scheduled to
+        be started at the same time as B, the transaction will either
+        fail (in case both are required part of the transaction) or be
+        modified to be fixed (in case one or both jobs are not a
+        required part of the transaction). In the latter case, the job
+        that is not the required will be removed, or in case both are
+        not required, the unit that conflicts will be started and the
+        unit that is conflicted is stopped.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Before=</varname></term>
+        <term><varname>After=</varname></term>
+
+        <listitem><para>A space-separated list of unit names.
+        Configures ordering dependencies between units. If a unit
+        <filename>foo.service</filename> contains a setting
+        <option>Before=bar.service</option> and both units are being
+        started, <filename>bar.service</filename>'s start-up is
+        delayed until <filename>foo.service</filename> is started up.
+        Note that this setting is independent of and orthogonal to the
+        requirement dependencies as configured by
+        <varname>Requires=</varname>. It is a common pattern to
+        include a unit name in both the <varname>After=</varname> and
+        <varname>Requires=</varname> option, in which case the unit
+        listed will be started before the unit that is configured with
+        these options. This option may be specified more than once, in
+        which case ordering dependencies for all listed names are
+        created. <varname>After=</varname> is the inverse of
+        <varname>Before=</varname>, i.e. while
+        <varname>After=</varname> ensures that the configured unit is
+        started after the listed unit finished starting up,
+        <varname>Before=</varname> ensures the opposite, i.e. that the
+        configured unit is fully started up before the listed unit is
+        started. Note that when two units with an ordering dependency
+        between them are shut down, the inverse of the start-up order
+        is applied. i.e. if a unit is configured with
+        <varname>After=</varname> on another unit, the former is
+        stopped before the latter if both are shut down. Given two units
+        with any ordering dependency between them, if one unit is shut
+        down and the other is started up, the shutdown is ordered
+        before the start-up. It doesn't matter if the ordering
+        dependency is <varname>After=</varname> or
+        <varname>Before=</varname>. It also doesn't matter which of the
+        two is shut down, as long as one is shut down and the other is
+        started up. The shutdown is ordered before the start-up in all
+        cases. If two units have no ordering dependencies between them,
+        they are shut down or started up simultaneously, and no ordering
+        takes place.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnFailure=</varname></term>
+
+        <listitem><para>A space-separated list of one or more units
+        that are activated when this unit enters the
+        <literal>failed</literal> state.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PropagatesReloadTo=</varname></term>
+        <term><varname>ReloadPropagatedFrom=</varname></term>
+
+        <listitem><para>A space-separated list of one or more units
+        where reload requests on this unit will be propagated to, or
+        reload requests on the other unit will be propagated to this
+        unit, respectively. Issuing a reload request on a unit will
+        automatically also enqueue a reload request on all units that
+        the reload request shall be propagated to via these two
+        settings.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>JoinsNamespaceOf=</varname></term>
+
+        <listitem><para>For units that start processes (such as
+        service units), lists one or more other units whose network
+        and/or temporary file namespace to join. This only applies to
+        unit types which support the
+        <varname>PrivateNetwork=</varname> and
+        <varname>PrivateTmp=</varname> directives (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details). If a unit that has this setting set is started,
+        its processes will see the same <filename>/tmp</filename>,
+        <filename>/var/tmp</filename> and network namespace as one
+        listed unit that is started. If multiple listed units are
+        already started, it is not defined which namespace is joined.
+        Note that this setting only has an effect if
+        <varname>PrivateNetwork=</varname> and/or
+        <varname>PrivateTmp=</varname> is enabled for both the unit
+        that joins the namespace and the unit whose namespace is
+        joined.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RequiresMountsFor=</varname></term>
+
+        <listitem><para>Takes a space-separated list of absolute
+        paths. Automatically adds dependencies of type
+        <varname>Requires=</varname> and <varname>After=</varname> for
+        all mount units required to access the specified path.</para>
+
+        <para>Mount points marked with <option>noauto</option> are not
+        mounted automatically and will be ignored for the purposes of
+        this option. If such a mount should be a requirement for this
+        unit, direct dependencies on the mount units may be added
+        (<varname>Requires=</varname> and <varname>After=</varname> or
+        some other combination). </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnFailureJobMode=</varname></term>
+
+        <listitem><para>Takes a value of
+        <literal>fail</literal>,
+        <literal>replace</literal>,
+        <literal>replace-irreversibly</literal>,
+        <literal>isolate</literal>,
+        <literal>flush</literal>,
+        <literal>ignore-dependencies</literal> or
+        <literal>ignore-requirements</literal>. Defaults to
+        <literal>replace</literal>. Specifies how the units listed in
+        <varname>OnFailure=</varname> will be enqueued. See
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <option>--job-mode=</option> option for details on the
+        possible values. If this is set to <literal>isolate</literal>,
+        only a single unit may be listed in
+        <varname>OnFailure=</varname>..</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IgnoreOnIsolate=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit will not be stopped when
+        isolating another unit. Defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StopWhenUnneeded=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit will be stopped when it is no
+        longer used. Note that, in order to minimize the work to be
+        executed, systemd will not stop units by default unless they
+        are conflicting with other units, or the user explicitly
+        requested their shut down. If this option is set, a unit will
+        be automatically cleaned up if no other active unit requires
+        it. Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RefuseManualStart=</varname></term>
+        <term><varname>RefuseManualStop=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit can only be activated or
+        deactivated indirectly. In this case, explicit start-up or
+        termination requested by the user is denied, however if it is
+        started or stopped as a dependency of another unit, start-up
+        or termination will succeed. This is mostly a safety feature
+        to ensure that the user does not accidentally activate units
+        that are not intended to be activated explicitly, and not
+        accidentally deactivate units that are not intended to be
+        deactivated. These options default to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllowIsolate=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit may be used with the
+        <command>systemctl isolate</command> command. Otherwise, this
+        will be refused. It probably is a good idea to leave this
+        disabled except for target units that shall be used similar to
+        runlevels in SysV init systems, just as a precaution to avoid
+        unusable system states. This option defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultDependencies=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, (the default), a few default
+        dependencies will implicitly be created for the unit. The
+        actual dependencies created depend on the unit type. For
+        example, for service units, these dependencies ensure that the
+        service is started only after basic system initialization is
+        completed and is properly terminated on system shutdown. See
+        the respective man pages for details. Generally, only services
+        involved with early boot or late shutdown should set this
+        option to <option>false</option>. It is highly recommended to
+        leave this option enabled for the majority of common units. If
+        set to <option>false</option>, this option does not disable
+        all implicit dependencies, just non-essential
+        ones.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>JobTimeoutSec=</varname></term>
+        <term><varname>JobTimeoutAction=</varname></term>
+        <term><varname>JobTimeoutRebootArgument=</varname></term>
+
+        <listitem><para>When a job for this unit is queued, a time-out may be configured. If this time limit is
+        reached, the job will be cancelled, the unit however will not change state or even enter the
+        <literal>failed</literal> mode. This value defaults to <literal>infinity</literal> (job timeouts disabled),
+        except for device units. NB: this timeout is independent from any unit-specific timeout (for example, the
+        timeout set with <varname>TimeoutStartSec=</varname> in service units) as the job timeout has no effect on the
+        unit itself, only on the job that might be pending for it. Or in other words: unit-specific timeouts are useful
+        to abort unit state changes, and revert them. The job timeout set with this option however is useful to abort
+        only the job waiting for the unit state to change.</para>
+
+        <para><varname>JobTimeoutAction=</varname>
+        optionally configures an additional
+        action to take when the time-out is
+        hit. It takes the same values as the
+        per-service
+        <varname>StartLimitAction=</varname>
+        setting, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. Defaults to
+        <option>none</option>. <varname>JobTimeoutRebootArgument=</varname>
+        configures an optional reboot string
+        to pass to the
+        <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        system call.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StartLimitIntervalSec=</varname></term>
+        <term><varname>StartLimitBurst=</varname></term>
+
+        <listitem><para>Configure unit start rate limiting. By default, units which are started more than 5 times
+        within 10 seconds are not permitted to start any more times until the 10 second interval ends. With these two
+        options, this rate limiting may be modified. Use <varname>StartLimitIntervalSec=</varname> to configure the
+        checking interval (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file,
+        set to 0 to disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many
+        starts per interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager
+        configuration file). These configuration options are particularly useful in conjunction with the service
+        setting <varname>Restart=</varname> (see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>); however,
+        they apply to all kinds of starts (including manual), not just those triggered by the
+        <varname>Restart=</varname> logic. Note that units which are configured for <varname>Restart=</varname> and
+        which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted
+        manually at a later point, from which point on, the restart logic is again activated. Note that
+        <command>systemctl reset-failed</command> will cause the restart rate counter for a service to be flushed,
+        which is useful if the administrator wants to manually start a unit and the start limit interferes with
+        that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit
+        activations with failing conditions are not counted by this rate limiting. Slice, target, device and scope
+        units do not enforce this setting, as they are unit types whose activation may either never fail, or may
+        succeed only a single time.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StartLimitAction=</varname></term>
+
+        <listitem><para>Configure the action to take if the rate limit configured with
+        <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> is hit. Takes one of
+        <option>none</option>, <option>reboot</option>, <option>reboot-force</option>,
+        <option>reboot-immediate</option>, <option>poweroff</option>, <option>poweroff-force</option> or
+        <option>poweroff-immediate</option>. If <option>none</option> is set, hitting the rate limit will trigger no
+        action besides that the start will not be permitted. <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. Similarly, <option>poweroff</option>, <option>poweroff-force</option>,
+        <option>poweroff-immediate</option> have the effect of powering down the system with similar
+        semantics. Defaults to <option>none</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RebootArgument=</varname></term>
+        <listitem><para>Configure the optional argument for the
+        <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call if
+        <varname>StartLimitAction=</varname> or a service's <varname>FailureAction=</varname> is a reboot action. This
+        works just like the optional argument to <command>systemctl reboot</command> command.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ConditionArchitecture=</varname></term>
+        <term><varname>ConditionVirtualization=</varname></term>
+        <term><varname>ConditionHost=</varname></term>
+        <term><varname>ConditionKernelCommandLine=</varname></term>
+        <term><varname>ConditionSecurity=</varname></term>
+        <term><varname>ConditionCapability=</varname></term>
+        <term><varname>ConditionACPower=</varname></term>
+        <term><varname>ConditionNeedsUpdate=</varname></term>
+        <term><varname>ConditionFirstBoot=</varname></term>
+        <term><varname>ConditionPathExists=</varname></term>
+        <term><varname>ConditionPathExistsGlob=</varname></term>
+        <term><varname>ConditionPathIsDirectory=</varname></term>
+        <term><varname>ConditionPathIsSymbolicLink=</varname></term>
+        <term><varname>ConditionPathIsMountPoint=</varname></term>
+        <term><varname>ConditionPathIsReadWrite=</varname></term>
+        <term><varname>ConditionDirectoryNotEmpty=</varname></term>
+        <term><varname>ConditionFileNotEmpty=</varname></term>
+        <term><varname>ConditionFileIsExecutable=</varname></term>
+
+        <!-- We do not document ConditionNull=
+             here, as it is not particularly
+             useful and probably just
+             confusing. -->
+
+        <listitem><para>Before starting a unit, verify that the specified condition is true. If it is not true, the
+        starting of the unit will be (mostly silently) skipped, however all ordering dependencies of it are still
+        respected. A failing condition will not result in the unit being moved into a failure state. The condition is
+        checked at the time the queued start job is to be executed. Use condition expressions in order to silently skip
+        units that do not apply to the local running system, for example because the kernel or runtime environment
+        doesn't require its functionality. Use the various <varname>AssertArchitecture=</varname>,
+        <varname>AssertVirtualization=</varname>, … options for a similar mechanism that puts the unit in a failure
+        state and logs about the failed check (see below).</para>
+
+        <para><varname>ConditionArchitecture=</varname> may be used to
+        check whether the system is running on a specific
+        architecture. Takes one of
+        <varname>x86</varname>,
+        <varname>x86-64</varname>,
+        <varname>ppc</varname>,
+        <varname>ppc-le</varname>,
+        <varname>ppc64</varname>,
+        <varname>ppc64-le</varname>,
+        <varname>ia64</varname>,
+        <varname>parisc</varname>,
+        <varname>parisc64</varname>,
+        <varname>s390</varname>,
+        <varname>s390x</varname>,
+        <varname>sparc</varname>,
+        <varname>sparc64</varname>,
+        <varname>mips</varname>,
+        <varname>mips-le</varname>,
+        <varname>mips64</varname>,
+        <varname>mips64-le</varname>,
+        <varname>alpha</varname>,
+        <varname>arm</varname>,
+        <varname>arm-be</varname>,
+        <varname>arm64</varname>,
+        <varname>arm64-be</varname>,
+        <varname>sh</varname>,
+        <varname>sh64</varname>,
+        <varname>m86k</varname>,
+        <varname>tilegx</varname>,
+        <varname>cris</varname> to test
+        against a specific architecture. The architecture is
+        determined from the information returned by
+        <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        and is thus subject to
+        <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+        Note that a <varname>Personality=</varname> setting in the
+        same unit file has no effect on this condition. A special
+        architecture name <varname>native</varname> is mapped to the
+        architecture the system manager itself is compiled for. The
+        test may be negated by prepending an exclamation mark.</para>
+
+        <para><varname>ConditionVirtualization=</varname> may be used
+        to check whether the system is executed in a virtualized
+        environment and optionally test whether it is a specific
+        implementation. Takes either boolean value to check if being
+        executed in any virtualized environment, or one of
+        <varname>vm</varname> and
+        <varname>container</varname> to test against a generic type of
+        virtualization solution, or one of
+        <varname>qemu</varname>,
+        <varname>kvm</varname>,
+        <varname>zvm</varname>,
+        <varname>vmware</varname>,
+        <varname>microsoft</varname>,
+        <varname>oracle</varname>,
+        <varname>xen</varname>,
+        <varname>bochs</varname>,
+        <varname>uml</varname>,
+        <varname>openvz</varname>,
+        <varname>lxc</varname>,
+        <varname>lxc-libvirt</varname>,
+        <varname>systemd-nspawn</varname>,
+        <varname>docker</varname>,
+        <varname>rkt</varname> to test
+        against a specific implementation. See
+        <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for a full list of known virtualization technologies and their
+        identifiers. If multiple virtualization technologies are
+        nested, only the innermost is considered. The test may be
+        negated by prepending an exclamation mark.</para>
+
+        <para><varname>ConditionHost=</varname> may be used to match
+        against the hostname or machine ID of the host. This either
+        takes a hostname string (optionally with shell style globs)
+        which is tested against the locally set hostname as returned
+        by
+        <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        or a machine ID formatted as string (see
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        The test may be negated by prepending an exclamation
+        mark.</para>
+
+        <para><varname>ConditionKernelCommandLine=</varname> may be
+        used to check whether a specific kernel command line option is
+        set (or if prefixed with the exclamation mark unset). The
+        argument must either be a single word, or an assignment (i.e.
+        two words, separated <literal>=</literal>). In the former case
+        the kernel command line is searched for the word appearing as
+        is, or as left hand side of an assignment. In the latter case,
+        the exact assignment is looked for with right and left hand
+        side matching.</para>
+
+        <para><varname>ConditionSecurity=</varname> may be used to
+        check whether the given security module is enabled on the
+        system. Currently, the recognized values are
+        <varname>selinux</varname>,
+        <varname>apparmor</varname>,
+        <varname>ima</varname>,
+        <varname>smack</varname> and
+        <varname>audit</varname>. The test may be negated by
+        prepending an exclamation mark.</para>
+
+        <para><varname>ConditionCapability=</varname> may be used to
+        check whether the given capability exists in the capability
+        bounding set of the service manager (i.e. this does not check
+        whether capability is actually available in the permitted or
+        effective sets, see
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). Pass a capability name such as
+        <literal>CAP_MKNOD</literal>, possibly prefixed with an
+        exclamation mark to negate the check.</para>
+
+        <para><varname>ConditionACPower=</varname> may be used to
+        check whether the system has AC power, or is exclusively
+        battery powered at the time of activation of the unit. This
+        takes a boolean argument. If set to <varname>true</varname>,
+        the condition will hold only if at least one AC connector of
+        the system is connected to a power source, or if no AC
+        connectors are known. Conversely, if set to
+        <varname>false</varname>, the condition will hold only if
+        there is at least one AC connector known and all AC connectors
+        are disconnected from a power source.</para>
+
+        <para><varname>ConditionNeedsUpdate=</varname> takes one of
+        <filename>/var</filename> or <filename>/etc</filename> as
+        argument, possibly prefixed with a <literal>!</literal> (for
+        inverting the condition). This condition may be used to
+        conditionalize units on whether the specified directory
+        requires an update because <filename>/usr</filename>'s
+        modification time is newer than the stamp file
+        <filename>.updated</filename> in the specified directory. This
+        is useful to implement offline updates of the vendor operating
+        system resources in <filename>/usr</filename> that require
+        updating of <filename>/etc</filename> or
+        <filename>/var</filename> on the next following boot. Units
+        making use of this condition should order themselves before
+        <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        to make sure they run before the stamp file's modification
+        time gets reset indicating a completed update.</para>
+
+        <para><varname>ConditionFirstBoot=</varname> takes a boolean
+        argument. This condition may be used to conditionalize units
+        on whether the system is booting up with an unpopulated
+        <filename>/etc</filename> directory. This may be used to
+        populate <filename>/etc</filename> on the first boot after
+        factory reset, or when a new system instances boots up for the
+        first time.</para>
+
+        <para>With <varname>ConditionPathExists=</varname> a file
+        existence condition is checked before a unit is started. If
+        the specified absolute path name does not exist, the condition
+        will fail. If the absolute path name passed to
+        <varname>ConditionPathExists=</varname> is prefixed with an
+        exclamation mark (<literal>!</literal>), the test is negated,
+        and the unit is only started if the path does not
+        exist.</para>
+
+        <para><varname>ConditionPathExistsGlob=</varname> is similar
+        to <varname>ConditionPathExists=</varname>, but checks for the
+        existence of at least one file or directory matching the
+        specified globbing pattern.</para>
+
+        <para><varname>ConditionPathIsDirectory=</varname> is similar
+        to <varname>ConditionPathExists=</varname> but verifies
+        whether a certain path exists and is a directory.</para>
+
+        <para><varname>ConditionPathIsSymbolicLink=</varname> is
+        similar to <varname>ConditionPathExists=</varname> but
+        verifies whether a certain path exists and is a symbolic
+        link.</para>
+
+        <para><varname>ConditionPathIsMountPoint=</varname> is similar
+        to <varname>ConditionPathExists=</varname> but verifies
+        whether a certain path exists and is a mount point.</para>
+
+        <para><varname>ConditionPathIsReadWrite=</varname> is similar
+        to <varname>ConditionPathExists=</varname> but verifies
+        whether the underlying file system is readable and writable
+        (i.e. not mounted read-only).</para>
+
+        <para><varname>ConditionDirectoryNotEmpty=</varname> is
+        similar to <varname>ConditionPathExists=</varname> but
+        verifies whether a certain path exists and is a non-empty
+        directory.</para>
+
+        <para><varname>ConditionFileNotEmpty=</varname> is similar to
+        <varname>ConditionPathExists=</varname> but verifies whether a
+        certain path exists and refers to a regular file with a
+        non-zero size.</para>
+
+        <para><varname>ConditionFileIsExecutable=</varname> is similar
+        to <varname>ConditionPathExists=</varname> but verifies
+        whether a certain path exists, is a regular file and marked
+        executable.</para>
+
+        <para>If multiple conditions are specified, the unit will be
+        executed if all of them apply (i.e. a logical AND is applied).
+        Condition checks can be prefixed with a pipe symbol (|) in
+        which case a condition becomes a triggering condition. If at
+        least one triggering condition is defined for a unit, then the
+        unit will be executed if at least one of the triggering
+        conditions apply and all of the non-triggering conditions. If
+        you prefix an argument with the pipe symbol and an exclamation
+        mark, the pipe symbol must be passed first, the exclamation
+        second. Except for
+        <varname>ConditionPathIsSymbolicLink=</varname>, all path
+        checks follow symlinks. If any of these options is assigned
+        the empty string, the list of conditions is reset completely,
+        all previous condition settings (of any kind) will have no
+        effect.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AssertArchitecture=</varname></term>
+        <term><varname>AssertVirtualization=</varname></term>
+        <term><varname>AssertHost=</varname></term>
+        <term><varname>AssertKernelCommandLine=</varname></term>
+        <term><varname>AssertSecurity=</varname></term>
+        <term><varname>AssertCapability=</varname></term>
+        <term><varname>AssertACPower=</varname></term>
+        <term><varname>AssertNeedsUpdate=</varname></term>
+        <term><varname>AssertFirstBoot=</varname></term>
+        <term><varname>AssertPathExists=</varname></term>
+        <term><varname>AssertPathExistsGlob=</varname></term>
+        <term><varname>AssertPathIsDirectory=</varname></term>
+        <term><varname>AssertPathIsSymbolicLink=</varname></term>
+        <term><varname>AssertPathIsMountPoint=</varname></term>
+        <term><varname>AssertPathIsReadWrite=</varname></term>
+        <term><varname>AssertDirectoryNotEmpty=</varname></term>
+        <term><varname>AssertFileNotEmpty=</varname></term>
+        <term><varname>AssertFileIsExecutable=</varname></term>
+
+        <listitem><para>Similar to the <varname>ConditionArchitecture=</varname>,
+        <varname>ConditionVirtualization=</varname>, …, condition settings described above, these settings add
+        assertion checks to the start-up of the unit. However, unlike the conditions settings, any assertion setting
+        that is not met results in failure of the start job (which means this is logged loudly). Use assertion
+        expressions for units that cannot operate when specific requirements are not met, and when this is something
+        the administrator or user should look into.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SourcePath=</varname></term>
+        <listitem><para>A path to a configuration file this unit has
+        been generated from. This is primarily useful for
+        implementation of generator tools that convert configuration
+        from an external configuration file format into native unit
+        files. This functionality should not be used in normal
+        units.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Install] Section Options</title>
+
+    <para>Unit files may include an <literal>[Install]</literal> section, which carries installation information for
+    the unit. This section is not interpreted by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> during runtime; it is
+    used by the <command>enable</command> and <command>disable</command> commands of the
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool during
+    installation of a unit. Note that settings in the <literal>[Install]</literal> section may not appear in
+    <filename>.d/*.conf</filename> unit file drop-ins (see above).</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>Alias=</varname></term>
+
+        <listitem><para>A space-separated list of additional names this unit shall be installed under. The names listed
+        here must have the same suffix (i.e. type) as the unit file name. This option may be specified more than once,
+        in which case all listed names are used. At installation time, <command>systemctl enable</command> will create
+        symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this
+        setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support
+        aliasing.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WantedBy=</varname></term>
+        <term><varname>RequiredBy=</varname></term>
+
+        <listitem><para>This option may be used more than once, or a
+        space-separated list of unit names may be given. A symbolic
+        link is created in the <filename>.wants/</filename> or
+        <filename>.requires/</filename> directory of each of the
+        listed units when this unit is installed by <command>systemctl
+        enable</command>. This has the effect that a dependency of
+        type <varname>Wants=</varname> or <varname>Requires=</varname>
+        is added from the listed unit to the current unit. The primary
+        result is that the current unit will be started when the
+        listed unit is started. See the description of
+        <varname>Wants=</varname> and <varname>Requires=</varname> in
+        the [Unit] section for details.</para>
+
+        <para><command>WantedBy=foo.service</command> in a service
+        <filename>bar.service</filename> is mostly equivalent to
+        <command>Alias=foo.service.wants/bar.service</command> in the
+        same file. In case of template units, <command>systemctl
+        enable</command> must be called with an instance name, and
+        this instance will be added to the
+        <filename>.wants/</filename> or
+        <filename>.requires/</filename> list of the listed unit. E.g.
+        <command>WantedBy=getty.target</command> in a service
+        <filename>getty@.service</filename> will result in
+        <command>systemctl enable getty@tty2.service</command>
+        creating a
+        <filename>getty.target.wants/getty@tty2.service</filename>
+        link to <filename>getty@.service</filename>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Also=</varname></term>
+
+        <listitem><para>Additional units to install/deinstall when
+        this unit is installed/deinstalled. If the user requests
+        installation/deinstallation of a unit with this option
+        configured, <command>systemctl enable</command> and
+        <command>systemctl disable</command> will automatically
+        install/uninstall units listed in this option as well.</para>
+
+        <para>This option may be used more than once, or a
+        space-separated list of unit names may be
+        given.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultInstance=</varname></term>
+
+        <listitem><para>In template unit files, this specifies for
+        which instance the unit shall be enabled if the template is
+        enabled without any explicitly set instance. This option has
+        no effect in non-template unit files. The specified string
+        must be usable as instance identifier.</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The following specifiers are interpreted in the Install
+    section: %n, %N, %p, %i, %U, %u, %m, %H, %b, %v. For their meaning
+    see the next section.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Many settings resolve specifiers which may be used to write
+    generic unit files referring to runtime or unit parameters that
+    are replaced when the unit files are loaded. The following
+    specifiers are understood:</para>
+
+    <table>
+      <title>Specifiers available in unit files</title>
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="spec" />
+        <colspec colname="mean" />
+        <colspec colname="detail" />
+        <thead>
+          <row>
+      <entry>Specifier</entry>
+      <entry>Meaning</entry>
+      <entry>Details</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><literal>%n</literal></entry>
+      <entry>Full unit name</entry>
+      <entry></entry>
+          </row>
+          <row>
+      <entry><literal>%N</literal></entry>
+      <entry>Unescaped full unit name</entry>
+      <entry>Same as <literal>%n</literal>, but with escaping undone</entry>
+          </row>
+          <row>
+      <entry><literal>%p</literal></entry>
+      <entry>Prefix name</entry>
+      <entry>For instantiated units, this refers to the string before the <literal>@</literal> character of the unit name. For non-instantiated units, this refers to the name of the unit with the type suffix removed.</entry>
+          </row>
+          <row>
+      <entry><literal>%P</literal></entry>
+      <entry>Unescaped prefix name</entry>
+      <entry>Same as <literal>%p</literal>, but with escaping undone</entry>
+          </row>
+          <row>
+      <entry><literal>%i</literal></entry>
+      <entry>Instance name</entry>
+      <entry>For instantiated units: this is the string between the <literal>@</literal> character and the suffix of the unit name.</entry>
+          </row>
+          <row>
+      <entry><literal>%I</literal></entry>
+      <entry>Unescaped instance name</entry>
+      <entry>Same as <literal>%i</literal>, but with escaping undone</entry>
+          </row>
+          <row>
+      <entry><literal>%f</literal></entry>
+      <entry>Unescaped filename</entry>
+      <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the prefix name prepended with <filename>/</filename>.</entry>
+          </row>
+          <row>
+      <entry><literal>%c</literal></entry>
+      <entry>Control group path of the unit</entry>
+      <entry>This path does not include the <filename>/sys/fs/cgroup/systemd/</filename> prefix.</entry>
+          </row>
+          <row>
+      <entry><literal>%r</literal></entry>
+      <entry>Control group path of the slice the unit is placed in</entry>
+      <entry>This usually maps to the parent cgroup path of <literal>%c</literal>.</entry>
+          </row>
+          <row>
+      <entry><literal>%R</literal></entry>
+      <entry>Root control group path below which slices and units are placed</entry>
+      <entry>For system instances, this resolves to <filename>/</filename>, except in containers, where this maps to the container's root control group path.</entry>
+          </row>
+          <row>
+      <entry><literal>%t</literal></entry>
+      <entry>Runtime directory</entry>
+      <entry>This is either <filename>/run</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
+          </row>
+          <row>
+      <entry><literal>%u</literal></entry>
+      <entry>User name</entry>
+      <entry>This is the name of the user running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry>
+          </row>
+          <row>
+      <entry><literal>%U</literal></entry>
+      <entry>User UID</entry>
+      <entry>This is the numeric UID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry>
+          </row>
+          <row>
+      <entry><literal>%h</literal></entry>
+      <entry>User home directory</entry>
+      <entry>This is the home directory of the user running the service manager instance. In case of the system manager this resolves to <literal>/root</literal>.</entry>
+          </row>
+          <row>
+      <entry><literal>%s</literal></entry>
+      <entry>User shell</entry>
+      <entry>This is the shell of the user running the service manager instance. In case of the system manager this resolves to <literal>/bin/sh</literal>.</entry>
+          </row>
+          <row>
+      <entry><literal>%m</literal></entry>
+      <entry>Machine ID</entry>
+      <entry>The machine ID of the running system, formatted as string. See <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+          </row>
+          <row>
+      <entry><literal>%b</literal></entry>
+      <entry>Boot ID</entry>
+      <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
+          </row>
+          <row>
+      <entry><literal>%H</literal></entry>
+      <entry>Host name</entry>
+      <entry>The hostname of the running system at the point in time the unit configuration is loaded.</entry>
+          </row>
+          <row>
+      <entry><literal>%v</literal></entry>
+      <entry>Kernel release</entry>
+      <entry>Identical to <command>uname -r</command> output</entry>
+          </row>
+          <row>
+      <entry><literal>%%</literal></entry>
+      <entry>Single percent sign</entry>
+      <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Please note that specifiers <literal>%U</literal>,
+    <literal>%h</literal>, <literal>%s</literal> are mostly useless
+    when systemd is running in system mode. PID 1 cannot query the
+    user account database for information, so the specifiers only work
+    as shortcuts for things which are already specified in a different
+    way in the unit file. They are fully functional when systemd is
+    running in <option>--user</option> mode.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Allowing units to be enabled</title>
+
+      <para>The following snippet (highlighted) allows a unit (e.g.
+      <filename>foo.service</filename>) to be enabled via
+      <command>systemctl enable</command>:</para>
+
+      <programlisting>[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+<emphasis>[Install]</emphasis>
+<emphasis>WantedBy=multi-user.target</emphasis></programlisting>
+
+      <para>After running <command>systemctl enable</command>, a
+      symlink
+      <filename>/etc/systemd/system/multi-user.target.wants/foo.service</filename>
+      linking to the actual unit will be created. It tells systemd to
+      pull in the unit when starting
+      <filename>multi-user.target</filename>. The inverse
+      <command>systemctl disable</command> will remove that symlink
+      again.</para>
+    </example>
+
+    <example>
+      <title>Overriding vendor settings</title>
+
+      <para>There are two methods of overriding vendor settings in
+      unit files: copying the unit file from
+      <filename>/usr/lib/systemd/system</filename> to
+      <filename>/etc/systemd/system</filename> and modifying the
+      chosen settings. Alternatively, one can create a directory named
+      <filename><replaceable>unit</replaceable>.d/</filename> within
+      <filename>/etc/systemd/system</filename> and place a drop-in
+      file <filename><replaceable>name</replaceable>.conf</filename>
+      there that only changes the specific settings one is interested
+      in. Note that multiple such drop-in files are read if
+      present.</para>
+
+      <para>The advantage of the first method is that one easily
+      overrides the complete unit, the vendor unit is not parsed at
+      all anymore. It has the disadvantage that improvements to the
+      unit file by the vendor are not automatically incorporated on
+      updates.</para>
+
+      <para>The advantage of the second method is that one only
+      overrides the settings one specifically wants, where updates to
+      the unit by the vendor automatically apply. This has the
+      disadvantage that some future updates by the vendor might be
+      incompatible with the local changes.</para>
+
+      <para>Note that for drop-in files, if one wants to remove
+      entries from a setting that is parsed as a list (and is not a
+      dependency), such as <varname>ConditionPathExists=</varname> (or
+      e.g. <varname>ExecStart=</varname> in service units), one needs
+      to first clear the list before re-adding all entries except the
+      one that is to be removed. See below for an example.</para>
+
+      <para>This also applies for user instances of systemd, but with
+      different locations for the unit files. See the section on unit
+      load paths for further details.</para>
+
+      <para>Suppose there is a vendor-supplied unit
+      <filename>/usr/lib/systemd/system/httpd.service</filename> with
+      the following contents:</para>
+
+      <programlisting>[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service
+Requires=sqldb.service
+AssertPathExists=/srv/webserver
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+Nice=5
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Now one wants to change some settings as an administrator:
+      firstly, in the local setup, <filename>/srv/webserver</filename>
+      might not exist, because the HTTP server is configured to use
+      <filename>/srv/www</filename> instead. Secondly, the local
+      configuration makes the HTTP server also depend on a memory
+      cache service, <filename>memcached.service</filename>, that
+      should be pulled in (<varname>Requires=</varname>) and also be
+      ordered appropriately (<varname>After=</varname>). Thirdly, in
+      order to harden the service a bit more, the administrator would
+      like to set the <varname>PrivateTmp=</varname> setting (see
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details). And lastly, the administrator would like to reset
+      the niceness of the service to its default value of 0.</para>
+
+      <para>The first possibility is to copy the unit file to
+      <filename>/etc/systemd/system/httpd.service</filename> and
+      change the chosen settings:</para>
+
+      <programlisting>[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service <emphasis>memcached.service</emphasis>
+Requires=sqldb.service <emphasis>memcached.service</emphasis>
+AssertPathExists=<emphasis>/srv/www</emphasis>
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+<emphasis>Nice=0</emphasis>
+<emphasis>PrivateTmp=yes</emphasis>
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Alternatively, the administrator could create a drop-in
+      file
+      <filename>/etc/systemd/system/httpd.service.d/local.conf</filename>
+      with the following contents:</para>
+
+      <programlisting>[Unit]
+After=memcached.service
+Requires=memcached.service
+# Reset all assertions and then re-add the condition we want
+AssertPathExists=
+AssertPathExists=/srv/www
+
+[Service]
+Nice=0
+PrivateTmp=yes</programlisting>
+
+      <para>Note that dependencies (<varname>After=</varname>, etc.)
+      cannot be reset to an empty list, so dependencies can only be
+      added in drop-ins. If you want to remove dependencies, you have
+      to override the entire unit.</para>
+
+    </example>
+  </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.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/src/grp-system/systemd/systemd.xml b/src/grp-system/systemd/systemd.xml
new file mode 100644
index 0000000000..e05a9d6e29
--- /dev/null
+++ b/src/grp-system/systemd/systemd.xml
@@ -0,0 +1,1153 @@
+<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+-->
+
+<refentry id="systemd"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd</title>
+    <productname>systemd</productname>
+
+    <authorgroup>
+      <author>
+        <contrib>Developer</contrib>
+        <firstname>Lennart</firstname>
+        <surname>Poettering</surname>
+        <email>lennart@poettering.net</email>
+      </author>
+    </authorgroup>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd</refname>
+    <refname>init</refname>
+    <refpurpose>systemd system and service manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd <arg choice="opt" rep="repeat">OPTIONS</arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>init <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>systemd is a system and service manager for GNU/Linux operating
+    systems. When run as first process on boot (as PID 1), it acts as
+    init system that brings up and maintains userspace
+    services.</para>
+
+    <para>For compatibility with SysV, if systemd is called as
+    <command>init</command> and a PID that is not 1, it will execute
+    <command>telinit</command> and pass all command line arguments
+    unmodified. That means <command>init</command> and
+    <command>telinit</command> are mostly equivalent when invoked from
+    normal login sessions. See
+    <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for more information.</para>
+
+    <para>When run as a system instance, systemd interprets the
+    configuration file <filename>system.conf</filename> and the files
+    in <filename>system.conf.d</filename> directories; when run as a
+    user instance, systemd interprets the configuration file
+    <filename>user.conf</filename> and the files in
+    <filename>user.conf.d</filename> directories. See
+    <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--test</option></term>
+
+        <listitem><para>Determine startup sequence, dump it and exit.
+        This is an option useful for debugging only.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--dump-configuration-items</option></term>
+
+        <listitem><para>Dump understood unit configuration items. This
+        outputs a terse but complete list of configuration items
+        understood in unit definition files.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--unit=</option></term>
+
+        <listitem><para>Set default unit to activate on startup. If
+        not specified, defaults to
+        <filename>default.target</filename>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--system</option></term>
+        <term><option>--user</option></term>
+
+        <listitem><para>For <option>--system</option>, tell systemd to
+        run a system instance, even if the process ID is not 1, i.e.
+        systemd is not run as init process. <option>--user</option>
+        does the opposite, running a user instance even if the process
+        ID is 1. Normally, it should not be necessary to pass these
+        options, as systemd automatically detects the mode it is
+        started in. These options are hence of little use except for
+        debugging. Note that it is not supported booting and
+        maintaining a full system with systemd running in
+        <option>--system</option> mode, but PID not 1. In practice,
+        passing <option>--system</option> explicitly is only useful in
+        conjunction with <option>--test</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--dump-core</option></term>
+
+        <listitem><para>Enable core dumping on crash. This switch has
+        no effect when running as user instance. This setting may also
+        be enabled during boot on the kernel command line via the
+        <varname>systemd.dump_core=</varname> option, see
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--crash-vt=</option><replaceable>VT</replaceable></term>
+
+        <listitem><para>Switch to a specific virtual console (VT) on
+        crash. Takes a positive integer in the range 1–63, or a
+        boolean argument. If an integer is passed, selects which VT to
+        switch to. If <constant>yes</constant>, the VT kernel messages
+        are written to is selected. If <constant>no</constant>, no VT
+        switch is attempted. This switch has no effect when running as
+        user instance. This setting may also be enabled during boot,
+        on the kernel command line via the
+        <varname>systemd.crash_vt=</varname> option, see
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--crash-shell</option></term>
+
+        <listitem><para>Run a shell on crash. This switch has no
+        effect when running as user instance. This setting may also be
+        enabled during boot, on the kernel command line via the
+        <varname>systemd.crash_shell=</varname> option, see
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--crash-reboot</option></term>
+
+        <listitem><para>Automatically reboot the system on crash. This
+        switch has no effect when running as user instance. This
+        setting may also be enabled during boot, on the kernel command
+        line via the <varname>systemd.crash_reboot=</varname> option,
+        see below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--confirm-spawn</option></term>
+
+        <listitem><para>Ask for confirmation when spawning processes.
+        This switch has no effect when run as user
+        instance.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--show-status=</option></term>
+
+        <listitem><para>Show terse service status information while
+        booting. This switch has no effect when run as user instance.
+        Takes a boolean argument which may be omitted which is
+        interpreted as <option>true</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--log-target=</option></term>
+
+        <listitem><para>Set log target. Argument must be one of
+        <option>console</option>,
+        <option>journal</option>,
+        <option>kmsg</option>,
+        <option>journal-or-kmsg</option>,
+        <option>null</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--log-level=</option></term>
+
+        <listitem><para>Set log level. As
+        argument this accepts a numerical log
+        level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        symbolic names (lowercase):
+        <option>emerg</option>,
+        <option>alert</option>,
+        <option>crit</option>,
+        <option>err</option>,
+        <option>warning</option>,
+        <option>notice</option>,
+        <option>info</option>,
+        <option>debug</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--log-color=</option></term>
+
+        <listitem><para>Highlight important log messages. Argument is
+        a boolean value. If the argument is omitted, it defaults to
+        <option>true</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--log-location=</option></term>
+
+        <listitem><para>Include code location in log messages. This is
+        mostly relevant for debugging purposes. Argument is a boolean
+        value. If the argument is omitted it defaults to
+        <option>true</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--default-standard-output=</option></term>
+        <term><option>--default-standard-error=</option></term>
+
+        <listitem><para>Sets the default output or error output for
+        all services and sockets, respectively. That is, controls the
+        default for <option>StandardOutput=</option> and
+        <option>StandardError=</option> (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details). Takes one of
+        <option>inherit</option>,
+        <option>null</option>,
+        <option>tty</option>,
+        <option>journal</option>,
+        <option>journal+console</option>,
+        <option>syslog</option>,
+        <option>syslog+console</option>,
+        <option>kmsg</option>,
+        <option>kmsg+console</option>.  If the
+        argument is omitted
+        <option>--default-standard-output=</option> defaults to
+        <option>journal</option> and
+        <option>--default-standard-error=</option> to
+        <option>inherit</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--machine-id=</option></term>
+
+        <listitem><para>Override the machine-id set on the hard drive,
+        useful for network booting or for containers. May not be set
+        to all zeros.</para></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Concepts</title>
+
+    <para>systemd provides a dependency system between various
+    entities called "units" of 12 different types. Units encapsulate
+    various objects that are relevant for system boot-up and
+    maintenance. The majority of units are configured in unit
+    configuration files, whose syntax and basic set of options is
+    described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    however some are created automatically from other configuration,
+    dynamically from system state or programmatically at runtime.
+    Units may be "active" (meaning started, bound, plugged in, ...,
+    depending on the unit type, see below), or "inactive" (meaning
+    stopped, unbound, unplugged, ...), as well as in the process of
+    being activated or deactivated, i.e. between the two states (these
+    states are called "activating", "deactivating"). A special
+    "failed" state is available as well, which is very similar to
+    "inactive" and is entered when the service failed in some way
+    (process returned error code on exit, or crashed, or an operation
+    timed out). If this state is entered, the cause will be logged,
+    for later reference. Note that the various unit types may have a
+    number of additional substates, which are mapped to the five
+    generalized unit states described here.</para>
+
+    <para>The following unit types are available:</para>
+
+    <orderedlist>
+      <listitem><para>Service units, which start and control daemons
+      and the processes they consist of. For details, see
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Socket units, which encapsulate local IPC or
+      network sockets in the system, useful for socket-based
+      activation. For details about socket units, see
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      for details on socket-based activation and other forms of
+      activation, see
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Target units are useful to group units, or
+      provide well-known synchronization points during boot-up, see
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Device units expose kernel devices in systemd
+      and may be used to implement device-based activation. For
+      details, see
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Mount units control mount points in the file
+      system, for details see
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Automount units provide automount capabilities,
+      for on-demand mounting of file systems as well as parallelized
+      boot-up. See
+      <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Timer units are useful for triggering activation
+      of other units based on timers. You may find details in
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Swap units are very similar to mount units and
+      encapsulate memory swap partitions or files of the operating
+      system. They are described in
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Path units may be used to activate other
+      services when file system objects change or are modified. See
+      <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Slice units may be used to group units which
+      manage system processes (such as service and scope units) in a
+      hierarchical tree for resource management purposes. See
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Scope units are similar to service units, but
+      manage foreign processes instead of starting them as well. See
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+    </orderedlist>
+
+    <para>Units are named as their configuration files. Some units
+    have special semantics. A detailed list is available in
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>systemd knows various kinds of dependencies, including
+    positive and negative requirement dependencies (i.e.
+    <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
+    well as ordering dependencies (<varname>After=</varname> and
+    <varname>Before=</varname>). NB: ordering and requirement
+    dependencies are orthogonal. If only a requirement dependency
+    exists between two units (e.g. <filename>foo.service</filename>
+    requires <filename>bar.service</filename>), but no ordering
+    dependency (e.g. <filename>foo.service</filename> after
+    <filename>bar.service</filename>) and both are requested to start,
+    they will be started in parallel. It is a common pattern that both
+    requirement and ordering dependencies are placed between two
+    units. Also note that the majority of dependencies are implicitly
+    created and maintained by systemd. In most cases, it should be
+    unnecessary to declare additional dependencies manually, however
+    it is possible to do this.</para>
+
+    <para>Application programs and units (via dependencies) may
+    request state changes of units. In systemd, these requests are
+    encapsulated as 'jobs' and maintained in a job queue. Jobs may
+    succeed or can fail, their execution is ordered based on the
+    ordering dependencies of the units they have been scheduled
+    for.</para>
+
+    <para>On boot systemd activates the target unit
+    <filename>default.target</filename> whose job is to activate
+    on-boot services and other on-boot units by pulling them in via
+    dependencies. Usually, the unit name is just an alias (symlink) for
+    either <filename>graphical.target</filename> (for fully-featured
+    boots into the UI) or <filename>multi-user.target</filename> (for
+    limited console-only boots for use in embedded or server
+    environments, or similar; a subset of graphical.target). However,
+    it is at the discretion of the administrator to configure it as an
+    alias to any other target unit. See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for details about these target units.</para>
+
+    <para>Processes systemd spawns are placed in individual Linux
+    control groups named after the unit which they belong to in the
+    private systemd hierarchy. (see <ulink
+    url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
+    for more information about control groups, or short "cgroups").
+    systemd uses this to effectively keep track of processes. Control
+    group information is maintained in the kernel, and is accessible
+    via the file system hierarchy (beneath
+    <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as
+    <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    or
+    <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    (<command>ps xawf -eo pid,user,cgroup,args</command> is
+    particularly useful to list all processes and the systemd units
+    they belong to.).</para>
+
+    <para>systemd is compatible with the SysV init system to a large
+    degree: SysV init scripts are supported and simply read as an
+    alternative (though limited) configuration file format. The SysV
+    <filename>/dev/initctl</filename> interface is provided, and
+    compatibility implementations of the various SysV client tools are
+    available. In addition to that, various established Unix
+    functionality such as <filename>/etc/fstab</filename> or the
+    <filename>utmp</filename> database are supported.</para>
+
+    <para>systemd has a minimal transaction system: if a unit is
+    requested to start up or shut down it will add it and all its
+    dependencies to a temporary transaction. Then, it will verify if
+    the transaction is consistent (i.e. whether the ordering of all
+    units is cycle-free). If it is not, systemd will try to fix it up,
+    and removes non-essential jobs from the transaction that might
+    remove the loop. Also, systemd tries to suppress non-essential
+    jobs in the transaction that would stop a running service. Finally
+    it is checked whether the jobs of the transaction contradict jobs
+    that have already been queued, and optionally the transaction is
+    aborted then. If all worked out and the transaction is consistent
+    and minimized in its impact it is merged with all already
+    outstanding jobs and added to the run queue. Effectively this
+    means that before executing a requested operation, systemd will
+    verify that it makes sense, fixing it if possible, and only
+    failing if it really cannot work.</para>
+
+    <para>Systemd contains native implementations of various tasks
+    that need to be executed as part of the boot process. For example,
+    it sets the hostname or configures the loopback network device. It
+    also sets up and mounts various API file systems, such as
+    <filename>/sys</filename> or <filename>/proc</filename>.</para>
+
+    <para>For more information about the concepts and
+    ideas behind systemd, please refer to the
+    <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
+
+    <para>Note that some but not all interfaces provided
+    by systemd are covered by the
+    <ulink url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
+    Stability Promise</ulink>.</para>
+
+    <para>Units may be generated dynamically at boot and system
+    manager reload time, for example based on other configuration
+    files or parameters passed on the kernel command line. For details, see
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>Systems which invoke systemd in a container or initrd
+    environment should implement the
+    <ulink url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
+    <ulink url="http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
+    specifications, respectively.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Directories</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>System unit directories</term>
+
+        <listitem><para>The systemd system manager reads unit
+        configuration from various directories. Packages that want to
+        install unit files shall place them in the directory returned
+        by <command>pkg-config systemd
+        --variable=systemdsystemunitdir</command>. Other directories
+        checked are <filename>/usr/local/lib/systemd/system</filename>
+        and <filename>/usr/lib/systemd/system</filename>. User
+        configuration always takes precedence. <command>pkg-config
+        systemd --variable=systemdsystemconfdir</command> returns the
+        path of the system configuration directory. Packages should
+        alter the content of these directories only with the
+        <command>enable</command> and <command>disable</command>
+        commands of the
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool. Full list of directories is provided in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term>User unit directories</term>
+
+        <listitem><para>Similar rules apply for the user unit
+        directories. However, here the
+        <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+        Base Directory specification</ulink> is followed to find
+        units. Applications should place their unit files in the
+        directory returned by <command>pkg-config systemd
+        --variable=systemduserunitdir</command>. Global configuration
+        is done in the directory reported by <command>pkg-config
+        systemd --variable=systemduserconfdir</command>. The
+        <command>enable</command> and <command>disable</command>
+        commands of the
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool can handle both global (i.e. for all users) and private
+        (for one user) enabling/disabling of units. Full list of
+        directories is provided in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term>SysV init scripts directory</term>
+
+        <listitem><para>The location of the SysV init script directory
+        varies between distributions. If systemd cannot find a native
+        unit file for a requested service, it will look for a SysV
+        init script of the same name (with the
+        <filename>.service</filename> suffix
+        removed).</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term>SysV runlevel link farm directory</term>
+
+        <listitem><para>The location of the SysV runlevel link farm
+        directory varies between distributions. systemd will take the
+        link farm into account when figuring out whether a service
+        shall be enabled. Note that a service unit with a native unit
+        configuration file cannot be started by activating it in the
+        SysV runlevel link farm.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Signals</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>SIGTERM</constant></term>
+
+        <listitem><para>Upon receiving this signal the systemd system
+        manager serializes its state, reexecutes itself and
+        deserializes the saved state again. This is mostly equivalent
+        to <command>systemctl daemon-reexec</command>.</para>
+
+        <para>systemd user managers will start the
+        <filename>exit.target</filename> unit when this signal is
+        received. This is mostly equivalent to <command>systemctl
+        --user start exit.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGINT</constant></term>
+
+        <listitem><para>Upon receiving this signal the systemd system
+        manager will start the
+        <filename>ctrl-alt-del.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        ctl-alt-del.target</command>. If this signal is received more
+        than 7 times per 2s, an immediate reboot is triggered.
+        Note that pressing Ctrl-Alt-Del on the console will trigger
+        this signal. Hence, if a reboot is hanging, pressing
+        Ctrl-Alt-Del more than 7 times in 2s is a relatively safe way
+        to trigger an immediate reboot.</para>
+
+        <para>systemd user managers treat this signal the same way as
+        <constant>SIGTERM</constant>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGWINCH</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        system manager will start the
+        <filename>kbrequest.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        kbrequest.target</command>.</para>
+
+        <para>This signal is ignored by systemd user
+        managers.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGPWR</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        manager will start the <filename>sigpwr.target</filename>
+        unit. This is mostly equivalent to <command>systemctl start
+        sigpwr.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGUSR1</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        manager will try to reconnect to the D-Bus
+        bus.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGUSR2</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        manager will log its complete state in human-readable form.
+        The data logged is the same as printed by
+        <command>systemd-analyze dump</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGHUP</constant></term>
+
+        <listitem><para>Reloads the complete daemon configuration.
+        This is mostly equivalent to <command>systemctl
+        daemon-reload</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+0</constant></term>
+
+        <listitem><para>Enters default mode, starts the
+        <filename>default.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        default.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+1</constant></term>
+
+        <listitem><para>Enters rescue mode, starts the
+        <filename>rescue.target</filename> unit. This is mostly
+        equivalent to <command>systemctl isolate
+        rescue.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+2</constant></term>
+
+        <listitem><para>Enters emergency mode, starts the
+        <filename>emergency.service</filename> unit. This is mostly
+        equivalent to <command>systemctl isolate
+        emergency.service</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+3</constant></term>
+
+        <listitem><para>Halts the machine, starts the
+        <filename>halt.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        halt.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+4</constant></term>
+
+        <listitem><para>Powers off the machine, starts the
+        <filename>poweroff.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        poweroff.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+5</constant></term>
+
+        <listitem><para>Reboots the machine, starts the
+        <filename>reboot.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        reboot.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+6</constant></term>
+
+        <listitem><para>Reboots the machine via kexec, starts the
+        <filename>kexec.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        kexec.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+13</constant></term>
+
+        <listitem><para>Immediately halts the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+14</constant></term>
+
+        <listitem><para>Immediately powers off the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+15</constant></term>
+
+        <listitem><para>Immediately reboots the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+16</constant></term>
+
+        <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+20</constant></term>
+
+        <listitem><para>Enables display of status messages on the
+        console, as controlled via
+        <varname>systemd.show_status=1</varname> on the kernel command
+        line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+21</constant></term>
+
+        <listitem><para>Disables display of
+        status messages on the console, as
+        controlled via
+        <varname>systemd.show_status=0</varname>
+        on the kernel command
+        line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+22</constant></term>
+        <term><constant>SIGRTMIN+23</constant></term>
+
+        <listitem><para>Sets the log level to <literal>debug</literal>
+        (or <literal>info</literal> on
+        <constant>SIGRTMIN+23</constant>), as controlled via
+        <varname>systemd.log_level=debug</varname> (or
+        <varname>systemd.log_level=info</varname> on
+        <constant>SIGRTMIN+23</constant>) on the kernel command
+        line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+24</constant></term>
+
+        <listitem><para>Immediately exits the manager (only available
+        for --user instances).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+26</constant></term>
+        <term><constant>SIGRTMIN+27</constant></term>
+        <term><constant>SIGRTMIN+28</constant></term>
+
+        <listitem><para>Sets the log level to
+        <literal>journal-or-kmsg</literal> (or
+        <literal>console</literal> on
+        <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
+        <constant>SIGRTMIN+28</constant>), as controlled via
+        <varname>systemd.log_target=journal-or-kmsg</varname> (or
+        <varname>systemd.log_target=console</varname> on
+        <constant>SIGRTMIN+27</constant> or
+        <varname>systemd.log_target=kmsg</varname> on
+        <constant>SIGRTMIN+28</constant>) on the kernel command
+        line.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
+        <listitem><para>systemd reads the log level from this
+        environment variable. This can be overridden with
+        <option>--log-level=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
+        <listitem><para>systemd reads the log target from this
+        environment variable. This can be overridden with
+        <option>--log-target=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
+        <listitem><para>Controls whether systemd highlights important
+        log messages. This can be overridden with
+        <option>--log-color=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
+        <listitem><para>Controls whether systemd prints the code
+        location along with log messages. This can be overridden with
+        <option>--log-location=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_CONFIG_HOME</varname></term>
+        <term><varname>$XDG_CONFIG_DIRS</varname></term>
+        <term><varname>$XDG_DATA_HOME</varname></term>
+        <term><varname>$XDG_DATA_DIRS</varname></term>
+
+        <listitem><para>The systemd user manager uses these variables
+        in accordance to the <ulink
+        url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+        Base Directory specification</ulink> to find its
+        configuration.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
+
+        <listitem><para>Controls where systemd looks for unit
+        files.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
+
+        <listitem><para>Controls where systemd looks for SysV init
+        scripts.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
+
+        <listitem><para>Controls where systemd looks for SysV init
+        script runlevel link farms.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_COLORS</varname></term>
+
+        <listitem><para>Controls whether colorized output should be generated.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$LISTEN_PID</varname></term>
+        <term><varname>$LISTEN_FDS</varname></term>
+        <term><varname>$LISTEN_FDNAMES</varname></term>
+
+        <listitem><para>Set by systemd for supervised processes during
+        socket-based activation. See
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for more information. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$NOTIFY_SOCKET</varname></term>
+
+        <listitem><para>Set by systemd for supervised processes for
+        status and start-up completion notification. See
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for more information. </para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para>When run as system instance systemd parses a number of
+    kernel command line arguments<footnote><para>If run inside a Linux
+    container these arguments may be passed as command line arguments
+    to systemd itself, next to any of the command line options listed
+    in the Options section above. If run outside of Linux containers,
+    these arguments are parsed from <filename>/proc/cmdline</filename>
+    instead.</para></footnote>:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.unit=</varname></term>
+        <term><varname>rd.systemd.unit=</varname></term>
+
+        <listitem><para>Overrides the unit to activate on boot.
+        Defaults to <filename>default.target</filename>. This may be
+        used to temporarily boot into a different boot unit, for
+        example <filename>rescue.target</filename> or
+        <filename>emergency.service</filename>. See
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about these units. The option prefixed with
+        <literal>rd.</literal> is honored only in the initial RAM disk
+        (initrd), while the one that is not prefixed only in the main
+        system.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.dump_core=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>yes</option>, the systemd manager (PID 1) dumps core
+        when it crashes.  Otherwise, no core dump is created. Defaults
+        to <option>yes</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.crash_chvt=</varname></term>
+
+        <listitem><para>Takes a positive integer, or a boolean
+        argument. If a positive integer (in the range 1–63) is
+        specified, the system manager (PID 1) will activate the specified
+        virtual terminal (VT) when it crashes. Defaults to
+        <constant>no</constant>, meaning that no such switch is
+        attempted. If set to <constant>yes</constant>, the VT the
+        kernel messages are written to is selected.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.crash_shell=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>yes</option>, the system manager (PID 1) spawns a
+        shell when it crashes, after a 10s delay. Otherwise, no shell
+        is spawned. Defaults to <option>no</option>, for security
+        reasons, as the shell is not protected by password
+        authentication.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.crash_reboot=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>yes</option>, the system manager (PID 1) will reboot
+        the machine automatically when it crashes, after a 10s delay.
+        Otherwise, the system will hang indefinitely. Defaults to
+        <option>no</option>, in order to avoid a reboot loop. If
+        combined with <varname>systemd.crash_shell=</varname>, the
+        system is rebooted after the shell exits.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.confirm_spawn=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>yes</option>, the system manager (PID 1) asks for
+        confirmation when spawning processes. Defaults to
+        <option>no</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.show_status=</varname></term>
+
+        <listitem><para>Takes a boolean argument or the constant
+        <constant>auto</constant>. If <option>yes</option>, the
+        systemd manager (PID 1) shows terse service status updates on
+        the console during bootup.  <constant>auto</constant> behaves
+        like <option>false</option> until a service fails or there is
+        a significant delay in boot.  Defaults to
+        <option>yes</option>, unless <option>quiet</option> is passed
+        as kernel command line option, in which case it defaults to
+        <constant>auto</constant>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.log_target=</varname></term>
+        <term><varname>systemd.log_level=</varname></term>
+        <term><varname>systemd.log_color=</varname></term>
+        <term><varname>systemd.log_location=</varname></term>
+
+        <listitem><para>Controls log output, with the same effect as
+        the <varname>$SYSTEMD_LOG_TARGET</varname>,
+        <varname>$SYSTEMD_LOG_LEVEL</varname>,
+        <varname>$SYSTEMD_LOG_COLOR</varname>,
+        <varname>$SYSTEMD_LOG_LOCATION</varname> environment variables
+        described above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.default_standard_output=</varname></term>
+        <term><varname>systemd.default_standard_error=</varname></term>
+        <listitem><para>Controls default standard output and error
+        output for services, with the same effect as the
+        <option>--default-standard-output=</option> and
+        <option>--default-standard-error=</option> command line
+        arguments described above, respectively.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.setenv=</varname></term>
+
+        <listitem><para>Takes a string argument in the form
+        VARIABLE=VALUE. May be used to set default environment
+        variables to add to forked child processes. May be used more
+        than once to set multiple variables.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.machine_id=</varname></term>
+
+        <listitem><para>Takes a 32 character hex value to be
+        used for setting the machine-id. Intended mostly for
+        network booting where the same machine-id is desired
+        for every boot.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>quiet</varname></term>
+
+        <listitem><para>Turn off status output at boot, much like
+        <varname>systemd.show_status=false</varname> would. Note that
+        this option is also read by the kernel itself and disables
+        kernel log output. Passing this option hence turns off the
+        usual output from both the system manager and the kernel.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname></term>
+
+        <listitem><para>Turn on debugging output. This is equivalent
+        to <varname>systemd.log_level=debug</varname>. Note that this
+        option is also read by the kernel itself and enables kernel
+        debug output. Passing this option hence turns on the debug
+        output from both the system manager and the
+        kernel.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>emergency</varname></term>
+        <term><varname>-b</varname></term>
+
+        <listitem><para>Boot into emergency mode. This is equivalent
+        to <varname>systemd.unit=emergency.target</varname> and
+        provided for compatibility reasons and to be easier to
+        type.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>rescue</varname></term>
+        <term><varname>single</varname></term>
+        <term><varname>s</varname></term>
+        <term><varname>S</varname></term>
+        <term><varname>1</varname></term>
+
+        <listitem><para>Boot into rescue mode. This is equivalent to
+        <varname>systemd.unit=rescue.target</varname> and provided for
+        compatibility reasons and to be easier to
+        type.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>2</varname></term>
+        <term><varname>3</varname></term>
+        <term><varname>4</varname></term>
+        <term><varname>5</varname></term>
+
+        <listitem><para>Boot into the specified legacy SysV runlevel.
+        These are equivalent to
+        <varname>systemd.unit=runlevel2.target</varname>,
+        <varname>systemd.unit=runlevel3.target</varname>,
+        <varname>systemd.unit=runlevel4.target</varname>, and
+        <varname>systemd.unit=runlevel5.target</varname>,
+        respectively, and provided for compatibility reasons and to be
+        easier to type.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>locale.LANG=</varname></term>
+        <term><varname>locale.LANGUAGE=</varname></term>
+        <term><varname>locale.LC_CTYPE=</varname></term>
+        <term><varname>locale.LC_NUMERIC=</varname></term>
+        <term><varname>locale.LC_TIME=</varname></term>
+        <term><varname>locale.LC_COLLATE=</varname></term>
+        <term><varname>locale.LC_MONETARY=</varname></term>
+        <term><varname>locale.LC_MESSAGES=</varname></term>
+        <term><varname>locale.LC_PAPER=</varname></term>
+        <term><varname>locale.LC_NAME=</varname></term>
+        <term><varname>locale.LC_ADDRESS=</varname></term>
+        <term><varname>locale.LC_TELEPHONE=</varname></term>
+        <term><varname>locale.LC_MEASUREMENT=</varname></term>
+        <term><varname>locale.LC_IDENTIFICATION=</varname></term>
+
+        <listitem><para>Set the system locale to use. This overrides
+        the settings in <filename>/etc/locale.conf</filename>. For
+        more information, see
+        <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        and
+        <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>For other kernel command line parameters understood by
+    components of the core OS, please refer to
+    <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Sockets and FIFOs</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/systemd/notify</filename></term>
+
+        <listitem><para>Daemon status notification socket. This is an
+        <constant>AF_UNIX</constant> datagram socket and is used to
+        implement the daemon notification logic as implemented by
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/systemd/private</filename></term>
+
+        <listitem><para>Used internally as communication channel
+        between
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and the systemd process. This is an
+        <constant>AF_UNIX</constant> stream socket. This interface is
+        private to systemd and should not be used in external
+        projects.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/dev/initctl</filename></term>
+
+        <listitem><para>Limited compatibility support for the SysV
+        client interface, as implemented by the
+        <filename>systemd-initctl.service</filename> unit. This is a
+        named pipe in the file system. This interface is obsolete and
+        should not be used in new applications.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      The <ulink url="http://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
+      <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>