1 <?xml version='
1.0'
?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM
"custom-entities.ent" >
9 This file is part of systemd.
11 Copyright 2010 Lennart Poettering
13 systemd is free software; you can redistribute it and/or modify it
14 under the terms of the GNU Lesser General Public License as published by
15 the Free Software Foundation; either version 2.1 of the License, or
16 (at your option) any later version.
18 systemd is distributed in the hope that it will be useful, but
19 WITHOUT ANY WARRANTY; without even the implied warranty of
20 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
21 Lesser General Public License for more details.
23 You should have received a copy of the GNU Lesser General Public License
24 along with systemd; If not, see <http://www.gnu.org/licenses/>.
27 <refentry id=
"systemd.service">
29 <title>systemd.service
</title>
30 <productname>systemd
</productname>
34 <contrib>Developer
</contrib>
35 <firstname>Lennart
</firstname>
36 <surname>Poettering
</surname>
37 <email>lennart@poettering.net
</email>
43 <refentrytitle>systemd.service
</refentrytitle>
44 <manvolnum>5</manvolnum>
48 <refname>systemd.service
</refname>
49 <refpurpose>Service unit configuration
</refpurpose>
53 <para><filename><replaceable>service
</replaceable>.service
</filename></para>
57 <title>Description
</title>
59 <para>A unit configuration file whose name ends in
60 <filename>.service
</filename> encodes information about a process
61 controlled and supervised by systemd.
</para>
63 <para>This man page lists the configuration options specific to
65 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
66 for the common options of all unit configuration files. The common
67 configuration items are configured in the generic
68 <literal>[Unit]
</literal> and
<literal>[Install]
</literal>
69 sections. The service specific configuration options are
70 configured in the
<literal>[Service]
</literal> section.
</para>
72 <para>Additional options are listed in
73 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
74 which define the execution environment the commands are executed
76 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
77 which define the way the processes of the service are terminated,
79 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
80 which configure resource control settings for the processes of the
83 <para>Unless
<varname>DefaultDependencies=
</varname> is set to
84 <option>false
</option>, service units will implicitly have
85 dependencies of type
<varname>Requires=
</varname> and
86 <varname>After=
</varname> on
<filename>basic.target
</filename> as
87 well as dependencies of type
<varname>Conflicts=
</varname> and
88 <varname>Before=
</varname> on
89 <filename>shutdown.target
</filename>. These ensure that normal
90 service units pull in basic system initialization, and are
91 terminated cleanly prior to system shutdown. Only services
92 involved with early boot or late system shutdown should disable
95 <para>If a service is requested under a certain name but no unit
96 configuration file is found, systemd looks for a SysV init script
97 by the same name (with the
<filename>.service
</filename> suffix
98 removed) and dynamically creates a service unit from that script.
99 This is useful for compatibility with SysV. Note that this
100 compatibility is quite comprehensive but not
100%. For details
101 about the incompatibilities, see the
<ulink
102 url=
"http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
103 with SysV
</ulink> document.
108 <title>Options
</title>
110 <para>Service files must include a
<literal>[Service]
</literal>
111 section, which carries information about the service and the
112 process it supervises. A number of options that may be used in
113 this section are shared with other unit types. These options are
115 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
117 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
118 The options specific to the
<literal>[Service]
</literal> section
119 of service units are the following:
</para>
121 <variablelist class='unit-directives'
>
123 <term><varname>Type=
</varname></term>
125 <listitem><para>Configures the process start-up type for this
127 <option>simple
</option>,
128 <option>forking
</option>,
129 <option>oneshot
</option>,
130 <option>dbus
</option>,
131 <option>notify
</option> or
132 <option>idle
</option>.
</para>
134 <para>If set to
<option>simple
</option> (the default if
135 neither
<varname>Type=
</varname> nor
136 <varname>BusName=
</varname>, but
<varname>ExecStart=
</varname>
137 are specified), it is expected that the process configured
138 with
<varname>ExecStart=
</varname> is the main process of the
139 service. In this mode, if the process offers functionality to
140 other processes on the system, its communication channels
141 should be installed before the daemon is started up (e.g.
142 sockets set up by systemd, via socket activation), as systemd
143 will immediately proceed starting follow-up units.
</para>
145 <para>If set to
<option>forking
</option>, it is expected that
146 the process configured with
<varname>ExecStart=
</varname> will
147 call
<function>fork()
</function> as part of its start-up. The
148 parent process is expected to exit when start-up is complete
149 and all communication channels are set up. The child continues
150 to run as the main daemon process. This is the behavior of
151 traditional UNIX daemons. If this setting is used, it is
152 recommended to also use the
<varname>PIDFile=
</varname>
153 option, so that systemd can identify the main process of the
154 daemon. systemd will proceed with starting follow-up units as
155 soon as the parent process exits.
</para>
157 <para>Behavior of
<option>oneshot
</option> is similar to
158 <option>simple
</option>; however, it is expected that the
159 process has to exit before systemd starts follow-up units.
160 <varname>RemainAfterExit=
</varname> is particularly useful for
161 this type of service. This is the implied default if neither
162 <varname>Type=
</varname> or
<varname>ExecStart=
</varname> are
165 <para>Behavior of
<option>dbus
</option> is similar to
166 <option>simple
</option>; however, it is expected that the
167 daemon acquires a name on the D-Bus bus, as configured by
168 <varname>BusName=
</varname>. systemd will proceed with
169 starting follow-up units after the D-Bus bus name has been
170 acquired. Service units with this option configured implicitly
171 gain dependencies on the
<filename>dbus.socket
</filename>
172 unit. This type is the default if
<varname>BusName=
</varname>
175 <para>Behavior of
<option>notify
</option> is similar to
176 <option>simple
</option>; however, it is expected that the
177 daemon sends a notification message via
178 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
179 or an equivalent call when it has finished starting up.
180 systemd will proceed with starting follow-up units after this
181 notification message has been sent. If this option is used,
182 <varname>NotifyAccess=
</varname> (see below) should be set to
183 open access to the notification socket provided by systemd. If
184 <varname>NotifyAccess=
</varname> is not set, it will be
185 implicitly set to
<option>main
</option>. Note that currently
186 <varname>Type=
</varname><option>notify
</option> will not work
187 if used in combination with
188 <varname>PrivateNetwork=
</varname><option>yes
</option>.
</para>
190 <para>Behavior of
<option>idle
</option> is very similar to
191 <option>simple
</option>; however, actual execution of the
192 service binary is delayed until all jobs are dispatched. This
193 may be used to avoid interleaving of output of shell services
194 with the status output on the console.
</para>
199 <term><varname>RemainAfterExit=
</varname></term>
201 <listitem><para>Takes a boolean value that specifies whether
202 the service shall be considered active even when all its
203 processes exited. Defaults to
<option>no
</option>.
</para>
208 <term><varname>GuessMainPID=
</varname></term>
210 <listitem><para>Takes a boolean value that specifies whether
211 systemd should try to guess the main PID of a service if it
212 cannot be determined reliably. This option is ignored unless
213 <option>Type=forking
</option> is set and
214 <option>PIDFile=
</option> is unset because for the other types
215 or with an explicitly configured PID file, the main PID is
216 always known. The guessing algorithm might come to incorrect
217 conclusions if a daemon consists of more than one process. If
218 the main PID cannot be determined, failure detection and
219 automatic restarting of a service will not work reliably.
220 Defaults to
<option>yes
</option>.
</para>
225 <term><varname>PIDFile=
</varname></term>
227 <listitem><para>Takes an absolute file name pointing to the
228 PID file of this daemon. Use of this option is recommended for
229 services where
<varname>Type=
</varname> is set to
230 <option>forking
</option>. systemd will read the PID of the
231 main process of the daemon after start-up of the service.
232 systemd will not write to the file configured here.
</para>
237 <term><varname>BusName=
</varname></term>
239 <listitem><para>Takes a D-Bus bus name that this service is
240 reachable as. This option is mandatory for services where
241 <varname>Type=
</varname> is set to
242 <option>dbus
</option>.
</para>
247 <term><varname>BusPolicy=
</varname></term>
249 <listitem><para>If specified, a custom
250 <ulink url=
"https://code.google.com/p/d-bus/">kdbus
</ulink>
251 endpoint will be created and installed as the default bus node
252 for the service. Such a custom endpoint can hold an own set of
253 policy rules that are enforced on top of the bus-wide ones.
254 The custom endpoint is named after the service it was created
255 for, and its node will be bind-mounted over the default bus
256 node location, so the service can only access the bus through
257 its own endpoint. Note that custom bus endpoints default to a
258 'deny all' policy. Hence, if at least one
259 <varname>BusPolicy=
</varname> directive is given, you have to
260 make sure to add explicit rules for everything the service
261 should be able to do.
</para>
262 <para>The value of this directive is comprised
263 of two parts; the bus name, and a verb to
264 specify to granted access, which is one of
265 <option>see
</option>,
266 <option>talk
</option>, or
267 <option>own
</option>.
268 <option>talk
</option> implies
269 <option>see
</option>, and
<option>own
</option>
270 implies both
<option>talk
</option> and
271 <option>see
</option>.
272 If multiple access levels are specified for the
273 same bus name, the most powerful one takes
276 <para>Examples:
</para>
277 <programlisting>BusPolicy=org.freedesktop.systemd1 talk
</programlisting>
278 <programlisting>BusPolicy=org.foo.bar see
</programlisting>
279 <para>This option is only available on kdbus enabled systems.
</para>
284 <term><varname>ExecStart=
</varname></term>
285 <listitem><para>Commands with their arguments that are
286 executed when this service is started. The value is split into
287 zero or more command lines is according to the rules described
288 below (see section
"Command Lines" below).
291 <para>When
<varname>Type
</varname> is not
292 <option>oneshot
</option>, only one command may and must be
293 given. When
<varname>Type=oneshot
</varname> is used, zero or
294 more commands may be specified. This can be specified by
295 providing multiple command lines in the same directive, or
296 alternatively, this directive may be specified more than once
297 with the same effect. If the empty string is assigned to this
298 option, the list of commands to start is reset, prior
299 assignments of this option will have no effect. If no
300 <varname>ExecStart=
</varname> is specified, then the service
301 must have
<varname>RemainAfterExit=yes
</varname> set.
</para>
303 <para>For each of the specified commands, the first argument
304 must be an absolute path to an executable. Optionally, if this
305 file name is prefixed with
<literal>@
</literal>, the second
306 token will be passed as
<literal>argv[
0]
</literal> to the
307 executed process, followed by the further arguments specified.
308 If the absolute filename is prefixed with
309 <literal>-
</literal>, an exit code of the command normally
310 considered a failure (i.e. non-zero exit status or abnormal
311 exit due to signal) is ignored and considered success. If both
312 <literal>-
</literal> and
<literal>@
</literal> are used, they
313 can appear in either order.
</para>
315 <para>If more than one command is specified, the commands are
316 invoked sequentially in the order they appear in the unit
317 file. If one of the commands fails (and is not prefixed with
318 <literal>-
</literal>), other lines are not executed, and the
319 unit is considered failed.
</para>
321 <para>Unless
<varname>Type=forking
</varname> is set, the
322 process started via this command line will be considered the
323 main process of the daemon.
</para>
328 <term><varname>ExecStartPre=
</varname></term>
329 <term><varname>ExecStartPost=
</varname></term>
330 <listitem><para>Additional commands that are executed before
331 or after the command in
<varname>ExecStart=
</varname>,
332 respectively. Syntax is the same as for
333 <varname>ExecStart=
</varname>, except that multiple command
334 lines are allowed and the commands are executed one after the
335 other, serially.
</para>
337 <para>If any of those commands (not prefixed with
338 <literal>-
</literal>) fail, the rest are not executed and the
339 unit is considered failed.
</para>
341 <para>Note that
<varname>ExecStartPre=
</varname> may not be
342 used to start long-running processes. All processes forked
343 off by processes invoked via
<varname>ExecStartPre=
</varname> will
344 be killed before the next service process is run.
</para>
349 <term><varname>ExecReload=
</varname></term>
350 <listitem><para>Commands to execute to trigger a configuration
351 reload in the service. This argument takes multiple command
352 lines, following the same scheme as described for
353 <varname>ExecStart=
</varname> above. Use of this setting is
354 optional. Specifier and environment variable substitution is
355 supported here following the same scheme as for
356 <varname>ExecStart=
</varname>.
</para>
358 <para>One additional, special environment variable is set: if
359 known,
<varname>$MAINPID
</varname> is set to the main process
360 of the daemon, and may be used for command lines like the
363 <programlisting>/bin/kill -HUP $MAINPID
</programlisting>
365 <para>Note however that reloading a daemon by sending a signal
366 (as with the example line above) is usually not a good choice,
367 because this is an asynchronous operation and hence not
368 suitable to order reloads of multiple services against each
369 other. It is strongly recommended to set
370 <varname>ExecReload=
</varname> to a command that not only
371 triggers a configuration reload of the daemon, but also
372 synchronously waits for it to complete.
</para>
377 <term><varname>ExecStop=
</varname></term>
378 <listitem><para>Commands to execute to stop the service
379 started via
<varname>ExecStart=
</varname>. This argument takes
380 multiple command lines, following the same scheme as described
381 for
<varname>ExecStart=
</varname> above. Use of this setting
382 is optional. After the commands configured in this option are
383 run, all processes remaining for a service are terminated
384 according to the
<varname>KillMode=
</varname> setting (see
385 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
386 If this option is not specified, the process is terminated by
387 sending the signal specified in
<varname>KillSignal=
</varname>
388 when service stop is requested. Specifier and environment
389 variable substitution is supported (including
390 <varname>$MAINPID
</varname>, see above).
</para>
392 <para>Note that it is usually not sufficient to specify a
393 command for this setting that only asks the service to
394 terminate (for example by queuing some form of termination
395 signal for it), but does not wait for it to do so. Since the
396 remaining processes of the services are killed using
397 <constant>SIGKILL
</constant> immediately after the command
398 exited this would not result in a clean stop. The specified
399 command should hence be a synchronous operation, not an
400 asynchronous one.
</para></listitem>
404 <term><varname>ExecStopPost=
</varname></term>
405 <listitem><para>Additional commands that are executed after
406 the service was stopped. This includes cases where the
407 commands configured in
<varname>ExecStop=
</varname> were used,
408 where the service does not have any
409 <varname>ExecStop=
</varname> defined, or where the service
410 exited unexpectedly. This argument takes multiple command
411 lines, following the same scheme as described for
412 <varname>ExecStart
</varname>. Use of these settings is
413 optional. Specifier and environment variable substitution is
414 supported.
</para></listitem>
418 <term><varname>RestartSec=
</varname></term>
419 <listitem><para>Configures the time to sleep before restarting
420 a service (as configured with
<varname>Restart=
</varname>).
421 Takes a unit-less value in seconds, or a time span value such
422 as
"5min 20s". Defaults to
100ms.
</para></listitem>
426 <term><varname>TimeoutStartSec=
</varname></term>
427 <listitem><para>Configures the time to wait for start-up. If a
428 daemon service does not signal start-up completion within the
429 configured time, the service will be considered failed and
430 will be shut down again. Takes a unit-less value in seconds,
431 or a time span value such as
"5min 20s". Pass
432 <literal>0</literal> to disable the timeout logic. Defaults to
433 <varname>DefaultTimeoutStartSec=
</varname> from the manager
434 configuration file, except when
435 <varname>Type=oneshot
</varname> is used, in which case the
436 timeout is disabled by default (see
437 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
442 <term><varname>TimeoutStopSec=
</varname></term>
443 <listitem><para>Configures the time to wait for stop. If a
444 service is asked to stop, but does not terminate in the
445 specified time, it will be terminated forcibly via
446 <constant>SIGTERM
</constant>, and after another timeout of
447 equal duration with
<constant>SIGKILL
</constant> (see
448 <varname>KillMode=
</varname> in
449 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
450 Takes a unit-less value in seconds, or a time span value such
451 as
"5min 20s". Pass
<literal>0</literal> to disable the
452 timeout logic. Defaults to
453 <varname>DefaultTimeoutStopSec=
</varname> from the manager
454 configuration file (see
455 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
460 <term><varname>TimeoutSec=
</varname></term>
461 <listitem><para>A shorthand for configuring both
462 <varname>TimeoutStartSec=
</varname> and
463 <varname>TimeoutStopSec=
</varname> to the specified value.
468 <term><varname>WatchdogSec=
</varname></term>
469 <listitem><para>Configures the watchdog timeout for a service.
470 The watchdog is activated when the start-up is completed. The
472 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
473 regularly with
<literal>WATCHDOG=
1</literal> (i.e. the
474 "keep-alive ping"). If the time between two such calls is
475 larger than the configured time, then the service is placed in
476 a failed state and it will be terminated with
477 <varname>SIGABRT
</varname>. By setting
478 <varname>Restart=
</varname> to
<option>on-failure
</option> or
479 <option>always
</option>, the service will be automatically
480 restarted. The time configured here will be passed to the
481 executed service process in the
482 <varname>WATCHDOG_USEC=
</varname> environment variable. This
483 allows daemons to automatically enable the keep-alive pinging
484 logic if watchdog support is enabled for the service. If this
485 option is used,
<varname>NotifyAccess=
</varname> (see below)
486 should be set to open access to the notification socket
487 provided by systemd. If
<varname>NotifyAccess=
</varname> is
488 not set, it will be implicitly set to
<option>main
</option>.
489 Defaults to
0, which disables this feature.
</para></listitem>
493 <term><varname>Restart=
</varname></term>
494 <listitem><para>Configures whether the service shall be
495 restarted when the service process exits, is killed, or a
496 timeout is reached. The service process may be the main
497 service process, but it may also be one of the processes
498 specified with
<varname>ExecStartPre=
</varname>,
499 <varname>ExecStartPost=
</varname>,
500 <varname>ExecStop=
</varname>,
501 <varname>ExecStopPost=
</varname>, or
502 <varname>ExecReload=
</varname>. When the death of the process
503 is a result of systemd operation (e.g. service stop or
504 restart), the service will not be restarted. Timeouts include
505 missing the watchdog
"keep-alive ping" deadline and a service
506 start, reload, and stop operation timeouts.
</para>
510 <option>on-success
</option>,
511 <option>on-failure
</option>,
512 <option>on-abnormal
</option>,
513 <option>on-watchdog
</option>,
514 <option>on-abort
</option>, or
515 <option>always
</option>.
516 If set to
<option>no
</option> (the default), the service will
517 not be restarted. If set to
<option>on-success
</option>, it
518 will be restarted only when the service process exits cleanly.
519 In this context, a clean exit means an exit code of
0, or one
521 <constant>SIGHUP
</constant>,
522 <constant>SIGINT
</constant>,
523 <constant>SIGTERM
</constant> or
524 <constant>SIGPIPE
</constant>, and
525 additionally, exit statuses and signals specified in
526 <varname>SuccessExitStatus=
</varname>. If set to
527 <option>on-failure
</option>, the service will be restarted
528 when the process exits with a non-zero exit code, is
529 terminated by a signal (including on core dump, but excluding
530 the aforementioned four signals), when an operation (such as
531 service reload) times out, and when the configured watchdog
532 timeout is triggered. If set to
<option>on-abnormal
</option>,
533 the service will be restarted when the process is terminated
534 by a signal (including on core dump, excluding the
535 aforementioned four signals), when an operation times out, or
536 when the watchdog timeout is triggered. If set to
537 <option>on-abort
</option>, the service will be restarted only
538 if the service process exits due to an uncaught signal not
539 specified as a clean exit status. If set to
540 <option>on-watchdog
</option>, the service will be restarted
541 only if the watchdog timeout for the service expires. If set
542 to
<option>always
</option>, the service will be restarted
543 regardless of whether it exited cleanly or not, got terminated
544 abnormally by a signal, or hit a timeout.
</para>
547 <title>Exit causes and the effect of the
<varname>Restart=
</varname> settings on them
</title>
550 <colspec colname='path'
/>
551 <colspec colname='expl'
/>
554 <entry>Restart settings/Exit causes
</entry>
555 <entry><option>no
</option></entry>
556 <entry><option>always
</option></entry>
557 <entry><option>on-success
</option></entry>
558 <entry><option>on-failure
</option></entry>
559 <entry><option>on-abnormal
</option></entry>
560 <entry><option>on-abort
</option></entry>
561 <entry><option>on-watchdog
</option></entry>
566 <entry>Clean exit code or signal
</entry>
576 <entry>Unclean exit code
</entry>
586 <entry>Unclean signal
</entry>
596 <entry>Timeout
</entry>
606 <entry>Watchdog
</entry>
619 <para>As exceptions to the setting above the service will not
620 be restarted if the exit code or signal is specified in
621 <varname>RestartPreventExitStatus=
</varname> (see below).
622 Also, the services will always be restarted if the exit code
623 or signal is specified in
624 <varname>RestartForceExitStatus=
</varname> (see below).
</para>
626 <para>Setting this to
<option>on-failure
</option> is the
627 recommended choice for long-running services, in order to
628 increase reliability by attempting automatic recovery from
629 errors. For services that shall be able to terminate on their
630 own choice (and avoid immediate restarting),
631 <option>on-abnormal
</option> is an alternative choice.
</para>
636 <term><varname>SuccessExitStatus=
</varname></term>
637 <listitem><para>Takes a list of exit status definitions that
638 when returned by the main service process will be considered
639 successful termination, in addition to the normal successful
640 exit code
0 and the signals
<constant>SIGHUP
</constant>,
641 <constant>SIGINT
</constant>,
<constant>SIGTERM
</constant>, and
642 <constant>SIGPIPE
</constant>. Exit status definitions can
643 either be numeric exit codes or termination signal names,
644 separated by spaces. For example:
645 <programlisting>SuccessExitStatus=
1 2 8
646 SIGKILL
</programlisting> ensures that exit codes
1,
2,
8 and
647 the termination signal
<constant>SIGKILL
</constant> are
648 considered clean service terminations.
651 <para>Note that if a process has a signal handler installed
653 <citerefentry><refentrytitle>_exit
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
654 in response to a signal, the information about the signal is
655 lost. Programs should instead perform cleanup and kill
656 themselves with the same signal instead. See
657 <ulink url=
"http://www.cons.org/cracauer/sigint.html">Proper
658 handling of SIGINT/SIGQUIT — How to be a proper
659 program
</ulink>.
</para>
661 <para>This option may appear more than once, in which case the
662 list of successful exit statuses is merged. If the empty
663 string is assigned to this option, the list is reset, all
664 prior assignments of this option will have no
665 effect.
</para></listitem>
669 <term><varname>RestartPreventExitStatus=
</varname></term>
670 <listitem><para>Takes a list of exit status definitions that
671 when returned by the main service process will prevent
672 automatic service restarts, regardless of the restart setting
673 configured with
<varname>Restart=
</varname>. Exit status
674 definitions can either be numeric exit codes or termination
675 signal names, and are separated by spaces. Defaults to the
676 empty list, so that, by default, no exit status is excluded
677 from the configured restart logic. For example:
678 <programlisting>RestartPreventExitStatus=
1 6
679 SIGABRT
</programlisting> ensures that exit codes
1 and
6 and
680 the termination signal
<constant>SIGABRT
</constant> will not
681 result in automatic service restarting. This option may appear
682 more than once, in which case the list of restart-preventing
683 statuses is merged. If the empty string is assigned to this
684 option, the list is reset and all prior assignments of this
685 option will have no effect.
</para></listitem>
689 <term><varname>RestartForceExitStatus=
</varname></term>
690 <listitem><para>Takes a list of exit status definitions that
691 when returned by the main service process will force automatic
692 service restarts, regardless of the restart setting configured
693 with
<varname>Restart=
</varname>. The argument format is
695 <varname>RestartPreventExitStatus=
</varname>.
</para></listitem>
699 <term><varname>PermissionsStartOnly=
</varname></term>
700 <listitem><para>Takes a boolean argument. If true, the
701 permission-related execution options, as configured with
702 <varname>User=
</varname> and similar options (see
703 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
704 for more information), are only applied to the process started
706 <varname>ExecStart=
</varname>, and not to the various other
707 <varname>ExecStartPre=
</varname>,
708 <varname>ExecStartPost=
</varname>,
709 <varname>ExecReload=
</varname>,
710 <varname>ExecStop=
</varname>, and
711 <varname>ExecStopPost=
</varname>
712 commands. If false, the setting is applied to all configured
713 commands the same way. Defaults to false.
</para></listitem>
717 <term><varname>RootDirectoryStartOnly=
</varname></term>
718 <listitem><para>Takes a boolean argument. If true, the root
719 directory, as configured with the
720 <varname>RootDirectory=
</varname> option (see
721 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
722 for more information), is only applied to the process started
723 with
<varname>ExecStart=
</varname>, and not to the various
724 other
<varname>ExecStartPre=
</varname>,
725 <varname>ExecStartPost=
</varname>,
726 <varname>ExecReload=
</varname>,
<varname>ExecStop=
</varname>,
727 and
<varname>ExecStopPost=
</varname> commands. If false, the
728 setting is applied to all configured commands the same way.
729 Defaults to false.
</para></listitem>
733 <term><varname>NonBlocking=
</varname></term>
734 <listitem><para>Set the
<constant>O_NONBLOCK
</constant> flag
735 for all file descriptors passed via socket-based activation.
736 If true, all file descriptors
>=
3 (i.e. all except stdin,
737 stdout, and stderr) will have the
738 <constant>O_NONBLOCK
</constant> flag set and hence are in
739 non-blocking mode. This option is only useful in conjunction
740 with a socket unit, as described in
741 <citerefentry><refentrytitle>systemd.socket
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
742 Defaults to false.
</para></listitem>
746 <term><varname>NotifyAccess=
</varname></term>
747 <listitem><para>Controls access to the service status
748 notification socket, as accessible via the
749 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
750 call. Takes one of
<option>none
</option> (the default),
751 <option>main
</option> or
<option>all
</option>. If
752 <option>none
</option>, no daemon status updates are accepted
753 from the service processes, all status update messages are
754 ignored. If
<option>main
</option>, only service updates sent
755 from the main process of the service are accepted. If
756 <option>all
</option>, all services updates from all members of
757 the service's control group are accepted. This option should
758 be set to open access to the notification socket when using
759 <varname>Type=notify
</varname> or
760 <varname>WatchdogSec=
</varname> (see above). If those options
761 are used but
<varname>NotifyAccess=
</varname> is not
762 configured, it will be implicitly set to
763 <option>main
</option>.
</para></listitem>
767 <term><varname>Sockets=
</varname></term>
768 <listitem><para>Specifies the name of the socket units this
769 service shall inherit socket file descriptors from when the
770 service is started. Normally it should not be necessary to use
771 this setting as all socket file descriptors whose unit shares
772 the same name as the service (subject to the different unit
773 name suffix of course) are passed to the spawned
776 <para>Note that the same socket file descriptors may be passed
777 to multiple processes simultaneously. Also note that a
778 different service may be activated on incoming socket traffic
779 than the one which is ultimately configured to inherit the
780 socket file descriptors. Or in other words: the
781 <varname>Service=
</varname> setting of
782 <filename>.socket
</filename> units does not have to match the
783 inverse of the
<varname>Sockets=
</varname> setting of the
784 <filename>.service
</filename> it refers to.
</para>
786 <para>This option may appear more than once, in which case the
787 list of socket units is merged. If the empty string is
788 assigned to this option, the list of sockets is reset, and all
789 prior uses of this setting will have no
790 effect.
</para></listitem>
794 <term><varname>StartLimitInterval=
</varname></term>
795 <term><varname>StartLimitBurst=
</varname></term>
797 <listitem><para>Configure service start rate limiting. By
798 default, services which are started more than
5 times within
799 10 seconds are not permitted to start any more times until the
800 10 second interval ends. With these two options, this rate
801 limiting may be modified. Use
802 <varname>StartLimitInterval=
</varname> to configure the
803 checking interval (defaults to
804 <varname>DefaultStartLimitInterval=
</varname> in manager
805 configuration file, set to
0 to disable any kind of rate
806 limiting). Use
<varname>StartLimitBurst=
</varname> to
807 configure how many starts per interval are allowed (defaults
808 to
<varname>DefaultStartLimitBurst=
</varname> in manager
809 configuration file). These configuration options are
810 particularly useful in conjunction with
811 <varname>Restart=
</varname>; however, they apply to all kinds
812 of starts (including manual), not just those triggered by the
813 <varname>Restart=
</varname> logic. Note that units which are
814 configured for
<varname>Restart=
</varname> and which reach the
815 start limit are not attempted to be restarted anymore;
816 however, they may still be restarted manually at a later
817 point, from which point on, the restart logic is again
818 activated. Note that
<command>systemctl reset-failed
</command>
819 will cause the restart rate counter for a service to be
820 flushed, which is useful if the administrator wants to
821 manually start a service and the start limit interferes with
822 that.
</para></listitem>
826 <term><varname>StartLimitAction=
</varname></term>
828 <listitem><para>Configure the action to take if the rate limit
829 configured with
<varname>StartLimitInterval=
</varname> and
830 <varname>StartLimitBurst=
</varname> is hit. Takes one of
831 <option>none
</option>,
832 <option>reboot
</option>,
833 <option>reboot-force
</option>,
834 <option>reboot-immediate
</option>,
835 <option>poweroff
</option>,
836 <option>poweroff-force
</option> or
837 <option>poweroff-immediate
</option>. If
838 <option>none
</option> is set, hitting the rate limit will
839 trigger no action besides that the start will not be
840 permitted.
<option>reboot
</option> causes a reboot following
841 the normal shutdown procedure (i.e. equivalent to
842 <command>systemctl reboot
</command>).
843 <option>reboot-force
</option> causes a forced reboot which
844 will terminate all processes forcibly but should cause no
845 dirty file systems on reboot (i.e. equivalent to
846 <command>systemctl reboot -f
</command>) and
847 <option>reboot-immediate
</option> causes immediate execution
849 <citerefentry><refentrytitle>reboot
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
850 system call, which might result in data loss. Similar,
851 <option>poweroff
</option>,
<option>poweroff-force
</option>,
852 <option>poweroff-immediate
</option> have the effect of
853 powering down the system with similar semantics. Defaults to
854 <option>none
</option>.
</para></listitem>
858 <term><varname>FailureAction=
</varname></term>
859 <listitem><para>Configure the action to take when the service
860 enters a failed state. Takes the same values as
861 <varname>StartLimitAction=
</varname> and executes the same
862 actions. Defaults to
<option>none
</option>.
</para></listitem>
866 <term><varname>RebootArgument=
</varname></term>
867 <listitem><para>Configure the optional argument for the
868 <citerefentry><refentrytitle>reboot
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
869 system call if
<varname>StartLimitAction=
</varname> or
870 <varname>FailureAction=
</varname> is a reboot action. This
871 works just like the optional argument to
<command>systemctl
872 reboot
</command> command.
</para></listitem>
876 <term><varname>FileDescriptorStoreMax=
</varname></term>
877 <listitem><para>Configure how many file descriptors may be
878 stored in the service manager for the service using
879 <citerefentry><refentrytitle>sd_pid_notify_with_fds
</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
880 <literal>FDSTORE=
1</literal> messages. This is useful for
881 implementing service restart schemes where the state is
882 serialized to
<filename>/run
</filename> and the file
883 descriptors passed to the service manager, to allow restarts
884 without losing state. Defaults to
0, i.e. no file descriptors
885 may be stored in the service manager by default. All file
886 descriptors passed to the service manager from a specific
887 service are passed back to the service's main process on the
888 next service restart. Any file descriptors passed to the
889 service manager are automatically closed when POLLHUP or
890 POLLERR is seen on them, or when the service is fully stopped
891 and no job queued or being executed for it.
</para></listitem>
897 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
899 <citerefentry><refentrytitle>systemd.kill
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
900 for more settings.
</para>
905 <title>Command lines
</title>
907 <para>This section describes command line parsing and
908 variable and specifier substitutions for
909 <varname>ExecStart=
</varname>,
910 <varname>ExecStartPre=
</varname>,
911 <varname>ExecStartPost=
</varname>,
912 <varname>ExecReload=
</varname>,
913 <varname>ExecStop=
</varname>, and
914 <varname>ExecStopPost=
</varname> options.
</para>
916 <para>Multiple command lines may be concatenated in a single
917 directive by separating them with semicolons (these semicolons
918 must be passed as separate words). Lone semicolons may be escaped
919 as
<literal>\;
</literal>.
</para>
921 <para>Each command line is split on whitespace, with the first
922 item being the command to execute, and the subsequent items being
923 the arguments. Double quotes (
"...") and single quotes ('...') may
924 be used, in which case everything until the next matching quote
925 becomes part of the same argument. C-style escapes are also
926 supported, see table below. Quotes themselves are removed after
927 parsing and escape sequences substituted. In addition, a trailing
928 backslash (
<literal>\
</literal>) may be used to merge lines.
931 <para>This syntax is intended to be very similar to shell syntax,
932 but only the meta-characters and expansions described in the
933 following paragraphs are understood. Specifically, redirection
935 <literal><</literal>,
936 <literal><<</literal>,
937 <literal>></literal>, and
938 <literal>>></literal>, pipes using
939 <literal>|
</literal>, running programs in the background using
940 <literal>&</literal>, and
<emphasis>other elements of shell
941 syntax are not supported
</emphasis>.
</para>
943 <para>The command to execute must an absolute path name. It may
944 contain spaces, but control characters are not allowed.
</para>
946 <para>The command line accepts
<literal>%
</literal> specifiers as
948 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
949 Note that the first argument of the command line (i.e. the program
950 to execute) may not include specifiers.
</para>
952 <para>Basic environment variable substitution is supported. Use
953 <literal>${FOO}
</literal> as part of a word, or as a word of its
954 own, on the command line, in which case it will be replaced by the
955 value of the environment variable including all whitespace it
956 contains, resulting in a single argument. Use
957 <literal>$FOO
</literal> as a separate word on the command line, in
958 which case it will be replaced by the value of the environment
959 variable split at whitespace resulting in zero or more arguments.
960 For this type of expansion, quotes and respected when splitting
961 into words, and afterwards removed.
</para>
963 <para>Example:
</para>
965 <programlisting>Environment=
"ONE=one" 'TWO=two two'
966 ExecStart=/bin/echo $ONE $TWO ${TWO}
</programlisting>
968 <para>This will execute
<command>/bin/echo
</command> with four
969 arguments:
<literal>one
</literal>,
<literal>two
</literal>,
970 <literal>two
</literal>, and
<literal>two two
</literal>.
</para>
972 <para>Example:
</para>
973 <programlisting>Environment=ONE='one'
"TWO='two two' too" THREE=
974 ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
975 ExecStart=/bin/echo $ONE $TWO $THREE
</programlisting>
976 <para>This results in
<filename>echo
</filename> being
977 called twice, the first time with arguments
978 <literal>'one'
</literal>,
979 <literal>'two two' too
</literal>,
<literal></literal>,
980 and the second time with arguments
981 <literal>one
</literal>,
<literal>two two
</literal>,
982 <literal>too
</literal>.
985 <para>To pass a literal dollar sign, use
<literal>$$
</literal>.
986 Variables whose value is not known at expansion time are treated
987 as empty strings. Note that the first argument (i.e. the program
988 to execute) may not be a variable.
</para>
990 <para>Variables to be used in this fashion may be defined through
991 <varname>Environment=
</varname> and
992 <varname>EnvironmentFile=
</varname>. In addition, variables listed
993 in the section
"Environment variables in spawned processes" in
994 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
995 which are considered
"static configuration", may be used (this
996 includes e.g.
<varname>$USER
</varname>, but not
997 <varname>$TERM
</varname>).
</para>
999 <para>Note that shell command lines are not directly supported. If
1000 shell command lines are to be used, they need to be passed
1001 explicitly to a shell implementation of some kind. Example:
</para>
1002 <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'
</programlisting>
1004 <para>Example:
</para>
1006 <programlisting>ExecStart=/bin/echo one ; /bin/echo
"two two"</programlisting>
1008 <para>This will execute
<command>/bin/echo
</command> two times,
1009 each time with one argument:
<literal>one
</literal> and
1010 <literal>two two
</literal>, respectively. Because two commands are
1011 specified,
<varname>Type=oneshot
</varname> must be used.
</para>
1013 <para>Example:
</para>
1015 <programlisting>ExecStart=/bin/echo /
>/dev/null
& \; \
1016 /bin/ls
</programlisting>
1018 <para>This will execute
<command>/bin/echo
</command>
1019 with five arguments:
<literal>/
</literal>,
1020 <literal>>/dev/null
</literal>,
1021 <literal>&</literal>,
<literal>;
</literal>, and
1022 <literal>/bin/ls
</literal>.
</para>
1025 <title>C escapes supported in command lines and environment variables
</title>
1027 <colspec colname='escape'
/>
1028 <colspec colname='meaning'
/>
1031 <entry>Literal
</entry>
1032 <entry>Actual value
</entry>
1037 <entry><literal>\a
</literal></entry>
1041 <entry><literal>\b
</literal></entry>
1042 <entry>backspace
</entry>
1045 <entry><literal>\f
</literal></entry>
1046 <entry>form feed
</entry>
1049 <entry><literal>\n
</literal></entry>
1050 <entry>newline
</entry>
1053 <entry><literal>\r
</literal></entry>
1054 <entry>carriage return
</entry>
1057 <entry><literal>\t
</literal></entry>
1061 <entry><literal>\v
</literal></entry>
1062 <entry>vertical tab
</entry>
1065 <entry><literal>\\
</literal></entry>
1066 <entry>backslash
</entry>
1069 <entry><literal>\
"</literal></entry>
1070 <entry>double quotation mark</entry>
1073 <entry><literal>\'</literal></entry>
1074 <entry>single quotation mark</entry>
1077 <entry><literal>\s</literal></entry>
1078 <entry>space</entry>
1081 <entry><literal>\x<replaceable>xx</replaceable></literal></entry>
1082 <entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry>
1085 <entry><literal>\<replaceable>nnn</replaceable></literal></entry>
1086 <entry>character number <replaceable>nnn</replaceable> in octal encoding</entry>
1094 <title>Examples</title>
1097 <title>Simple service</title>
1099 <para>The following unit file creates a service that will
1100 execute <filename>/usr/sbin/foo-daemon</filename>. Since no
1101 <varname>Type=</varname> is specified, the default
1102 <varname>Type=</varname><option>simple</option> will be assumed.
1103 systemd will assume the unit to be started immediately after the
1104 program has begun executing.</para>
1106 <programlisting>[Unit]
1110 ExecStart=/usr/sbin/foo-daemon
1113 WantedBy=multi-user.target</programlisting>
1115 <para>Note that systemd assumes here that the process started by
1116 systemd will continue running until the service terminates. If
1117 the program daemonizes itself (i.e. forks), please use
1118 <varname>Type=</varname><option>forking</option> instead.</para>
1120 <para>Since no <varname>ExecStop=</varname> was specified,
1121 systemd will send SIGTERM to all processes started from this
1122 service, and after a timeout also SIGKILL. This behavior can be
1124 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1127 <para>Note that this unit type does not include any type of
1128 notification when a service has completed initialization. For
1129 this, you should use other unit types, such as
1130 <varname>Type=</varname><option>notify</option> if the service
1131 understands systemd's notification protocol,
1132 <varname>Type=</varname><option>forking</option> if the service
1133 can background itself or
1134 <varname>Type=</varname><option>dbus</option> if the unit
1135 acquires a DBus name once initialization is complete. See
1140 <title>Oneshot service</title>
1142 <para>Sometimes units should just execute an action without
1143 keeping active processes, such as a filesystem check or a
1144 cleanup action on boot. For this,
1145 <varname>Type=</varname><option>oneshot</option> exists. Units
1146 of this type will wait until the process specified terminates
1147 and then fall back to being inactive. The following unit will
1148 perform a cleanup action:</para>
1150 <programlisting>[Unit]
1151 Description=Cleanup old Foo data
1155 ExecStart=/usr/sbin/foo-cleanup
1158 WantedBy=multi-user.target</programlisting>
1160 <para>Note that systemd will consider the unit to be in the
1161 state 'starting' until the program has terminated, so ordered
1162 dependencies will wait for the program to finish before starting
1163 themselves. The unit will revert to the 'inactive' state after
1164 the execution is done, never reaching the 'active' state. That
1165 means another request to start the unit will perform the action
1168 <para><varname>Type=</varname><option>oneshot</option> are the
1169 only service units that may have more than one
1170 <varname>ExecStart=</varname> specified. They will be executed
1171 in order until either they are all successful or one of them
1176 <title>Stoppable oneshot service</title>
1178 <para>Similarly to the oneshot services, there are sometimes
1179 units that need to execute a program to set up something and
1180 then execute another to shut it down, but no process remains
1181 active while they are considered 'started'. Network
1182 configuration can sometimes fall into this category. Another use
1183 case is if a oneshot service shall not be executed a each time
1184 when they are pulled in as a dependency, but only the first
1187 <para>For this, systemd knows the setting
1188 <varname>RemainAfterExit=</varname><option>yes</option>, which
1189 causes systemd to consider the unit to be active if the start
1190 action exited successfully. This directive can be used with all
1191 types, but is most useful with
1192 <varname>Type=</varname><option>oneshot</option> and
1193 <varname>Type=</varname><option>simple</option>. With
1194 <varname>Type=</varname><option>oneshot</option> systemd waits
1195 until the start action has completed before it considers the
1196 unit to be active, so dependencies start only after the start
1197 action has succeeded. With
1198 <varname>Type=</varname><option>simple</option> dependencies
1199 will start immediately after the start action has been
1200 dispatched. The following unit provides an example for a simple
1201 static firewall.</para>
1203 <programlisting>[Unit]
1204 Description=Simple firewall
1209 ExecStart=/usr/local/sbin/simple-firewall-start
1210 ExecStop=/usr/local/sbin/simple-firewall-stop
1213 WantedBy=multi-user.target</programlisting>
1215 <para>Since the unit is considered to be running after the start
1216 action has exited, invoking <command>systemctl start</command>
1217 on that unit again will cause no action to be taken.</para>
1221 <title>Traditional forking services</title>
1223 <para>Many traditional daemons/services background (i.e. fork,
1224 daemonize) themselves when starting. Set
1225 <varname>Type=</varname><option>forking</option> in the
1226 service's unit file to support this mode of operation. systemd
1227 will consider the service to be in the process of initialization
1228 while the original program is still running. Once it exits
1229 successfully and at least a process remains (and
1230 <varname>RemainAfterExit=</varname><option>no</option>), the
1231 service is considered started.</para>
1233 <para>Often a traditional daemon only consists of one process.
1234 Therefore, if only one process is left after the original
1235 process terminates, systemd will consider that process the main
1236 process of the service. In that case, the
1237 <varname>$MAINPID</varname> variable will be available in
1238 <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
1241 <para>In case more than one process remains, systemd will be
1242 unable to determine the main process, so it will not assume
1243 there is one. In that case, <varname>$MAINPID</varname> will not
1244 expand to anything. However, if the process decides to write a
1245 traditional PID file, systemd will be able to read the main PID
1246 from there. Please set <varname>PIDFile=</varname> accordingly.
1247 Note that the daemon should write that file before finishing
1248 with its initialization, otherwise systemd might try to read the
1249 file before it exists.</para>
1251 <para>The following example shows a simple daemon that forks and
1252 just starts one process in the background:</para>
1254 <programlisting>[Unit]
1255 Description=Some simple daemon
1259 ExecStart=/usr/sbin/my-simple-daemon -d
1262 WantedBy=multi-user.target</programlisting>
1265 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1266 for details on how you can influence the way systemd terminates
1271 <title>DBus services</title>
1273 <para>For services that acquire a name on the DBus system bus,
1274 use <varname>Type=</varname><option>dbus</option> and set
1275 <varname>BusName=</varname> accordingly. The service should not
1276 fork (daemonize). systemd will consider the service to be
1277 initialized once the name has been acquired on the system bus.
1278 The following example shows a typical DBus service:</para>
1280 <programlisting>[Unit]
1281 Description=Simple DBus service
1285 BusName=org.example.simple-dbus-service
1286 ExecStart=/usr/sbin/simple-dbus-service
1289 WantedBy=multi-user.target</programlisting>
1291 <para>For <emphasis>bus-activatable</emphasis> services, don't
1292 include a <literal>[Install]</literal> section in the systemd
1293 service file, but use the <varname>SystemdService=</varname>
1294 option in the corresponding DBus service file, for example
1295 (<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para>
1297 <programlisting>[D-BUS Service]
1298 Name=org.example.simple-dbus-service
1299 Exec=/usr/sbin/simple-dbus-service
1301 SystemdService=simple-dbus-service.service</programlisting>
1304 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1305 for details on how you can influence the way systemd terminates
1310 <title>Services that notify systemd about their initialization</title>
1312 <para><varname>Type=</varname><option>simple</option> services
1313 are really easy to write, but have the major disadvantage of
1314 systemd not being able to tell when initialization of the given
1315 service is complete. For this reason, systemd supports a simple
1316 notification protocol that allows daemons to make systemd aware
1317 that they are done initializing. Use
1318 <varname>Type=</varname><option>notify</option> for this. A
1319 typical service file for such a daemon would look like
1322 <programlisting>[Unit]
1323 Description=Simple notifying service
1327 ExecStart=/usr/sbin/simple-notifying-service
1330 WantedBy=multi-user.target</programlisting>
1332 <para>Note that the daemon has to support systemd's notification
1333 protocol, else systemd will think the service hasn't started yet
1334 and kill it after a timeout. For an example of how to update
1335 daemons to support this protocol transparently, take a look at
1336 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
1337 systemd will consider the unit to be in the 'starting' state
1338 until a readiness notification has arrived.</para>
1341 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1342 for details on how you can influence the way systemd terminates
1348 <title>See Also</title>
1350 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1351 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1352 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1353 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1354 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1355 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1356 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>