<title>Description</title>
<para>These files configure various parameters of
- <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+ <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
<title>Description</title>
<para>These files configure various parameters of
- <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+ <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
<refsect1>
<title>Description</title>
- <para>These files configure various parameters of the systemd
- journal service,
- <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+ <para>These files configure various parameters of the systemd journal service,
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+ See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<refsect1>
<title>Description</title>
- <para>These files configure various parameters of the systemd
- login manager,
- <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
- </para>
+ <para>These files configure various parameters of the systemd login manager,
+ <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
'8',
['systemd-hibernate.service',
'systemd-hybrid-sleep.service',
- 'systemd-suspend-then-hibernate.service',
- 'systemd-sleep'],
+ 'systemd-sleep',
+ 'systemd-suspend-then-hibernate.service'],
''],
['systemd-sysctl.service', '8', ['systemd-sysctl'], ''],
['systemd-system-update-generator', '8', [], ''],
''],
['systemd-sysusers', '8', ['systemd-sysusers.service'], ''],
['systemd-sysv-generator', '8', [], 'HAVE_SYSV_COMPAT'],
- ['systemd-time-wait-sync.service', '8', ['systemd-time-wait-sync'], 'ENABLE_TIMESYNCD'],
+ ['systemd-time-wait-sync.service',
+ '8',
+ ['systemd-time-wait-sync'],
+ 'ENABLE_TIMESYNCD'],
['systemd-timedated.service', '8', ['systemd-timedated'], 'ENABLE_TIMEDATED'],
['systemd-timesyncd.service', '8', ['systemd-timesyncd'], 'ENABLE_TIMESYNCD'],
['systemd-tmpfiles',
['systemd.socket', '5', [], ''],
['systemd.special', '7', [], ''],
['systemd.swap', '5', [], ''],
+ ['systemd.syntax', '7', [], ''],
['systemd.target', '5', [], ''],
['systemd.time', '7', [], ''],
['systemd.timer', '5', [], ''],
through
<varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname>.
In the second case, an HTTP or HTTPS server will be spawned on
- this port, respectively for <option>--listen-http</option> and
- <option>--listen-https</option>. Currently, only POST requests
+ this port, respectively for <option>--listen-http=</option> and
+ <option>--listen-https=</option>. Currently, only POST requests
to <filename>/upload</filename> with <literal>Content-Type:
application/vnd.fdo.journal</literal> are supported.</para>
</listitem>
<refsect1>
<title>Description</title>
- <para>
- <command>systemd-journal-upload</command> will upload journal
- entries to the URL specified with <option>--url</option>. Unless
- limited by one of the options specified below, all journal
- entries accessible to the user the program is running as will be
- uploaded, and then the program will wait and send new entries
- as they become available.
- </para>
+ <para><command>systemd-journal-upload</command> will upload journal entries to the URL specified
+ with <option>--url=</option>. This program reads journal entries from one or more journal files,
+ similarly to
+ <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+ Unless limited by one of the options specified below, all journal entries accessible to the user
+ the program is running as will be uploaded, and then the program will wait and send new entries
+ as they become available.</para>
</refsect1>
<refsect1>
entries from the specified journal directory
<replaceable>DIR</replaceable> instead of the default runtime
and system journal paths. This has the same meaning as
- <option>--directory</option> option for
+ <option>--directory=</option> option for
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
</para></listitem>
</varlistentry>
<replaceable>GLOB</replaceable> instead of the default runtime
and system journal paths. May be specified multiple times, in
which case files will be suitably interleaved. This has the same meaning as
- <option>--file</option> option for
+ <option>--file=</option> option for
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
</para></listitem>
</varlistentry>
<listitem><para>Upload entries from the location in the
journal specified by the passed cursor. This has the same
- meaning as <option>--cursor</option> option for
+ meaning as <option>--cursor=</option> option for
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
<listitem><para>Upload entries from the location in the
journal <emphasis>after</emphasis> the location specified by
the this cursor. This has the same meaning as
- <option>--after-cursor</option> option for
+ <option>--after-cursor=</option> option for
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
</para></listitem>
</varlistentry>
<citerefentry><refentrytitle>systemd-sleep</refentrytitle><manvolnum>8</manvolnum></citerefentry>
when
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
- attempts to suspend or hibernate the machine.</para>
+ attempts to suspend or hibernate the machine.
+ See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
<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>
+ operations. See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
+ <title>Automatic Dependencies</title>
- <para>The following dependencies are implicitly added:</para>
+ <refsect2>
+ <title>Implicit Dependencies</title>
- <itemizedlist>
- <listitem><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></listitem>
+ <para>The following dependencies are implicitly added:</para>
- <listitem><para>An implicit <varname>Before=</varname> dependency is created
- between an automount unit and the mount unit it activates.</para></listitem>
- </itemizedlist>
- </refsect1>
+ <itemizedlist>
+ <listitem><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></listitem>
- <refsect1>
- <title>Default Dependencies</title>
+ <listitem><para>An implicit <varname>Before=</varname> dependency is created
+ between an automount unit and the mount unit it activates.</para></listitem>
+ </itemizedlist>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
- <itemizedlist>
- <listitem><para>Automount units acquire automatic <varname>Before=</varname> and
- <varname>Conflicts=</varname> on <filename>umount.target</filename> in order to be stopped during
- shutdown.</para></listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem><para>Automount units acquire automatic <varname>Before=</varname> and
+ <varname>Conflicts=</varname> on <filename>umount.target</filename> in order to be stopped during
+ shutdown.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
corresponding device generates a <literal>changed</literal> event.
Other units can use <varname>ReloadPropagatedFrom=</varname> to react
to that event</para>
-
</refsect1>
<refsect1>
- <title>Implicit 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>
+ <title>Automatic Dependencies</title>
- <refsect1>
- <title>Default Dependencies</title>
+ <refsect2>
+ <title>Implicit 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>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
- <para>There are no default dependencies for device units.</para>
+ <para>There are no default dependencies for device units.</para>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>The following dependencies are implicitly added:</para>
-
- <itemizedlist>
- <listitem><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></listitem>
-
- <listitem><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></listitem>
-
- <listitem><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></listitem>
-
- <listitem><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></listitem>
- </itemizedlist>
- </refsect1>
+ <title>Automatic Dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>The following dependencies are implicitly added:</para>
+
+ <itemizedlist>
+ <listitem><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></listitem>
+
+ <listitem><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></listitem>
+
+ <listitem><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></listitem>
+
+ <listitem><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></listitem>
+ </itemizedlist>
+ </refsect2>
- <refsect1>
- <title>Default Dependencies</title>
+ <refsect2>
+ <title>Default Dependencies</title>
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
- <itemizedlist>
- <listitem><para>All mount units acquire automatic <varname>Before=</varname> and <varname>Conflicts=</varname> on
- <filename>umount.target</filename> in order to be stopped during shutdown.</para></listitem>
+ <itemizedlist>
+
<listitem><para>All mount units acquire automatic <varname>Before=</varname> and <varname>Conflicts=</varname> on
+ <filename>umount.target</filename> in order to be stopped during shutdown.</para></listitem>
- <listitem><para>Mount units referring to local file systems automatically gain
- an <varname>After=</varname> dependency on <filename>local-fs-pre.target</filename>.</para></listitem>
+
<listitem><para>Mount units referring to local file systems automatically gain
+ an <varname>After=</varname> dependency on <filename>local-fs-pre.target</filename>.</para></listitem>
- <listitem><para>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.</para></listitem>
- </itemizedlist>
+
<listitem><para>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.</para></listitem>
+ </itemizedlist>
- <para>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.</para>
+ <para>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.</para>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
+ <title>Automatic Dependencies</title>
- <para>The following dependencies are implicitly added:</para>
+ <refsect2>
+ <title>Implicit Dependencies</title>
- <itemizedlist>
- <listitem><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></listitem>
+ <para>The following dependencies are implicitly added:</para>
- <listitem><para>An implicit <varname>Before=</varname> dependency is added
- between a path unit and the unit it is supposed to activate.</para></listitem>
- </itemizedlist>
- </refsect1>
+ <itemizedlist>
+ <listitem><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></listitem>
- <refsect1>
- <title>Default Dependencies</title>
+ <listitem><para>An implicit <varname>Before=</varname> dependency is added
+ between a path unit and the unit it is supposed to activate.</para></listitem>
+ </itemizedlist>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
- <itemizedlist>
- <listitem><para>Path units will automatically 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 <varname>DefaultDependencies=</varname> option.</para></listitem>
- </itemizedlist>
+ <itemizedlist>
+
<listitem><para>Path units will automatically 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 <varname>DefaultDependencies=</varname> option.</para></listitem>
+ </itemizedlist>
- <para></para>
+ <para></para>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>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>Default Dependencies</title>
-
- <para>The following dependencies are added unless
- <varname>DefaultDependencies=no</varname> is set:</para>
-
- <itemizedlist>
- <listitem><para>Scope units will automatically 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
- <varname>DefaultDependencies=</varname> option.</para></listitem>
- </itemizedlist>
+ <title>Automatic Dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>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>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless
+ <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Scope units will automatically 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
+ <varname>DefaultDependencies=</varname> option.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>The following dependencies are implicitly added:</para>
-
- <itemizedlist>
- <listitem><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></listitem>
-
- <listitem><para>Socket activated services are automatically ordered after
- their activating <filename>.socket</filename> units via an
- automatic <varname>After=</varname> dependency.
- Services also pull in all <filename>.socket</filename> units
- listed in <varname>Sockets=</varname> via automatic
- <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem>
- </itemizedlist>
-
- <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>
+ <title>Service Templates</title>
+
+ <para>It is possible for <command>systemd</command> services to take a single argument via the
+ <literal><replaceable>service</replaceable>@<replaceable>argument</replaceable>.service</literal>
+ syntax. Such services are called "instantiated" services, while the unit definition without the
+ <replaceable>argument</replaceable> parameter is called a "template". An example could be a
+ <filename>dhcpcd@.service</filename> service template which takes a network interface as a
+ parameter to form an instantiated service. Within the service file, this parameter or "instance
+ name" can be accessed with %-specifiers. See
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para>
</refsect1>
<refsect1>
- <title>Default Dependencies</title>
-
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
-
- <itemizedlist>
- <listitem><para>Service units will 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></listitem>
-
- <listitem><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></listitem>
- </itemizedlist>
+ <title>Automatic Dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>The following dependencies are implicitly added:</para>
+
+ <itemizedlist>
+ <listitem><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></listitem>
+
+ <listitem><para>Socket activated services are automatically ordered after
+ their activating <filename>.socket</filename> units via an
+ automatic <varname>After=</varname> dependency.
+ Services also pull in all <filename>.socket</filename> units
+ listed in <varname>Sockets=</varname> via automatic
+ <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem>
+ </itemizedlist>
+
+ <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>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Service units will 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></listitem>
+
+ <listitem><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></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
+ <title>Automatic Dependencies</title>
- <para>The following dependencies are implicitly added:</para>
+ <refsect2>
+ <title>Implicit Dependencies</title>
- <itemizedlist>
- <listitem><para>Slice units automatically gain dependencies of type
- <varname>After=</varname> and <varname>Requires=</varname> on
- their immediate parent slice unit.</para></listitem>
- </itemizedlist>
- </refsect1>
+ <para>The following dependencies are implicitly added:</para>
- <refsect1>
- <title>Default Dependencies</title>
+ <itemizedlist>
+ <listitem><para>Slice units automatically gain dependencies of type
+ <varname>After=</varname> and <varname>Requires=</varname> on
+ their immediate parent slice unit.</para></listitem>
+ </itemizedlist>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
- <itemizedlist>
- <listitem><para>Slice units will automatically 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 late system shutdown should disable
- <varname>DefaultDependencies=</varname> option.</para></listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem><para>Slice units will automatically 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 late system shutdown should disable
+ <varname>DefaultDependencies=</varname> option.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>The following dependencies are implicitly added:</para>
-
- <itemizedlist>
- <listitem><para>Socket units automatically gain a <varname>Before=</varname>
- dependency on the service units they activate.</para></listitem>
-
- <listitem><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></listitem>
-
- <listitem><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></listitem>
- </itemizedlist>
-
- <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>Default Dependencies</title>
-
- <para>The following dependencies are added unless
- <varname>DefaultDependencies=no</varname> is set:</para>
-
- <itemizedlist>
- <listitem><para>Socket units automatically gain a
- <varname>Before=</varname> dependency on
- <filename>sockets.target</filename>.</para></listitem>
-
- <listitem><para>Socket units automatically 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. Only sockets
- involved with early boot or late system shutdown should disable
- <varname>DefaultDependencies=</varname> option.</para></listitem>
- </itemizedlist>
+ <title>Automatic Dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>The following dependencies are implicitly added:</para>
+
+ <itemizedlist>
+ <listitem><para>Socket units automatically gain a <varname>Before=</varname>
+ dependency on the service units they activate.</para></listitem>
+
+ <listitem><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></listitem>
+
+ <listitem><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></listitem>
+ </itemizedlist>
+
+ <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>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless
+ <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Socket units automatically gain a
+ <varname>Before=</varname> dependency on
+ <filename>sockets.target</filename>.</para></listitem>
+
+ <listitem><para>Socket units automatically 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. Only sockets
+ involved with early boot or late system shutdown should disable
+ <varname>DefaultDependencies=</varname> option.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>The following dependencies are implicitly added:</para>
-
- <itemizedlist>
- <listitem><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></listitem>
- </itemizedlist>
-
- <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>Default Dependencies</title>
-
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
-
- <itemizedlist>
- <listitem><para>Swap units automatically acquire a <varname>Conflicts=</varname> and a
- <varname>Before=</varname> dependency on <filename>umount.target</filename> so that they are deactivated at
- shutdown as well as a <varname>Before=swap.target</varname> dependency.</para></listitem>
- </itemizedlist>
+ <title>Automatic Dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>The following dependencies are implicitly added:</para>
+
+ <itemizedlist>
+ <listitem><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></listitem>
+ </itemizedlist>
+
+ <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>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Swap units automatically acquire a <varname>Conflicts=</varname> and a
+ <varname>Before=</varname> dependency on <filename>umount.target</filename> so that they are deactivated at
+ shutdown as well as a <varname>Before=swap.target</varname> dependency.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
--- /dev/null
+<?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;
+]>
+
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
+
+<refentry id="systemd.syntax">
+
+ <refentryinfo>
+ <title>systemd.syntax</title>
+ <productname>systemd</productname>
+
+ <authorgroup>
+ <author>
+ <contrib>A. U. Thor</contrib>
+ <firstname>Zbigniew</firstname>
+ <surname>Jędrzejewski-Szmek</surname>
+ <email>zbyszek@in.waw.pl</email>
+ </author>
+ </authorgroup>
+ </refentryinfo>
+
+ <refmeta>
+ <refentrytitle>systemd.syntax</refentrytitle>
+ <manvolnum>7</manvolnum>
+ </refmeta>
+
+ <refnamediv>
+ <refname>systemd.syntax</refname>
+ <refpurpose>General syntax of systemd configuration files</refpurpose>
+ </refnamediv>
+
+ <refsect1>
+ <title>Introduction</title>
+
+ <para>This page describes the basic principles of configuration files used by
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ and related programs for:
+ <itemizedlist>
+ <listitem><para>systemd unit files, see
+ <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.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></listitem>
+
+ <listitem><para>daemon config files, see
+ <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>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>Each file is a plain text file divided into sections, with configuration entries in the
+ style <replaceable>key</replaceable>=<replaceable>value</replaceable>.
+ Empty lines and lines starting with <literal>#</literal> or <literal>;</literal> are
+ ignored, which may be used for commenting.</para>
+
+ <para>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. The limit on
+ line length is very large (currently 1 MB), but it is recommended to avoid such long lines and
+ use multiple directives, variable substitution, or other mechanism as appropriate for the given
+ file type.</para>
+
+ <example><programlisting>[Section A]
+KeyOne=value 1
+KeyTwo=value 2
+
+# a comment
+
+[Section B]
+Setting="something" "some thing" "…"
+KeyTwo=value 2 \
+ value 2 continued
+</programlisting></example>
+
+ <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 file incompatible with parsers for the XDG <filename>.desktop</filename>
+ file format.</para>
+ </refsect1>
+
+</refentry>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>There are no implicit dependencies for target units.</para>
- </refsect1>
-
- <refsect1>
- <title>Default Dependencies</title>
-
- <para>The following dependencies are added unless
- <varname>DefaultDependencies=no</varname> is set:</para>
-
- <itemizedlist>
- <listitem><para>Target units will automatically complement all
- configured dependencies of type <varname>Wants=</varname> or
- <varname>Requires=</varname> with dependencies of type
- <varname>After=</varname> unless <varname>DefaultDependencies=no</varname>
- is set in the specified units. Note that <varname>Wants=</varname> or
- <varname>Requires=</varname> must be defined in the target unit itself — if
- you for example define <varname>Wants=</varname>some.target in
- some.service, the automatic ordering will not be added.</para></listitem>
-
- <listitem><para>Target units automatically gain <varname>Conflicts=</varname>
- dependency against <filename>shutdown.target</filename>.</para></listitem>
- </itemizedlist>
+ <title>Automatic Dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>There are no implicit dependencies for target units.</para>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless
+ <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Target units will automatically complement all
+ configured dependencies of type <varname>Wants=</varname> or
+ <varname>Requires=</varname> with dependencies of type
+ <varname>After=</varname> unless <varname>DefaultDependencies=no</varname>
+ is set in the specified units. Note that <varname>Wants=</varname> or
+ <varname>Requires=</varname> must be defined in the target unit itself — if
+ you for example define <varname>Wants=</varname>some.target in
+ some.service, the automatic ordering will not be added.</para></listitem>
+
+ <listitem><para>Target units automatically gain <varname>Conflicts=</varname>
+ dependency against <filename>shutdown.target</filename>.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
</refsect1>
<refsect1>
- <title>Default Dependencies</title>
+ <title>Automatic Dependencies</title>
- <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+ <refsect2>
+ <title>Implicit Dependencies</title>
- <itemizedlist>
- <listitem><para>Timer units will automatically 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. Only timer
- units involved with early boot or late system shutdown should disable the
- <varname>DefaultDependencies=</varname> option.</para></listitem>
-
- <listitem><para>Timer units
- with at least one <varname>OnCalendar=</varname> directive will have an additional <varname>After=</varname>
- dependency on <filename>time-sync.target</filename> to avoid being started before the system clock has been
- correctly set.</para></listitem>
- </itemizedlist>
+ <para>There are no implicit dependencies for timer units.</para>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+ <itemizedlist>
+ <listitem><para>Timer units will automatically 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. Only timer
+ units involved with early boot or late system shutdown should disable the
+ <varname>DefaultDependencies=</varname> option.</para></listitem>
+
+ <listitem><para>Timer units
+ with at least one <varname>OnCalendar=</varname> directive will have an additional <varname>After=</varname>
+ dependency on <filename>time-sync.target</filename> to avoid being started before the system clock has been
+ correctly set.</para></listitem>
+ </itemizedlist>
+ </refsect2>
</refsect1>
<refsect1>
<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>A unit file is a plain text ini-style file that 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. See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
<para>This man page lists the common configuration options of all
the unit types. These options need to be configured in the [Unit]
<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 can be parameterized by a single argument called the "instance name". The unit
+ is then constructed based on a "template file" which serves as the definition of multiple
+ services or other units. A template unit must have a single <literal>@</literal> at the end of
+ the name (right before the type suffix). The name of the full unit is formed by inserting the
+ instance name between <literal>@</literal> and the unit type suffix. In the unit file itself,
+ the instance parameter may be referred to using <literal>%i</literal> and other specifiers, see
+ below.</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
<literal>w</literal>, <literal>ms</literal>, <literal>us</literal>. For details see
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
- <para>Empty lines and lines starting with <literal>#</literal> or <literal>;</literal> 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>Units can be aliased (have an alternative name), by creating a symlink from the new name
to the existing name in one of the unit search paths. For example,
<filename>systemd-networkd.service</filename> has the alias
socket-based activation which make dependencies implicit,
resulting in a both simpler and more flexible system.</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>As mentioned above, a unit may be instantiated from a template file. 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>
</refsect1>
<refsect1>
- <title>Implicit Dependencies</title>
-
- <para>A number of unit dependencies are implicitly established,
- depending on unit type and unit configuration. These implicit
- dependencies can make unit configuration file cleaner. For the
- implicit dependencies in each unit type, please refer to
- section "Implicit Dependencies" in respective man pages.</para>
-
- <para>For example, service units with <varname>Type=dbus</varname>
- automatically acquire dependencies of type <varname>Requires=</varname>
- and <varname>After=</varname> on <filename>dbus.socket</filename>. See
- <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details.</para>
- </refsect1>
-
- <refsect1>
- <title>Default Dependencies</title>
-
- <para>Default dependencies are similar to implicit dependencies,
- but can be turned on and off by setting
- <varname>DefaultDependencies=</varname> to <varname>yes</varname>
- (the default) and <varname>no</varname>, while implicit dependencies
- are always in effect. See section "Default Dependencies" in respective
- man pages for the effect of enabling
- <varname>DefaultDependencies=</varname> in each unit types.</para>
-
- <para>For example, target units will complement all configured
- dependencies of type <varname>Wants=</varname> or
- <varname>Requires=</varname> with dependencies of type
- <varname>After=</varname> unless <varname>DefaultDependencies=no</varname>
- is set in the specified units. See
- <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details. Note that this behavior can be turned off by setting
- <varname>DefaultDependencies=no</varname>.</para>
+ <title>Automatic dependencies</title>
+
+ <refsect2>
+ <title>Implicit Dependencies</title>
+
+ <para>A number of unit dependencies are implicitly established, depending on unit type and
+ unit configuration. These implicit dependencies can make unit configuration file cleaner. For
+ the implicit dependencies in each unit type, please refer to section "Implicit Dependencies"
+ in respective man pages.</para>
+
+ <para>For example, service units with <varname>Type=dbus</varname> automatically acquire
+ dependencies of type <varname>Requires=</varname> and <varname>After=</varname> on
+ <filename>dbus.socket</filename>. See
+ <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para>
+ </refsect2>
+
+ <refsect2>
+ <title>Default Dependencies</title>
+
+ <para>Default dependencies are similar to implicit dependencies, but can be turned on and off
+ by setting <varname>DefaultDependencies=</varname> to <varname>yes</varname> (the default) and
+ <varname>no</varname>, while implicit dependencies are always in effect. See section "Default
+ Dependencies" in respective man pages for the effect of enabling
+ <varname>DefaultDependencies=</varname> in each unit types.</para>
+
+ <para>For example, target units will complement all configured dependencies of type
+ <varname>Wants=</varname> or <varname>Requires=</varname> with dependencies of type
+ <varname>After=</varname> unless <varname>DefaultDependencies=no</varname> is set in the
+ specified units. See
+ <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details. Note that this behavior can be turned off by setting
+ <varname>DefaultDependencies=no</varname>.</para>
+ </refsect2>
</refsect1>
<refsect1>
<para>Unit settings that create a relationship with a second unit usually show up
in properties of both units, for example in <command>systemctl show</command>
output. In some cases the name of the property is the same as the name of the
- configuration setting, but not always. This table lists the pairs of properties
+ configuration setting, but not always. This table lists the properties
that are shown on two units which are connected through some dependency, and shows
which property on "source" unit corresponds to which property on the "target" unit.
</para>
<entry><varname>ReloadPropagatedFrom=</varname></entry>
<entry><varname>PropagatesReloadTo=</varname></entry>
</row>
+ <row>
+ <entry><varname>Following=</varname></entry>
+ <entry>n/a</entry>
+ <entry>An automatic property</entry>
+ </row>
</tbody>
</tgroup>
</table>
<citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details. <varname>TriggersBy=</varname> is created implicitly on the
triggered unit.</para>
+
+ <para>Note: <varname>Following=</varname> is used to group device aliases and points to the
+ "primary" device unit that systemd is using to track device state, usually corresponding to a
+ sysfs path. It does not show up in the "target" unit.</para>
</refsect1>
<refsect1>
<refsect1>
<title>Description</title>
- <para>These configuration files control NTP network time
- synchronization.</para>
-
+ <para>These configuration files control NTP network time synchronization. See
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for a general description of the syntax.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
projects / thirdparty / systemd.git / commitdiff
