+ <listitem><para>Commands with their
+ arguments that are executed when this
+ service is started. For each of the
+ specified commands, the first argument
+ must be an absolute and literal path
+ to an executable.</para>
+
+ <para>When <varname>Type</varname> is
+ not <option>oneshot</option>, only one
+ command may be given. When
+ <varname>Type=oneshot</varname> is
+ 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
+ once with the same effect.
+ Lone semicolons may be escaped as
+ <literal>\;</literal>. If the empty
+ string is assigned to this option, the
+ list of commands to start is reset,
+ prior assignments of this option will
+ have no effect.</para>
+
+ <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>
+
+ <para>If more than one command is
+ specified, the commands are invoked
+ sequentially in the order they appear
+ in the unit file. If one of the
+ commands fails (and is not prefixed
+ with <literal>-</literal>), other lines
+ are not executed, and the unit is
+ considered failed.</para>
+
+ <para>Unless
+ <varname>Type=forking</varname> is
+ set, the process started via this
+ command line will be considered the
+ main process of the daemon.</para>
+
+ <para>The command line accepts
+ <literal>%</literal> specifiers as
+ described in
+ <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>
+
+ <para>Basic environment variable
+ substitution is supported. Use
+ <literal>${FOO}</literal> as part of a
+ word, or as a word of its own, on the
+ 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 at
+ whitespace, resulting in zero or more
+ arguments. To pass a literal dollar
+ sign, use <literal>$$</literal>.
+ Variables whose value is not known at
+ expansion time are treated as empty
+ strings. Note that the first argument
+ (i.e. the program to execute) may not
+ be a variable.</para>
+
+ <para>Variables to be used in this
+ fashion may be defined through
+ <varname>Environment=</varname> and
+ <varname>EnvironmentFile=</varname>.
+ In addition, variables listed in the
+ section "Environment variables in
+ spawned processes" in
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ which are considered "static
+ configuration", may be used (this includes
+ e.g. <varname>$USER</varname>, but not
+ <varname>$TERM</varname>).</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
+ absolute filename 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, they
+ can appear in either order.</para>
+
+ <para>Note that this setting does not
+ directly support shell command
+ lines. If shell command lines are to
+ be used, they need to be passed
+ explicitly to a shell implementation
+ of some kind. Example:</para>
+ <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'</programlisting>
+ <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. Because 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>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ExecStartPre=</varname></term>
+ <term><varname>ExecStartPost=</varname></term>
+ <listitem><para>Additional commands
+ that are executed before or after
+ the command in
+ <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>
+
+ <para>If any of those commands (not
+ prefixed with <literal>-</literal>)
+ fail, the rest are not executed and
+ the unit is considered failed.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ExecReload=</varname></term>
+ <listitem><para>Commands to execute to
+ trigger a configuration reload in the
+ service. This argument takes multiple
+ command lines, following the same
+ scheme as described for
+ <varname>ExecStart=</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>.</para>
+
+ <para>One additional, special
+ environment variable is set: if known,
+ <varname>$MAINPID</varname> is set to
+ the main process of the daemon, and
+ may be used for command lines like the
+ following:</para>
+
+ <programlisting>/bin/kill -HUP $MAINPID</programlisting>
+
+ <para>Note however that reloading a
+ daemon by sending a signal (as with
+ the example line above) is usually not
+ a good choice, because this is an
+ asynchronous operation and hence not
+ suitable to order reloads of multiple
+ services against each other. It is
+ strongly recommended to set
+ <varname>ExecReload=</varname> to a
+ command that not only triggers a
+ configuration reload of the daemon,
+ but also synchronously waits for it to
+ complete.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ExecStop=</varname></term>
+ <listitem><para>Commands to execute to
+ stop the service started via
+ <varname>ExecStart=</varname>. This
+ argument takes multiple command lines,
+ following the same scheme as described
+ for <varname>ExecStart=</varname>
+ above. Use of this setting is
+ optional. After the commands configured
+ in this option are run, all processes
+ remaining for a service are
+ terminated according to the
+ <varname>KillMode=</varname> setting
+ (see
+ <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
+ this option is not specified, the
+ process is terminated immediately when
+ service stop is requested. Specifier
+ and environment variable substitution
+ is supported (including
+ <varname>$MAINPID</varname>, see
+ above).</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>ExecStopPost=</varname></term>
+ <listitem><para>Additional commands
+ that are executed after the service
+ was stopped. This includes cases where
+ the commands configured in
+ <varname>ExecStop=</varname> were used,
+ where the service does not have any
+ <varname>ExecStop=</varname> defined, or
+ where the service exited unexpectedly. This
+ argument takes multiple command lines,
+ following the same scheme as described
+ for <varname>ExecStart</varname>. Use
+ of these settings is
+ optional. Specifier and environment
+ variable substitution is
+ supported.</para></listitem>
+ </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>
+ <term><varname>TimeoutStartSec=</varname></term>
+ <listitem><para>Configures the time to
+ wait for start-up. If a
+ daemon service does not signal
+ start-up completion within the
+ configured time, the service will be
+ considered failed and will be shut
+ down again.
+ Takes a unit-less value in seconds, or a
+ time span value such as "5min
+ 20s". Pass <literal>0</literal> to
+ disable the timeout logic. Defaults to
+ <varname>DefaultTimeoutStartSec=</varname> from
+ the manager configuration file, except
+ when <varname>Type=oneshot</varname> is
+ used, in which case the timeout
+ is disabled by default
+ (see <citerefentry><refentrytitle>systemd-systemd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ </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
+ forcibly via <constant>SIGTERM</constant>,
+ and after another timeout of equal duration
+ with <constant>SIGKILL</constant> (see
+ <varname>KillMode=</varname>
+ in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ Takes a unit-less value in seconds, or a
+ time span value such as "5min
+ 20s". Pass <literal>0</literal> to disable
+ the timeout logic. Defaults to
+ <varname>DefaultTimeoutStopSec=</varname> from the
+ manager configuration file
+ (see <citerefentry><refentrytitle>systemd-systemd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+ </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>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>WatchdogSec=</varname></term>
+ <listitem><para>Configures the
+ watchdog timeout for a service. The
+ watchdog is activated when the start-up is
+ completed. The service must call
+ <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ regularly with <literal>WATCHDOG=1</literal>
+ (i.e. the "keep-alive ping"). If the time
+ between two such calls is larger than
+ the configured time, then the service
+ is placed in a failed state. By
+ setting <varname>Restart=</varname> to
+ <option>on-failure</option> or
+ <option>always</option>, the service
+ will be automatically restarted. The
+ time configured here will be passed to
+ the executed service process in the
+ <varname>WATCHDOG_USEC=</varname>
+ environment variable. This allows
+ daemons to automatically enable the
+ keep-alive pinging logic if watchdog
+ support is enabled for the service. If
+ this option is used,
+ <varname>NotifyAccess=</varname> (see
+ 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
+ <option>main</option>. Defaults to 0,
+ which disables this
+ feature.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>Restart=</varname></term>
+ <listitem><para>Configures whether the
+ 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 it may also be one of the
+ processes specified with
+ <varname>ExecStartPre=</varname>,
+ <varname>ExecStartPost=</varname>,
+ <varname>ExecStop=</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
+ <option>no</option>,
+ <option>on-success</option>,
+ <option>on-failure</option>,
+ <option>on-abnormal</option>,
+ <option>on-watchdog</option>,
+ <option>on-abort</option>, or
+ <option>always</option>. If set to
+ <option>no</option> (the default), the
+ service will not be restarted. If set
+ to <option>on-success</option>, it
+ will be 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
+ <constant>SIGHUP</constant>,
+ <constant>SIGINT</constant>,
+ <constant>SIGTERM</constant> or
+ <constant>SIGPIPE</constant>, and
+ additionally, exit statuses and
+ signals specified in
+ <varname>SuccessExitStatus=</varname>.
+ If set to <option>on-failure</option>,
+ the service will be restarted when the
+ process exits with a non-zero exit
+ code, is terminated by a signal
+ (including on core dump, but excluding
+ the aforementiond four signals), when
+ an operation (such as service reload)
+ times out, and when the configured
+ watchdog timeout is triggered. If set
+ to <option>on-abnormal</option>, the
+ service will be restarted when the
+ process is terminated by a signal
+ (including on core dump, excluding the
+ aforementioned four signals), when an
+ operation times out, or when the
+ watchdog timeout is triggered. If set
+ to <option>on-abort</option>, the
+ service will be restarted only if the
+ service process exits due to an
+ uncaught signal not specified as a
+ clean exit status. If set to
+ <option>on-watchdog</option>, the
+ service will be restarted only if the
+ watchdog timeout for the service
+ expires. If set to
+ <option>always</option>, the service
+ will be restarted regardless of
+ whether it exited cleanly or not, got
+ terminated abnormally by a signal, or
+ hit a timeout.</para>
+
+ <table>
+ <title>Exit causes and the effect of the <varname>Restart=</varname> settings on them</title>
+
+ <tgroup cols='2'>
+ <colspec colname='path' />
+ <colspec colname='expl' />
+ <thead>
+ <row>
+ <entry>Restart settings/Exit causes</entry>
+ <entry><option>no</option></entry>
+ <entry><option>always</option></entry>
+ <entry><option>on-success</option></entry>
+ <entry><option>on-failure</option></entry>
+ <entry><option>on-abnormal</option></entry>
+ <entry><option>on-abort</option></entry>
+ <entry><option>on-watchdog</option></entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Clean exit code or signal</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry>X</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry>Unclean exit code</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry/>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry>Unclean signal</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry>X</entry>
+ <entry>X</entry>
+ <entry/>
+ </row>
+ <row>
+ <entry>Timeout</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry>X</entry>
+ <entry/>
+ <entry/>
+ </row>
+ <row>
+ <entry>Watchdog</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry/>
+ <entry>X</entry>
+ <entry>X</entry>
+ <entry/>
+ <entry>X</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>As exceptions to the setting
+ above the service will not be
+ restarted if the exit code or signal
+ is specified in
+ <varname>RestartPreventExitStatus=</varname>
+ (see below). Also, the services will
+ always be restarted if the exit code
+ or signal is specified in
+ <varname>RestartForceExitStatus=</varname>
+ (see below).</para>
+
+ <para>Setting this to
+ <option>on-failure</option> is the
+ recommended choice for long-running
+ services, in order to increase
+ reliability by attempting automatic
+ recovery from errors. For services
+ that shall be able to terminate on
+ their own choice (and avoid
+ immediate restarting),
+ <option>on-abnormal</option> is an
+ alternative choice.</para>