code style format: clang-format applied to src/a*/*
[thirdparty/systemd.git] / man / systemd.service.xml
CommitLineData
514094f9 1<?xml version='1.0'?>
3a54a157 2<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
12b42c76 3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
0307f791 4<!-- SPDX-License-Identifier: LGPL-2.1+ -->
d1ab0ca0
LP
5
6<refentry id="systemd.service">
798d3a52
ZJS
7 <refentryinfo>
8 <title>systemd.service</title>
9 <productname>systemd</productname>
798d3a52
ZJS
10 </refentryinfo>
11
12 <refmeta>
13 <refentrytitle>systemd.service</refentrytitle>
14 <manvolnum>5</manvolnum>
15 </refmeta>
16
17 <refnamediv>
18 <refname>systemd.service</refname>
19 <refpurpose>Service unit configuration</refpurpose>
20 </refnamediv>
21
22 <refsynopsisdiv>
23 <para><filename><replaceable>service</replaceable>.service</filename></para>
24 </refsynopsisdiv>
25
26 <refsect1>
27 <title>Description</title>
28
29 <para>A unit configuration file whose name ends in
ed10715a 30 <literal>.service</literal> encodes information about a process
798d3a52
ZJS
31 controlled and supervised by systemd.</para>
32
33 <para>This man page lists the configuration options specific to
34 this unit type. See
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>
41
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
45 in, and in
46 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
47 which define the way the processes of the service are terminated,
48 and in
49 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
50 which configure resource control settings for the processes of the
51 service.</para>
52
798d3a52
ZJS
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
28a0ad81 60 url="https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
c129bd5d 61 with SysV</ulink> document.</para>
438e6a48
LP
62
63 <para>The <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
64 command allows creating <filename>.service</filename> and <filename>.scope</filename> units dynamically
65 and transiently from the command line.</para>
c129bd5d
LP
66 </refsect1>
67
68 <refsect1>
75695fb7
ZJS
69 <title>Service Templates</title>
70
71 <para>It is possible for <command>systemd</command> services to take a single argument via the
72 <literal><replaceable>service</replaceable>@<replaceable>argument</replaceable>.service</literal>
73 syntax. Such services are called "instantiated" services, while the unit definition without the
74 <replaceable>argument</replaceable> parameter is called a "template". An example could be a
75 <filename>dhcpcd@.service</filename> service template which takes a network interface as a
76 parameter to form an instantiated service. Within the service file, this parameter or "instance
77 name" can be accessed with %-specifiers. See
78 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
79 for details.</para>
798d3a52
ZJS
80 </refsect1>
81
45f09f93 82 <refsect1>
aed5cb03
ZJS
83 <title>Automatic Dependencies</title>
84
85 <refsect2>
86 <title>Implicit Dependencies</title>
87
88 <para>The following dependencies are implicitly added:</para>
89
90 <itemizedlist>
91 <listitem><para>Services with <varname>Type=dbus</varname> set automatically
92 acquire dependencies of type <varname>Requires=</varname> and
93 <varname>After=</varname> on
94 <filename>dbus.socket</filename>.</para></listitem>
95
96 <listitem><para>Socket activated services are automatically ordered after
97 their activating <filename>.socket</filename> units via an
98 automatic <varname>After=</varname> dependency.
99 Services also pull in all <filename>.socket</filename> units
100 listed in <varname>Sockets=</varname> via automatic
101 <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem>
102 </itemizedlist>
103
104 <para>Additional implicit dependencies may be added as result of
105 execution and resource control parameters as documented in
106 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
107 and
108 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
109 </refsect2>
110
111 <refsect2>
112 <title>Default Dependencies</title>
113
114 <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
115
116 <itemizedlist>
117 <listitem><para>Service units will have dependencies of type <varname>Requires=</varname> and
118 <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
119 <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
120 <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
121 basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
122 boot or late system shutdown should disable this option.</para></listitem>
123
124 <listitem><para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
125 default a per-template slice unit (see
126 <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
127 template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
128 together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
129 template unit, and either define your own per-template slice unit file that also sets
130 <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
131 in the template unit. Also see
132 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
133 </para></listitem>
134 </itemizedlist>
135 </refsect2>
45f09f93
JL
136 </refsect1>
137
798d3a52
ZJS
138 <refsect1>
139 <title>Options</title>
140
141 <para>Service files must include a <literal>[Service]</literal>
142 section, which carries information about the service and the
143 process it supervises. A number of options that may be used in
144 this section are shared with other unit types. These options are
145 documented in
aa9f9e58
LW
146 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
147 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
798d3a52 148 and
aa9f9e58 149 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
798d3a52
ZJS
150 The options specific to the <literal>[Service]</literal> section
151 of service units are the following:</para>
152
153 <variablelist class='unit-directives'>
154 <varlistentry>
155 <term><varname>Type=</varname></term>
156
79905a24
LP
157 <listitem>
158 <para>Configures the process start-up type for this service unit. One of <option>simple</option>,
159 <option>exec</option>, <option>forking</option>, <option>oneshot</option>, <option>dbus</option>,
160 <option>notify</option> or <option>idle</option>:</para>
161
162 <itemizedlist>
163 <listitem><para>If set to <option>simple</option> (the default if <varname>ExecStart=</varname> is
164 specified but neither <varname>Type=</varname> nor <varname>BusName=</varname> are), the service manager
165 will consider the unit started immediately after the main service process has been forked off. It is
166 expected that the process configured with <varname>ExecStart=</varname> is the main process of the
167 service. In this mode, if the process offers functionality to other processes on the system, its
168 communication channels should be installed before the service is started up (e.g. sockets set up by
169 systemd, via socket activation), as the service manager will immediately proceed starting follow-up units,
170 right after creating the main service process, and before executing the service's binary. Note that this
171 means <command>systemctl start</command> command lines for <option>simple</option> services will report
172 success even if the service's binary cannot be invoked successfully (for example because the selected
173 <varname>User=</varname> doesn't exist, or the service binary is missing).</para></listitem>
174
175 <listitem><para>The <option>exec</option> type is similar to <option>simple</option>, but the service
176 manager will consider the unit started immediately after the main service binary has been executed. The service
177 manager will delay starting of follow-up units until that point. (Or in other words:
178 <option>simple</option> proceeds with further jobs right after <function>fork()</function> returns, while
179 <option>exec</option> will not proceed before both <function>fork()</function> and
180 <function>execve()</function> in the service process succeeded.) Note that this means <command>systemctl
181 start</command> command lines for <option>exec</option> services will report failure when the service's
182 binary cannot be invoked successfully (for example because the selected <varname>User=</varname> doesn't
183 exist, or the service binary is missing).</para></listitem>
184
185 <listitem><para>If set to <option>forking</option>, it is expected that the process configured with
186 <varname>ExecStart=</varname> will call <function>fork()</function> as part of its start-up. The parent
187 process is expected to exit when start-up is complete and all communication channels are set up. The child
188 continues to run as the main service process, and the service manager will consider the unit started when
189 the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is
190 recommended to also use the <varname>PIDFile=</varname> option, so that systemd can reliably identify the
191 main process of the service. systemd will proceed with starting follow-up units as soon as the parent
192 process exits.</para></listitem>
193
194 <listitem><para>Behavior of <option>oneshot</option> is similar to <option>simple</option>; however, the
195 service manager will consider the unit started after the main process exits. It will then start follow-up
196 units. <varname>RemainAfterExit=</varname> is particularly useful for this type of
197 service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither
198 <varname>Type=</varname> nor <varname>ExecStart=</varname> are specified.</para></listitem>
199
200 <listitem><para>Behavior of <option>dbus</option> is similar to <option>simple</option>; however, it is
201 expected that the service acquires a name on the D-Bus bus, as configured by
202 <varname>BusName=</varname>. systemd will proceed with starting follow-up units after the D-Bus bus name
203 has been acquired. Service units with this option configured implicitly gain dependencies on the
204 <filename>dbus.socket</filename> unit. This type is the default if <varname>BusName=</varname> is
205 specified.</para></listitem>
206
207 <listitem><para>Behavior of <option>notify</option> is similar to <option>exec</option>; however, it is
208 expected that the service sends a notification message via
209 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> or an
210 equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after
211 this notification message has been sent. If this option is used, <varname>NotifyAccess=</varname> (see
212 below) should be set to open access to the notification socket provided by systemd. If
213 <varname>NotifyAccess=</varname> is missing or set to <option>none</option>, it will be forcibly set to
214 <option>main</option>. Note that currently <varname>Type=</varname><option>notify</option> will not work if
215 used in combination with <varname>PrivateNetwork=</varname><option>yes</option>.</para></listitem>
216
217 <listitem><para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however,
218 actual execution of the service program is delayed until all active jobs are dispatched. This may be used
219 to avoid interleaving of output of shell services with the status output on the console. Note that this
220 type is useful only to improve console output, it is not useful as a general unit ordering tool, and the
3f9a0a52 221 effect of this service type is subject to a 5s timeout, after which the service program is invoked
79905a24
LP
222 anyway.</para></listitem>
223 </itemizedlist>
224
225 <para>It is generally recommended to use <varname>Type=</varname><option>simple</option> for long-running
226 services whenever possible, as it is the simplest and fastest option. However, as this service type won't
227 propagate service start-up failures and doesn't allow ordering of other units against completion of
228 initialization of the service (which for example is useful if clients need to connect to the service through
229 some form of IPC, and the IPC channel is only established by the service itself — in contrast to doing this
230 ahead of time through socket or bus activation or similar), it might not be sufficient for many cases. If so,
231 <option>notify</option> or <option>dbus</option> (the latter only in case the service provides a D-Bus
232 interface) are the preferred options as they allow service program code to precisely schedule when to
233 consider the service started up successfully and when to proceed with follow-up units. The
234 <option>notify</option> service type requires explicit support in the service codebase (as
235 <function>sd_notify()</function> or an equivalent API needs to be invoked by the service at the appropriate
236 time) — if it's not supported, then <option>forking</option> is an alternative: it supports the traditional
237 UNIX service start-up protocol. Finally, <option>exec</option> might be an option for cases where it is
238 enough to ensure the service binary is invoked, and where the service binary itself executes no or little
239 initialization on its own (and its initialization is unlikely to fail). Note that using any type other than
240 <option>simple</option> possibly delays the boot process, as the service manager needs to wait for service
241 initialization to complete. It is hence recommended not to needlessly use any types other than
242 <option>simple</option>. (Also note it is generally not recommended to use <option>idle</option> or
243 <option>oneshot</option> for long-running services.)</para>
798d3a52
ZJS
244 </listitem>
245 </varlistentry>
246
247 <varlistentry>
248 <term><varname>RemainAfterExit=</varname></term>
249
250 <listitem><para>Takes a boolean value that specifies whether
251 the service shall be considered active even when all its
252 processes exited. Defaults to <option>no</option>.</para>
253 </listitem>
254 </varlistentry>
255
256 <varlistentry>
257 <term><varname>GuessMainPID=</varname></term>
258
259 <listitem><para>Takes a boolean value that specifies whether
260 systemd should try to guess the main PID of a service if it
261 cannot be determined reliably. This option is ignored unless
262 <option>Type=forking</option> is set and
263 <option>PIDFile=</option> is unset because for the other types
264 or with an explicitly configured PID file, the main PID is
265 always known. The guessing algorithm might come to incorrect
266 conclusions if a daemon consists of more than one process. If
267 the main PID cannot be determined, failure detection and
268 automatic restarting of a service will not work reliably.
269 Defaults to <option>yes</option>.</para>
270 </listitem>
271 </varlistentry>
272
273 <varlistentry>
274 <term><varname>PIDFile=</varname></term>
275
a9353a5c
LP
276 <listitem><para>Takes a path referring to the PID file of the service. Usage of this option is recommended for
277 services where <varname>Type=</varname> is set to <option>forking</option>. The path specified typically points
278 to a file below <filename>/run/</filename>. If a relative path is specified it is hence prefixed with
279 <filename>/run/</filename>. The service manager will read the PID of the main process of the service from this
280 file after start-up of the service. The service manager will not write to the file configured here, although it
281 will remove the file after the service has shut down if it still exists. The PID file does not need to be owned
282 by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced:
283 the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the
284 PID file must refer to a process already belonging to the service.</para></listitem>
798d3a52
ZJS
285 </varlistentry>
286
287 <varlistentry>
288 <term><varname>BusName=</varname></term>
289
290 <listitem><para>Takes a D-Bus bus name that this service is
291 reachable as. This option is mandatory for services where
292 <varname>Type=</varname> is set to
293 <option>dbus</option>.</para>
294 </listitem>
295 </varlistentry>
296
798d3a52
ZJS
297 <varlistentry>
298 <term><varname>ExecStart=</varname></term>
299 <listitem><para>Commands with their arguments that are
300 executed when this service is started. The value is split into
a8eaaee7 301 zero or more command lines according to the rules described
798d3a52
ZJS
302 below (see section "Command Lines" below).
303 </para>
304
29df65f9
ZJS
305 <para>Unless <varname>Type=</varname> is <option>oneshot</option>, exactly one command must be given. When
306 <varname>Type=oneshot</varname> is used, zero or more commands may be specified. Commands may be specified by
307 providing multiple command lines in the same directive, or alternatively, this directive may be specified more
308 than once with the same effect. If the empty string is assigned to this option, the list of commands to start
309 is reset, prior assignments of this option will have no effect. If no <varname>ExecStart=</varname> is
e4b45b32
LP
310 specified, then the service must have <varname>RemainAfterExit=yes</varname> and at least one
311 <varname>ExecStop=</varname> line set. (Services lacking both <varname>ExecStart=</varname> and
312 <varname>ExecStop=</varname> are not valid.)</para>
798d3a52 313
5008da1e
ZJS
314 <para>For each of the specified commands, the first argument must be either an absolute path to an executable
315 or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special
316 characters:</para>
165a31c0
LP
317
318 <table>
319 <title>Special executable prefixes</title>
320
321 <tgroup cols='2'>
322 <colspec colname='prefix'/>
323 <colspec colname='meaning'/>
324
325 <thead>
326 <row>
327 <entry>Prefix</entry>
328 <entry>Effect</entry>
329 </row>
330 </thead>
331 <tbody>
332 <row>
333 <entry><literal>@</literal></entry>
334 <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>
335 </row>
336
337 <row>
338 <entry><literal>-</literal></entry>
6e021090 339 <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>
165a31c0
LP
340 </row>
341
7ca69792
AZ
342 <row>
343 <entry><literal>:</literal></entry>
344 <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>
345 </row>
346
165a31c0
LP
347 <row>
348 <entry><literal>+</literal></entry>
349 <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>
350 </row>
351
352 <row>
353 <entry><literal>!</literal></entry>
354
7fc97da0 355 <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>
165a31c0
LP
356 </row>
357
358 <row>
359 <entry><literal>!!</literal></entry>
360
132523e7 361 <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>
165a31c0
LP
362 </row>
363 </tbody>
364 </tgroup>
365 </table>
366
7ca69792 367 <para><literal>@</literal>, <literal>-</literal>, <literal>:</literal>, and one of
165a31c0 368 <literal>+</literal>/<literal>!</literal>/<literal>!!</literal> may be used together and they can appear in any
ee905de0 369 order. However, only one of <literal>+</literal>, <literal>!</literal>, <literal>!!</literal> may be used at a
165a31c0 370 time. Note that these prefixes are also supported for the other command line settings,
78a263f4 371 i.e. <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecReload=</varname>,
165a31c0 372 <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>.</para>
798d3a52
ZJS
373
374 <para>If more than one command is specified, the commands are
375 invoked sequentially in the order they appear in the unit
376 file. If one of the commands fails (and is not prefixed with
377 <literal>-</literal>), other lines are not executed, and the
378 unit is considered failed.</para>
379
380 <para>Unless <varname>Type=forking</varname> is set, the
381 process started via this command line will be considered the
382 main process of the daemon.</para>
383 </listitem>
384 </varlistentry>
385
386 <varlistentry>
387 <term><varname>ExecStartPre=</varname></term>
388 <term><varname>ExecStartPost=</varname></term>
389 <listitem><para>Additional commands that are executed before
390 or after the command in <varname>ExecStart=</varname>,
391 respectively. Syntax is the same as for
392 <varname>ExecStart=</varname>, except that multiple command
393 lines are allowed and the commands are executed one after the
394 other, serially.</para>
395
396 <para>If any of those commands (not prefixed with
397 <literal>-</literal>) fail, the rest are not executed and the
398 unit is considered failed.</para>
b481de3b 399
12e2683d
RM
400 <para><varname>ExecStart=</varname> commands are only run after
401 all <varname>ExecStartPre=</varname> commands that were not prefixed
402 with a <literal>-</literal> exit successfully.</para>
403
80af263b
LP
404 <para><varname>ExecStartPost=</varname> commands are only run after the commands specified in
405 <varname>ExecStart=</varname> have been invoked successfully, as determined by <varname>Type=</varname>
406 (i.e. the process has been started for <varname>Type=simple</varname> or <varname>Type=idle</varname>, the last
407 <varname>ExecStart=</varname> process exited successfully for <varname>Type=oneshot</varname>, the initial
408 process exited successfully for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent for
409 <varname>Type=notify</varname>, or the <varname>BusName=</varname> has been taken for
410 <varname>Type=dbus</varname>).</para>
12e2683d 411
b481de3b
LP
412 <para>Note that <varname>ExecStartPre=</varname> may not be
413 used to start long-running processes. All processes forked
414 off by processes invoked via <varname>ExecStartPre=</varname> will
415 be killed before the next service process is run.</para>
ce359e98
LP
416
417 <para>Note that if any of the commands specified in <varname>ExecStartPre=</varname>,
418 <varname>ExecStart=</varname>, or <varname>ExecStartPost=</varname> fail (and are not prefixed with
419 <literal>-</literal>, see above) or time out before the service is fully up, execution continues with commands
420 specified in <varname>ExecStopPost=</varname>, the commands in <varname>ExecStop=</varname> are skipped.</para>
798d3a52
ZJS
421 </listitem>
422 </varlistentry>
423
424 <varlistentry>
425 <term><varname>ExecReload=</varname></term>
426 <listitem><para>Commands to execute to trigger a configuration
427 reload in the service. This argument takes multiple command
428 lines, following the same scheme as described for
429 <varname>ExecStart=</varname> above. Use of this setting is
430 optional. Specifier and environment variable substitution is
431 supported here following the same scheme as for
432 <varname>ExecStart=</varname>.</para>
433
434 <para>One additional, special environment variable is set: if
435 known, <varname>$MAINPID</varname> is set to the main process
436 of the daemon, and may be used for command lines like the
437 following:</para>
438
439 <programlisting>/bin/kill -HUP $MAINPID</programlisting>
440
441 <para>Note however that reloading a daemon by sending a signal
442 (as with the example line above) is usually not a good choice,
443 because this is an asynchronous operation and hence not
444 suitable to order reloads of multiple services against each
445 other. It is strongly recommended to set
446 <varname>ExecReload=</varname> to a command that not only
447 triggers a configuration reload of the daemon, but also
448 synchronously waits for it to complete.</para>
449 </listitem>
450 </varlistentry>
451
452 <varlistentry>
453 <term><varname>ExecStop=</varname></term>
454 <listitem><para>Commands to execute to stop the service
455 started via <varname>ExecStart=</varname>. This argument takes
456 multiple command lines, following the same scheme as described
457 for <varname>ExecStart=</varname> above. Use of this setting
458 is optional. After the commands configured in this option are
23656d2b
AY
459 run, it is implied that the service is stopped, and any processes
460 remaining for it are terminated
798d3a52
ZJS
461 according to the <varname>KillMode=</varname> setting (see
462 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
cceb20c7
LP
463 If this option is not specified, the process is terminated by
464 sending the signal specified in <varname>KillSignal=</varname>
465 when service stop is requested. Specifier and environment
466 variable substitution is supported (including
467 <varname>$MAINPID</varname>, see above).</para>
468
99479986
FS
469 <para>Note that it is usually not sufficient to specify a command for this setting that only asks the service
470 to terminate (for example, by queuing some form of termination signal for it), but does not wait for it to do
471 so. Since the remaining processes of the services are killed according to <varname>KillMode=</varname> and
472 <varname>KillSignal=</varname> as described above immediately after the command exited, this may not result in
473 a clean stop. The specified command should hence be a synchronous operation, not an asynchronous one.</para>
ce359e98
LP
474
475 <para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service
07ff561c 476 started successfully first. They are not invoked if the service was never started at all, or in case its
ce359e98
LP
477 start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
478 <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
479 <literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
3aaae27a
ZJS
480 service failed to start up correctly and is shut down again. Also note that the stop operation is always
481 performed if the service started successfully, even if the processes in the service terminated on their
482 own or were killed. The stop commands must be prepared to deal with that case. <varname>$MAINPID</varname>
483 will be unset if systemd knows that the main process exited by the time the stop commands are called.</para>
484
485 <para>Service restart requests are implemented as stop operations followed by start operations. This
486 means that <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> are executed during a
487 service restart operation.</para>
488
489 <para>It is recommended to use this setting for commands that communicate with the service requesting
490 clean termination. For post-mortem clean-up steps use <varname>ExecStopPost=</varname> instead.
491 </para></listitem>
798d3a52
ZJS
492 </varlistentry>
493
494 <varlistentry>
495 <term><varname>ExecStopPost=</varname></term>
ce359e98
LP
496 <listitem><para>Additional commands that are executed after the service is stopped. This includes cases where
497 the commands configured in <varname>ExecStop=</varname> were used, where the service does not have any
498 <varname>ExecStop=</varname> defined, or where the service exited unexpectedly. This argument takes multiple
499 command lines, following the same scheme as described for <varname>ExecStart=</varname>. Use of these settings
500 is optional. Specifier and environment variable substitution is supported. Note that – unlike
501 <varname>ExecStop=</varname> – commands specified with this setting are invoked when a service failed to start
502 up correctly and is shut down again.</para>
503
504 <para>It is recommended to use this setting for clean-up operations that shall be executed even when the
505 service failed to start up correctly. Commands configured with this setting need to be able to operate even if
506 the service failed starting up half-way and left incompletely initialized data around. As the service's
507 processes have been terminated already when the commands specified with this setting are executed they should
136dc4c4
LP
508 not attempt to communicate with them.</para>
509
510 <para>Note that all commands that are configured with this setting are invoked with the result code of the
511 service, as well as the main process' exit code and status, set in the <varname>$SERVICE_RESULT</varname>,
512 <varname>$EXIT_CODE</varname> and <varname>$EXIT_STATUS</varname> environment variables, see
513 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
514 details.</para></listitem>
798d3a52
ZJS
515 </varlistentry>
516
517 <varlistentry>
518 <term><varname>RestartSec=</varname></term>
519 <listitem><para>Configures the time to sleep before restarting
520 a service (as configured with <varname>Restart=</varname>).
521 Takes a unit-less value in seconds, or a time span value such
522 as "5min 20s". Defaults to 100ms.</para></listitem>
523 </varlistentry>
524
525 <varlistentry>
526 <term><varname>TimeoutStartSec=</varname></term>
527 <listitem><para>Configures the time to wait for start-up. If a
528 daemon service does not signal start-up completion within the
529 configured time, the service will be considered failed and
530 will be shut down again. Takes a unit-less value in seconds,
531 or a time span value such as "5min 20s". Pass
2c29d332 532 <literal>infinity</literal> to disable the timeout logic. Defaults to
798d3a52
ZJS
533 <varname>DefaultTimeoutStartSec=</varname> from the manager
534 configuration file, except when
535 <varname>Type=oneshot</varname> is used, in which case the
536 timeout is disabled by default (see
537 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
a327431b
DB
538 </para>
539
540 <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause
541 the start time to be extended beyond <varname>TimeoutStartSec=</varname>. The first receipt of this message
542 must occur before <varname>TimeoutStartSec=</varname> is exceeded, and once the start time has exended beyond
543 <varname>TimeoutStartSec=</varname>, the service manager will allow the service to continue to start, provided
544 the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified until the service
545 startup status is finished by <literal>READY=1</literal>. (see
546 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
798d3a52
ZJS
547 </para></listitem>
548 </varlistentry>
549
550 <varlistentry>
551 <term><varname>TimeoutStopSec=</varname></term>
9a6da355
JS
552 <listitem><para>This option serves two purposes. First, it configures the time to wait for each
553 <constant>ExecStop=</constant> command. If any of them times out, subsequent <constant>ExecStop=</constant> commands
554 are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <constant>ExecStop=</constant>
555 commands are specified, the service gets the <constant>SIGTERM</constant> immediately. Second, it configures the time
556 to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated
557 by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in
798d3a52
ZJS
558 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
559 Takes a unit-less value in seconds, or a time span value such
2c29d332 560 as "5min 20s". Pass <literal>infinity</literal> to disable the
798d3a52
ZJS
561 timeout logic. Defaults to
562 <varname>DefaultTimeoutStopSec=</varname> from the manager
563 configuration file (see
564 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
a327431b
DB
565 </para>
566
567 <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause
568 the stop time to be extended beyond <varname>TimeoutStopSec=</varname>. The first receipt of this message
569 must occur before <varname>TimeoutStopSec=</varname> is exceeded, and once the stop time has exended beyond
570 <varname>TimeoutStopSec=</varname>, the service manager will allow the service to continue to stop, provided
571 the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified, or terminates itself
572 (see <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
798d3a52
ZJS
573 </para></listitem>
574 </varlistentry>
575
576 <varlistentry>
577 <term><varname>TimeoutSec=</varname></term>
578 <listitem><para>A shorthand for configuring both
579 <varname>TimeoutStartSec=</varname> and
580 <varname>TimeoutStopSec=</varname> to the specified value.
581 </para></listitem>
582 </varlistentry>
583
2c29d332
LP
584 <varlistentry>
585 <term><varname>RuntimeMaxSec=</varname></term>
586
587 <listitem><para>Configures a maximum time for the service to run. If this is used and the service has been
588 active for longer than the specified time it is terminated and put into a failure state. Note that this setting
589 does not have any effect on <varname>Type=oneshot</varname> services, as they terminate immediately after
590 activation completed. Pass <literal>infinity</literal> (the default) to configure no runtime
a327431b
DB
591 limit.</para>
592
593 <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause
594 the runtime to be extended beyond <varname>RuntimeMaxSec=</varname>. The first receipt of this message
595 must occur before <varname>RuntimeMaxSec=</varname> is exceeded, and once the runtime has exended beyond
596 <varname>RuntimeMaxSec=</varname>, the service manager will allow the service to continue to run, provided
597 the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified until the service
90bc77af 598 shutdown is achieved by <literal>STOPPING=1</literal> (or termination). (see
a327431b
DB
599 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
600 </para></listitem>
2c29d332
LP
601 </varlistentry>
602
798d3a52
ZJS
603 <varlistentry>
604 <term><varname>WatchdogSec=</varname></term>
605 <listitem><para>Configures the watchdog timeout for a service.
606 The watchdog is activated when the start-up is completed. The
607 service must call
608 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
609 regularly with <literal>WATCHDOG=1</literal> (i.e. the
610 "keep-alive ping"). If the time between two such calls is
611 larger than the configured time, then the service is placed in
612 a failed state and it will be terminated with
c87700a1
AZ
613 <constant>SIGABRT</constant> (or the signal specified by
614 <varname>WatchdogSignal=</varname>). By setting
a0533c6d
EV
615 <varname>Restart=</varname> to <option>on-failure</option>,
616 <option>on-watchdog</option>, <option>on-abnormal</option> or
798d3a52
ZJS
617 <option>always</option>, the service will be automatically
618 restarted. The time configured here will be passed to the
619 executed service process in the
620 <varname>WATCHDOG_USEC=</varname> environment variable. This
621 allows daemons to automatically enable the keep-alive pinging
622 logic if watchdog support is enabled for the service. If this
623 option is used, <varname>NotifyAccess=</varname> (see below)
624 should be set to open access to the notification socket
625 provided by systemd. If <varname>NotifyAccess=</varname> is
626 not set, it will be implicitly set to <option>main</option>.
582f2fcb
EV
627 Defaults to 0, which disables this feature. The service can
628 check whether the service manager expects watchdog keep-alive
629 notifications. See
630 <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
a0533c6d
EV
631 for details.
632 <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
633 may be used to enable automatic watchdog notification support.
582f2fcb 634 </para></listitem>
798d3a52
ZJS
635 </varlistentry>
636
637 <varlistentry>
638 <term><varname>Restart=</varname></term>
639 <listitem><para>Configures whether the service shall be
640 restarted when the service process exits, is killed, or a
641 timeout is reached. The service process may be the main
642 service process, but it may also be one of the processes
643 specified with <varname>ExecStartPre=</varname>,
644 <varname>ExecStartPost=</varname>,
645 <varname>ExecStop=</varname>,
646 <varname>ExecStopPost=</varname>, or
647 <varname>ExecReload=</varname>. When the death of the process
648 is a result of systemd operation (e.g. service stop or
649 restart), the service will not be restarted. Timeouts include
650 missing the watchdog "keep-alive ping" deadline and a service
651 start, reload, and stop operation timeouts.</para>
652
653 <para>Takes one of
654 <option>no</option>,
655 <option>on-success</option>,
656 <option>on-failure</option>,
657 <option>on-abnormal</option>,
658 <option>on-watchdog</option>,
659 <option>on-abort</option>, or
660 <option>always</option>.
661 If set to <option>no</option> (the default), the service will
662 not be restarted. If set to <option>on-success</option>, it
663 will be restarted only when the service process exits cleanly.
664 In this context, a clean exit means an exit code of 0, or one
665 of the signals
666 <constant>SIGHUP</constant>,
667 <constant>SIGINT</constant>,
668 <constant>SIGTERM</constant> or
669 <constant>SIGPIPE</constant>, and
670 additionally, exit statuses and signals specified in
671 <varname>SuccessExitStatus=</varname>. If set to
672 <option>on-failure</option>, the service will be restarted
673 when the process exits with a non-zero exit code, is
674 terminated by a signal (including on core dump, but excluding
ff9b60f3 675 the aforementioned four signals), when an operation (such as
798d3a52
ZJS
676 service reload) times out, and when the configured watchdog
677 timeout is triggered. If set to <option>on-abnormal</option>,
678 the service will be restarted when the process is terminated
679 by a signal (including on core dump, excluding the
680 aforementioned four signals), when an operation times out, or
681 when the watchdog timeout is triggered. If set to
682 <option>on-abort</option>, the service will be restarted only
683 if the service process exits due to an uncaught signal not
684 specified as a clean exit status. If set to
685 <option>on-watchdog</option>, the service will be restarted
686 only if the watchdog timeout for the service expires. If set
687 to <option>always</option>, the service will be restarted
688 regardless of whether it exited cleanly or not, got terminated
689 abnormally by a signal, or hit a timeout.</para>
690
691 <table>
692 <title>Exit causes and the effect of the <varname>Restart=</varname> settings on them</title>
693
694 <tgroup cols='2'>
695 <colspec colname='path' />
696 <colspec colname='expl' />
697 <thead>
698 <row>
699 <entry>Restart settings/Exit causes</entry>
700 <entry><option>no</option></entry>
701 <entry><option>always</option></entry>
702 <entry><option>on-success</option></entry>
703 <entry><option>on-failure</option></entry>
704 <entry><option>on-abnormal</option></entry>
705 <entry><option>on-abort</option></entry>
706 <entry><option>on-watchdog</option></entry>
707 </row>
708 </thead>
709 <tbody>
710 <row>
711 <entry>Clean exit code or signal</entry>
712 <entry/>
713 <entry>X</entry>
714 <entry>X</entry>
715 <entry/>
716 <entry/>
717 <entry/>
718 <entry/>
719 </row>
720 <row>
721 <entry>Unclean exit code</entry>
722 <entry/>
723 <entry>X</entry>
724 <entry/>
725 <entry>X</entry>
726 <entry/>
727 <entry/>
728 <entry/>
729 </row>
730 <row>
731 <entry>Unclean signal</entry>
732 <entry/>
733 <entry>X</entry>
734 <entry/>
735 <entry>X</entry>
736 <entry>X</entry>
737 <entry>X</entry>
738 <entry/>
739 </row>
740 <row>
741 <entry>Timeout</entry>
742 <entry/>
743 <entry>X</entry>
744 <entry/>
745 <entry>X</entry>
746 <entry>X</entry>
747 <entry/>
748 <entry/>
749 </row>
750 <row>
751 <entry>Watchdog</entry>
752 <entry/>
753 <entry>X</entry>
754 <entry/>
755 <entry>X</entry>
756 <entry>X</entry>
757 <entry/>
758 <entry>X</entry>
759 </row>
760 </tbody>
761 </tgroup>
762 </table>
763
b938cb90 764 <para>As exceptions to the setting above, the service will not
798d3a52 765 be restarted if the exit code or signal is specified in
09b69d68
T
766 <varname>RestartPreventExitStatus=</varname> (see below) or
767 the service is stopped with <command>systemctl stop</command>
768 or an equivalent operation. Also, the services will always be
769 restarted if the exit code or signal is specified in
798d3a52
ZJS
770 <varname>RestartForceExitStatus=</varname> (see below).</para>
771
6d249476
LW
772 <para>Note that service restart is subject to unit start rate
773 limiting configured with <varname>StartLimitIntervalSec=</varname>
774 and <varname>StartLimitBurst=</varname>, see
775 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
bd2538b5
KBM
776 for details. A restarted service enters the failed state only
777 after the start limits are reached.</para>
6d249476 778
798d3a52
ZJS
779 <para>Setting this to <option>on-failure</option> is the
780 recommended choice for long-running services, in order to
781 increase reliability by attempting automatic recovery from
782 errors. For services that shall be able to terminate on their
783 own choice (and avoid immediate restarting),
784 <option>on-abnormal</option> is an alternative choice.</para>
785 </listitem>
786 </varlistentry>
787
788 <varlistentry>
789 <term><varname>SuccessExitStatus=</varname></term>
b938cb90
JE
790 <listitem><para>Takes a list of exit status definitions that,
791 when returned by the main service process, will be considered
798d3a52
ZJS
792 successful termination, in addition to the normal successful
793 exit code 0 and the signals <constant>SIGHUP</constant>,
794 <constant>SIGINT</constant>, <constant>SIGTERM</constant>, and
795 <constant>SIGPIPE</constant>. Exit status definitions can
796 either be numeric exit codes or termination signal names,
797 separated by spaces. For example:
dc83f27a
LP
798
799 <programlisting>SuccessExitStatus=1 2 8 SIGKILL</programlisting>
800
801 ensures that exit codes 1, 2, 8 and
798d3a52
ZJS
802 the termination signal <constant>SIGKILL</constant> are
803 considered clean service terminations.
804 </para>
805
798d3a52
ZJS
806 <para>This option may appear more than once, in which case the
807 list of successful exit statuses is merged. If the empty
808 string is assigned to this option, the list is reset, all
809 prior assignments of this option will have no
810 effect.</para></listitem>
811 </varlistentry>
812
813 <varlistentry>
814 <term><varname>RestartPreventExitStatus=</varname></term>
57639710
LP
815
816 <listitem><para>Takes a list of exit status definitions that, when returned by the main service
817 process, will prevent automatic service restarts, regardless of the restart setting configured with
818 <varname>Restart=</varname>. Exit status definitions can either be numeric exit codes or termination
819 signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit
820 status is excluded from the configured restart logic. For example:
dc83f27a
LP
821
822 <programlisting>RestartPreventExitStatus=1 6 SIGABRT</programlisting>
823
57639710
LP
824 ensures that exit codes 1 and 6 and the termination signal <constant>SIGABRT</constant> will not
825 result in automatic service restarting. This option may appear more than once, in which case the list
826 of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is
827 reset and all prior assignments of this option will have no effect.</para>
828
829 <para>Note that this setting has no effect on processes configured via
830 <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecStop=</varname>,
831 <varname>ExecStopPost=</varname> or <varname>ExecReload=</varname>, but only on the main service
832 process, i.e. either the one invoked by <varname>ExecStart=</varname> or (depending on
833 <varname>Type=</varname>, <varname>PIDFile=</varname>, …) the otherwise configured main
834 process.</para></listitem>
798d3a52
ZJS
835 </varlistentry>
836
837 <varlistentry>
838 <term><varname>RestartForceExitStatus=</varname></term>
b938cb90
JE
839 <listitem><para>Takes a list of exit status definitions that,
840 when returned by the main service process, will force automatic
798d3a52
ZJS
841 service restarts, regardless of the restart setting configured
842 with <varname>Restart=</varname>. The argument format is
843 similar to
844 <varname>RestartPreventExitStatus=</varname>.</para></listitem>
845 </varlistentry>
846
798d3a52
ZJS
847 <varlistentry>
848 <term><varname>RootDirectoryStartOnly=</varname></term>
849 <listitem><para>Takes a boolean argument. If true, the root
850 directory, as configured with the
851 <varname>RootDirectory=</varname> option (see
852 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
853 for more information), is only applied to the process started
854 with <varname>ExecStart=</varname>, and not to the various
855 other <varname>ExecStartPre=</varname>,
856 <varname>ExecStartPost=</varname>,
857 <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
858 and <varname>ExecStopPost=</varname> commands. If false, the
859 setting is applied to all configured commands the same way.
860 Defaults to false.</para></listitem>
861 </varlistentry>
862
863 <varlistentry>
864 <term><varname>NonBlocking=</varname></term>
9b141911
FB
865 <listitem><para>Set the <constant>O_NONBLOCK</constant> flag for all file descriptors passed via socket-based
866 activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr), excluding those passed
867 in via the file descriptor storage logic (see <varname>FileDescriptorStoreMax=</varname> for details), will
868 have the <constant>O_NONBLOCK</constant> flag set and hence are in non-blocking mode. This option is only
869 useful in conjunction with a socket unit, as described in
870 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> and has no
871 effect on file descriptors which were previously saved in the file-descriptor store for example. Defaults to
872 false.</para></listitem>
798d3a52
ZJS
873 </varlistentry>
874
875 <varlistentry>
876 <term><varname>NotifyAccess=</varname></term>
b3bb6476
LP
877 <listitem><para>Controls access to the service status notification socket, as accessible via the
878 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> call. Takes one
879 of <option>none</option> (the default), <option>main</option>, <option>exec</option> or
880 <option>all</option>. If <option>none</option>, no daemon status updates are accepted from the service
881 processes, all status update messages are ignored. If <option>main</option>, only service updates sent from the
882 main process of the service are accepted. If <option>exec</option>, only service updates sent from any of the
883 main or control processes originating from one of the <varname>Exec*=</varname> commands are accepted. If
884 <option>all</option>, all services updates from all members of the service's control group are accepted. This
885 option should be set to open access to the notification socket when using <varname>Type=notify</varname> or
886 <varname>WatchdogSec=</varname> (see above). If those options are used but <varname>NotifyAccess=</varname> is
887 not configured, it will be implicitly set to <option>main</option>.</para>
888
889 <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if
890 either the sending process is still around at the time PID 1 processes the message, or if the sending process
891 is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally
892 forked off the process, i.e. on all processes that match <option>main</option> or
893 <option>exec</option>. Conversely, if an auxiliary process of the unit sends an
894 <function>sd_notify()</function> message and immediately exits, the service manager might not be able to
895 properly attribute the message to the unit, and thus will ignore it, even if
896 <varname>NotifyAccess=</varname><option>all</option> is set for it.</para></listitem>
798d3a52
ZJS
897 </varlistentry>
898
899 <varlistentry>
900 <term><varname>Sockets=</varname></term>
901 <listitem><para>Specifies the name of the socket units this
902 service shall inherit socket file descriptors from when the
b938cb90
JE
903 service is started. Normally, it should not be necessary to use
904 this setting, as all socket file descriptors whose unit shares
798d3a52
ZJS
905 the same name as the service (subject to the different unit
906 name suffix of course) are passed to the spawned
907 process.</para>
908
909 <para>Note that the same socket file descriptors may be passed
910 to multiple processes simultaneously. Also note that a
911 different service may be activated on incoming socket traffic
912 than the one which is ultimately configured to inherit the
b938cb90 913 socket file descriptors. Or, in other words: the
798d3a52
ZJS
914 <varname>Service=</varname> setting of
915 <filename>.socket</filename> units does not have to match the
916 inverse of the <varname>Sockets=</varname> setting of the
917 <filename>.service</filename> it refers to.</para>
918
919 <para>This option may appear more than once, in which case the
920 list of socket units is merged. If the empty string is
921 assigned to this option, the list of sockets is reset, and all
922 prior uses of this setting will have no
923 effect.</para></listitem>
924 </varlistentry>
925
798d3a52
ZJS
926 <varlistentry>
927 <term><varname>FileDescriptorStoreMax=</varname></term>
3ceb72e5 928 <listitem><para>Configure how many file descriptors may be stored in the service manager for the service using
798d3a52 929 <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
3ceb72e5
LP
930 <literal>FDSTORE=1</literal> messages. This is useful for implementing services that can restart after an
931 explicit request or a crash without losing state. Any open sockets and other file descriptors which should not
932 be closed during the restart may be stored this way. Application state can either be serialized to a file in
933 <filename>/run</filename>, or better, stored in a
934 <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> memory file
935 descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service manager. All file descriptors
936 passed to the service manager from a specific service are passed back to the service's main process on the next
937 service restart. Any file descriptors passed to the service manager are automatically closed when
938 <constant>POLLHUP</constant> or <constant>POLLERR</constant> is seen on them, or when the service is fully
4330dc03
AJ
939 stopped and no job is queued or being executed for it. If this option is used, <varname>NotifyAccess=</varname>
940 (see above) should be set to open access to the notification socket provided by systemd. If
941 <varname>NotifyAccess=</varname> is not set, it will be implicitly set to
942 <option>main</option>.</para></listitem>
798d3a52
ZJS
943 </varlistentry>
944
8c7c9839
PS
945 <varlistentry>
946 <term><varname>USBFunctionDescriptors=</varname></term>
3d314510
LP
947 <listitem><para>Configure the location of a file containing
948 <ulink
949 url="https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB
950 FunctionFS</ulink> descriptors, for implementation of USB
a8eaaee7 951 gadget functions. This is used only in conjunction with a
3d314510 952 socket unit with <varname>ListenUSBFunction=</varname>
a8eaaee7 953 configured. The contents of this file are written to the
3d314510
LP
954 <filename>ep0</filename> file after it is
955 opened.</para></listitem>
8c7c9839
PS
956 </varlistentry>
957
958 <varlistentry>
959 <term><varname>USBFunctionStrings=</varname></term>
3d314510
LP
960 <listitem><para>Configure the location of a file containing
961 USB FunctionFS strings. Behavior is similar to
962 <varname>USBFunctionDescriptors=</varname>
963 above.</para></listitem>
8c7c9839
PS
964 </varlistentry>
965
8e74bf7f
LP
966 <varlistentry>
967 <term><varname>OOMPolicy=</varname></term>
968
969 <listitem><para>Configure the Out-Of-Memory (OOM) killer policy. On Linux, when memory becomes scarce
970 the kernel might decide to kill a running process in order to free up memory and reduce memory
971 pressure. This setting takes one of <constant>continue</constant>, <constant>stop</constant> or
972 <constant>kill</constant>. If set to <constant>continue</constant> and a process of the service is
973 killed by the kernel's OOM killer this is logged but the service continues running. If set to
974 <constant>stop</constant> the event is logged but the service is terminated cleanly by the service
975 manager. If set to <constant>kill</constant> and one of the service's processes is killed by the OOM
976 killer the kernel is instructed to kill all remaining processes of the service, too. Defaults to the
977 setting <varname>DefaultOOMPolicy=</varname> in
978 <citerefentry><refentrytitle>system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> is
979 set to, except for services where <varname>Delegate=</varname> is turned on, where it defaults to
980 <constant>continue</constant>.</para>
981
982 <para>Use the <varname>OOMScoreAdjust=</varname> setting to configure whether processes of the unit
983 shall be considered preferred or less preferred candidates for process termination by the Linux OOM
984 killer logic. See
985 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
986 details.</para></listitem>
987 </varlistentry>
988
798d3a52
ZJS
989 </variablelist>
990
991 <para>Check
992 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
993 and
994 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
995 for more settings.</para>
996
997 </refsect1>
998
999 <refsect1>
1000 <title>Command lines</title>
1001
1002 <para>This section describes command line parsing and
ff9b60f3 1003 variable and specifier substitutions for
798d3a52
ZJS
1004 <varname>ExecStart=</varname>,
1005 <varname>ExecStartPre=</varname>,
1006 <varname>ExecStartPost=</varname>,
1007 <varname>ExecReload=</varname>,
1008 <varname>ExecStop=</varname>, and
1009 <varname>ExecStopPost=</varname> options.</para>
1010
1011 <para>Multiple command lines may be concatenated in a single
1012 directive by separating them with semicolons (these semicolons
1013 must be passed as separate words). Lone semicolons may be escaped
1014 as <literal>\;</literal>.</para>
1015
330785f5 1016 <para>Each command line is split on whitespace, with the first item being the command to
1eecafb8 1017 execute, and the subsequent items being the arguments. Double quotes ("…") and single quotes
fa0c9e63
ZJS
1018 ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning or
1019 after whitespace that is not quoted, and the closing quote must be followed by whitespace or the
1020 end of line), in which case everything until the next matching quote becomes part of the same
1021 argument. Quotes themselves are removed. C-style escapes are also supported. The table below
1022 contains the list of known escape patterns. Only escape patterns which match the syntax in the
1023 table are allowed; other patterns may be added in the future and unknown patterns will result in
1024 a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash
1025 (<literal>\</literal>) may be used to merge lines.</para>
798d3a52 1026
0e3f51cf
ZJS
1027 <para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
1028 described in the following paragraphs are understood, and the expansion of variables is
1029 different. Specifically, redirection using
798d3a52
ZJS
1030 <literal>&lt;</literal>,
1031 <literal>&lt;&lt;</literal>,
1032 <literal>&gt;</literal>, and
1033 <literal>&gt;&gt;</literal>, pipes using
1034 <literal>|</literal>, running programs in the background using
1035 <literal>&amp;</literal>, and <emphasis>other elements of shell
1036 syntax are not supported</emphasis>.</para>
1037
5008da1e 1038 <para>The command to execute may contain spaces, but control characters are not allowed.</para>
798d3a52 1039
5008da1e 1040 <para>The command line accepts <literal>%</literal> specifiers as described in
2d06ddb7 1041 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
798d3a52
ZJS
1042
1043 <para>Basic environment variable substitution is supported. Use
1044 <literal>${FOO}</literal> as part of a word, or as a word of its
1045 own, on the command line, in which case it will be replaced by the
1046 value of the environment variable including all whitespace it
1047 contains, resulting in a single argument. Use
1048 <literal>$FOO</literal> as a separate word on the command line, in
1049 which case it will be replaced by the value of the environment
b938cb90 1050 variable split at whitespace, resulting in zero or more arguments.
3faf145d 1051 For this type of expansion, quotes are respected when splitting
798d3a52
ZJS
1052 into words, and afterwards removed.</para>
1053
5008da1e
ZJS
1054 <para>If the command is not a full (absolute) path, it will be resolved to a full path using a
1055 fixed search path determinted at compilation time. Searched directories include
1056 <filename>/usr/local/bin/</filename>, <filename>/usr/bin/</filename>, <filename>/bin/</filename>
1057 on systems using split <filename>/usr/bin/</filename> and <filename>/bin/</filename>
1058 directories, and their <filename>sbin/</filename> counterparts on systems using split
1059 <filename>bin/</filename> and <filename>sbin/</filename>. It is thus safe to use just the
1060 executable name in case of executables located in any of the "standard" directories, and an
1061 absolute path must be used in other cases. Using an absolute path is recommended to avoid
e12d446b
ZJS
1062 ambiguity. Hint: this search path may be queried using
1063 <command>systemd-path search-binaries-default</command>.</para>
5008da1e 1064
798d3a52
ZJS
1065 <para>Example:</para>
1066
1067 <programlisting>Environment="ONE=one" 'TWO=two two'
5008da1e 1068ExecStart=echo $ONE $TWO ${TWO}</programlisting>
5d9a2698 1069
798d3a52
ZJS
1070 <para>This will execute <command>/bin/echo</command> with four
1071 arguments: <literal>one</literal>, <literal>two</literal>,
1072 <literal>two</literal>, and <literal>two two</literal>.</para>
5d9a2698 1073
798d3a52
ZJS
1074 <para>Example:</para>
1075 <programlisting>Environment=ONE='one' "TWO='two two' too" THREE=
5d9a2698
ZJS
1076ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
1077ExecStart=/bin/echo $ONE $TWO $THREE</programlisting>
5008da1e 1078 <para>This results in <filename>/bin/echo</filename> being
798d3a52
ZJS
1079 called twice, the first time with arguments
1080 <literal>'one'</literal>,
1081 <literal>'two two' too</literal>, <literal></literal>,
1082 and the second time with arguments
1083 <literal>one</literal>, <literal>two two</literal>,
1084 <literal>too</literal>.
1085 </para>
1086
1087 <para>To pass a literal dollar sign, use <literal>$$</literal>.
1088 Variables whose value is not known at expansion time are treated
1089 as empty strings. Note that the first argument (i.e. the program
1090 to execute) may not be a variable.</para>
1091
1092 <para>Variables to be used in this fashion may be defined through
1093 <varname>Environment=</varname> and
1094 <varname>EnvironmentFile=</varname>. In addition, variables listed
1095 in the section "Environment variables in spawned processes" in
1096 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1097 which are considered "static configuration", may be used (this
1098 includes e.g. <varname>$USER</varname>, but not
1099 <varname>$TERM</varname>).</para>
1100
1101 <para>Note that shell command lines are not directly supported. If
1102 shell command lines are to be used, they need to be passed
1103 explicitly to a shell implementation of some kind. Example:</para>
5008da1e 1104 <programlisting>ExecStart=sh -c 'dmesg | tac'</programlisting>
798d3a52
ZJS
1105
1106 <para>Example:</para>
1107
5008da1e 1108 <programlisting>ExecStart=echo one ; echo "two two"</programlisting>
798d3a52 1109
5008da1e 1110 <para>This will execute <command>echo</command> two times,
798d3a52
ZJS
1111 each time with one argument: <literal>one</literal> and
1112 <literal>two two</literal>, respectively. Because two commands are
1113 specified, <varname>Type=oneshot</varname> must be used.</para>
1114
1115 <para>Example:</para>
1116
5008da1e
ZJS
1117 <programlisting>ExecStart=echo / &gt;/dev/null &amp; \; \
1118ls</programlisting>
30d88d54 1119
5008da1e 1120 <para>This will execute <command>echo</command>
798d3a52
ZJS
1121 with five arguments: <literal>/</literal>,
1122 <literal>&gt;/dev/null</literal>,
1123 <literal>&amp;</literal>, <literal>;</literal>, and
5008da1e 1124 <literal>ls</literal>.</para>
798d3a52
ZJS
1125
1126 <table>
1127 <title>C escapes supported in command lines and environment variables</title>
1128 <tgroup cols='2'>
1129 <colspec colname='escape' />
1130 <colspec colname='meaning' />
1131 <thead>
1132 <row>
1133 <entry>Literal</entry>
1134 <entry>Actual value</entry>
1135 </row>
1136 </thead>
1137 <tbody>
1138 <row>
1139 <entry><literal>\a</literal></entry>
1140 <entry>bell</entry>
1141 </row>
1142 <row>
1143 <entry><literal>\b</literal></entry>
1144 <entry>backspace</entry>
1145 </row>
1146 <row>
1147 <entry><literal>\f</literal></entry>
1148 <entry>form feed</entry>
1149 </row>
1150 <row>
1151 <entry><literal>\n</literal></entry>
1152 <entry>newline</entry>
1153 </row>
1154 <row>
1155 <entry><literal>\r</literal></entry>
1156 <entry>carriage return</entry>
1157 </row>
1158 <row>
1159 <entry><literal>\t</literal></entry>
1160 <entry>tab</entry>
1161 </row>
1162 <row>
1163 <entry><literal>\v</literal></entry>
1164 <entry>vertical tab</entry>
1165 </row>
1166 <row>
1167 <entry><literal>\\</literal></entry>
1168 <entry>backslash</entry>
1169 </row>
1170 <row>
1171 <entry><literal>\"</literal></entry>
1172 <entry>double quotation mark</entry>
1173 </row>
1174 <row>
1175 <entry><literal>\'</literal></entry>
1176 <entry>single quotation mark</entry>
1177 </row>
1178 <row>
1179 <entry><literal>\s</literal></entry>
1180 <entry>space</entry>
1181 </row>
1182 <row>
1183 <entry><literal>\x<replaceable>xx</replaceable></literal></entry>
1184 <entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry>
1185 </row>
1186 <row>
1187 <entry><literal>\<replaceable>nnn</replaceable></literal></entry>
1188 <entry>character number <replaceable>nnn</replaceable> in octal encoding</entry>
1189 </row>
1190 </tbody>
1191 </tgroup>
1192 </table>
1193 </refsect1>
1194
1195 <refsect1>
1196 <title>Examples</title>
1197
1198 <example>
1199 <title>Simple service</title>
1200
1201 <para>The following unit file creates a service that will
1202 execute <filename>/usr/sbin/foo-daemon</filename>. Since no
1203 <varname>Type=</varname> is specified, the default
1204 <varname>Type=</varname><option>simple</option> will be assumed.
1205 systemd will assume the unit to be started immediately after the
1206 program has begun executing.</para>
1207
1208 <programlisting>[Unit]
d44efb62
CS
1209Description=Foo
1210
1211[Service]
1212ExecStart=/usr/sbin/foo-daemon
1213
1214[Install]
1215WantedBy=multi-user.target</programlisting>
1216
798d3a52
ZJS
1217 <para>Note that systemd assumes here that the process started by
1218 systemd will continue running until the service terminates. If
1219 the program daemonizes itself (i.e. forks), please use
1220 <varname>Type=</varname><option>forking</option> instead.</para>
1221
1222 <para>Since no <varname>ExecStop=</varname> was specified,
1223 systemd will send SIGTERM to all processes started from this
1224 service, and after a timeout also SIGKILL. This behavior can be
1225 modified, see
1226 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1227 for details.</para>
1228
1229 <para>Note that this unit type does not include any type of
1230 notification when a service has completed initialization. For
1231 this, you should use other unit types, such as
1232 <varname>Type=</varname><option>notify</option> if the service
1233 understands systemd's notification protocol,
1234 <varname>Type=</varname><option>forking</option> if the service
1235 can background itself or
1236 <varname>Type=</varname><option>dbus</option> if the unit
1237 acquires a DBus name once initialization is complete. See
1238 below.</para>
1239 </example>
1240
1241 <example>
1242 <title>Oneshot service</title>
1243
b938cb90 1244 <para>Sometimes, units should just execute an action without
798d3a52
ZJS
1245 keeping active processes, such as a filesystem check or a
1246 cleanup action on boot. For this,
1247 <varname>Type=</varname><option>oneshot</option> exists. Units
1248 of this type will wait until the process specified terminates
1249 and then fall back to being inactive. The following unit will
ff9b60f3 1250 perform a cleanup action:</para>
798d3a52
ZJS
1251
1252 <programlisting>[Unit]
d44efb62
CS
1253Description=Cleanup old Foo data
1254
1255[Service]
1256Type=oneshot
1257ExecStart=/usr/sbin/foo-cleanup
1258
1259[Install]
1260WantedBy=multi-user.target</programlisting>
1261
798d3a52 1262 <para>Note that systemd will consider the unit to be in the
b938cb90 1263 state "starting" until the program has terminated, so ordered
798d3a52 1264 dependencies will wait for the program to finish before starting
b938cb90
JE
1265 themselves. The unit will revert to the "inactive" state after
1266 the execution is done, never reaching the "active" state. That
798d3a52
ZJS
1267 means another request to start the unit will perform the action
1268 again.</para>
1269
1270 <para><varname>Type=</varname><option>oneshot</option> are the
1271 only service units that may have more than one
1272 <varname>ExecStart=</varname> specified. They will be executed
1273 in order until either they are all successful or one of them
1274 fails.</para>
1275 </example>
1276
1277 <example>
1278 <title>Stoppable oneshot service</title>
1279
1280 <para>Similarly to the oneshot services, there are sometimes
1281 units that need to execute a program to set up something and
1282 then execute another to shut it down, but no process remains
b938cb90 1283 active while they are considered "started". Network
798d3a52 1284 configuration can sometimes fall into this category. Another use
a8eaaee7 1285 case is if a oneshot service shall not be executed each time
798d3a52
ZJS
1286 when they are pulled in as a dependency, but only the first
1287 time.</para>
1288
1289 <para>For this, systemd knows the setting
1290 <varname>RemainAfterExit=</varname><option>yes</option>, which
1291 causes systemd to consider the unit to be active if the start
1292 action exited successfully. This directive can be used with all
1293 types, but is most useful with
1294 <varname>Type=</varname><option>oneshot</option> and
1295 <varname>Type=</varname><option>simple</option>. With
b938cb90 1296 <varname>Type=</varname><option>oneshot</option>, systemd waits
798d3a52
ZJS
1297 until the start action has completed before it considers the
1298 unit to be active, so dependencies start only after the start
1299 action has succeeded. With
b938cb90 1300 <varname>Type=</varname><option>simple</option>, dependencies
798d3a52
ZJS
1301 will start immediately after the start action has been
1302 dispatched. The following unit provides an example for a simple
1303 static firewall.</para>
1304
1305 <programlisting>[Unit]
d44efb62
CS
1306Description=Simple firewall
1307
1308[Service]
1309Type=oneshot
1310RemainAfterExit=yes
1311ExecStart=/usr/local/sbin/simple-firewall-start
1312ExecStop=/usr/local/sbin/simple-firewall-stop
1313
1314[Install]
1315WantedBy=multi-user.target</programlisting>
1316
798d3a52
ZJS
1317 <para>Since the unit is considered to be running after the start
1318 action has exited, invoking <command>systemctl start</command>
1319 on that unit again will cause no action to be taken.</para>
1320 </example>
1321
1322 <example>
1323 <title>Traditional forking services</title>
1324
1325 <para>Many traditional daemons/services background (i.e. fork,
1326 daemonize) themselves when starting. Set
1327 <varname>Type=</varname><option>forking</option> in the
1328 service's unit file to support this mode of operation. systemd
1329 will consider the service to be in the process of initialization
1330 while the original program is still running. Once it exits
1331 successfully and at least a process remains (and
1332 <varname>RemainAfterExit=</varname><option>no</option>), the
1333 service is considered started.</para>
1334
b938cb90 1335 <para>Often, a traditional daemon only consists of one process.
798d3a52
ZJS
1336 Therefore, if only one process is left after the original
1337 process terminates, systemd will consider that process the main
1338 process of the service. In that case, the
1339 <varname>$MAINPID</varname> variable will be available in
1340 <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
1341 etc.</para>
1342
1343 <para>In case more than one process remains, systemd will be
1344 unable to determine the main process, so it will not assume
1345 there is one. In that case, <varname>$MAINPID</varname> will not
1346 expand to anything. However, if the process decides to write a
1347 traditional PID file, systemd will be able to read the main PID
1348 from there. Please set <varname>PIDFile=</varname> accordingly.
1349 Note that the daemon should write that file before finishing
b938cb90 1350 with its initialization. Otherwise, systemd might try to read the
798d3a52
ZJS
1351 file before it exists.</para>
1352
1353 <para>The following example shows a simple daemon that forks and
1354 just starts one process in the background:</para>
1355
1356 <programlisting>[Unit]
d44efb62
CS
1357Description=Some simple daemon
1358
1359[Service]
1360Type=forking
1361ExecStart=/usr/sbin/my-simple-daemon -d
1362
1363[Install]
1364WantedBy=multi-user.target</programlisting>
1365
798d3a52
ZJS
1366 <para>Please see
1367 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1368 for details on how you can influence the way systemd terminates
1369 the service.</para>
1370 </example>
1371
1372 <example>
1373 <title>DBus services</title>
1374
1375 <para>For services that acquire a name on the DBus system bus,
1376 use <varname>Type=</varname><option>dbus</option> and set
1377 <varname>BusName=</varname> accordingly. The service should not
1378 fork (daemonize). systemd will consider the service to be
1379 initialized once the name has been acquired on the system bus.
1380 The following example shows a typical DBus service:</para>
1381
1382 <programlisting>[Unit]
d44efb62
CS
1383Description=Simple DBus service
1384
1385[Service]
1386Type=dbus
1387BusName=org.example.simple-dbus-service
1388ExecStart=/usr/sbin/simple-dbus-service
1389
1390[Install]
1391WantedBy=multi-user.target</programlisting>
1392
7ca41557 1393 <para>For <emphasis>bus-activatable</emphasis> services, do not
798d3a52
ZJS
1394 include a <literal>[Install]</literal> section in the systemd
1395 service file, but use the <varname>SystemdService=</varname>
1396 option in the corresponding DBus service file, for example
1397 (<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para>
d44efb62 1398
798d3a52 1399 <programlisting>[D-BUS Service]
d44efb62
CS
1400Name=org.example.simple-dbus-service
1401Exec=/usr/sbin/simple-dbus-service
1402User=root
1403SystemdService=simple-dbus-service.service</programlisting>
1404
798d3a52
ZJS
1405 <para>Please see
1406 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1407 for details on how you can influence the way systemd terminates
1408 the service.</para>
1409 </example>
1410
1411 <example>
1412 <title>Services that notify systemd about their initialization</title>
1413
1414 <para><varname>Type=</varname><option>simple</option> services
1415 are really easy to write, but have the major disadvantage of
1416 systemd not being able to tell when initialization of the given
1417 service is complete. For this reason, systemd supports a simple
1418 notification protocol that allows daemons to make systemd aware
1419 that they are done initializing. Use
1420 <varname>Type=</varname><option>notify</option> for this. A
1421 typical service file for such a daemon would look like
1422 this:</para>
1423
1424 <programlisting>[Unit]
d44efb62
CS
1425Description=Simple notifying service
1426
1427[Service]
1428Type=notify
1429ExecStart=/usr/sbin/simple-notifying-service
1430
1431[Install]
1432WantedBy=multi-user.target</programlisting>
1433
798d3a52 1434 <para>Note that the daemon has to support systemd's notification
7ca41557 1435 protocol, else systemd will think the service has not started yet
798d3a52
ZJS
1436 and kill it after a timeout. For an example of how to update
1437 daemons to support this protocol transparently, take a look at
1438 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
1439 systemd will consider the unit to be in the 'starting' state
1440 until a readiness notification has arrived.</para>
1441
1442 <para>Please see
1443 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1444 for details on how you can influence the way systemd terminates
1445 the service.</para>
1446 </example>
1447 </refsect1>
1448
1449 <refsect1>
1450 <title>See Also</title>
1451 <para>
1452 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1453 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
d1698b82 1454 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
798d3a52
ZJS
1455 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1456 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1457 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1458 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
438e6a48
LP
1459 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1460 <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
798d3a52
ZJS
1461 </para>
1462 </refsect1>
d1ab0ca0
LP
1463
1464</refentry>