acquired. Service units with this
option configured implicitly gain
dependencies on the
- <filename>dbus.target</filename>
+ <filename>dbus.socket</filename>
unit.</para>
<para>Behaviour of
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>GuessMainPID=</varname></term>
+
+ <listitem><para>Takes a boolean value
+ that specifies whether systemd should
+ try to guess the main PID of a service
+ should if it cannot be determined
+ reliably. This option is ignored
+ unless <option>Type=forking</option>
+ is set and <option>PIDFile=</option>
+ is unset because for the other types
+ or with an explicitly configured PID
+ file the main PID is always known. The
+ guessing algorithm might come to
+ incorrect conclusions if a daemon
+ consists of more than one process. If
+ the main PID cannot be determined
+ failure detection and automatic
+ restarting of a service will not work
+ reliably. Defaults to
+ <option>yes</option>.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>PIDFile=</varname></term>
daemon. Use of this option is
recommended for services where
<varname>Type=</varname> is set to
- <option>forking</option>.</para>
+ <option>forking</option>. systemd will
+ read the PID of the main process of
+ the daemon after start-up of the
+ service. systemd will not write to the
+ file configured here.</para>
</listitem>
</varlistentry>
<literal>-</literal> an exit code of
the command normally considered a
failure (i.e. non-zero exit status or
- abormal exit due to signal) is ignored
+ abnormal exit due to signal) is ignored
and considered success. If both
<literal>-</literal> and
<literal>@</literal> are used for the
- same command the former must preceed
+ same command the former must precede
the latter. Unless
<varname>Type=forking</varname> is
set, the process started via this
the command in
<varname>ExecStart=</varname>. Multiple
command lines may be concatenated in a
- single directive, by seperating them
+ single directive, by separating them
by semicolons (these semicolons must
be passed as separate words). In that
case, the commands are executed one
after the other,
serially. Alternatively, these
directives may be specified more than
- once whith the same effect. However,
+ once with the same effect. However,
the latter syntax is not recommended
for compatibility with parsers
suitable for XDG
daemon, and may be used for command
lines like the following:
<command>/bin/kill -HUP
- $(MAINPID)</command>.</para></listitem>
+ $MAINPID</command>.</para></listitem>
</varlistentry>
<varlistentry>
requested. Specifier and environment
variable substitution is supported
(including
- <literal>$(MAINPID)</literal>, see
+ <literal>$MAINPID</literal>, see
above).</para></listitem>
</varlistentry>
time span value such as "5min
20s". Pass 0 to disable the timeout
logic. Defaults to
- 60s.</para></listitem>
+ 90s.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Restart=</varname></term>
<listitem><para>Configures whether the
- main service process shall be restarted when
- it exists. Takes one of
+ main service process shall be
+ restarted when it exits. Takes one of
<option>no</option>,
- <option>on-success</option> or
- <option>always</option>. If
- set to <option>no</option> (the
- default) the service will not be
- restarted when it exits. If set to
- <option>on-success</option> it
- will be restarted only when it exited
- cleanly, i.e. terminated with an exit
- code of 0. If set to
- <option>always</option> the
+ <option>on-success</option>,
+ <option>on-failure</option>,
+ <option>on-abort</option> or
+ <option>always</option>. If set to
+ <option>no</option> (the default) the
+ service will not be restarted when it
+ exits. If set to
+ <option>on-success</option> it will be
+ restarted only when it exited cleanly,
+ i.e. terminated with an exit code of
+ 0. If set to
+ <option>on-failure</option> it will be
+ restarted only when it exited with an
+ exit code not equalling 0, or when
+ terminated by a signal. If set to
+ <option>on-abort</option> it will be
+ restarted only if it exits due to
+ reception of an uncaught signal. If
+ set to <option>always</option> the
service will be restarted regardless
whether it exited cleanly or not, or
got terminated abnormally by a
processes of this service shall be
killed. One of
<option>control-group</option>,
- <option>process-group</option>,
<option>process</option>,
<option>none</option>.</para>
stop command (as configured with
<varname>ExecStop=</varname>) is
executed. If set to
- <option>process-group</option> only
- the members of the process group of
- the main service process are
- killed. If set to
<option>process</option> only the main
process itself is killed. If set to
<option>none</option> no process is
group and the control group continues
to exist after stop unless it is
empty. Defaults to
- <option>control-croup</option>.</para>
+ <option>control-group</option>.</para>
<para>Processes will first be
- terminated via SIGTERM. If then after
- a delay (configured via the
+ terminated via SIGTERM (unless the
+ signal to send is changed via
+ <varname>KillSignal=</varname>). If
+ then after a delay (configured via the
<varname>TimeoutSec=</varname> option)
processes still remain, the
termination request is repeated with
- the SIGKILL signal. See
+ the SIGKILL signal (unless this is
+ disabled via the
+ <varname>SendSIGKILL=</varname>
+ option). See
<citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for more
information.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>KillSignal=</varname></term>
+ <listitem><para>Specifies which signal
+ to use when killing a
+ service. Defaults to SIGTERM.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>SendSIGKILL=</varname></term>
+ <listitem><para>Specifies whether to
+ send SIGKILL to remaining processes
+ after a timeout, if the normal
+ shutdown procedure left processes of
+ the service around. Takes a boolean
+ value. Defaults to "yes".
+ </para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>NonBlocking=</varname></term>
<listitem><para>Set O_NONBLOCK flag
<option>main</option> or
<option>all</option>. If
<option>none</option> no daemon status
- updates are accepted by the service
+ updates are accepted from the service
processes, all status update messages
are ignored. If <option>main</option>
only service updates sent from the
<varname>Type=notify</varname> (see above).</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>Sockets=</varname></term>
+ <listitem><para>Specifies the name of
+ the socket units this service shall
+ inherit the sockets from when the
+ service (ignoring the different suffix
+ of course) is started. Normally it
+ should not be necessary to use this
+ setting as all sockets whose unit
+ shares the same name as the service
+ are passed to the spawned
+ process.</para>
+
+ <para>Note that the same socket may be
+ passed to multiple processes at the
+ same time. Also note that a different
+ service may be activated on incoming
+ traffic than inherits the sockets. Or
+ in other words: The
+ <varname>Service=</varname> setting of
+ <filename>.socket</filename> units
+ doesn't have to match the inverse of the
+ <varname>Sockets=</varname> setting of
+ the <filename>.service</filename> it
+ refers to.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>FsckPassNo=</varname></term>
+ <listitem><para>Set the fsck passno
+ priority to use to order this service
+ in relation to other file system
+ checking services. This option is only
+ necessary to fix ordering in relation
+ to fsck jobs automatically created for
+ all <filename>/etc/fstab</filename>
+ entries with a value in the fs_passno
+ column > 0. As such it should only be
+ used as option for fsck
+ services. Almost always it is a better
+ choice to add explicit ordering
+ directives via
+ <varname>After=</varname> or
+ <varname>Before=</varname>,
+ instead. For more details see
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
+ used, pass an integer value in the
+ same range as
+ <filename>/etc/fstab</filename>'s
+ fs_passno column. See
+ <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details.</para></listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>