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
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>
will proceed starting follow-up units
after the D-Bus bus name has been
acquired. Service units with this
- option configured implicitly have
+ option configured implicitly gain
dependencies on the
<filename>dbus.target</filename>
unit.</para>
notification message has been sent. If
this option is used
<varname>NotifyAccess=</varname> (see
- below) must be set to open access to
+ below) 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
+ 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
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 <literal>@</literal>, the second
- token will be passed as
+ 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 error code of
+ <literal>-</literal> an exit code of
the command normally considered a
- failure is ignored and considered
- success. If both <literal>-</literal>
- and <literal>@</literal> are used for
- the same command the latter must
- preceed the latter. Unless
+ failure (i.e. non-zero exit status or
+ abormal 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
+ the latter. Unless
<varname>Type=forking</varname> is
set, the process started via this
command line will be considered the
by the string value of the environment
variable of the same name. Also
<literal>$FOO</literal> may appear as
- seperate word on the command line in
+ separate word on the command line in
which case the variable is replaced by
- its value split at
- whitespaces.</para></listitem>
+ 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>
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 seperate words). In that
+ be passed as separate words). In that
case, the commands are executed one
after the other,
serially. Alternatively, these
<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 exists. 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
+ restared 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
<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>
+
</variablelist>
</refsect1>