2010-05-16 01:06:41 +04:00
<?xml version='1.0'?> <!-- * - nxml - * -->
<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"?>
< !DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
This file is part of systemd.
Copyright 2010 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
2012-04-12 02:20:58 +04:00
under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
2010-05-16 01:06:41 +04:00
(at your option) any later version.
systemd is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
2012-04-12 02:20:58 +04:00
Lesser General Public License for more details.
2010-05-16 01:06:41 +04:00
2012-04-12 02:20:58 +04:00
You should have received a copy of the GNU Lesser General Public License
2010-05-16 01:06:41 +04:00
along with systemd; If not, see <http: / / w w w . g n u . o r g / l i c e n s e s /> .
-->
<refentry id= "systemd.service" >
<refentryinfo >
<title > systemd.service</title>
<productname > systemd</productname>
<authorgroup >
<author >
<contrib > Developer</contrib>
<firstname > Lennart</firstname>
<surname > Poettering</surname>
<email > lennart@poettering.net</email>
</author>
</authorgroup>
</refentryinfo>
<refmeta >
<refentrytitle > systemd.service</refentrytitle>
<manvolnum > 5</manvolnum>
</refmeta>
<refnamediv >
<refname > systemd.service</refname>
2012-07-16 20:08:25 +04:00
<refpurpose > Service unit configuration</refpurpose>
2010-05-16 01:06:41 +04:00
</refnamediv>
<refsynopsisdiv >
2013-02-14 07:46:37 +04:00
<para > <filename > <replaceable > service</replaceable> .service</filename> </para>
2010-05-16 01:06:41 +04:00
</refsynopsisdiv>
<refsect1 >
<title > Description</title>
2010-07-02 01:49:50 +04:00
<para > A unit configuration file whose name ends in
2010-07-02 03:17:55 +04:00
<filename > .service</filename> encodes information
about a process controlled and supervised by
systemd.</para>
2010-05-16 01:06:41 +04:00
<para > This man page lists the configuration options
specific to this unit type. See
<citerefentry > <refentrytitle > systemd.unit</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for the common options of all unit configuration
2010-07-01 21:39:35 +04:00
files. The common configuration items are configured
2010-07-03 21:54:00 +04:00
in the generic <literal > [Unit]</literal> and
<literal > [Install]</literal> sections. The service
specific configuration options are configured in the
<literal > [Service]</literal> section.</para>
2010-07-01 21:39:35 +04:00
2010-07-02 21:51:07 +04:00
<para > Additional options are listed in
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
which define the execution environment the commands
2012-07-20 01:47:10 +04:00
are executed in, and in
2013-07-10 09:25:02 +04:00
<citerefentry > <refentrytitle > systemd.kill</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
2012-07-20 01:47:10 +04:00
which define the way the processes of the service are
2013-07-10 09:25:02 +04:00
terminated, and in
2013-09-27 02:05:07 +04:00
<citerefentry > <refentrytitle > systemd.resource-control</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
which configure resource control settings for the
2013-07-10 09:25:02 +04:00
processes of the service.</para>
2010-07-03 21:54:00 +04:00
<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>
2010-07-06 05:46:31 +04:00
<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 removed) and
dynamically creates a service unit from that
script. This is useful for compatibility with
2012-06-28 20:58:56 +04:00
SysV. Note that this compatibility is quite
comprehensive but not 100%. For details about the
2012-10-26 02:16:47 +04:00
incompatibilities see the <ulink
2012-06-28 20:58:56 +04:00
url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
with SysV</ulink> document.
</para>
2010-05-16 01:06:41 +04:00
</refsect1>
<refsect1 >
<title > Options</title>
2010-07-03 21:54:00 +04:00
<para > Service files must include a
<literal > [Service]</literal> section, which carries
information about the service and the process it
supervises. A number of options that may be used in
this section are shared with other unit types. These
options are documented in
2012-07-20 01:47:10 +04:00
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
and
<citerefentry > <refentrytitle > systemd.kill</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> . The
2010-07-03 21:54:00 +04:00
options specific to the <literal > [Service]</literal>
section of service units are the following:</para>
2010-07-01 21:39:35 +04:00
2013-01-26 19:47:16 +04:00
<variablelist class= 'unit-directives' >
2010-05-16 01:06:41 +04:00
<varlistentry >
<term > <varname > Type=</varname> </term>
2010-07-01 21:39:35 +04:00
<listitem > <para > Configures the process
start-up type for this service
unit. One of <option > simple</option> ,
<option > forking</option> ,
2010-08-13 20:23:01 +04:00
<option > oneshot</option> ,
2010-07-01 21:39:35 +04:00
<option > dbus</option> ,
2012-04-26 22:32:26 +04:00
<option > notify</option> or
<option > idle</option> .</para>
2010-07-01 21:39:35 +04:00
<para > If set to
<option > simple</option> (the default
2012-05-03 16:46:29 +04:00
value if <varname > BusName=</varname>
2013-09-12 23:12:49 +04:00
is not specified), it is expected that
2012-05-03 16:46:29 +04:00
the process configured with
2010-07-01 21:39:35 +04:00
<varname > ExecStart=</varname> is the
main process of the service. In this
2010-08-13 20:46:04 +04:00
mode, if the process offers
functionality to other processes on
2013-09-12 23:12:49 +04:00
the system, its communication channels
2010-08-13 20:46:04 +04:00
should be installed before the daemon
is started up (e.g. sockets set up by
systemd, via socket activation), as
systemd will immediately proceed
starting follow-up units.</para>
2010-07-01 21:39:35 +04:00
<para > If set to
2013-09-12 23:12:49 +04:00
<option > forking</option> , it is
2010-07-01 21:39:35 +04:00
expected that the process configured
with <varname > ExecStart=</varname>
2010-08-13 20:46:04 +04:00
will call <function > fork()</function>
as part of its start-up. The parent process is
expected to exit when start-up is
complete and all communication
2013-09-12 23:12:49 +04:00
channels are set up. The child continues
2010-08-13 20:46:04 +04:00
to run as the main daemon
2012-09-04 21:24:16 +04:00
process. This is the behavior of
2010-08-13 20:46:04 +04:00
traditional UNIX daemons. If this
2010-07-01 21:39:35 +04:00
setting is used, it is recommended to
also use the
<varname > PIDFile=</varname> option, so
that systemd can identify the main
process of the daemon. systemd will
proceed starting follow-up units as
soon as the parent process
exits.</para>
2012-09-04 21:24:16 +04:00
<para > Behavior of
2010-08-13 20:23:01 +04:00
<option > oneshot</option> is similar
2010-07-01 21:39:35 +04:00
to <option > simple</option> , however
it is expected that the process has to
exit before systemd starts follow-up
2010-08-17 21:37:36 +04:00
units. <varname > RemainAfterExit=</varname>
2010-07-01 21:39:35 +04:00
is particularly useful for this type
of service.</para>
2012-09-04 21:24:16 +04:00
<para > Behavior of
2010-07-01 21:39:35 +04:00
<option > dbus</option> is similar to
2010-07-03 21:54:00 +04:00
<option > simple</option> , however it is
expected that the daemon acquires a
2010-07-01 21:39:35 +04:00
name on the D-Bus bus, as configured
by
<varname > BusName=</varname> . systemd
will proceed starting follow-up units
after the D-Bus bus name has been
2010-07-03 21:54:00 +04:00
acquired. Service units with this
2010-08-13 20:46:04 +04:00
option configured implicitly gain
2010-07-03 21:54:00 +04:00
dependencies on the
2011-03-18 05:32:33 +03:00
<filename > dbus.socket</filename>
2012-05-03 16:46:29 +04:00
unit. This type is the default if
<varname > BusName=</varname> is
specified.</para>
2010-07-01 21:39:35 +04:00
2012-09-04 21:24:16 +04:00
<para > Behavior of
2010-07-01 21:39:35 +04:00
<option > notify</option> is similar to
<option > simple</option> , however it is
expected that the daemon sends a
notification message via
<citerefentry > <refentrytitle > sd_notify</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
or an equivalent call when it finished
starting up. systemd will proceed
starting follow-up units after this
notification message has been sent. If
2013-09-12 23:12:49 +04:00
this option is used,
2010-07-03 21:54:00 +04:00
<varname > NotifyAccess=</varname> (see
2010-08-13 20:46:04 +04:00
below) should be set to open access to
2010-07-01 21:39:35 +04:00
the notification socket provided by
2010-07-03 21:54:00 +04:00
systemd. If
2012-02-10 00:11:25 +04:00
<varname > NotifyAccess=</varname> is
not set, it will be implicitly set to
2013-09-11 15:57:34 +04:00
<option > main</option> . Note that
currently
<varname > Type=</varname> <option > notify</option>
2013-09-12 23:12:49 +04:00
will not work if used in combination with
2013-09-11 15:57:34 +04:00
<varname > PrivateNetwork=</varname> <option > yes</option> .</para>
2012-04-26 22:32:26 +04:00
2012-09-04 21:24:16 +04:00
<para > Behavior of
2012-04-26 22:32:26 +04:00
<option > idle</option> is very similar
2012-04-30 17:30:57 +04:00
to <option > simple</option> , however
2012-10-26 02:16:47 +04:00
actual execution of the service
2012-04-26 22:32:26 +04:00
binary is delayed until all jobs are
dispatched. This may be used to avoid
interleaving of output of shell
services with the status output on the
console.</para>
2010-05-16 01:06:41 +04:00
</listitem>
</varlistentry>
2010-07-01 21:39:35 +04:00
2010-05-16 01:06:41 +04:00
<varlistentry >
2010-08-17 21:37:36 +04:00
<term > <varname > RemainAfterExit=</varname> </term>
2010-07-01 21:39:35 +04:00
<listitem > <para > Takes a boolean value
that specifies whether the service
shall be considered active even when
all its processes exited. Defaults to
<option > no</option> .</para>
2010-05-16 01:06:41 +04:00
</listitem>
2011-02-13 20:51:30 +03:00
</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
2012-10-26 02:16:47 +04:00
if it cannot be determined
2011-02-13 20:51:30 +03:00
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
2013-09-12 23:12:49 +04:00
the main PID cannot be determined,
2011-02-13 20:51:30 +03:00
failure detection and automatic
restarting of a service will not work
reliably. Defaults to
<option > yes</option> .</para>
</listitem>
2010-05-16 01:06:41 +04:00
</varlistentry>
<varlistentry >
<term > <varname > PIDFile=</varname> </term>
2010-07-01 21:39:35 +04:00
<listitem > <para > Takes an absolute file
name pointing to the PID file of this
daemon. Use of this option is
recommended for services where
<varname > Type=</varname> is set to
2011-02-09 13:00:17 +03:00
<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>
2010-05-16 01:06:41 +04:00
</listitem>
</varlistentry>
<varlistentry >
<term > <varname > BusName=</varname> </term>
2010-07-01 21:39:35 +04:00
<listitem > <para > Takes a D-Bus bus
2012-10-26 02:16:47 +04:00
name, that this service is reachable
2010-07-01 21:39:35 +04:00
as. This option is mandatory for
services where
<varname > Type=</varname> is set to
<option > dbus</option> , but its use
is otherwise recommended as well if
the process takes a name on the D-Bus
bus.</para>
2010-05-16 01:06:41 +04:00
</listitem>
</varlistentry>
<varlistentry >
<term > <varname > ExecStart=</varname> </term>
2013-01-04 01:37:31 +04:00
<listitem > <para > Commands with their
arguments that are executed when this
2013-12-15 02:21:55 +04:00
service is started. For each of the
specified commands, the first argument
must be an absolute and literal path
to an executable.</para>
2012-11-15 18:54:17 +04:00
2013-03-20 06:13:48 +04:00
<para > When <varname > Type</varname> is
not <option > oneshot</option> , only one
command may be given. When
2010-08-13 20:46:04 +04:00
<varname > Type=oneshot</varname> is
2012-11-15 18:54:17 +04:00
used, more than one command may be
specified. Multiple command lines may
be concatenated in a single directive,
by separating them with semicolons
(these semicolons must be passed as
separate words). Alternatively, this
directive may be specified more than
2013-12-15 02:30:25 +04:00
once with the same effect.
2013-03-20 06:13:48 +04:00
Lone semicolons may be escaped as
2013-06-26 16:03:53 +04:00
<literal > \;</literal> . If the empty
2013-09-12 23:12:49 +04:00
string is assigned to this option, the
2013-01-17 05:27:06 +04:00
list of commands to start is reset,
prior assignments of this option will
have no effect.</para>
2012-11-15 18:54:17 +04:00
2013-12-15 02:21:55 +04:00
<para > Each command line is split on
whitespace, with the first item being
the command to execute, and the
subsequent items being the arguments.
Double quotes ("...") and single
quotes ('...') may be used, in which
case everything until the next
matching quote becomes part of the
same argument. Quotes themselves are
removed after parsing. In addition, a
trailing backslash
(<literal > \</literal> ) may be used to
merge lines. This syntax is intended
to be very similar to shell syntax,
but only the meta-characters and
expansions described in the following
paragraphs are understood.
Specifically, redirection using
<literal > < </literal> ,
<literal > < < </literal> ,
<literal > > </literal> , and
<literal > > > </literal> , pipes
using <literal > |</literal> , and
running programs in the background
using <literal > & </literal>
and <emphasis > other elements of shell
syntax are not supported</emphasis> .
</para>
2013-03-20 06:13:48 +04:00
<para > If more than one command is
specified, the commands are invoked
one by one sequentially in the order
they appear in the unit file. If one
of the commands fails (and is not
2013-06-26 16:03:53 +04:00
prefixed with <literal > -</literal> ),
2013-03-20 06:13:48 +04:00
other lines are not executed and the
unit is considered failed.</para>
2012-11-15 18:54:17 +04:00
<para > Unless
<varname > Type=forking</varname> is
set, the process started via this
command line will be considered the
2013-01-04 01:37:31 +04:00
main process of the daemon.</para>
<para > The command line accepts
2013-06-26 16:03:53 +04:00
<literal > %</literal> specifiers as
2013-01-04 01:37:31 +04:00
described in
2013-12-15 02:21:55 +04:00
<citerefentry > <refentrytitle > systemd.unit</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> .
Note that the first argument of the
command line (i.e. the program to
execute) may not include
specifiers.</para>
2010-08-13 20:46:04 +04:00
2013-03-20 06:13:48 +04:00
<para > Basic environment variable
substitution is supported. Use
2011-10-03 14:50:09 +04:00
<literal > ${FOO}</literal> as part of a
2012-10-26 02:16:47 +04:00
word, or as a word of its own on the
2011-10-03 14:50:09 +04:00
command line, in which case it will be
replaced by the value of the
environment variable including all
whitespace it contains, resulting in a
single argument. Use
<literal > $FOO</literal> as a separate
word on the command line, in which
case it will be replaced by the value
of the environment variable split up
2013-03-20 06:13:48 +04:00
at whitespace, resulting in zero or
2013-10-15 10:58:51 +04:00
more arguments. To pass a literal dollar sign,
2013-09-19 15:52:31 +04:00
use <literal > $$</literal> . Note that the first
2011-10-03 14:50:09 +04:00
argument (i.e. the program to execute)
2013-12-15 02:21:55 +04:00
may not be a variable.</para>
2012-09-06 10:51:19 +04:00
2013-01-17 05:27:06 +04:00
<para > Optionally, if the absolute file
name is prefixed with
2013-06-26 16:03:53 +04:00
<literal > @</literal> , the second token
2013-01-17 05:27:06 +04:00
will be passed as
<literal > argv[0]</literal> to the
executed process, followed by the
further arguments specified. If the
2013-06-27 23:51:44 +04:00
absolute filename is prefixed with
2013-09-12 23:12:49 +04:00
<literal > -</literal> , an exit code of
2013-01-17 05:27:06 +04:00
the command normally considered a
failure (i.e. non-zero exit status or
abnormal exit due to signal) is ignored
and considered success. If both
2013-06-26 16:03:53 +04:00
<literal > -</literal> and
2013-09-12 23:12:49 +04:00
<literal > @</literal> are used, they
2013-01-17 05:27:06 +04:00
can appear in either order.</para>
2012-09-06 10:51:19 +04:00
<para > Note that this setting does not
directly support shell command
lines. If shell command lines are to
2013-09-12 23:12:49 +04:00
be used, they need to be passed
2012-09-06 10:51:19 +04:00
explicitly to a shell implementation
2013-03-20 06:13:48 +04:00
of some kind. Example:</para>
<programlisting > ExecStart=/bin/sh -c 'dmesg | tac'
</programlisting>
2012-10-18 03:18:50 +04:00
2013-12-15 02:21:55 +04:00
<para > Only select environment variables
are set for executed commands. See
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> .
</para>
<para > Example:</para>
<programlisting > ExecStart=/bin/echo one ; /bin/echo "two two"
</programlisting>
<para > This will execute
<command > /bin/echo</command> two
times, each time with one argument,
<literal > one</literal> and
<literal > two two</literal> ,
respectively. Since two commands are
specified
<varname > Type=oneshot</varname> must
be used.</para>
<para > Example:</para>
<programlisting > ExecStart=/bin/echo / > /dev/null & \; \
/bin/ls
</programlisting>
<para > This will execute
<command > /bin/echo</command> with five
arguments: <literal > /</literal> ,
<literal > > /dev/null</literal> ,
<literal > & </literal> ,
<literal > ;</literal> , and
<literal > /bin/ls</literal> .</para>
<para > Example:</para>
<programlisting > Environment="ONE=one" 'TWO=two two'
ExecStart=/bin/echo $ONE $TWO ${TWO}
</programlisting>
<para > This will execute
<command > /bin/echo</command> with four
arguments: <literal > one</literal> ,
<literal > two</literal> ,
<literal > two</literal> , and
<literal > two two</literal> .</para>
</listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
<varlistentry >
<term > <varname > ExecStartPre=</varname> </term>
<term > <varname > ExecStartPost=</varname> </term>
<listitem > <para > Additional commands
Reword sentences that contain psuedo-English "resp."
As you likely know, Arch Linux is in the process of moving to systemd.
So I was reading through the various systemd docs and quickly became
baffled by this new abbreviation "resp.", which I've never seen before
in my English-mother-tongue life.
Some quick Googling turned up a reference:
<http://www.transblawg.eu/index.php?/archives/870-Resp.-and-other-non-existent-English-wordsNicht-existente-englische-Woerter.html>
I guess it's a literal translation of the German "Beziehungsweise", but
English doesn't work the same way. The word "respectively" is used
exclusively to provide an ordering connection between two lists. E.g.
"the prefixes k, M, and G refer to kilo-, mega-, and giga-,
respectively." It is also never abbreviated to "resp." So the sentence
"Sets the default output resp. error output for all services and
sockets" makes no sense to a natural English speaker.
This patch removes all instances of "resp." in the man pages and
replaces them with sentences which are much more clear and, hopefully,
grammatically valid. In almost all instances, it was simply replacing
"resp." with "or," which the original author (Lennart?) could probably
just do in the future.
The only other instances of "resp." are in the src/ subtree, which I
don't feel privileged to correct.
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
2012-10-15 22:59:12 +04:00
that are executed before or after
2010-07-01 21:39:35 +04:00
the command in
2012-11-15 18:54:17 +04:00
<varname > ExecStart=</varname> , respectively.
Syntax is the same as for
<varname > ExecStart=</varname> , except
that multiple command lines are allowed
and the commands are executed one
after the other, serially.</para>
2013-03-20 06:13:48 +04:00
<para > If any of those commands (not
2013-06-26 16:03:53 +04:00
prefixed with <literal > -</literal> )
2013-03-20 06:13:48 +04:00
fail, the rest are not executed and
the unit is considered failed.</para>
2012-11-15 18:54:17 +04:00
</listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
<varlistentry >
<term > <varname > ExecReload=</varname> </term>
<listitem > <para > Commands to execute to
trigger a configuration reload in the
2010-07-07 23:22:56 +04:00
service. This argument takes multiple
command lines, following the same
2012-11-15 18:54:17 +04:00
scheme as described for
<varname > ExecStart=</varname>
2010-07-07 23:22:56 +04:00
above. Use of this setting is
2010-07-08 06:19:54 +04:00
optional. Specifier and environment
variable substitution is supported
here following the same scheme as for
2013-03-20 06:13:48 +04:00
<varname > ExecStart=</varname> .</para>
<para > One additional special
environment variables is set: if known
<varname > $MAINPID</varname> is set to
2012-10-18 03:18:50 +04:00
the main process of the daemon, and
may be used for command lines like the
2013-03-20 06:13:48 +04:00
following:</para>
<programlisting > /bin/kill -HUP $MAINPID</programlisting>
</listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
<varlistentry >
<term > <varname > ExecStop=</varname> </term>
<listitem > <para > Commands to execute to
stop the service started via
2010-07-07 23:22:56 +04:00
<varname > ExecStart=</varname> . This
argument takes multiple command lines,
2012-11-15 18:54:17 +04:00
following the same scheme as described
for <varname > ExecStart=</varname>
2010-07-07 23:22:56 +04:00
above. Use of this setting is
2010-07-01 21:39:35 +04:00
optional. All processes remaining for
a service after the commands
configured in this option are run are
terminated according to the
<varname > KillMode=</varname> setting
2012-07-20 01:47:10 +04:00
(see
<citerefentry > <refentrytitle > systemd.kill</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ). If
2013-09-12 23:12:49 +04:00
this option is not specified, the
2012-07-20 01:47:10 +04:00
process is terminated right-away when
service stop is requested. Specifier
and environment variable substitution
is supported (including
2013-03-20 06:13:48 +04:00
<varname > $MAINPID</varname> , see
2010-07-08 06:19:54 +04:00
above).</para> </listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
<varlistentry >
<term > <varname > ExecStopPost=</varname> </term>
<listitem > <para > Additional commands
that are executed after the service
2013-03-13 08:43:40 +04:00
was stopped. This includes cases where
the commands configured in
<varname > ExecStop=</varname> were used,
2013-08-25 11:01:45 +04:00
where the service does not have any
2013-03-13 08:43:40 +04:00
<varname > ExecStop=</varname> defined, or
where the service exited unexpectedly. This
2010-07-07 23:22:56 +04:00
argument takes multiple command lines,
2012-11-15 18:54:17 +04:00
following the same scheme as described
for <varname > ExecStart</varname> . Use
2010-07-07 23:22:56 +04:00
of these settings is
2010-07-08 06:19:54 +04:00
optional. Specifier and environment
variable substitution is
supported.</para> </listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
<varlistentry >
<term > <varname > RestartSec=</varname> </term>
<listitem > <para > Configures the time to
sleep before restarting a service (as
configured with
<varname > Restart=</varname> ). Takes a
unit-less value in seconds, or a time
span value such as "5min
20s". Defaults to
100ms.</para> </listitem>
</varlistentry>
<varlistentry >
2012-08-07 16:41:48 +04:00
<term > <varname > TimeoutStartSec=</varname> </term>
2010-07-01 21:39:35 +04:00
<listitem > <para > Configures the time to
2012-08-07 16:41:48 +04:00
wait for start-up. If a
2010-07-01 21:39:35 +04:00
daemon service does not signal
start-up completion within the
2012-08-07 16:41:48 +04:00
configured time, the service will be
2010-07-01 21:39:35 +04:00
considered failed and be shut down
2012-08-07 16:41:48 +04:00
again.
Takes a unit-less value in seconds, or a
time span value such as "5min
20s". Pass 0 to disable the timeout
2013-11-07 04:17:48 +04:00
logic. Defaults to <varname > TimeoutStartSec=</varname> from the
2013-11-04 20:47:43 +04:00
manager configuration file, except when
2012-08-07 16:41:48 +04:00
<varname > Type=oneshot</varname> is
2013-11-07 04:17:48 +04:00
used, in which case the timeout
2012-08-07 16:41:48 +04:00
is disabled by default.
</para> </listitem>
</varlistentry>
<varlistentry >
<term > <varname > TimeoutStopSec=</varname> </term>
<listitem > <para > Configures the time to
wait for stop. If a service is asked
to stop but does not terminate in the
specified time, it will be terminated
2013-06-29 20:09:14 +04:00
forcibly via <constant > SIGTERM</constant> , and after
2010-07-01 21:39:35 +04:00
another delay of this time with
2013-06-29 20:09:14 +04:00
<constant > SIGKILL</constant> (See
2010-07-03 21:54:00 +04:00
<varname > KillMode=</varname>
2012-08-07 16:41:48 +04:00
in <citerefentry > <refentrytitle > systemd.kill</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ).
Takes a unit-less value in seconds, or a
2010-07-01 21:39:35 +04:00
time span value such as "5min
20s". Pass 0 to disable the timeout
2013-11-07 04:17:48 +04:00
logic. Defaults to <varname > TimeoutStartSec=</varname> from the
2013-11-04 20:47:43 +04:00
manager configuration file.
2012-08-07 16:41:48 +04:00
</para> </listitem>
</varlistentry>
<varlistentry >
<term > <varname > TimeoutSec=</varname> </term>
<listitem > <para > A shorthand for configuring
both <varname > TimeoutStartSec=</varname>
and <varname > TimeoutStopSec=</varname>
to the specified value.
</para> </listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
2012-02-08 13:10:34 +04:00
<varlistentry >
<term > <varname > WatchdogSec=</varname> </term>
2012-02-09 00:24:41 +04:00
<listitem > <para > Configures the
2013-04-30 03:46:19 +04:00
watchdog timeout for a service. The
watchdog is activated when the start-up is
2012-02-09 00:24:41 +04:00
completed. The service must call
2012-02-08 13:10:34 +04:00
<citerefentry > <refentrytitle > sd_notify</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
2012-06-28 02:24:36 +04:00
regularly with "WATCHDOG=1" (i.e. the
"keep-alive ping"). If the time
between two such calls is larger than
2013-09-12 23:12:49 +04:00
the configured time, then the service
2012-06-28 02:24:36 +04:00
is placed in a failure state. By
setting <varname > Restart=</varname> to
<option > on-failure</option> or
2013-09-12 23:12:49 +04:00
<option > always</option> , the service
2012-02-09 00:24:41 +04:00
will be automatically restarted. The
time configured here will be passed to
the executed service process in the
<varname > WATCHDOG_USEC=</varname>
2012-06-28 02:24:36 +04:00
environment variable. This allows
daemons to automatically enable the
keep-alive pinging logic if watchdog
support is enabled for the service. If
2013-09-12 23:12:49 +04:00
this option is used,
2012-02-10 00:11:25 +04:00
<varname > NotifyAccess=</varname> (see
below) should be set to open access to
the notification socket provided by
systemd. If
2012-06-28 02:24:36 +04:00
<varname > NotifyAccess=</varname> is
not set, it will be implicitly set to
2012-02-10 00:11:25 +04:00
<option > main</option> . Defaults to 0,
2012-02-09 00:24:41 +04:00
which disables this
feature.</para> </listitem>
2012-02-08 13:10:34 +04:00
</varlistentry>
2010-07-01 21:39:35 +04:00
<varlistentry >
<term > <varname > Restart=</varname> </term>
<listitem > <para > Configures whether the
2013-04-30 03:46:19 +04:00
service shall be restarted when the
service process exits, is killed,
or a timeout is reached. The service
process may be the main service
process, but also one of the processes
specified with
<varname > ExecStartPre=</varname> ,
<varname > ExecStartPost=</varname> ,
<varname > ExecStopPre=</varname> ,
<varname > ExecStopPost=</varname> , or
<varname > ExecReload=</varname> .
When the death of the process is a
result of systemd operation (e.g. service
stop or restart), the service will not be
restarted. Timeouts include missing
the watchdog "keep-alive ping"
deadline and a service start, reload,
and stop operation timeouts.</para>
<para > Takes one of
2010-10-05 22:30:44 +04:00
<option > no</option> ,
2010-10-08 20:34:54 +04:00
<option > on-success</option> ,
<option > on-failure</option> ,
2013-07-25 16:07:59 +04:00
<option > on-watchdog</option> ,
2013-04-30 03:46:19 +04:00
<option > on-abort</option> , or
2010-10-08 20:34:54 +04:00
<option > always</option> . If set to
2013-09-12 23:12:49 +04:00
<option > no</option> (the default), the
2013-04-30 03:46:19 +04:00
service will not be restarted. If set to
2013-09-12 23:12:49 +04:00
<option > on-success</option> , it will be
2013-04-30 03:46:19 +04:00
restarted only when the service process
exits cleanly.
In this context, a clean exit means
an exit code of 0, or one of the signals
2013-06-29 20:09:14 +04:00
<constant > SIGHUP</constant> , <constant > SIGINT</constant> , <constant > SIGTERM</constant> , or <constant > SIGPIPE</constant> , and
2013-05-04 00:43:11 +04:00
additionally, exit statuses and signals
2013-04-30 03:46:19 +04:00
specified in <varname > SuccessExitStatus=</varname> .
2013-09-12 23:12:49 +04:00
If set to <option > on-failure</option> ,
2013-04-30 03:46:19 +04:00
the service will be restarted when the
process exits with an nonzero exit code,
is terminated by a signal (including on
2012-07-04 02:37:12 +04:00
core dump), when an operation (such as
2013-04-30 03:46:19 +04:00
service reload) times out, and when the
configured watchdog timeout is triggered.
If set to
2013-09-12 23:12:49 +04:00
<option > on-abort</option> , the service
2013-04-30 03:46:19 +04:00
will be restarted only if the service
process exits due to an uncaught
signal not specified as a clean exit
status.
If set to
2013-09-12 23:12:49 +04:00
<option > on-watchdog</option> , the service
2013-07-25 16:07:59 +04:00
will be restarted only if the watchdog
timeout for the service expires.
If set to
2013-09-12 23:12:49 +04:00
<option > always</option> , the service
2012-07-04 02:37:12 +04:00
will be restarted regardless whether
it exited cleanly or not, got
terminated abnormally by a signal or
2013-04-30 03:46:19 +04:00
hit a timeout.</para>
<para > In addition to the above settings,
the service will not be restarted if the
exit code or signal is specified in
<varname > RestartPreventExitStatus=</varname>
(see below).</para> </listitem>
2010-07-01 21:39:35 +04:00
</varlistentry>
2012-08-13 15:58:01 +04:00
<varlistentry >
2012-08-14 20:37:45 +04:00
<term > <varname > SuccessExitStatus=</varname> </term>
<listitem > <para > Takes a list of exit
status definitions that when returned
by the main service process will be
considered successful termination, in
addition to the normal successful exit
2013-06-29 20:09:14 +04:00
code 0 and the signals <constant > SIGHUP</constant> , <constant > SIGINT</constant> ,
<constant > SIGTERM</constant> and <constant > SIGPIPE</constant> . Exit status
2012-08-14 20:37:45 +04:00
definitions can either be numeric exit
2013-04-30 03:46:19 +04:00
codes or termination signal names,
separated by spaces. Example:
2013-06-26 16:03:53 +04:00
<literal > SuccessExitStatus=1 2 8
2013-06-29 20:09:14 +04:00
<constant > SIGKILL</constant> </literal> , ensures that exit
2012-08-14 20:37:45 +04:00
codes 1, 2, 8 and the termination
2013-06-29 20:09:14 +04:00
signal <constant > SIGKILL</constant> are considered clean
2013-01-17 05:27:06 +04:00
service terminations. This option may
appear more than once in which case
the list of successful exit statuses
is merged. If the empty string is
2013-09-12 23:12:49 +04:00
assigned to this option, the list is
2013-01-17 05:27:06 +04:00
reset, all prior assignments of this
option will have no
effect.</para> </listitem>
2012-08-13 15:58:01 +04:00
</varlistentry>
<varlistentry >
2012-08-14 20:37:45 +04:00
<term > <varname > RestartPreventExitStatus=</varname> </term>
<listitem > <para > Takes a list of exit
status definitions that when returned
by the main service process will
prevent automatic service restarts
regardless of the restart setting
configured with
<varname > Restart=</varname> . Exit
status definitions can either be
numeric exit codes or termination
signal names, and are separated by
spaces. Defaults to the empty list, so
that by default no exit status is
excluded from the configured restart
logic. Example:
2013-06-26 16:03:53 +04:00
<literal > RestartPreventExitStatus=1 6
SIGABRT</literal> , ensures that exit
2013-01-17 05:27:06 +04:00
codes 1 and 6 and the termination
signal SIGABRT will not result in
automatic service restarting. This
option may appear more than once in
which case the list of restart preventing
statuses is merged. If the empty
2013-09-12 23:12:49 +04:00
string is assigned to this option, the
2013-01-17 05:27:06 +04:00
list is reset, all prior assignments
of this option will have no
effect.</para> </listitem>
2012-08-13 15:58:01 +04:00
</varlistentry>
2010-07-01 21:39:35 +04:00
<varlistentry >
<term > <varname > PermissionsStartOnly=</varname> </term>
<listitem > <para > Takes a boolean
argument. If true, the permission
related execution options as
configured with
<varname > User=</varname> and similar
options (see
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for more information) are only applied
to the process started with
<varname > ExecStart=</varname> , and not
to the various other
<varname > ExecStartPre=</varname> ,
<varname > ExecStartPost=</varname> ,
<varname > ExecReload=</varname> ,
<varname > ExecStop=</varname> ,
<varname > ExecStopPost=</varname>
commands. If false, the setting is
applied to all configured commands the
same way. Defaults to
false.</para> </listitem>
</varlistentry>
<varlistentry >
<term > <varname > RootDirectoryStartOnly=</varname> </term>
<listitem > <para > Takes a boolean
argument. If true, the root directory
as configured with the
<varname > RootDirectory=</varname>
option (see
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for more information) is only applied
to the process started with
<varname > ExecStart=</varname> , and not
to the various other
<varname > ExecStartPre=</varname> ,
<varname > ExecStartPost=</varname> ,
<varname > ExecReload=</varname> ,
<varname > ExecStop=</varname> ,
<varname > ExecStopPost=</varname>
commands. If false, the setting is
applied to all configured commands the
same way. Defaults to
false.</para> </listitem>
</varlistentry>
<varlistentry >
<term > <varname > NonBlocking=</varname> </term>
<listitem > <para > Set O_NONBLOCK flag
for all file descriptors passed via
socket-based activation. If true, all
file descriptors >= 3 (i.e. all except
STDIN/STDOUT/STDERR) will have
the O_NONBLOCK flag set and hence are in
non-blocking mode. This option is only
useful in conjunction with a socket
unit, as described in
<citerefentry > <refentrytitle > systemd.socket</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> . Defaults
to false.</para> </listitem>
</varlistentry>
<varlistentry >
<term > <varname > NotifyAccess=</varname> </term>
<listitem > <para > Controls access to the
service status notification socket, as
accessible via the
<citerefentry > <refentrytitle > sd_notify</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
call. Takes one of
<option > none</option> (the default),
<option > main</option> or
<option > all</option> . If
2013-09-12 23:12:49 +04:00
<option > none</option> , no daemon status
2010-11-11 16:24:47 +03:00
updates are accepted from the service
2010-07-01 21:39:35 +04:00
processes, all status update messages
2013-09-12 23:12:49 +04:00
are ignored. If <option > main</option> ,
2010-07-01 21:39:35 +04:00
only service updates sent from the
main process of the service are
2013-09-12 23:12:49 +04:00
accepted. If <option > all</option> , all
2010-07-01 21:39:35 +04:00
services updates from all members of
the service's control group are
2012-02-10 00:11:25 +04:00
accepted. This option should be set to
2010-07-01 21:39:35 +04:00
open access to the notification socket
when using
2012-02-10 00:11:25 +04:00
<varname > Type=notify</varname> or
2013-01-20 19:27:58 +04:00
<varname > WatchdogSec=</varname> (see
2012-02-10 00:11:25 +04:00
above). If those options are used but
2013-09-12 23:12:49 +04:00
<varname > NotifyAccess=</varname> is not
configured, it will be implicitly set
2012-02-10 00:11:25 +04:00
to
<option > main</option> .</para> </listitem>
2010-05-16 01:06:41 +04:00
</varlistentry>
2010-10-05 22:51:00 +04:00
<varlistentry >
<term > <varname > Sockets=</varname> </term>
<listitem > <para > Specifies the name of
the socket units this service shall
inherit the sockets from when the
2011-12-17 03:39:19 +04:00
service is started. Normally it
2010-10-05 22:51:00 +04:00
should not be necessary to use this
setting as all sockets whose unit
shares the same name as the service
2011-12-17 03:39:19 +04:00
(ignoring the different suffix of course)
2010-10-05 22:51:00 +04:00
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
2013-01-17 05:27:06 +04:00
in other words: the
2010-10-05 22:51:00 +04:00
<varname > Service=</varname> setting of
<filename > .socket</filename> units
2013-08-25 11:01:45 +04:00
does not have to match the inverse of
2013-01-17 05:27:06 +04:00
the <varname > Sockets=</varname>
setting of the
<filename > .service</filename> it
refers to.</para>
<para > This option may appear more than
once, in which case the list of socket
units is merged. If the empty string
2013-09-12 23:12:49 +04:00
is assigned to this option, the list of
2013-01-17 05:27:06 +04:00
sockets is reset, all prior uses of
this setting will have no
effect.</para> </listitem>
2010-10-05 22:51:00 +04:00
</varlistentry>
2012-02-10 00:01:18 +04:00
<varlistentry >
<term > <varname > StartLimitInterval=</varname> </term>
<term > <varname > StartLimitBurst=</varname> </term>
<listitem > <para > Configure service
2013-09-12 23:12:49 +04:00
start rate limiting. By default,
2012-02-10 00:01:18 +04:00
services which are started more often
than 5 times within 10s are not
permitted to start any more times
until the 10s interval ends. With
2013-09-12 23:12:49 +04:00
these two options, this rate limiting
2012-02-10 00:01:18 +04:00
may be modified. Use
<varname > StartLimitInterval=</varname>
2013-11-08 19:01:22 +04:00
to configure the checking interval (defaults to
<varname > DefaultStartLimitInterval=</varname> in
manager configuration file, set to 0 to disable
2012-02-10 00:01:18 +04:00
any kind of rate limiting). Use
<varname > StartLimitBurst=</varname> to
configure how many starts per interval
2013-11-08 19:01:22 +04:00
are allowed (defaults to
<varname > DefaultStartLimitBurst=</varname> in
manager configuration file). These
2012-02-10 00:01:18 +04:00
configuration options are particularly
useful in conjunction with
2012-07-04 02:12:13 +04:00
<varname > Restart=</varname> , however
apply to all kinds of starts
(including manual), not just those
triggered by the
<varname > Restart=</varname> logic.
Note that units which are configured
for <varname > Restart=</varname> and
which reach the start limit are not
2012-07-04 02:07:33 +04:00
attempted to be restarted anymore,
however they may still be restarted
manually at a later point from which
point on the restart logic is again
2012-07-04 02:23:42 +04:00
activated. Note that
<command > systemctl
reset-failed</command> will cause the
restart rate counter for a service to
be flushed, which is useful if the
administrator wants to manually start
a service and the start limit
interferes with
that.</para> </listitem>
2012-02-10 00:01:18 +04:00
</varlistentry>
<varlistentry >
<term > <varname > StartLimitAction=</varname> </term>
<listitem > <para > Configure the action
to take if the rate limit configured
with
<varname > StartLimitInterval=</varname>
and
<varname > StartLimitBurst=</varname> is
hit. Takes one of
<option > none</option> ,
<option > reboot</option> ,
<option > reboot-force</option> or
<option > reboot-immediate</option> . If
<option > none</option> is set,
hitting the rate limit will trigger no
action besides that the start will not
be
permitted. <option > reboot</option>
causes a reboot following the normal
shutdown procedure (i.e. equivalent to
<command > systemctl reboot</command> ),
<option > reboot-force</option> causes
an forced reboot which will terminate
all processes forcibly but should
cause no dirty file systems on reboot
(i.e. equivalent to <command > systemctl
reboot -f</command> ) and
<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. Defaults to
<option > none</option> .</para> </listitem>
</varlistentry>
2010-05-16 01:06:41 +04:00
</variablelist>
2012-07-20 01:47:10 +04:00
<para > Check
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
and
<citerefentry > <refentrytitle > systemd.kill</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
for more settings.</para>
2010-05-16 01:06:41 +04:00
</refsect1>
2012-05-30 23:42:07 +04:00
<refsect1 >
<title > Compatibility Options</title>
<para > The following options are also available in the
<literal > [Service]</literal> section, but exist purely
for compatibility reasons and should not be used in
newly written service files.</para>
2013-01-26 19:47:16 +04:00
<variablelist class= 'unit-directives' >
2012-05-30 23:42:07 +04:00
<varlistentry >
<term > <varname > SysVStartPriority=</varname> </term>
<listitem > <para > Set the SysV start
priority to use to order this service
in relation to SysV services lacking
LSB headers. This option is only
necessary to fix ordering in relation
to legacy SysV services, that have no
ordering information encoded in the
script headers. As such it should only
be used as temporary compatibility
option, and not be used in new unit
files. 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
range 0-99.</para> </listitem>
</varlistentry>
</variablelist>
</refsect1>
2010-05-16 01:06:41 +04:00
<refsect1 >
<title > See Also</title>
<para >
2010-07-07 03:38:56 +04:00
<citerefentry > <refentrytitle > systemd</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> ,
2010-07-01 21:39:35 +04:00
<citerefentry > <refentrytitle > systemctl</refentrytitle> <manvolnum > 8</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > systemd.unit</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
2012-07-20 01:47:10 +04:00
<citerefentry > <refentrytitle > systemd.exec</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
2013-09-27 02:05:07 +04:00
<citerefentry > <refentrytitle > systemd.resource-control</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
2013-01-15 07:08:33 +04:00
<citerefentry > <refentrytitle > systemd.kill</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > systemd.directives</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry>
2010-05-16 01:06:41 +04:00
</para>
</refsect1>
</refentry>