2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
6 <refentry id=
"systemd.service">
8 <title>systemd.service
</title>
9 <productname>systemd
</productname>
13 <refentrytitle>systemd.service
</refentrytitle>
14 <manvolnum>5</manvolnum>
18 <refname>systemd.service
</refname>
19 <refpurpose>Service unit configuration
</refpurpose>
23 <para><filename><replaceable>service
</replaceable>.service
</filename></para>
27 <title>Description
</title>
29 <para>A unit configuration file whose name ends in
30 <literal>.service
</literal> encodes information about a process
31 controlled and supervised by systemd.
</para>
33 <para>This man page lists the configuration options specific to
35 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
36 for the common options of all unit configuration files. The common
37 configuration items are configured in the generic
38 <literal>[Unit]
</literal> and
<literal>[Install]
</literal>
39 sections. The service specific configuration options are
40 configured in the
<literal>[Service]
</literal> section.
</para>
42 <para>Additional options are listed in
43 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
44 which define the execution environment the commands are executed
46 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
47 which define the way the processes of the service are terminated,
49 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
50 which configure resource control settings for the processes of the
53 <para>If a service is requested under a certain name but no unit
54 configuration file is found, systemd looks for a SysV init script
55 by the same name (with the
<filename>.service
</filename> suffix
56 removed) and dynamically creates a service unit from that script.
57 This is useful for compatibility with SysV. Note that this
58 compatibility is quite comprehensive but not
100%. For details
59 about the incompatibilities, see the
<ulink
60 url=
"https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
61 with SysV
</ulink> document.
</para>
65 <title>Service Templates
</title>
67 <para>It is possible for
<command>systemd
</command> services to take a single argument via the
68 <literal><replaceable>service
</replaceable>@
<replaceable>argument
</replaceable>.service
</literal>
69 syntax. Such services are called
"instantiated" services, while the unit definition without the
70 <replaceable>argument
</replaceable> parameter is called a
"template". An example could be a
71 <filename>dhcpcd@.service
</filename> service template which takes a network interface as a
72 parameter to form an instantiated service. Within the service file, this parameter or
"instance
73 name" can be accessed with %-specifiers. See
74 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
79 <title>Automatic Dependencies
</title>
82 <title>Implicit Dependencies
</title>
84 <para>The following dependencies are implicitly added:
</para>
87 <listitem><para>Services with
<varname>Type=dbus
</varname> set automatically
88 acquire dependencies of type
<varname>Requires=
</varname> and
89 <varname>After=
</varname> on
90 <filename>dbus.socket
</filename>.
</para></listitem>
92 <listitem><para>Socket activated services are automatically ordered after
93 their activating
<filename>.socket
</filename> units via an
94 automatic
<varname>After=
</varname> dependency.
95 Services also pull in all
<filename>.socket
</filename> units
96 listed in
<varname>Sockets=
</varname> via automatic
97 <varname>Wants=
</varname> and
<varname>After=
</varname> dependencies.
</para></listitem>
100 <para>Additional implicit dependencies may be added as result of
101 execution and resource control parameters as documented in
102 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
104 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
108 <title>Default Dependencies
</title>
110 <para>The following dependencies are added unless
<varname>DefaultDependencies=no
</varname> is set:
</para>
113 <listitem><para>Service units will have dependencies of type
<varname>Requires=
</varname> and
114 <varname>After=
</varname> on
<filename>sysinit.target
</filename>, a dependency of type
<varname>After=
</varname> on
115 <filename>basic.target
</filename> as well as dependencies of type
<varname>Conflicts=
</varname> and
116 <varname>Before=
</varname> on
<filename>shutdown.target
</filename>. These ensure that normal service units pull in
117 basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
118 boot or late system shutdown should disable this option.
</para></listitem>
120 <listitem><para>Instanced service units (i.e. service units with an
<literal>@
</literal> in their name) are assigned by
121 default a per-template slice unit (see
122 <citerefentry><refentrytitle>systemd.slice
</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
123 template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
124 together with all template instances. If that is not desired, set
<varname>DefaultDependencies=no
</varname> in the
125 template unit, and either define your own per-template slice unit file that also sets
126 <varname>DefaultDependencies=no
</varname>, or set
<varname>Slice=system.slice
</varname> (or another suitable slice)
127 in the template unit. Also see
128 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
135 <title>Options
</title>
137 <para>Service files must include a
<literal>[Service]
</literal>
138 section, which carries information about the service and the
139 process it supervises. A number of options that may be used in
140 this section are shared with other unit types. These options are
142 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
143 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
145 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
146 The options specific to the
<literal>[Service]
</literal> section
147 of service units are the following:
</para>
149 <variablelist class='unit-directives'
>
151 <term><varname>Type=
</varname></term>
154 <para>Configures the process start-up type for this service unit. One of
<option>simple
</option>,
155 <option>exec
</option>,
<option>forking
</option>,
<option>oneshot
</option>,
<option>dbus
</option>,
156 <option>notify
</option> or
<option>idle
</option>:
</para>
159 <listitem><para>If set to
<option>simple
</option> (the default if
<varname>ExecStart=
</varname> is
160 specified but neither
<varname>Type=
</varname> nor
<varname>BusName=
</varname> are), the service manager
161 will consider the unit started immediately after the main service process has been forked off. It is
162 expected that the process configured with
<varname>ExecStart=
</varname> is the main process of the
163 service. In this mode, if the process offers functionality to other processes on the system, its
164 communication channels should be installed before the service is started up (e.g. sockets set up by
165 systemd, via socket activation), as the service manager will immediately proceed starting follow-up units,
166 right after creating the main service process, and before executing the service's binary. Note that this
167 means
<command>systemctl start
</command> command lines for
<option>simple
</option> services will report
168 success even if the service's binary cannot be invoked successfully (for example because the selected
169 <varname>User=
</varname> doesn't exist, or the service binary is missing).
</para></listitem>
171 <listitem><para>The
<option>exec
</option> type is similar to
<option>simple
</option>, but the service
172 manager will consider the unit started immediately after the main service binary has been executed. The service
173 manager will delay starting of follow-up units until that point. (Or in other words:
174 <option>simple
</option> proceeds with further jobs right after
<function>fork()
</function> returns, while
175 <option>exec
</option> will not proceed before both
<function>fork()
</function> and
176 <function>execve()
</function> in the service process succeeded.) Note that this means
<command>systemctl
177 start
</command> command lines for
<option>exec
</option> services will report failure when the service's
178 binary cannot be invoked successfully (for example because the selected
<varname>User=
</varname> doesn't
179 exist, or the service binary is missing).
</para></listitem>
181 <listitem><para>If set to
<option>forking
</option>, it is expected that the process configured with
182 <varname>ExecStart=
</varname> will call
<function>fork()
</function> as part of its start-up. The parent
183 process is expected to exit when start-up is complete and all communication channels are set up. The child
184 continues to run as the main service process, and the service manager will consider the unit started when
185 the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is
186 recommended to also use the
<varname>PIDFile=
</varname> option, so that systemd can reliably identify the
187 main process of the service. systemd will proceed with starting follow-up units as soon as the parent
188 process exits.
</para></listitem>
190 <listitem><para>Behavior of
<option>oneshot
</option> is similar to
<option>simple
</option>; however, the
191 service manager will consider the unit started after the main process exits. It will then start follow-up
192 units.
<varname>RemainAfterExit=
</varname> is particularly useful for this type of
193 service.
<varname>Type=
</varname><option>oneshot
</option> is the implied default if neither
194 <varname>Type=
</varname> nor
<varname>ExecStart=
</varname> are specified.
</para></listitem>
196 <listitem><para>Behavior of
<option>dbus
</option> is similar to
<option>simple
</option>; however, it is
197 expected that the service acquires a name on the D-Bus bus, as configured by
198 <varname>BusName=
</varname>. systemd will proceed with starting follow-up units after the D-Bus bus name
199 has been acquired. Service units with this option configured implicitly gain dependencies on the
200 <filename>dbus.socket
</filename> unit. This type is the default if
<varname>BusName=
</varname> is
201 specified.
</para></listitem>
203 <listitem><para>Behavior of
<option>notify
</option> is similar to
<option>exec
</option>; however, it is
204 expected that the service sends a notification message via
205 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry> or an
206 equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after
207 this notification message has been sent. If this option is used,
<varname>NotifyAccess=
</varname> (see
208 below) should be set to open access to the notification socket provided by systemd. If
209 <varname>NotifyAccess=
</varname> is missing or set to
<option>none
</option>, it will be forcibly set to
210 <option>main
</option>. Note that currently
<varname>Type=
</varname><option>notify
</option> will not work if
211 used in combination with
<varname>PrivateNetwork=
</varname><option>yes
</option>.
</para></listitem>
213 <listitem><para>Behavior of
<option>idle
</option> is very similar to
<option>simple
</option>; however,
214 actual execution of the service program is delayed until all active jobs are dispatched. This may be used
215 to avoid interleaving of output of shell services with the status output on the console. Note that this
216 type is useful only to improve console output, it is not useful as a general unit ordering tool, and the
217 effect of this service type is subject to a
5s timeout, after which the service program is invoked
218 anyway.
</para></listitem>
221 <para>It is generally recommended to use
<varname>Type=
</varname><option>simple
</option> for long-running
222 services whenever possible, as it is the simplest and fastest option. However, as this service type won't
223 propagate service start-up failures and doesn't allow ordering of other units against completion of
224 initialization of the service (which for example is useful if clients need to connect to the service through
225 some form of IPC, and the IPC channel is only established by the service itself — in contrast to doing this
226 ahead of time through socket or bus activation or similar), it might not be sufficient for many cases. If so,
227 <option>notify
</option> or
<option>dbus
</option> (the latter only in case the service provides a D-Bus
228 interface) are the preferred options as they allow service program code to precisely schedule when to
229 consider the service started up successfully and when to proceed with follow-up units. The
230 <option>notify
</option> service type requires explicit support in the service codebase (as
231 <function>sd_notify()
</function> or an equivalent API needs to be invoked by the service at the appropriate
232 time) — if it's not supported, then
<option>forking
</option> is an alternative: it supports the traditional
233 UNIX service start-up protocol. Finally,
<option>exec
</option> might be an option for cases where it is
234 enough to ensure the service binary is invoked, and where the service binary itself executes no or little
235 initialization on its own (and its initialization is unlikely to fail). Note that using any type other than
236 <option>simple
</option> possibly delays the boot process, as the service manager needs to wait for service
237 initialization to complete. It is hence recommended not to needlessly use any types other than
238 <option>simple
</option>. (Also note it is generally not recommended to use
<option>idle
</option> or
239 <option>oneshot
</option> for long-running services.)
</para>
244 <term><varname>RemainAfterExit=
</varname></term>
246 <listitem><para>Takes a boolean value that specifies whether
247 the service shall be considered active even when all its
248 processes exited. Defaults to
<option>no
</option>.
</para>
253 <term><varname>GuessMainPID=
</varname></term>
255 <listitem><para>Takes a boolean value that specifies whether
256 systemd should try to guess the main PID of a service if it
257 cannot be determined reliably. This option is ignored unless
258 <option>Type=forking
</option> is set and
259 <option>PIDFile=
</option> is unset because for the other types
260 or with an explicitly configured PID file, the main PID is
261 always known. The guessing algorithm might come to incorrect
262 conclusions if a daemon consists of more than one process. If
263 the main PID cannot be determined, failure detection and
264 automatic restarting of a service will not work reliably.
265 Defaults to
<option>yes
</option>.
</para>
270 <term><varname>PIDFile=
</varname></term>
272 <listitem><para>Takes a path referring to the PID file of the service. Usage of this option is recommended for
273 services where
<varname>Type=
</varname> is set to
<option>forking
</option>. The path specified typically points
274 to a file below
<filename>/run/
</filename>. If a relative path is specified it is hence prefixed with
275 <filename>/run/
</filename>. The service manager will read the PID of the main process of the service from this
276 file after start-up of the service. The service manager will not write to the file configured here, although it
277 will remove the file after the service has shut down if it still exists. The PID file does not need to be owned
278 by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced:
279 the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the
280 PID file must refer to a process already belonging to the service.
</para></listitem>
284 <term><varname>BusName=
</varname></term>
286 <listitem><para>Takes a D-Bus bus name that this service is
287 reachable as. This option is mandatory for services where
288 <varname>Type=
</varname> is set to
289 <option>dbus
</option>.
</para>
294 <term><varname>ExecStart=
</varname></term>
295 <listitem><para>Commands with their arguments that are
296 executed when this service is started. The value is split into
297 zero or more command lines according to the rules described
298 below (see section
"Command Lines" below).
301 <para>Unless
<varname>Type=
</varname> is
<option>oneshot
</option>, exactly one command must be given. When
302 <varname>Type=oneshot
</varname> is used, zero or more commands may be specified. Commands may be specified by
303 providing multiple command lines in the same directive, or alternatively, this directive may be specified more
304 than once with the same effect. If the empty string is assigned to this option, the list of commands to start
305 is reset, prior assignments of this option will have no effect. If no
<varname>ExecStart=
</varname> is
306 specified, then the service must have
<varname>RemainAfterExit=yes
</varname> and at least one
307 <varname>ExecStop=
</varname> line set. (Services lacking both
<varname>ExecStart=
</varname> and
308 <varname>ExecStop=
</varname> are not valid.)
</para>
310 <para>For each of the specified commands, the first argument must be either an absolute path to an executable
311 or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special
315 <title>Special executable prefixes
</title>
318 <colspec colname='prefix'
/>
319 <colspec colname='meaning'
/>
323 <entry>Prefix
</entry>
324 <entry>Effect
</entry>
329 <entry><literal>@
</literal></entry>
330 <entry>If the executable path is prefixed with
<literal>@
</literal>, the second specified token will be passed as
<literal>argv[
0]
</literal> to the executed process (instead of the actual filename), followed by the further arguments specified.
</entry>
334 <entry><literal>-
</literal></entry>
335 <entry>If the executable path 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 recorded, but has no further effect and is considered equivalent to success.
</entry>
339 <entry><literal>:
</literal></entry>
340 <entry>If the executable path is prefixed with
<literal>:
</literal>, environment variable substitution (as described by the
"Command Lines" section below) is not applied.
</entry>
344 <entry><literal>+
</literal></entry>
345 <entry>If the executable path is prefixed with
<literal>+
</literal> then the process is executed with full privileges. In this mode privilege restrictions configured with
<varname>User=
</varname>,
<varname>Group=
</varname>,
<varname>CapabilityBoundingSet=
</varname> or the various file system namespacing options (such as
<varname>PrivateDevices=
</varname>,
<varname>PrivateTmp=
</varname>) are not applied to the invoked command line (but still affect any other
<varname>ExecStart=
</varname>,
<varname>ExecStop=
</varname>, … lines).
</entry>
349 <entry><literal>!
</literal></entry>
351 <entry>Similar to the
<literal>+
</literal> character discussed above this permits invoking command lines with elevated privileges. However, unlike
<literal>+
</literal> the
<literal>!
</literal> character exclusively alters the effect of
<varname>User=
</varname>,
<varname>Group=
</varname> and
<varname>SupplementaryGroups=
</varname>, i.e. only the stanzas that affect user and group credentials. Note that this setting may be combined with
<varname>DynamicUser=
</varname>, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.
</entry>
355 <entry><literal>!!
</literal></entry>
357 <entry>This prefix is very similar to
<literal>!
</literal>, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for
<varname>AmbientCapabilities=
</varname>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when
<literal>!!
</literal> is used, and a system lacking ambient capability support is detected any configured
<varname>SystemCallFilter=
</varname> and
<varname>CapabilityBoundingSet=
</varname> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected
<varname>AmbientCapabilities=
</varname> will be skipped and not be applied. On systems supporting ambient capabilities,
<literal>!!
</literal> has no effect and is redundant.
</entry>
363 <para><literal>@
</literal>,
<literal>-
</literal>,
<literal>:
</literal>, and one of
364 <literal>+
</literal>/
<literal>!
</literal>/
<literal>!!
</literal> may be used together and they can appear in any
365 order. However, only one of
<literal>+
</literal>,
<literal>!
</literal>,
<literal>!!
</literal> may be used at a
366 time. Note that these prefixes are also supported for the other command line settings,
367 i.e.
<varname>ExecStartPre=
</varname>,
<varname>ExecStartPost=
</varname>,
<varname>ExecReload=
</varname>,
368 <varname>ExecStop=
</varname> and
<varname>ExecStopPost=
</varname>.
</para>
370 <para>If more than one command is specified, the commands are
371 invoked sequentially in the order they appear in the unit
372 file. If one of the commands fails (and is not prefixed with
373 <literal>-
</literal>), other lines are not executed, and the
374 unit is considered failed.
</para>
376 <para>Unless
<varname>Type=forking
</varname> is set, the
377 process started via this command line will be considered the
378 main process of the daemon.
</para>
383 <term><varname>ExecStartPre=
</varname></term>
384 <term><varname>ExecStartPost=
</varname></term>
385 <listitem><para>Additional commands that are executed before
386 or after the command in
<varname>ExecStart=
</varname>,
387 respectively. Syntax is the same as for
388 <varname>ExecStart=
</varname>, except that multiple command
389 lines are allowed and the commands are executed one after the
390 other, serially.
</para>
392 <para>If any of those commands (not prefixed with
393 <literal>-
</literal>) fail, the rest are not executed and the
394 unit is considered failed.
</para>
396 <para><varname>ExecStart=
</varname> commands are only run after
397 all
<varname>ExecStartPre=
</varname> commands that were not prefixed
398 with a
<literal>-
</literal> exit successfully.
</para>
400 <para><varname>ExecStartPost=
</varname> commands are only run after the commands specified in
401 <varname>ExecStart=
</varname> have been invoked successfully, as determined by
<varname>Type=
</varname>
402 (i.e. the process has been started for
<varname>Type=simple
</varname> or
<varname>Type=idle
</varname>, the last
403 <varname>ExecStart=
</varname> process exited successfully for
<varname>Type=oneshot
</varname>, the initial
404 process exited successfully for
<varname>Type=forking
</varname>,
<literal>READY=
1</literal> is sent for
405 <varname>Type=notify
</varname>, or the
<varname>BusName=
</varname> has been taken for
406 <varname>Type=dbus
</varname>).
</para>
408 <para>Note that
<varname>ExecStartPre=
</varname> may not be
409 used to start long-running processes. All processes forked
410 off by processes invoked via
<varname>ExecStartPre=
</varname> will
411 be killed before the next service process is run.
</para>
413 <para>Note that if any of the commands specified in
<varname>ExecStartPre=
</varname>,
414 <varname>ExecStart=
</varname>, or
<varname>ExecStartPost=
</varname> fail (and are not prefixed with
415 <literal>-
</literal>, see above) or time out before the service is fully up, execution continues with commands
416 specified in
<varname>ExecStopPost=
</varname>, the commands in
<varname>ExecStop=
</varname> are skipped.
</para>
421 <term><varname>ExecReload=
</varname></term>
422 <listitem><para>Commands to execute to trigger a configuration
423 reload in the service. This argument takes multiple command
424 lines, following the same scheme as described for
425 <varname>ExecStart=
</varname> above. Use of this setting is
426 optional. Specifier and environment variable substitution is
427 supported here following the same scheme as for
428 <varname>ExecStart=
</varname>.
</para>
430 <para>One additional, special environment variable is set: if
431 known,
<varname>$MAINPID
</varname> is set to the main process
432 of the daemon, and may be used for command lines like the
435 <programlisting>/bin/kill -HUP $MAINPID
</programlisting>
437 <para>Note however that reloading a daemon by sending a signal
438 (as with the example line above) is usually not a good choice,
439 because this is an asynchronous operation and hence not
440 suitable to order reloads of multiple services against each
441 other. It is strongly recommended to set
442 <varname>ExecReload=
</varname> to a command that not only
443 triggers a configuration reload of the daemon, but also
444 synchronously waits for it to complete.
</para>
449 <term><varname>ExecStop=
</varname></term>
450 <listitem><para>Commands to execute to stop the service
451 started via
<varname>ExecStart=
</varname>. This argument takes
452 multiple command lines, following the same scheme as described
453 for
<varname>ExecStart=
</varname> above. Use of this setting
454 is optional. After the commands configured in this option are
455 run, it is implied that the service is stopped, and any processes
456 remaining for it are terminated
457 according to the
<varname>KillMode=
</varname> setting (see
458 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
459 If this option is not specified, the process is terminated by
460 sending the signal specified in
<varname>KillSignal=
</varname>
461 when service stop is requested. Specifier and environment
462 variable substitution is supported (including
463 <varname>$MAINPID
</varname>, see above).
</para>
465 <para>Note that it is usually not sufficient to specify a command for this setting that only asks the service
466 to terminate (for example, by queuing some form of termination signal for it), but does not wait for it to do
467 so. Since the remaining processes of the services are killed according to
<varname>KillMode=
</varname> and
468 <varname>KillSignal=
</varname> as described above immediately after the command exited, this may not result in
469 a clean stop. The specified command should hence be a synchronous operation, not an asynchronous one.
</para>
471 <para>Note that the commands specified in
<varname>ExecStop=
</varname> are only executed when the service
472 started successfully first. They are not invoked if the service was never started at all, or in case its
473 start-up failed, for example because any of the commands specified in
<varname>ExecStart=
</varname>,
474 <varname>ExecStartPre=
</varname> or
<varname>ExecStartPost=
</varname> failed (and weren't prefixed with
475 <literal>-
</literal>, see above) or timed out. Use
<varname>ExecStopPost=
</varname> to invoke commands when a
476 service failed to start up correctly and is shut down again. Also note that the stop operation is always
477 performed if the service started successfully, even if the processes in the service terminated on their
478 own or were killed. The stop commands must be prepared to deal with that case.
<varname>$MAINPID
</varname>
479 will be unset if systemd knows that the main process exited by the time the stop commands are called.
</para>
481 <para>Service restart requests are implemented as stop operations followed by start operations. This
482 means that
<varname>ExecStop=
</varname> and
<varname>ExecStopPost=
</varname> are executed during a
483 service restart operation.
</para>
485 <para>It is recommended to use this setting for commands that communicate with the service requesting
486 clean termination. For post-mortem clean-up steps use
<varname>ExecStopPost=
</varname> instead.
491 <term><varname>ExecStopPost=
</varname></term>
492 <listitem><para>Additional commands that are executed after the service is stopped. This includes cases where
493 the commands configured in
<varname>ExecStop=
</varname> were used, where the service does not have any
494 <varname>ExecStop=
</varname> defined, or where the service exited unexpectedly. This argument takes multiple
495 command lines, following the same scheme as described for
<varname>ExecStart=
</varname>. Use of these settings
496 is optional. Specifier and environment variable substitution is supported. Note that – unlike
497 <varname>ExecStop=
</varname> – commands specified with this setting are invoked when a service failed to start
498 up correctly and is shut down again.
</para>
500 <para>It is recommended to use this setting for clean-up operations that shall be executed even when the
501 service failed to start up correctly. Commands configured with this setting need to be able to operate even if
502 the service failed starting up half-way and left incompletely initialized data around. As the service's
503 processes have been terminated already when the commands specified with this setting are executed they should
504 not attempt to communicate with them.
</para>
506 <para>Note that all commands that are configured with this setting are invoked with the result code of the
507 service, as well as the main process' exit code and status, set in the
<varname>$SERVICE_RESULT
</varname>,
508 <varname>$EXIT_CODE
</varname> and
<varname>$EXIT_STATUS
</varname> environment variables, see
509 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
510 details.
</para></listitem>
514 <term><varname>RestartSec=
</varname></term>
515 <listitem><para>Configures the time to sleep before restarting
516 a service (as configured with
<varname>Restart=
</varname>).
517 Takes a unit-less value in seconds, or a time span value such
518 as
"5min 20s". Defaults to
100ms.
</para></listitem>
522 <term><varname>TimeoutStartSec=
</varname></term>
523 <listitem><para>Configures the time to wait for start-up. If a
524 daemon service does not signal start-up completion within the
525 configured time, the service will be considered failed and
526 will be shut down again. Takes a unit-less value in seconds,
527 or a time span value such as
"5min 20s". Pass
528 <literal>infinity
</literal> to disable the timeout logic. Defaults to
529 <varname>DefaultTimeoutStartSec=
</varname> from the manager
530 configuration file, except when
531 <varname>Type=oneshot
</varname> is used, in which case the
532 timeout is disabled by default (see
533 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
536 <para>If a service of
<varname>Type=notify
</varname> sends
<literal>EXTEND_TIMEOUT_USEC=…
</literal>, this may cause
537 the start time to be extended beyond
<varname>TimeoutStartSec=
</varname>. The first receipt of this message
538 must occur before
<varname>TimeoutStartSec=
</varname> is exceeded, and once the start time has exended beyond
539 <varname>TimeoutStartSec=
</varname>, the service manager will allow the service to continue to start, provided
540 the service repeats
<literal>EXTEND_TIMEOUT_USEC=…
</literal> within the interval specified until the service
541 startup status is finished by
<literal>READY=
1</literal>. (see
542 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
547 <term><varname>TimeoutStopSec=
</varname></term>
548 <listitem><para>This option serves two purposes. First, it configures the time to wait for each
549 <constant>ExecStop=
</constant> command. If any of them times out, subsequent
<constant>ExecStop=
</constant> commands
550 are skipped and the service will be terminated by
<constant>SIGTERM
</constant>. If no
<constant>ExecStop=
</constant>
551 commands are specified, the service gets the
<constant>SIGTERM
</constant> immediately. Second, it configures the time
552 to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated
553 by
<constant>SIGKILL
</constant> (see
<varname>KillMode=
</varname> in
554 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
555 Takes a unit-less value in seconds, or a time span value such
556 as
"5min 20s". Pass
<literal>infinity
</literal> to disable the
557 timeout logic. Defaults to
558 <varname>DefaultTimeoutStopSec=
</varname> from the manager
559 configuration file (see
560 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
563 <para>If a service of
<varname>Type=notify
</varname> sends
<literal>EXTEND_TIMEOUT_USEC=…
</literal>, this may cause
564 the stop time to be extended beyond
<varname>TimeoutStopSec=
</varname>. The first receipt of this message
565 must occur before
<varname>TimeoutStopSec=
</varname> is exceeded, and once the stop time has exended beyond
566 <varname>TimeoutStopSec=
</varname>, the service manager will allow the service to continue to stop, provided
567 the service repeats
<literal>EXTEND_TIMEOUT_USEC=…
</literal> within the interval specified, or terminates itself
568 (see
<citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
573 <term><varname>TimeoutSec=
</varname></term>
574 <listitem><para>A shorthand for configuring both
575 <varname>TimeoutStartSec=
</varname> and
576 <varname>TimeoutStopSec=
</varname> to the specified value.
581 <term><varname>RuntimeMaxSec=
</varname></term>
583 <listitem><para>Configures a maximum time for the service to run. If this is used and the service has been
584 active for longer than the specified time it is terminated and put into a failure state. Note that this setting
585 does not have any effect on
<varname>Type=oneshot
</varname> services, as they terminate immediately after
586 activation completed. Pass
<literal>infinity
</literal> (the default) to configure no runtime
589 <para>If a service of
<varname>Type=notify
</varname> sends
<literal>EXTEND_TIMEOUT_USEC=…
</literal>, this may cause
590 the runtime to be extended beyond
<varname>RuntimeMaxSec=
</varname>. The first receipt of this message
591 must occur before
<varname>RuntimeMaxSec=
</varname> is exceeded, and once the runtime has exended beyond
592 <varname>RuntimeMaxSec=
</varname>, the service manager will allow the service to continue to run, provided
593 the service repeats
<literal>EXTEND_TIMEOUT_USEC=…
</literal> within the interval specified until the service
594 shutdown is achieved by
<literal>STOPPING=
1</literal> (or termination). (see
595 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
600 <term><varname>WatchdogSec=
</varname></term>
601 <listitem><para>Configures the watchdog timeout for a service.
602 The watchdog is activated when the start-up is completed. The
604 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
605 regularly with
<literal>WATCHDOG=
1</literal> (i.e. the
606 "keep-alive ping"). If the time between two such calls is
607 larger than the configured time, then the service is placed in
608 a failed state and it will be terminated with
609 <constant>SIGABRT
</constant> (or the signal specified by
610 <varname>WatchdogSignal=
</varname>). By setting
611 <varname>Restart=
</varname> to
<option>on-failure
</option>,
612 <option>on-watchdog
</option>,
<option>on-abnormal
</option> or
613 <option>always
</option>, the service will be automatically
614 restarted. The time configured here will be passed to the
615 executed service process in the
616 <varname>WATCHDOG_USEC=
</varname> environment variable. This
617 allows daemons to automatically enable the keep-alive pinging
618 logic if watchdog support is enabled for the service. If this
619 option is used,
<varname>NotifyAccess=
</varname> (see below)
620 should be set to open access to the notification socket
621 provided by systemd. If
<varname>NotifyAccess=
</varname> is
622 not set, it will be implicitly set to
<option>main
</option>.
623 Defaults to
0, which disables this feature. The service can
624 check whether the service manager expects watchdog keep-alive
626 <citerefentry><refentrytitle>sd_watchdog_enabled
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
628 <citerefentry><refentrytitle>sd_event_set_watchdog
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
629 may be used to enable automatic watchdog notification support.
634 <term><varname>Restart=
</varname></term>
635 <listitem><para>Configures whether the service shall be
636 restarted when the service process exits, is killed, or a
637 timeout is reached. The service process may be the main
638 service process, but it may also be one of the processes
639 specified with
<varname>ExecStartPre=
</varname>,
640 <varname>ExecStartPost=
</varname>,
641 <varname>ExecStop=
</varname>,
642 <varname>ExecStopPost=
</varname>, or
643 <varname>ExecReload=
</varname>. When the death of the process
644 is a result of systemd operation (e.g. service stop or
645 restart), the service will not be restarted. Timeouts include
646 missing the watchdog
"keep-alive ping" deadline and a service
647 start, reload, and stop operation timeouts.
</para>
651 <option>on-success
</option>,
652 <option>on-failure
</option>,
653 <option>on-abnormal
</option>,
654 <option>on-watchdog
</option>,
655 <option>on-abort
</option>, or
656 <option>always
</option>.
657 If set to
<option>no
</option> (the default), the service will
658 not be restarted. If set to
<option>on-success
</option>, it
659 will be restarted only when the service process exits cleanly.
660 In this context, a clean exit means an exit code of
0, or one
662 <constant>SIGHUP
</constant>,
663 <constant>SIGINT
</constant>,
664 <constant>SIGTERM
</constant> or
665 <constant>SIGPIPE
</constant>, and
666 additionally, exit statuses and signals specified in
667 <varname>SuccessExitStatus=
</varname>. If set to
668 <option>on-failure
</option>, the service will be restarted
669 when the process exits with a non-zero exit code, is
670 terminated by a signal (including on core dump, but excluding
671 the aforementioned four signals), when an operation (such as
672 service reload) times out, and when the configured watchdog
673 timeout is triggered. If set to
<option>on-abnormal
</option>,
674 the service will be restarted when the process is terminated
675 by a signal (including on core dump, excluding the
676 aforementioned four signals), when an operation times out, or
677 when the watchdog timeout is triggered. If set to
678 <option>on-abort
</option>, the service will be restarted only
679 if the service process exits due to an uncaught signal not
680 specified as a clean exit status. If set to
681 <option>on-watchdog
</option>, the service will be restarted
682 only if the watchdog timeout for the service expires. If set
683 to
<option>always
</option>, the service will be restarted
684 regardless of whether it exited cleanly or not, got terminated
685 abnormally by a signal, or hit a timeout.
</para>
688 <title>Exit causes and the effect of the
<varname>Restart=
</varname> settings on them
</title>
691 <colspec colname='path'
/>
692 <colspec colname='expl'
/>
695 <entry>Restart settings/Exit causes
</entry>
696 <entry><option>no
</option></entry>
697 <entry><option>always
</option></entry>
698 <entry><option>on-success
</option></entry>
699 <entry><option>on-failure
</option></entry>
700 <entry><option>on-abnormal
</option></entry>
701 <entry><option>on-abort
</option></entry>
702 <entry><option>on-watchdog
</option></entry>
707 <entry>Clean exit code or signal
</entry>
717 <entry>Unclean exit code
</entry>
727 <entry>Unclean signal
</entry>
737 <entry>Timeout
</entry>
747 <entry>Watchdog
</entry>
760 <para>As exceptions to the setting above, the service will not
761 be restarted if the exit code or signal is specified in
762 <varname>RestartPreventExitStatus=
</varname> (see below) or
763 the service is stopped with
<command>systemctl stop
</command>
764 or an equivalent operation. Also, the services will always be
765 restarted if the exit code or signal is specified in
766 <varname>RestartForceExitStatus=
</varname> (see below).
</para>
768 <para>Note that service restart is subject to unit start rate
769 limiting configured with
<varname>StartLimitIntervalSec=
</varname>
770 and
<varname>StartLimitBurst=
</varname>, see
771 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
772 for details. A restarted service enters the failed state only
773 after the start limits are reached.
</para>
775 <para>Setting this to
<option>on-failure
</option> is the
776 recommended choice for long-running services, in order to
777 increase reliability by attempting automatic recovery from
778 errors. For services that shall be able to terminate on their
779 own choice (and avoid immediate restarting),
780 <option>on-abnormal
</option> is an alternative choice.
</para>
785 <term><varname>SuccessExitStatus=
</varname></term>
786 <listitem><para>Takes a list of exit status definitions that,
787 when returned by the main service process, will be considered
788 successful termination, in addition to the normal successful
789 exit code
0 and the signals
<constant>SIGHUP
</constant>,
790 <constant>SIGINT
</constant>,
<constant>SIGTERM
</constant>, and
791 <constant>SIGPIPE
</constant>. Exit status definitions can
792 either be numeric exit codes or termination signal names,
793 separated by spaces. For example:
795 <programlisting>SuccessExitStatus=
1 2 8 SIGKILL
</programlisting>
797 ensures that exit codes
1,
2,
8 and
798 the termination signal
<constant>SIGKILL
</constant> are
799 considered clean service terminations.
802 <para>This option may appear more than once, in which case the
803 list of successful exit statuses is merged. If the empty
804 string is assigned to this option, the list is reset, all
805 prior assignments of this option will have no
806 effect.
</para></listitem>
810 <term><varname>RestartPreventExitStatus=
</varname></term>
812 <listitem><para>Takes a list of exit status definitions that, when returned by the main service
813 process, will prevent automatic service restarts, regardless of the restart setting configured with
814 <varname>Restart=
</varname>. Exit status definitions can either be numeric exit codes or termination
815 signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit
816 status is excluded from the configured restart logic. For example:
818 <programlisting>RestartPreventExitStatus=
1 6 SIGABRT
</programlisting>
820 ensures that exit codes
1 and
6 and the termination signal
<constant>SIGABRT
</constant> will not
821 result in automatic service restarting. This option may appear more than once, in which case the list
822 of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is
823 reset and all prior assignments of this option will have no effect.
</para>
825 <para>Note that this setting has no effect on processes configured via
826 <varname>ExecStartPre=
</varname>,
<varname>ExecStartPost=
</varname>,
<varname>ExecStop=
</varname>,
827 <varname>ExecStopPost=
</varname> or
<varname>ExecReload=
</varname>, but only on the main service
828 process, i.e. either the one invoked by
<varname>ExecStart=
</varname> or (depending on
829 <varname>Type=
</varname>,
<varname>PIDFile=
</varname>, …) the otherwise configured main
830 process.
</para></listitem>
834 <term><varname>RestartForceExitStatus=
</varname></term>
835 <listitem><para>Takes a list of exit status definitions that,
836 when returned by the main service process, will force automatic
837 service restarts, regardless of the restart setting configured
838 with
<varname>Restart=
</varname>. The argument format is
840 <varname>RestartPreventExitStatus=
</varname>.
</para></listitem>
844 <term><varname>RootDirectoryStartOnly=
</varname></term>
845 <listitem><para>Takes a boolean argument. If true, the root
846 directory, as configured with the
847 <varname>RootDirectory=
</varname> option (see
848 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
849 for more information), is only applied to the process started
850 with
<varname>ExecStart=
</varname>, and not to the various
851 other
<varname>ExecStartPre=
</varname>,
852 <varname>ExecStartPost=
</varname>,
853 <varname>ExecReload=
</varname>,
<varname>ExecStop=
</varname>,
854 and
<varname>ExecStopPost=
</varname> commands. If false, the
855 setting is applied to all configured commands the same way.
856 Defaults to false.
</para></listitem>
860 <term><varname>NonBlocking=
</varname></term>
861 <listitem><para>Set the
<constant>O_NONBLOCK
</constant> flag for all file descriptors passed via socket-based
862 activation. If true, all file descriptors
>=
3 (i.e. all except stdin, stdout, stderr), excluding those passed
863 in via the file descriptor storage logic (see
<varname>FileDescriptorStoreMax=
</varname> for details), will
864 have the
<constant>O_NONBLOCK
</constant> flag set and hence are in non-blocking mode. This option is only
865 useful in conjunction with a socket unit, as described in
866 <citerefentry><refentrytitle>systemd.socket
</refentrytitle><manvolnum>5</manvolnum></citerefentry> and has no
867 effect on file descriptors which were previously saved in the file-descriptor store for example. Defaults to
868 false.
</para></listitem>
872 <term><varname>NotifyAccess=
</varname></term>
873 <listitem><para>Controls access to the service status notification socket, as accessible via the
874 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry> call. Takes one
875 of
<option>none
</option> (the default),
<option>main
</option>,
<option>exec
</option> or
876 <option>all
</option>. If
<option>none
</option>, no daemon status updates are accepted from the service
877 processes, all status update messages are ignored. If
<option>main
</option>, only service updates sent from the
878 main process of the service are accepted. If
<option>exec
</option>, only service updates sent from any of the
879 main or control processes originating from one of the
<varname>Exec*=
</varname> commands are accepted. If
880 <option>all
</option>, all services updates from all members of the service's control group are accepted. This
881 option should be set to open access to the notification socket when using
<varname>Type=notify
</varname> or
882 <varname>WatchdogSec=
</varname> (see above). If those options are used but
<varname>NotifyAccess=
</varname> is
883 not configured, it will be implicitly set to
<option>main
</option>.
</para>
885 <para>Note that
<function>sd_notify()
</function> notifications may be attributed to units correctly only if
886 either the sending process is still around at the time PID
1 processes the message, or if the sending process
887 is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally
888 forked off the process, i.e. on all processes that match
<option>main
</option> or
889 <option>exec
</option>. Conversely, if an auxiliary process of the unit sends an
890 <function>sd_notify()
</function> message and immediately exits, the service manager might not be able to
891 properly attribute the message to the unit, and thus will ignore it, even if
892 <varname>NotifyAccess=
</varname><option>all
</option> is set for it.
</para></listitem>
896 <term><varname>Sockets=
</varname></term>
897 <listitem><para>Specifies the name of the socket units this
898 service shall inherit socket file descriptors from when the
899 service is started. Normally, it should not be necessary to use
900 this setting, as all socket file descriptors whose unit shares
901 the same name as the service (subject to the different unit
902 name suffix of course) are passed to the spawned
905 <para>Note that the same socket file descriptors may be passed
906 to multiple processes simultaneously. Also note that a
907 different service may be activated on incoming socket traffic
908 than the one which is ultimately configured to inherit the
909 socket file descriptors. Or, in other words: the
910 <varname>Service=
</varname> setting of
911 <filename>.socket
</filename> units does not have to match the
912 inverse of the
<varname>Sockets=
</varname> setting of the
913 <filename>.service
</filename> it refers to.
</para>
915 <para>This option may appear more than once, in which case the
916 list of socket units is merged. If the empty string is
917 assigned to this option, the list of sockets is reset, and all
918 prior uses of this setting will have no
919 effect.
</para></listitem>
923 <term><varname>FileDescriptorStoreMax=
</varname></term>
924 <listitem><para>Configure how many file descriptors may be stored in the service manager for the service using
925 <citerefentry><refentrytitle>sd_pid_notify_with_fds
</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
926 <literal>FDSTORE=
1</literal> messages. This is useful for implementing services that can restart after an
927 explicit request or a crash without losing state. Any open sockets and other file descriptors which should not
928 be closed during the restart may be stored this way. Application state can either be serialized to a file in
929 <filename>/run
</filename>, or better, stored in a
930 <citerefentry><refentrytitle>memfd_create
</refentrytitle><manvolnum>2</manvolnum></citerefentry> memory file
931 descriptor. Defaults to
0, i.e. no file descriptors may be stored in the service manager. All file descriptors
932 passed to the service manager from a specific service are passed back to the service's main process on the next
933 service restart. Any file descriptors passed to the service manager are automatically closed when
934 <constant>POLLHUP
</constant> or
<constant>POLLERR
</constant> is seen on them, or when the service is fully
935 stopped and no job is queued or being executed for it. If this option is used,
<varname>NotifyAccess=
</varname>
936 (see above) should be set to open access to the notification socket provided by systemd. If
937 <varname>NotifyAccess=
</varname> is not set, it will be implicitly set to
938 <option>main
</option>.
</para></listitem>
942 <term><varname>USBFunctionDescriptors=
</varname></term>
943 <listitem><para>Configure the location of a file containing
945 url=
"https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB
946 FunctionFS
</ulink> descriptors, for implementation of USB
947 gadget functions. This is used only in conjunction with a
948 socket unit with
<varname>ListenUSBFunction=
</varname>
949 configured. The contents of this file are written to the
950 <filename>ep0
</filename> file after it is
951 opened.
</para></listitem>
955 <term><varname>USBFunctionStrings=
</varname></term>
956 <listitem><para>Configure the location of a file containing
957 USB FunctionFS strings. Behavior is similar to
958 <varname>USBFunctionDescriptors=
</varname>
959 above.
</para></listitem>
965 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
967 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
968 for more settings.
</para>
973 <title>Command lines
</title>
975 <para>This section describes command line parsing and
976 variable and specifier substitutions for
977 <varname>ExecStart=
</varname>,
978 <varname>ExecStartPre=
</varname>,
979 <varname>ExecStartPost=
</varname>,
980 <varname>ExecReload=
</varname>,
981 <varname>ExecStop=
</varname>, and
982 <varname>ExecStopPost=
</varname> options.
</para>
984 <para>Multiple command lines may be concatenated in a single
985 directive by separating them with semicolons (these semicolons
986 must be passed as separate words). Lone semicolons may be escaped
987 as
<literal>\;
</literal>.
</para>
989 <para>Each command line is split on whitespace, with the first item being the command to
990 execute, and the subsequent items being the arguments. Double quotes (
"…") and single quotes
991 ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning or
992 after whitespace that is not quoted, and the closing quote must be followed by whitespace or the
993 end of line), in which case everything until the next matching quote becomes part of the same
994 argument. Quotes themselves are removed. C-style escapes are also supported. The table below
995 contains the list of known escape patterns. Only escape patterns which match the syntax in the
996 table are allowed; other patterns may be added in the future and unknown patterns will result in
997 a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash
998 (
<literal>\
</literal>) may be used to merge lines.
</para>
1000 <para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
1001 described in the following paragraphs are understood, and the expansion of variables is
1002 different. Specifically, redirection using
1003 <literal><</literal>,
1004 <literal><<</literal>,
1005 <literal>></literal>, and
1006 <literal>>></literal>, pipes using
1007 <literal>|
</literal>, running programs in the background using
1008 <literal>&</literal>, and
<emphasis>other elements of shell
1009 syntax are not supported
</emphasis>.
</para>
1011 <para>The command to execute may contain spaces, but control characters are not allowed.
</para>
1013 <para>The command line accepts
<literal>%
</literal> specifiers as described in
1014 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
1016 <para>Basic environment variable substitution is supported. Use
1017 <literal>${FOO}
</literal> as part of a word, or as a word of its
1018 own, on the command line, in which case it will be replaced by the
1019 value of the environment variable including all whitespace it
1020 contains, resulting in a single argument. Use
1021 <literal>$FOO
</literal> as a separate word on the command line, in
1022 which case it will be replaced by the value of the environment
1023 variable split at whitespace, resulting in zero or more arguments.
1024 For this type of expansion, quotes are respected when splitting
1025 into words, and afterwards removed.
</para>
1027 <para>If the command is not a full (absolute) path, it will be resolved to a full path using a
1028 fixed search path determinted at compilation time. Searched directories include
1029 <filename>/usr/local/bin/
</filename>,
<filename>/usr/bin/
</filename>,
<filename>/bin/
</filename>
1030 on systems using split
<filename>/usr/bin/
</filename> and
<filename>/bin/
</filename>
1031 directories, and their
<filename>sbin/
</filename> counterparts on systems using split
1032 <filename>bin/
</filename> and
<filename>sbin/
</filename>. It is thus safe to use just the
1033 executable name in case of executables located in any of the
"standard" directories, and an
1034 absolute path must be used in other cases. Using an absolute path is recommended to avoid
1035 ambiguity. Hint: this search path may be queried using
1036 <command>systemd-path search-binaries-default
</command>.
</para>
1038 <para>Example:
</para>
1040 <programlisting>Environment=
"ONE=one" 'TWO=two two'
1041 ExecStart=echo $ONE $TWO ${TWO}
</programlisting>
1043 <para>This will execute
<command>/bin/echo
</command> with four
1044 arguments:
<literal>one
</literal>,
<literal>two
</literal>,
1045 <literal>two
</literal>, and
<literal>two two
</literal>.
</para>
1047 <para>Example:
</para>
1048 <programlisting>Environment=ONE='one'
"TWO='two two' too" THREE=
1049 ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
1050 ExecStart=/bin/echo $ONE $TWO $THREE
</programlisting>
1051 <para>This results in
<filename>/bin/echo
</filename> being
1052 called twice, the first time with arguments
1053 <literal>'one'
</literal>,
1054 <literal>'two two' too
</literal>,
<literal></literal>,
1055 and the second time with arguments
1056 <literal>one
</literal>,
<literal>two two
</literal>,
1057 <literal>too
</literal>.
1060 <para>To pass a literal dollar sign, use
<literal>$$
</literal>.
1061 Variables whose value is not known at expansion time are treated
1062 as empty strings. Note that the first argument (i.e. the program
1063 to execute) may not be a variable.
</para>
1065 <para>Variables to be used in this fashion may be defined through
1066 <varname>Environment=
</varname> and
1067 <varname>EnvironmentFile=
</varname>. In addition, variables listed
1068 in the section
"Environment variables in spawned processes" in
1069 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1070 which are considered
"static configuration", may be used (this
1071 includes e.g.
<varname>$USER
</varname>, but not
1072 <varname>$TERM
</varname>).
</para>
1074 <para>Note that shell command lines are not directly supported. If
1075 shell command lines are to be used, they need to be passed
1076 explicitly to a shell implementation of some kind. Example:
</para>
1077 <programlisting>ExecStart=sh -c 'dmesg | tac'
</programlisting>
1079 <para>Example:
</para>
1081 <programlisting>ExecStart=echo one ; echo
"two two"</programlisting>
1083 <para>This will execute
<command>echo
</command> two times,
1084 each time with one argument:
<literal>one
</literal> and
1085 <literal>two two
</literal>, respectively. Because two commands are
1086 specified,
<varname>Type=oneshot
</varname> must be used.
</para>
1088 <para>Example:
</para>
1090 <programlisting>ExecStart=echo /
>/dev/null
& \; \
1093 <para>This will execute
<command>echo
</command>
1094 with five arguments:
<literal>/
</literal>,
1095 <literal>>/dev/null
</literal>,
1096 <literal>&</literal>,
<literal>;
</literal>, and
1097 <literal>ls
</literal>.
</para>
1100 <title>C escapes supported in command lines and environment variables
</title>
1102 <colspec colname='escape'
/>
1103 <colspec colname='meaning'
/>
1106 <entry>Literal
</entry>
1107 <entry>Actual value
</entry>
1112 <entry><literal>\a
</literal></entry>
1116 <entry><literal>\b
</literal></entry>
1117 <entry>backspace
</entry>
1120 <entry><literal>\f
</literal></entry>
1121 <entry>form feed
</entry>
1124 <entry><literal>\n
</literal></entry>
1125 <entry>newline
</entry>
1128 <entry><literal>\r
</literal></entry>
1129 <entry>carriage return
</entry>
1132 <entry><literal>\t
</literal></entry>
1136 <entry><literal>\v
</literal></entry>
1137 <entry>vertical tab
</entry>
1140 <entry><literal>\\
</literal></entry>
1141 <entry>backslash
</entry>
1144 <entry><literal>\
"</literal></entry>
1145 <entry>double quotation mark</entry>
1148 <entry><literal>\'</literal></entry>
1149 <entry>single quotation mark</entry>
1152 <entry><literal>\s</literal></entry>
1153 <entry>space</entry>
1156 <entry><literal>\x<replaceable>xx</replaceable></literal></entry>
1157 <entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry>
1160 <entry><literal>\<replaceable>nnn</replaceable></literal></entry>
1161 <entry>character number <replaceable>nnn</replaceable> in octal encoding</entry>
1169 <title>Examples</title>
1172 <title>Simple service</title>
1174 <para>The following unit file creates a service that will
1175 execute <filename>/usr/sbin/foo-daemon</filename>. Since no
1176 <varname>Type=</varname> is specified, the default
1177 <varname>Type=</varname><option>simple</option> will be assumed.
1178 systemd will assume the unit to be started immediately after the
1179 program has begun executing.</para>
1181 <programlisting>[Unit]
1185 ExecStart=/usr/sbin/foo-daemon
1188 WantedBy=multi-user.target</programlisting>
1190 <para>Note that systemd assumes here that the process started by
1191 systemd will continue running until the service terminates. If
1192 the program daemonizes itself (i.e. forks), please use
1193 <varname>Type=</varname><option>forking</option> instead.</para>
1195 <para>Since no <varname>ExecStop=</varname> was specified,
1196 systemd will send SIGTERM to all processes started from this
1197 service, and after a timeout also SIGKILL. This behavior can be
1199 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1202 <para>Note that this unit type does not include any type of
1203 notification when a service has completed initialization. For
1204 this, you should use other unit types, such as
1205 <varname>Type=</varname><option>notify</option> if the service
1206 understands systemd's notification protocol,
1207 <varname>Type=</varname><option>forking</option> if the service
1208 can background itself or
1209 <varname>Type=</varname><option>dbus</option> if the unit
1210 acquires a DBus name once initialization is complete. See
1215 <title>Oneshot service</title>
1217 <para>Sometimes, units should just execute an action without
1218 keeping active processes, such as a filesystem check or a
1219 cleanup action on boot. For this,
1220 <varname>Type=</varname><option>oneshot</option> exists. Units
1221 of this type will wait until the process specified terminates
1222 and then fall back to being inactive. The following unit will
1223 perform a cleanup action:</para>
1225 <programlisting>[Unit]
1226 Description=Cleanup old Foo data
1230 ExecStart=/usr/sbin/foo-cleanup
1233 WantedBy=multi-user.target</programlisting>
1235 <para>Note that systemd will consider the unit to be in the
1236 state "starting
" until the program has terminated, so ordered
1237 dependencies will wait for the program to finish before starting
1238 themselves. The unit will revert to the "inactive
" state after
1239 the execution is done, never reaching the "active
" state. That
1240 means another request to start the unit will perform the action
1243 <para><varname>Type=</varname><option>oneshot</option> are the
1244 only service units that may have more than one
1245 <varname>ExecStart=</varname> specified. They will be executed
1246 in order until either they are all successful or one of them
1251 <title>Stoppable oneshot service</title>
1253 <para>Similarly to the oneshot services, there are sometimes
1254 units that need to execute a program to set up something and
1255 then execute another to shut it down, but no process remains
1256 active while they are considered "started
". Network
1257 configuration can sometimes fall into this category. Another use
1258 case is if a oneshot service shall not be executed each time
1259 when they are pulled in as a dependency, but only the first
1262 <para>For this, systemd knows the setting
1263 <varname>RemainAfterExit=</varname><option>yes</option>, which
1264 causes systemd to consider the unit to be active if the start
1265 action exited successfully. This directive can be used with all
1266 types, but is most useful with
1267 <varname>Type=</varname><option>oneshot</option> and
1268 <varname>Type=</varname><option>simple</option>. With
1269 <varname>Type=</varname><option>oneshot</option>, systemd waits
1270 until the start action has completed before it considers the
1271 unit to be active, so dependencies start only after the start
1272 action has succeeded. With
1273 <varname>Type=</varname><option>simple</option>, dependencies
1274 will start immediately after the start action has been
1275 dispatched. The following unit provides an example for a simple
1276 static firewall.</para>
1278 <programlisting>[Unit]
1279 Description=Simple firewall
1284 ExecStart=/usr/local/sbin/simple-firewall-start
1285 ExecStop=/usr/local/sbin/simple-firewall-stop
1288 WantedBy=multi-user.target</programlisting>
1290 <para>Since the unit is considered to be running after the start
1291 action has exited, invoking <command>systemctl start</command>
1292 on that unit again will cause no action to be taken.</para>
1296 <title>Traditional forking services</title>
1298 <para>Many traditional daemons/services background (i.e. fork,
1299 daemonize) themselves when starting. Set
1300 <varname>Type=</varname><option>forking</option> in the
1301 service's unit file to support this mode of operation. systemd
1302 will consider the service to be in the process of initialization
1303 while the original program is still running. Once it exits
1304 successfully and at least a process remains (and
1305 <varname>RemainAfterExit=</varname><option>no</option>), the
1306 service is considered started.</para>
1308 <para>Often, a traditional daemon only consists of one process.
1309 Therefore, if only one process is left after the original
1310 process terminates, systemd will consider that process the main
1311 process of the service. In that case, the
1312 <varname>$MAINPID</varname> variable will be available in
1313 <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
1316 <para>In case more than one process remains, systemd will be
1317 unable to determine the main process, so it will not assume
1318 there is one. In that case, <varname>$MAINPID</varname> will not
1319 expand to anything. However, if the process decides to write a
1320 traditional PID file, systemd will be able to read the main PID
1321 from there. Please set <varname>PIDFile=</varname> accordingly.
1322 Note that the daemon should write that file before finishing
1323 with its initialization. Otherwise, systemd might try to read the
1324 file before it exists.</para>
1326 <para>The following example shows a simple daemon that forks and
1327 just starts one process in the background:</para>
1329 <programlisting>[Unit]
1330 Description=Some simple daemon
1334 ExecStart=/usr/sbin/my-simple-daemon -d
1337 WantedBy=multi-user.target</programlisting>
1340 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1341 for details on how you can influence the way systemd terminates
1346 <title>DBus services</title>
1348 <para>For services that acquire a name on the DBus system bus,
1349 use <varname>Type=</varname><option>dbus</option> and set
1350 <varname>BusName=</varname> accordingly. The service should not
1351 fork (daemonize). systemd will consider the service to be
1352 initialized once the name has been acquired on the system bus.
1353 The following example shows a typical DBus service:</para>
1355 <programlisting>[Unit]
1356 Description=Simple DBus service
1360 BusName=org.example.simple-dbus-service
1361 ExecStart=/usr/sbin/simple-dbus-service
1364 WantedBy=multi-user.target</programlisting>
1366 <para>For <emphasis>bus-activatable</emphasis> services, do not
1367 include a <literal>[Install]</literal> section in the systemd
1368 service file, but use the <varname>SystemdService=</varname>
1369 option in the corresponding DBus service file, for example
1370 (<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para>
1372 <programlisting>[D-BUS Service]
1373 Name=org.example.simple-dbus-service
1374 Exec=/usr/sbin/simple-dbus-service
1376 SystemdService=simple-dbus-service.service</programlisting>
1379 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1380 for details on how you can influence the way systemd terminates
1385 <title>Services that notify systemd about their initialization</title>
1387 <para><varname>Type=</varname><option>simple</option> services
1388 are really easy to write, but have the major disadvantage of
1389 systemd not being able to tell when initialization of the given
1390 service is complete. For this reason, systemd supports a simple
1391 notification protocol that allows daemons to make systemd aware
1392 that they are done initializing. Use
1393 <varname>Type=</varname><option>notify</option> for this. A
1394 typical service file for such a daemon would look like
1397 <programlisting>[Unit]
1398 Description=Simple notifying service
1402 ExecStart=/usr/sbin/simple-notifying-service
1405 WantedBy=multi-user.target</programlisting>
1407 <para>Note that the daemon has to support systemd's notification
1408 protocol, else systemd will think the service has not started yet
1409 and kill it after a timeout. For an example of how to update
1410 daemons to support this protocol transparently, take a look at
1411 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
1412 systemd will consider the unit to be in the 'starting' state
1413 until a readiness notification has arrived.</para>
1416 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1417 for details on how you can influence the way systemd terminates
1423 <title>See Also</title>
1425 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1426 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1427 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1428 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1429 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1430 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1431 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1432 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>