<para>Automount units may be used to implement on-demand mounting
as well as parallelized mounting of file systems.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>If an automount unit is beneath another mount unit in the
+ file system hierarchy, both a requirement and an ordering
+ dependency between both units are created automatically.</para>
+
+ <para>An implicit <varname>Before=</varname> dependency is created
+ between an automount unit and the mount unit it activates.</para>
+
+ <para>Automount units acquire automatic <varname>Before=</varname>
+ and <varname>Conflicts=</varname> on
+ <filename>umount.target</filename> in order to be stopped during
+ shutdown, unless <varname>DefaultDependencies=no</varname> is
+ set.</para>
- <para>If an automount point is beneath another mount point in the
- file system hierarchy, a dependency between both units is created
- automatically.</para>
</refsect1>
<refsect1>
the escaping logic used to convert a file system path to a unit
name see
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ </refsect1>
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Many unit types automatically acquire dependencies on device
+ units of devices they require. For example,
+ <filename>.socket</filename> unit acquire dependencies on the
+ device units of the network interface specified in
+ <varname>BindToDevice=</varname>. Similar, swap and mount units
+ acquire dependencies on the units encapsulating their backing
+ block devices.</para>
</refsect1>
<refsect1>
unit type.</para>
</refsect1>
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>A few execution parameters result in additional, automatic
+ dependencies to be added.</para>
+
+ <para>Units with <varname>WorkingDirectory=</varname> or
+ <varname>RootDirectory=</varname> set automatically gain
+ dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on all mount units required to access
+ the specified paths. This is equivalent to having them listed
+ explicitly in <varname>RequiresMountsFor=</varname>.</para>
+
+ <para>Similar, units with <varname>PrivateTmp=</varname> enabled
+ automatically get mount unit dependencies for all mounts
+ required to access <filename>/tmp</filename> and
+ <filename>/var/tmp</filename>.</para>
+
+ <para>Units whose output standard output or error output is
+ connected to any other sink but <option>null</option>,
+ <option>tty</option> and <option>socket</option> automatically
+ acquire dependencies of type <varname>After=</varname> on
+ <filename>journald.socket</filename>.</para>
+ </refsect1>
+
<refsect1>
<title>Options</title>
and the respective user's home directory if run as user. If
the setting is prefixed with the <literal>-</literal>
character, a missing working directory is not considered
- fatal.</para></listitem>
+ fatal. Note that setting this parameter might result in
+ additional dependencies to be added to the unit (see
+ above).</para></listitem>
</varlistentry>
<varlistentry>
project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
system call. If this is used, it must be ensured that the
process binary and all its auxiliary files are available in
- the <function>chroot()</function> jail.</para></listitem>
+ the <function>chroot()</function> jail. Note that setting this
+ parameter might result in additional dependencies to be added
+ to the unit (see above).</para></listitem>
</varlistentry>
<varlistentry>
<para>This setting defaults to
<option>null</option>.</para></listitem>
</varlistentry>
+
<varlistentry>
<term><varname>StandardOutput=</varname></term>
<listitem><para>Controls where file descriptor 1 (STDOUT) of
<para>This setting defaults to the value set with
<option>DefaultStandardOutput=</option> in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- which defaults to <option>journal</option>.</para></listitem>
+ which defaults to <option>journal</option>. Note that setting
+ this parameter might result in additional dependencies to be
+ added to the unit (see above).</para></listitem>
</varlistentry>
+
<varlistentry>
<term><varname>StandardError=</varname></term>
<listitem><para>Controls where file descriptor 2 (STDERR) of
standard error. This setting defaults to the value set with
<option>DefaultStandardError=</option> in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- which defaults to <option>inherit</option>.</para></listitem>
+ which defaults to <option>inherit</option>. Note that setting
+ this parameter might result in additional dependencies to be
+ added to the unit (see above).</para></listitem>
</varlistentry>
+
<varlistentry>
<term><varname>TTYPath=</varname></term>
<listitem><para>Sets the terminal device node to use if
unit, to allow on-demand or parallelized mounting. See
<citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
- <para>If a mount point is beneath another mount point in the file
- system hierarchy, a dependency between both units is created
- automatically.</para>
-
<para>Mount points created at runtime (independently of unit files
or <filename>/etc/fstab</filename>) will be monitored by systemd
and appear like any other mount unit in systemd. See
File Systems</ulink>.</para>
</refsect1>
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>If a mount unit is beneath another mount unit in the file
+ system hierarchy, both a requirement dependency and an ordering
+ dependency between both units are created automatically.</para>
+
+ <para>Block device backed file systems automatically gain
+ <varname>BindsTo=</varname> and <varname>After=</varname> type
+ dependencies on the device unit encapsulating the block
+ device (see below).</para>
+
+ <para>If traditional file system quota is enabled for a mount
+ unit, automatic <varname>Wants=</varname> and
+ <varname>Before=</varname> dependencies on
+ <filename>systemd-quotacheck.service</filename> and
+ <filename>quotaon.service</filename> are added.</para>
+
+ <para>For mount units with
+ <varname>DefaultDependencies=yes</varname> (the default) a couple
+ additional dependencies are added. Mount units referring to local
+ file systems automatically gain an <varname>After=</varname>
+ dependency on <filename>local-fs-pre.target</filename>. Network
+ mount units automatically acquire <varname>After=</varname>
+ dependencies on <filename>remote-fs-pre.target</filename>,
+ <filename>network.target</filename> and
+ <filename>network-online.target</filename>. Towards the latter a
+ <varname>Wants=</varname> unit is added as well. Mount units
+ referring to local and network file systems are distinguished by
+ their file system type specification. In some cases this is not
+ sufficient (for example network block device based mounts, such as
+ iSCSI), in which case <option>_netdev</option> may be added to the
+ mount option string of the unit, which forces systemd to consider the
+ mount unit a network mount. Mount units (regardless if local or
+ network) also acquire automatic <varname>Before=</varname> and
+ <varname>Conflicts=</varname> on
+ <filename>umount.target</filename> in order to be stopped
+ during shutdown.</para>
+
+ <para>Additional implicit dependencies may be added as result of
+ execution and resource control parameters as documented in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ </refsect1>
+
<refsect1>
<title><filename>fstab</filename></title>
<para>When reading <filename>/etc/fstab</filename> a few special
mount options are understood by systemd which influence how
dependencies are created for mount points. systemd will create a
- dependency of type <option>Wants</option> or
+ dependency of type <varname>Wants=</varname> or
<option>Requires</option> (see option <option>nofail</option>
below), from either <filename>local-fs.target</filename> or
<filename>remote-fs.target</filename>, depending whether the file
limitations as inotify, and for example cannot be used to monitor
files or directories changed by other machines on remote NFS file
systems.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>If a path unit is beneath another mount unit in the file
+ system hierarchy, both a requirement and an ordering dependency
+ between both units are created automatically.</para>
- <para>If a path unit is beneath another mount point in the file
- system hierarchy, a dependency between both units is created
- automatically.</para>
+ <para>An implicit <varname>Before=</varname> dependency is added
+ between a path unit and the unit it is supposed to activate.</para>
<para>Unless <varname>DefaultDependencies=false</varname> is used,
path units will implicitly have dependencies of type
+ <varname>Before=</varname> on <filename>paths.target</filename>,
+ dependencies of type <varname>After=</varname> and
+ <varname>Requires=</varname> on
+ <filename>sysinit.target</filename>, and have dependencies of type
<varname>Conflicts=</varname> and <varname>Before=</varname> on
<filename>shutdown.target</filename>. These ensure that path units
are terminated cleanly prior to system shutdown. Only path units
use of resource control APIs from programs.</para>
</refsect1>
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Units with the <varname>Slice=</varname> setting set get
+ automatic <varname>Requires=</varname> and
+ <varname>After=</varname> dependencies on the specified slice
+ unit.</para>
+ </refsect1>
+
<refsect1>
<title>Options</title>
url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
Control Group Interfaces</ulink> for an introduction on how to make
use of scope units from programs.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
<para>Unless <varname>DefaultDependencies=false</varname>
is used, scope units will implicitly have dependencies of
shutdown. Only scope units involved with early boot or
late system shutdown should disable this option.
</para>
+
+ <para>Additional implicit dependencies may be added as result of
+ resource control parameters as documented in
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
</refsect1>
<refsect1>
-<?xml version='1.0'?> <!--*-nxml-*-->
+<?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">
which configure resource control settings for the processes of the
service.</para>
- <para>Unless <varname>DefaultDependencies=</varname> is set to
- <option>false</option>, service units will implicitly have
- dependencies of type <varname>Requires=</varname> and
- <varname>After=</varname> on <filename>basic.target</filename> as
- well as dependencies of type <varname>Conflicts=</varname> and
- <varname>Before=</varname> on
- <filename>shutdown.target</filename>. These ensure that normal
- service units pull in basic system initialization, and are
- terminated cleanly prior to system shutdown. Only services
- involved with early boot or late system shutdown should disable
- this option.</para>
-
<para>If a service is requested under a certain name but no unit
configuration file is found, systemd looks for a SysV init script
by the same name (with the <filename>.service</filename> suffix
compatibility is quite comprehensive but not 100%. For details
about the incompatibilities, see the <ulink
url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
- with SysV</ulink> document.
- </para>
+ with SysV</ulink> document.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Services with <varname>Type=dbus</varname> set automatically
+ acquire dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on
+ <filename>dbus.socket</filename>.</para>
+
+ <para>Socket activated service are automatically ordered after
+ their activated <filename>.socket</filename> units via an
+ automatic <varname>After=</varname> dependency.</para>
+
+ <para>Unless <varname>DefaultDependencies=</varname> is set to
+ <option>false</option>, service units will implicitly have
+ dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on <filename>sysinit.target</filename>,
+ a dependency of type <varname>After=</varname> on
+ <filename>basic.target</filename> as well as dependencies of
+ type <varname>Conflicts=</varname> and <varname>Before=</varname>
+ on <filename>shutdown.target</filename>. These ensure that normal
+ service units pull in basic system initialization, and are
+ terminated cleanly prior to system shutdown. Only services
+ involved with early boot or late system shutdown should disable
+ this option.</para>
+
+ <para>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>
url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New
Control Group Interfaces</ulink> for an introduction on how to make
use of slice units from programs.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Slice units automatically gain dependencies of type
+ <varname>After=</varname> and <varname>Requires=</varname> on
+ their immediate parent slice unit.</para>
<para>Unless <varname>DefaultDependencies=false</varname>
is used, slice units will implicitly have dependencies of
service file).</para>
</refsect1>
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Socket units automatically gain a <varname>Before=</varname>
+ dependency on the service units they activate.</para>
+
+ <para>Socket units referring to file system paths (such as AF_UNIX
+ sockets or FIFOs) implicitly gain <varname>Requires=</varname> and
+ <varname>After=</varname> dependencies on all mount units
+ necessary to access those paths.</para>
+
+ <para>Socket units using the <varname>BindToDevice=</varname>
+ setting automatically gain a <varname>BindsTo=</varname> and
+ <varname>After=</varname> dependency on the device unit
+ encapsulating the specified network interface.</para>
+
+ <para>If <varname>DefaultDependencies=yes</varname> is set (the
+ default), socket units automatically gain a
+ <varname>Before=</varname> dependency on
+ <filename>sockets.target</filename>. They also gain a pair of
+ <varname>After=</varname> and <varname>Requires=</varname>
+ dependency on <filename>sysinit.target</filename>, and a pair of
+ <varname>Before=</varname> and <varname>Conflicts=</varname>
+ dependencies on <filename>shutdown.target</filename>. These
+ dependencies ensure that the socket unit is started before normal
+ services at boot, and is stopped on shutdown.</para>
+
+ <para>Additional implicit dependencies may be added as result of
+ execution and resource control parameters as documented in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ </refsect1>
+
<refsect1>
<title>Options</title>
<listitem><para>Specifies a network interface name to bind
this socket to. If set, traffic will only be accepted from the
specified network interfaces. This controls the
- SO_BINDTODEVICE socket option (see
- <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ SO_BINDTODEVICE socket option (see <citerefentry
+ project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details). If this option is used, an automatic dependency
from this socket unit on the network interface device unit
(<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- is created.</para></listitem>
+ is created. Note that setting this parameter might result in
+ additional dependencies to be added to the unit (see
+ above).</para></listitem>
</varlistentry>
<varlistentry>
with <varname>Accept=no</varname>. It defaults to the service
that bears the same name as the socket (with the suffix
replaced). In most cases, it should not be necessary to use
- this option.</para></listitem>
+ this option. Note that setting this parameter might result in
+ additional dependencies to be added to the unit (see
+ above).</para></listitem>
</varlistentry>
<varlistentry>
<para>Additional options are listed in
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- which define the execution environment the
- <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- binary is executed in, and in
+ which define the execution environment the <citerefentry
+ project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ binary is executed in, in
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- which define the way the processes are terminated, and in
+ which define the way the these processes are
+ terminated, and in
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
- which configure resource control settings for the processes of the
- service.</para>
+ which configure resource control settings for these processes of the
+ unit.</para>
<para>Swap units must be named after the devices
or files they control. Example: the swap device
the escaping logic used to convert a file system path to a unit
name, see
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
- <para>All swap units automatically get the appropriate
- dependencies on the devices or on the mount points of the files
+ <para>All swap units automatically get the
+ <varname>BindsTo=</varname> and <varname>After=</varname>
+ dependencies on the device units or the mount units of the files
they are activated from.</para>
<para>Swap units with <varname>DefaultDependencies=</varname>
- enabled implicitly acquire a conflicting dependency to
+ enabled implicitly acquire a <varname>Conflicts=</varname> and an
+ <varname>After=</varname> dependency on
<filename>umount.target</filename> so that they are deactivated at
- shutdown.</para>
+ shutdown, unless <varname>DefaultDependencies=no</varname> is
+ specified.</para>
+
+ <para>Additional implicit dependencies may be added as result of
+ execution and resource control parameters as documented in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ and
+ <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
</refsect1>
<refsect1>
See
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details).</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
<para>Unless <varname>DefaultDependencies=</varname> is set to
- <option>false</option>, target units will implicitly complement
- all configured dependencies of type <varname>Wants=</varname>,
+ <option>no</option>, target units will implicitly complement all
+ configured dependencies of type <varname>Wants=</varname>,
<varname>Requires=</varname>,
<varname>RequiresOverridable=</varname> with dependencies of type
- <varname>After=</varname> if the units in question also have
- <varname>DefaultDependencies=true</varname>.
- </para>
+ <varname>After=</varname>, unless an ordering dependency of any
+ kind between the target and the respective other unit is already
+ in place. Note that this behaviour is disabled if either unit has
+ <varname>DefaultDependencies=no</varname>.</para>
</refsect1>
<refsect1>
-<?xml version='1.0'?> <!--*-nxml-*-->
+<?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">
<filename>foo.timer</filename> activates a matching service
<filename>foo.service</filename>. The unit to activate may be
controlled by <varname>Unit=</varname> (see below).</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Timer units automatically gain a <varname>Before=</varname>
+ dependency on the service they are supposed to activate.</para>
<para>Unless <varname>DefaultDependencies=</varname> is set to
<option>false</option>, all timer units will implicitly have
- dependencies of type <varname>Conflicts=</varname> and
- <varname>Before=</varname> on <filename>shutdown.target</filename>
- to ensure that they are stopped cleanly prior to system shutdown.
- Timer units with at least one <varname>OnCalendar=</varname>
- directive will have an additional <varname>After=</varname>
- dependency on <filename>timer-sync.target</filename> to avoid
- being started before the system clock has been correctly set. Only
- timer units involved with early boot or late system shutdown
- should disable the <varname>DefaultDependencies=</varname>
- option.</para>
+ dependencies of type <varname>Requires=</varname> and
+ <varname>After=</varname> on <filename>sysinit.target</filename>,
+ a dependency of type <varname>Before=</varname> on
+ <filename>timers.target</filename>, as well as
+ <varname>Conflicts=</varname> and <varname>Before=</varname> on
+ <filename>shutdown.target</filename> to ensure that they are
+ stopped cleanly prior to system shutdown. Timer units with at
+ least one <varname>OnCalendar=</varname> directive will have an
+ additional <varname>After=</varname> dependency on
+ <filename>timer-sync.target</filename> to avoid being started
+ before the system clock has been correctly set. Only timer units
+ involved with early boot or late system shutdown should disable
+ the <varname>DefaultDependencies=</varname> option.</para>
</refsect1>
<refsect1>
-<?xml version='1.0'?> <!--*-nxml-*-->
+<?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" >
consider it mostly obsolete, and want people to
use .d/ drop-ins instead. -->
- <para>Note that while systemd offers a flexible dependency system
- between units it is recommended to use this functionality only
- sparingly and instead rely on techniques such as bus-based or
- socket-based activation which make dependencies implicit,
- resulting in a both simpler and more flexible system.</para>
-
<para>Some unit names reflect paths existing in the file system
namespace. Example: a device unit
<filename>dev-sda.device</filename> refers to a device with the
</refsect1>
+ <refsect1>
+ <title>Automatic Dependencies</title>
+
+ <para>Note that while systemd offers a flexible dependency system
+ between units it is recommended to use this functionality only
+ sparingly and instead rely on techniques such as bus-based or
+ socket-based activation which make dependencies implicit,
+ resulting in a both simpler and more flexible system.</para>
+
+ <para>A number of unit dependencies are automatically established,
+ depending on unit configuration. On top of that, for units with
+ <varname>DefaultDependencies=yes</varname> (the default) a couple
+ of additional dependencies are added. The precise effect of
+ <varname>DefaultDependencies=yes</varname> depends on the unit
+ type (see below).</para>
+
+ <para>If <varname>DefaultDependencies=yes</varname> is set, units
+ that are referenced by other units of type
+ <filename>.target</filename> via a <varname>Wants=</varname> or
+ <varname>Requires=</varname> dependency might automatically gain
+ an <varname>Before=</varname> dependency too. See
+ <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para>
+ </refsect1>
+
<refsect1>
<title>Unit File Load Path</title>
projects / thirdparty / systemd.git / commitdiff
