-<?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>
<term><varname>ExecStart=</varname></term>
<listitem><para>Commands with their arguments that are
executed when this service is started. The value is split into
- zero or more command lines is according to the rules described
+ zero or more command lines according to the rules described
below (see section "Command Lines" below).
</para>
<para><varname>ExecStartPost=</varname> commands are only run after
the service has started, as determined by <varname>Type=</varname>
- (i.e. The process has been started for <varname>Type=simple</varname>
+ (i.e. the process has been started for <varname>Type=simple</varname>
or <varname>Type=idle</varname>, the process exits successfully for
<varname>Type=oneshot</varname>, the initial process exits successfully
for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent
should be set to open access to the notification socket
provided by systemd. If <varname>NotifyAccess=</varname> is
not set, it will be implicitly set to <option>main</option>.
- Defaults to 0, which disables this feature.</para></listitem>
+ Defaults to 0, which disables this feature. The service can
+ check whether the service manager expects watchdog keep-alive
+ notifications. See
+ <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ for details.
+ </para></listitem>
</varlistentry>
<varlistentry>
<option>reboot-immediate</option> causes immediate execution
of the
<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- system call, which might result in data loss. Similar,
+ system call, which might result in data loss. Similarly,
<option>poweroff</option>, <option>poweroff-force</option>,
<option>poweroff-immediate</option> have the effect of
powering down the system with similar semantics. Defaults to
<ulink
url="https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB
FunctionFS</ulink> descriptors, for implementation of USB
- gadget functions. This is is used only in conjunction with a
+ gadget functions. This is used only in conjunction with a
socket unit with <varname>ListenUSBFunction=</varname>
- configured. The contents of this file is written to the
+ configured. The contents of this file are written to the
<filename>ep0</filename> file after it is
opened.</para></listitem>
</varlistentry>
then execute another to shut it down, but no process remains
active while they are considered "started". Network
configuration can sometimes fall into this category. Another use
- case is if a oneshot service shall not be executed a each time
+ case is if a oneshot service shall not be executed each time
when they are pulled in as a dependency, but only the first
time.</para>
[Install]
WantedBy=multi-user.target</programlisting>
- <para>For <emphasis>bus-activatable</emphasis> services, don't
+ <para>For <emphasis>bus-activatable</emphasis> services, do not
include a <literal>[Install]</literal> section in the systemd
service file, but use the <varname>SystemdService=</varname>
option in the corresponding DBus service file, for example
WantedBy=multi-user.target</programlisting>
<para>Note that the daemon has to support systemd's notification
- protocol, else systemd will think the service hasn't started yet
+ protocol, else systemd will think the service has not started yet
and kill it after a timeout. For an example of how to update
daemons to support this protocol transparently, take a look at
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
projects / thirdparty / systemd.git / blobdiff