<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for the common options of all unit configuration
files. The common configuration items are configured
- in the generic [Unit] and [Install] sections. The
- service specific configuration options are configured
- in the [Service] section.</para>
-
- <para>Additional options are listed in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+ 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>
+
+ <para>Additional options are listed in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ which define the execution environment the commands
+ are executed in.</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 removed) and
+ dynamically creates a service unit from that
+ script. This is useful for compatibility with
+ SysV.</para>
</refsect1>
<refsect1>
<title>Options</title>
- <para>Service files must include a [Service] 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
+ <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
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
- options specific to the [Service] section of service
- units are the following:</para>
+ options specific to the <literal>[Service]</literal>
+ section of service units are the following:</para>
<variablelist>
<varlistentry>
start-up type for this service
unit. One of <option>simple</option>,
<option>forking</option>,
- <option>finish</option>,
+ <option>oneshot</option>,
<option>dbus</option>,
<option>notify</option>.</para>
configured with
<varname>ExecStart=</varname> is the
main process of the service. In this
- mode, communication channels must 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>
+ mode, if the process offers
+ functionality to other processes on
+ the system its communication channels
+ 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>
<para>If set to
<option>forking</option> it is
expected that the process configured
with <varname>ExecStart=</varname>
- will start up and call
- <function>fork()</function>. The
- parent process is expected to finish
- when start-up is complete and all
- communication channels set up. The
- child continues to run as the main
- daemon process. This is the behaviour
- of traditional UNIX daemons. If this
+ 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
+ channels set up. The child continues
+ to run as the main daemon
+ process. This is the behaviour of
+ traditional UNIX daemons. If this
setting is used, it is recommended to
also use the
<varname>PIDFile=</varname> option, so
exits.</para>
<para>Behaviour of
- <option>finish</option> is similar
+ <option>oneshot</option> is similar
to <option>simple</option>, however
it is expected that the process has to
exit before systemd starts follow-up
- units. <varname>ValidNoProcess=</varname>
+ units. <varname>RemainAfterExit=</varname>
is particularly useful for this type
of service.</para>
<para>Behaviour of
<option>dbus</option> is similar to
- <option>simple</option>, however it
- is expected that the daemon acquires a
+ <option>simple</option>, however it is
+ expected that the daemon acquires a
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
- acquired.</para>
+ acquired. Service units with this
+ option configured implicitly gain
+ dependencies on the
+ <filename>dbus.socket</filename>
+ unit.</para>
<para>Behaviour of
<option>notify</option> is similar to
starting follow-up units after this
notification message has been sent. If
this option is used
- <option>NotifyAccess=</option> (see
- below) must be set to open access to
+ <varname>NotifyAccess=</varname> (see
+ below) should be set to open access to
the notification socket provided by
- systemd.</para>
+ systemd. If
+ <varname>NotifyAccess=</varname> is not
+ set, it will implicitly be set to
+ <option>main</option>.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><varname>ValidNoProcess=</varname></term>
+ <term><varname>RemainAfterExit=</varname></term>
<listitem><para>Takes a boolean value
that specifies whether the service
</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>
arguments for the process. It is
mandatory to set this option for all
services. This option may not be
- specified more than once. Optionally,
- if the absolute file name is prefixed
- with @, the second token will be
- passed as argv[0] to the executed
- process, followed by the further
- arguments specified. Unless
- <option>Type=forking</option> is set,
- the process started via this command
- line will be considered the main
- process of the
- daemon.</para></listitem>
+ specified more than once, except when
+ <varname>Type=oneshot</varname> is
+ used in which case more than one
+ <varname>ExecStart=</varname> line is
+ accepted which are then invoked one by
+ one, sequentially in the order they
+ appear in the unit file.</para>
+
+ <para>Optionally, if the absolute file
+ name is prefixed with
+ <literal>@</literal>, the second token
+ will be passed as
+ <literal>argv[0]</literal> to the
+ executed process, followed by the
+ further arguments specified. If the
+ first token is prefixed with
+ <literal>-</literal> an exit code of
+ 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
+ <literal>-</literal> and
+ <literal>@</literal> are used for the
+ same command the former must precede
+ the latter. Unless
+ <varname>Type=forking</varname> is
+ set, the process started via this
+ command line will be considered the
+ main process of the daemon. The
+ command line accepts % specifiers as
+ described in
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. On
+ top of that basic environment variable
+ substitution is supported, where
+ <literal>${FOO}</literal> is replaced
+ by the string value of the environment
+ variable of the same name. Also
+ <literal>$FOO</literal> may appear as
+ separate word on the command line in
+ which case the variable is replaced by
+ its value split at whitespaces. Note
+ that the first argument (i.e. the
+ binary to execute) may not be a
+ variable, and must be a literal and
+ absolute path name.</para></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Additional commands
that are executed before (resp. after)
the command in
- <varname>ExecStart=</varname>. If
- specified more than once, all commands
- are executed one after the other,
- serially. Use of these settings is
- optional.</para></listitem>
+ <varname>ExecStart=</varname>. Multiple
+ command lines may be concatenated in a
+ 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 with the same effect. However,
+ the latter syntax is not recommended
+ for compatibility with parsers
+ suitable for XDG
+ <filename>.desktop</filename> files.
+ Use of these settings is
+ optional. Specifier and environment
+ variable substitution is
+ supported.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ExecReload=</varname></term>
<listitem><para>Commands to execute to
trigger a configuration reload in the
- service. If used more than once, all
- commands are executed one after the
- other, serially. Use of this setting is optional.
- </para></listitem>
+ service. This argument takes multiple
+ command lines, following the same
+ scheme as pointed out for
+ <varname>ExecStartPre=</varname>
+ above. Use of this setting is
+ optional. Specifier and environment
+ variable substitution is supported
+ here following the same scheme as for
+ <varname>ExecStart=</varname>. One
+ special environment variable is set:
+ if known <literal>$MAINPID</literal> is
+ set to the main process of the
+ daemon, and may be used for command
+ lines like the following:
+ <command>/bin/kill -HUP
+ $MAINPID</command>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ExecStop=</varname></term>
<listitem><para>Commands to execute to
stop the service started via
- <varname>ExecStart=</varname>. If used
- more than once, all commands are
- executed one after the other,
- serially. Use of this setting is
+ <varname>ExecStart=</varname>. This
+ argument takes multiple command lines,
+ following the same scheme as pointed
+ out for
+ <varname>ExecStartPre=</varname>
+ above. Use of this setting is
optional. All processes remaining for
a service after the commands
configured in this option are run are
(see below). If this option is not
specified the process is terminated
right-away when service stop is
- requested.</para></listitem>
+ requested. Specifier and environment
+ variable substitution is supported
+ (including
+ <literal>$MAINPID</literal>, see
+ above).</para></listitem>
</varlistentry>
<varlistentry>
that are executed after the service
was stopped using the commands
configured in
- <varname>ExecStop=</varname>. If
- specified more than once, all commands
- are executed one after the other,
- serially. Use of these settings is
- optional.</para></listitem>
+ <varname>ExecStop=</varname>. This
+ argument takes multiple command lines,
+ following the same scheme as pointed
+ out for
+ <varname>ExecStartPre</varname>. Use
+ of these settings is
+ optional. Specifier and environment
+ variable substitution is
+ supported.</para></listitem>
</varlistentry>
<varlistentry>
forcibly via SIGTERM, and after
another delay of this time with
SIGKILL. (See
- <option>KillMode=</option>
+ <varname>KillMode=</varname>
below.) Takes a unit-less value in seconds, or a
time span value such as "5min
20s". Pass 0 to disable the timeout
<varlistentry>
<term><varname>Restart=</varname></term>
<listitem><para>Configures whether the
- main service process shall be restarted when
- it exists. Takes one of
- <option>once</option>,
- <option>restart-on-success</option> or
- <option>restart-always</option>. If
- set to <option>once</option> (the
- default) the service will not be
- restarted when it exits. If set to
- <option>restart-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>restart-always</option> the
+ main service process shall be
+ restarted when it exits. Takes one of
+ <option>no</option>,
+ <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
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
- <option>TimeoutSec=</option> option)
+ 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>
<refsect1>
<title>See Also</title>
<para>
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>