mirror of
https://github.com/systemd/systemd.git
synced 2025-01-20 07:24:19 +08:00
Merge pull request #8735 from keszybz/small-docs-updates
Small docs updates
This commit is contained in:
commit
d28e92c3fc
@ -48,7 +48,10 @@
|
||||
<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" />
|
||||
|
@ -48,7 +48,10 @@
|
||||
<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" />
|
||||
|
@ -47,9 +47,11 @@
|
||||
<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>
|
||||
|
||||
|
@ -50,10 +50,10 @@
|
||||
<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" />
|
||||
|
@ -628,8 +628,8 @@ manpages = [
|
||||
'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', [], ''],
|
||||
@ -639,7 +639,10 @@ manpages = [
|
||||
''],
|
||||
['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',
|
||||
@ -696,6 +699,7 @@ manpages = [
|
||||
['systemd.socket', '5', [], ''],
|
||||
['systemd.special', '7', [], ''],
|
||||
['systemd.swap', '5', [], ''],
|
||||
['systemd.syntax', '7', [], ''],
|
||||
['systemd.target', '5', [], ''],
|
||||
['systemd.time', '7', [], ''],
|
||||
['systemd.timer', '5', [], ''],
|
||||
|
@ -163,8 +163,8 @@
|
||||
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>
|
||||
|
@ -52,14 +52,13 @@
|
||||
<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>
|
||||
@ -110,7 +109,7 @@
|
||||
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>
|
||||
@ -123,7 +122,7 @@
|
||||
<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>
|
||||
@ -133,7 +132,7 @@
|
||||
|
||||
<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>
|
||||
|
||||
@ -143,7 +142,7 @@
|
||||
<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>
|
||||
|
@ -109,7 +109,10 @@
|
||||
<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" />
|
||||
|
@ -63,7 +63,9 @@
|
||||
<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" />
|
||||
|
@ -76,30 +76,34 @@
|
||||
</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>
|
||||
|
||||
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -77,25 +77,28 @@
|
||||
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>
|
||||
<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>
|
||||
<refsect2>
|
||||
<title>Implicit Dependencies</title>
|
||||
|
||||
<refsect1>
|
||||
<title>Default 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>
|
||||
|
||||
<para>There are no default dependencies for device units.</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<para>There are no default dependencies for device units.</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -102,57 +102,61 @@
|
||||
</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 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>
|
||||
<para>The following dependencies are implicitly added:</para>
|
||||
|
||||
<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>
|
||||
<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>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>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>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>
|
||||
<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>
|
||||
|
||||
<refsect1>
|
||||
<title>Default Dependencies</title>
|
||||
<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>
|
||||
|
||||
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
|
||||
<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>
|
||||
<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>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>Mount units referring to local file systems automatically gain
|
||||
an <varname>After=</varname> dependency on <filename>local-fs-pre.target</filename>.</para></listitem>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -71,36 +71,40 @@
|
||||
</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>
|
||||
|
||||
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
|
||||
<para></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>
|
||||
|
||||
<para></para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -64,29 +64,33 @@
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Implicit Dependencies</title>
|
||||
<title>Automatic 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>
|
||||
<refsect2>
|
||||
<title>Implicit Dependencies</title>
|
||||
|
||||
<refsect1>
|
||||
<title>Default 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>
|
||||
|
||||
<para>The following dependencies are added unless
|
||||
<varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
@ -78,55 +78,73 @@
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Implicit Dependencies</title>
|
||||
<title>Service Templates</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>
|
||||
<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>
|
||||
<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>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>
|
||||
<para>The following dependencies are implicitly added:</para>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
@ -85,29 +85,33 @@
|
||||
</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>
|
||||
|
||||
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -110,53 +110,57 @@
|
||||
</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>Socket units automatically gain a <varname>Before=</varname>
|
||||
dependency on the service units they activate.</para></listitem>
|
||||
<para>The following dependencies are implicitly added:</para>
|
||||
|
||||
<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>
|
||||
<itemizedlist>
|
||||
<listitem><para>Socket units automatically gain a <varname>Before=</varname>
|
||||
dependency on the service units they activate.</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>
|
||||
<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>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<refsect1>
|
||||
<title>Default Dependencies</title>
|
||||
<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>
|
||||
|
||||
<para>The following dependencies are added unless
|
||||
<varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Socket units automatically gain a
|
||||
<varname>Before=</varname> dependency on
|
||||
<filename>sockets.target</filename>.</para></listitem>
|
||||
<para>The following dependencies are added unless
|
||||
<varname>DefaultDependencies=no</varname> is set:</para>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
@ -76,34 +76,38 @@
|
||||
</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>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>The following dependencies are implicitly added:</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>
|
||||
<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>
|
||||
|
||||
<refsect1>
|
||||
<title>Default Dependencies</title>
|
||||
<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>
|
||||
|
||||
<para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
107
man/systemd.syntax.xml
Normal file
107
man/systemd.syntax.xml
Normal file
@ -0,0 +1,107 @@
|
||||
<?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>
|
@ -69,30 +69,34 @@
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Implicit Dependencies</title>
|
||||
<title>Automatic Dependencies</title>
|
||||
|
||||
<para>There are no implicit dependencies for target units.</para>
|
||||
</refsect1>
|
||||
<refsect2>
|
||||
<title>Implicit Dependencies</title>
|
||||
|
||||
<refsect1>
|
||||
<title>Default Dependencies</title>
|
||||
<para>There are no implicit dependencies for target units.</para>
|
||||
</refsect2>
|
||||
|
||||
<para>The following dependencies are added unless
|
||||
<varname>DefaultDependencies=no</varname> is set:</para>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<para>The following dependencies are added unless
|
||||
<varname>DefaultDependencies=no</varname> is set:</para>
|
||||
|
||||
<listitem><para>Target units automatically gain <varname>Conflicts=</varname>
|
||||
dependency against <filename>shutdown.target</filename>.</para></listitem>
|
||||
</itemizedlist>
|
||||
<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>
|
||||
|
@ -82,23 +82,33 @@
|
||||
</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>
|
||||
<para>There are no implicit dependencies for timer units.</para>
|
||||
</refsect2>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
@ -83,18 +83,13 @@
|
||||
<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]
|
||||
@ -117,18 +112,17 @@
|
||||
<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
|
||||
@ -154,11 +148,6 @@
|
||||
<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
|
||||
@ -223,21 +212,15 @@
|
||||
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>
|
||||
@ -285,40 +268,40 @@
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Implicit Dependencies</title>
|
||||
<title>Automatic 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>
|
||||
<refsect2>
|
||||
<title>Implicit Dependencies</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<refsect1>
|
||||
<title>Default Dependencies</title>
|
||||
<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>
|
||||
|
||||
<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>
|
||||
<refsect2>
|
||||
<title>Default Dependencies</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
@ -1331,7 +1314,7 @@
|
||||
<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>
|
||||
@ -1406,6 +1389,11 @@
|
||||
<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>
|
||||
@ -1431,6 +1419,10 @@
|
||||
<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>
|
||||
|
@ -47,9 +47,9 @@
|
||||
<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" />
|
||||
|
Loading…
Reference in New Issue
Block a user