]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.service.xml
man/service: document behaviour on failure
[thirdparty/systemd.git] / man / systemd.service.xml
1 <?xml version='1.0'?> <!--*-nxml-*-->
2 <?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"?>
3 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
4 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
5
6 <!--
7 This file is part of systemd.
8
9 Copyright 2010 Lennart Poettering
10
11 systemd is free software; you can redistribute it and/or modify it
12 under the terms of the GNU Lesser General Public License as published by
13 the Free Software Foundation; either version 2.1 of the License, or
14 (at your option) any later version.
15
16 systemd is distributed in the hope that it will be useful, but
17 WITHOUT ANY WARRANTY; without even the implied warranty of
18 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
19 Lesser General Public License for more details.
20
21 You should have received a copy of the GNU Lesser General Public License
22 along with systemd; If not, see <http://www.gnu.org/licenses/>.
23 -->
24
25 <refentry id="systemd.service">
26 <refentryinfo>
27 <title>systemd.service</title>
28 <productname>systemd</productname>
29
30 <authorgroup>
31 <author>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
36 </author>
37 </authorgroup>
38 </refentryinfo>
39
40 <refmeta>
41 <refentrytitle>systemd.service</refentrytitle>
42 <manvolnum>5</manvolnum>
43 </refmeta>
44
45 <refnamediv>
46 <refname>systemd.service</refname>
47 <refpurpose>Service unit configuration</refpurpose>
48 </refnamediv>
49
50 <refsynopsisdiv>
51 <para><filename><replaceable>service</replaceable>.service</filename></para>
52 </refsynopsisdiv>
53
54 <refsect1>
55 <title>Description</title>
56
57 <para>A unit configuration file whose name ends in
58 <filename>.service</filename> encodes information
59 about a process controlled and supervised by
60 systemd.</para>
61
62 <para>This man page lists the configuration options
63 specific to this unit type. See
64 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
65 for the common options of all unit configuration
66 files. The common configuration items are configured
67 in the generic <literal>[Unit]</literal> and
68 <literal>[Install]</literal> sections. The service
69 specific configuration options are configured in the
70 <literal>[Service]</literal> section.</para>
71
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
75 are executed in, and in
76 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
77 which define the way the processes of the service are
78 terminated.</para>
79
80 <para>Unless <varname>DefaultDependencies=</varname>
81 is set to <option>false</option>, service units will
82 implicitly have dependencies of type
83 <varname>Requires=</varname> and
84 <varname>After=</varname> on
85 <filename>basic.target</filename> as well as
86 dependencies of type <varname>Conflicts=</varname> and
87 <varname>Before=</varname> on
88 <filename>shutdown.target</filename>. These ensure
89 that normal service units pull in basic system
90 initialization, and are terminated cleanly prior to
91 system shutdown. Only services involved with early
92 boot or late system shutdown should disable this
93 option.</para>
94
95 <para>If a service is requested under a certain name
96 but no unit configuration file is found, systemd looks
97 for a SysV init script by the same name (with the
98 <filename>.service</filename> suffix removed) and
99 dynamically creates a service unit from that
100 script. This is useful for compatibility with
101 SysV. Note that this compatibility is quite
102 comprehensive but not 100%. For details about the
103 incompatibilities see the <ulink
104 url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
105 with SysV</ulink> document.
106 </para>
107 </refsect1>
108
109 <refsect1>
110 <title>Options</title>
111
112 <para>Service files must include a
113 <literal>[Service]</literal> section, which carries
114 information about the service and the process it
115 supervises. A number of options that may be used in
116 this section are shared with other unit types. These
117 options are documented in
118 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
119 and
120 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
121 options specific to the <literal>[Service]</literal>
122 section of service units are the following:</para>
123
124 <variablelist class='unit-directives'>
125 <varlistentry>
126 <term><varname>Type=</varname></term>
127
128 <listitem><para>Configures the process
129 start-up type for this service
130 unit. One of <option>simple</option>,
131 <option>forking</option>,
132 <option>oneshot</option>,
133 <option>dbus</option>,
134 <option>notify</option> or
135 <option>idle</option>.</para>
136
137 <para>If set to
138 <option>simple</option> (the default
139 value if <varname>BusName=</varname>
140 is not specified) it is expected that
141 the process configured with
142 <varname>ExecStart=</varname> is the
143 main process of the service. In this
144 mode, if the process offers
145 functionality to other processes on
146 the system its communication channels
147 should be installed before the daemon
148 is started up (e.g. sockets set up by
149 systemd, via socket activation), as
150 systemd will immediately proceed
151 starting follow-up units.</para>
152
153 <para>If set to
154 <option>forking</option> it is
155 expected that the process configured
156 with <varname>ExecStart=</varname>
157 will call <function>fork()</function>
158 as part of its start-up. The parent process is
159 expected to exit when start-up is
160 complete and all communication
161 channels set up. The child continues
162 to run as the main daemon
163 process. This is the behavior of
164 traditional UNIX daemons. If this
165 setting is used, it is recommended to
166 also use the
167 <varname>PIDFile=</varname> option, so
168 that systemd can identify the main
169 process of the daemon. systemd will
170 proceed starting follow-up units as
171 soon as the parent process
172 exits.</para>
173
174 <para>Behavior of
175 <option>oneshot</option> is similar
176 to <option>simple</option>, however
177 it is expected that the process has to
178 exit before systemd starts follow-up
179 units. <varname>RemainAfterExit=</varname>
180 is particularly useful for this type
181 of service.</para>
182
183 <para>Behavior of
184 <option>dbus</option> is similar to
185 <option>simple</option>, however it is
186 expected that the daemon acquires a
187 name on the D-Bus bus, as configured
188 by
189 <varname>BusName=</varname>. systemd
190 will proceed starting follow-up units
191 after the D-Bus bus name has been
192 acquired. Service units with this
193 option configured implicitly gain
194 dependencies on the
195 <filename>dbus.socket</filename>
196 unit. This type is the default if
197 <varname>BusName=</varname> is
198 specified.</para>
199
200 <para>Behavior of
201 <option>notify</option> is similar to
202 <option>simple</option>, however it is
203 expected that the daemon sends a
204 notification message via
205 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
206 or an equivalent call when it finished
207 starting up. systemd will proceed
208 starting follow-up units after this
209 notification message has been sent. If
210 this option is used
211 <varname>NotifyAccess=</varname> (see
212 below) should be set to open access to
213 the notification socket provided by
214 systemd. If
215 <varname>NotifyAccess=</varname> is
216 not set, it will be implicitly set to
217 <option>main</option>.</para>
218
219 <para>Behavior of
220 <option>idle</option> is very similar
221 to <option>simple</option>, however
222 actual execution of the service
223 binary is delayed until all jobs are
224 dispatched. This may be used to avoid
225 interleaving of output of shell
226 services with the status output on the
227 console.</para>
228 </listitem>
229 </varlistentry>
230
231 <varlistentry>
232 <term><varname>RemainAfterExit=</varname></term>
233
234 <listitem><para>Takes a boolean value
235 that specifies whether the service
236 shall be considered active even when
237 all its processes exited. Defaults to
238 <option>no</option>.</para>
239 </listitem>
240 </varlistentry>
241
242 <varlistentry>
243 <term><varname>GuessMainPID=</varname></term>
244
245 <listitem><para>Takes a boolean value
246 that specifies whether systemd should
247 try to guess the main PID of a service
248 if it cannot be determined
249 reliably. This option is ignored
250 unless <option>Type=forking</option>
251 is set and <option>PIDFile=</option>
252 is unset because for the other types
253 or with an explicitly configured PID
254 file the main PID is always known. The
255 guessing algorithm might come to
256 incorrect conclusions if a daemon
257 consists of more than one process. If
258 the main PID cannot be determined
259 failure detection and automatic
260 restarting of a service will not work
261 reliably. Defaults to
262 <option>yes</option>.</para>
263 </listitem>
264 </varlistentry>
265
266 <varlistentry>
267 <term><varname>PIDFile=</varname></term>
268
269 <listitem><para>Takes an absolute file
270 name pointing to the PID file of this
271 daemon. Use of this option is
272 recommended for services where
273 <varname>Type=</varname> is set to
274 <option>forking</option>. systemd will
275 read the PID of the main process of
276 the daemon after start-up of the
277 service. systemd will not write to the
278 file configured here.</para>
279 </listitem>
280 </varlistentry>
281
282 <varlistentry>
283 <term><varname>BusName=</varname></term>
284
285 <listitem><para>Takes a D-Bus bus
286 name, that this service is reachable
287 as. This option is mandatory for
288 services where
289 <varname>Type=</varname> is set to
290 <option>dbus</option>, but its use
291 is otherwise recommended as well if
292 the process takes a name on the D-Bus
293 bus.</para>
294 </listitem>
295 </varlistentry>
296
297 <varlistentry>
298 <term><varname>ExecStart=</varname></term>
299 <listitem><para>Commands with their
300 arguments that are executed when this
301 service is started. The first
302 argument must be an absolute path
303 name.</para>
304
305 <para>When <varname>Type</varname> is
306 not <option>oneshot</option>, only one
307 command may be given. When
308 <varname>Type=oneshot</varname> is
309 used, more than one command may be
310 specified. Multiple command lines may
311 be concatenated in a single directive,
312 by separating them with semicolons
313 (these semicolons must be passed as
314 separate words). Alternatively, this
315 directive may be specified more than
316 once with the same effect. However,
317 the latter syntax is not recommended
318 for compatibility with parsers
319 suitable for XDG
320 <filename>.desktop</filename> files.
321 Lone semicolons may be escaped as
322 '<literal>\;</literal>'. If the empty
323 string is assigned to this option the
324 list of commands to start is reset,
325 prior assignments of this option will
326 have no effect.</para>
327
328 <para>If more than one command is
329 specified, the commands are invoked
330 one by one sequentially in the order
331 they appear in the unit file. If one
332 of the commands fails (and is not
333 prefixed with '<literal>-</literal>'),
334 other lines are not executed and the
335 unit is considered failed.</para>
336
337 <para>Unless
338 <varname>Type=forking</varname> is
339 set, the process started via this
340 command line will be considered the
341 main process of the daemon.</para>
342
343 <para>The command line accepts
344 '<literal>%</literal>' specifiers as
345 described in
346 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
347 that the first argument of the command
348 line (i.e. the program to execute) may
349 not include specifiers.</para>
350
351 <para>Basic environment variable
352 substitution is supported. Use
353 <literal>${FOO}</literal> as part of a
354 word, or as a word of its own on the
355 command line, in which case it will be
356 replaced by the value of the
357 environment variable including all
358 whitespace it contains, resulting in a
359 single argument. Use
360 <literal>$FOO</literal> as a separate
361 word on the command line, in which
362 case it will be replaced by the value
363 of the environment variable split up
364 at whitespace, resulting in zero or
365 more arguments. Note that the first
366 argument (i.e. the program to execute)
367 may not be a variable, since it must
368 be a literal and absolute path
369 name.</para>
370
371 <para>Optionally, if the absolute file
372 name is prefixed with
373 '<literal>@</literal>', the second token
374 will be passed as
375 <literal>argv[0]</literal> to the
376 executed process, followed by the
377 further arguments specified. If the
378 absolute file name is prefixed with
379 '<literal>-</literal>' an exit code of
380 the command normally considered a
381 failure (i.e. non-zero exit status or
382 abnormal exit due to signal) is ignored
383 and considered success. If both
384 '<literal>-</literal>' and
385 '<literal>@</literal>' are used they
386 can appear in either order.</para>
387
388 <para>Note that this setting does not
389 directly support shell command
390 lines. If shell command lines are to
391 be used they need to be passed
392 explicitly to a shell implementation
393 of some kind. Example:</para>
394 <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'
395 </programlisting>
396
397 <para>For services run by a user
398 instance of systemd the special
399 environment variable
400 <varname>$MANAGERPID</varname> is set
401 to the PID of the systemd
402 instance.</para>
403 </listitem>
404 </varlistentry>
405
406 <varlistentry>
407 <term><varname>ExecStartPre=</varname></term>
408 <term><varname>ExecStartPost=</varname></term>
409 <listitem><para>Additional commands
410 that are executed before or after
411 the command in
412 <varname>ExecStart=</varname>, respectively.
413 Syntax is the same as for
414 <varname>ExecStart=</varname>, except
415 that multiple command lines are allowed
416 and the commands are executed one
417 after the other, serially.</para>
418
419 <para>If any of those commands (not
420 prefixed with '<literal>-</literal>')
421 fail, the rest are not executed and
422 the unit is considered failed.</para>
423 </listitem>
424 </varlistentry>
425
426 <varlistentry>
427 <term><varname>ExecReload=</varname></term>
428 <listitem><para>Commands to execute to
429 trigger a configuration reload in the
430 service. This argument takes multiple
431 command lines, following the same
432 scheme as described for
433 <varname>ExecStart=</varname>
434 above. Use of this setting is
435 optional. Specifier and environment
436 variable substitution is supported
437 here following the same scheme as for
438 <varname>ExecStart=</varname>.</para>
439
440 <para>One additional special
441 environment variables is set: if known
442 <varname>$MAINPID</varname> is set to
443 the main process of the daemon, and
444 may be used for command lines like the
445 following:</para>
446
447 <programlisting>/bin/kill -HUP $MAINPID</programlisting>
448 </listitem>
449 </varlistentry>
450
451 <varlistentry>
452 <term><varname>ExecStop=</varname></term>
453 <listitem><para>Commands to execute to
454 stop the service started via
455 <varname>ExecStart=</varname>. This
456 argument takes multiple command lines,
457 following the same scheme as described
458 for <varname>ExecStart=</varname>
459 above. Use of this setting is
460 optional. All processes remaining for
461 a service after the commands
462 configured in this option are run are
463 terminated according to the
464 <varname>KillMode=</varname> setting
465 (see
466 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
467 this option is not specified the
468 process is terminated right-away when
469 service stop is requested. Specifier
470 and environment variable substitution
471 is supported (including
472 <varname>$MAINPID</varname>, see
473 above).</para></listitem>
474 </varlistentry>
475
476 <varlistentry>
477 <term><varname>ExecStopPost=</varname></term>
478 <listitem><para>Additional commands
479 that are executed after the service
480 was stopped. This includes cases where
481 the commands configured in
482 <varname>ExecStop=</varname> were used,
483 where the service doesn't have any
484 <varname>ExecStop=</varname> defined, or
485 where the service exited unexpectedly. This
486 argument takes multiple command lines,
487 following the same scheme as described
488 for <varname>ExecStart</varname>. Use
489 of these settings is
490 optional. Specifier and environment
491 variable substitution is
492 supported.</para></listitem>
493 </varlistentry>
494
495 <varlistentry>
496 <term><varname>RestartSec=</varname></term>
497 <listitem><para>Configures the time to
498 sleep before restarting a service (as
499 configured with
500 <varname>Restart=</varname>). Takes a
501 unit-less value in seconds, or a time
502 span value such as "5min
503 20s". Defaults to
504 100ms.</para></listitem>
505 </varlistentry>
506
507 <varlistentry>
508 <term><varname>TimeoutStartSec=</varname></term>
509 <listitem><para>Configures the time to
510 wait for start-up. If a
511 daemon service does not signal
512 start-up completion within the
513 configured time, the service will be
514 considered failed and be shut down
515 again.
516 Takes a unit-less value in seconds, or a
517 time span value such as "5min
518 20s". Pass 0 to disable the timeout
519 logic. Defaults to 90s, except when
520 <varname>Type=oneshot</varname> is
521 used in which case the timeout
522 is disabled by default.
523 </para></listitem>
524 </varlistentry>
525
526 <varlistentry>
527 <term><varname>TimeoutStopSec=</varname></term>
528 <listitem><para>Configures the time to
529 wait for stop. If a service is asked
530 to stop but does not terminate in the
531 specified time, it will be terminated
532 forcibly via SIGTERM, and after
533 another delay of this time with
534 SIGKILL (See
535 <varname>KillMode=</varname>
536 in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
537 Takes a unit-less value in seconds, or a
538 time span value such as "5min
539 20s". Pass 0 to disable the timeout
540 logic. Defaults to 90s.
541 </para></listitem>
542 </varlistentry>
543
544 <varlistentry>
545 <term><varname>TimeoutSec=</varname></term>
546 <listitem><para>A shorthand for configuring
547 both <varname>TimeoutStartSec=</varname>
548 and <varname>TimeoutStopSec=</varname>
549 to the specified value.
550 </para></listitem>
551 </varlistentry>
552
553 <varlistentry>
554 <term><varname>WatchdogSec=</varname></term>
555 <listitem><para>Configures the
556 watchdog timeout for a service. This
557 is activated when the start-up is
558 completed. The service must call
559 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
560 regularly with "WATCHDOG=1" (i.e. the
561 "keep-alive ping"). If the time
562 between two such calls is larger than
563 the configured time then the service
564 is placed in a failure state. By
565 setting <varname>Restart=</varname> to
566 <option>on-failure</option> or
567 <option>always</option> the service
568 will be automatically restarted. The
569 time configured here will be passed to
570 the executed service process in the
571 <varname>WATCHDOG_USEC=</varname>
572 environment variable. This allows
573 daemons to automatically enable the
574 keep-alive pinging logic if watchdog
575 support is enabled for the service. If
576 this option is used
577 <varname>NotifyAccess=</varname> (see
578 below) should be set to open access to
579 the notification socket provided by
580 systemd. If
581 <varname>NotifyAccess=</varname> is
582 not set, it will be implicitly set to
583 <option>main</option>. Defaults to 0,
584 which disables this
585 feature.</para></listitem>
586 </varlistentry>
587
588 <varlistentry>
589 <term><varname>Restart=</varname></term>
590 <listitem><para>Configures whether the
591 main service process shall be
592 restarted when it exits. Takes one of
593 <option>no</option>,
594 <option>on-success</option>,
595 <option>on-failure</option>,
596 <option>on-abort</option> or
597 <option>always</option>. If set to
598 <option>no</option> (the default) the
599 service will not be restarted when it
600 exits. If set to
601 <option>on-success</option> it will be
602 restarted only when it exited cleanly,
603 i.e. terminated with an exit code of
604 0. If set to
605 <option>on-failure</option> it will be
606 restarted only when it exited with an
607 exit code not equaling 0, when
608 terminated by a signal (including on
609 core dump), when an operation (such as
610 service reload) times out or when the
611 configured watchdog timeout is
612 triggered. If set to
613 <option>on-abort</option> it will be
614 restarted only if it exits due to
615 reception of an uncaught signal
616 (including on core dump). If set to
617 <option>always</option> the service
618 will be restarted regardless whether
619 it exited cleanly or not, got
620 terminated abnormally by a signal or
621 hit a timeout.</para></listitem>
622 </varlistentry>
623
624 <varlistentry>
625 <term><varname>SuccessExitStatus=</varname></term>
626 <listitem><para>Takes a list of exit
627 status definitions that when returned
628 by the main service process will be
629 considered successful termination, in
630 addition to the normal successful exit
631 code 0 and the signals SIGHUP, SIGINT,
632 SIGTERM and SIGPIPE. Exit status
633 definitions can either be numeric exit
634 codes or termination signal names, and
635 are separated by spaces. Example:
636 "<literal>SuccessExitStatus=1 2 8
637 SIGKILL</literal>", ensures that exit
638 codes 1, 2, 8 and the termination
639 signal SIGKILL are considered clean
640 service terminations. This option may
641 appear more than once in which case
642 the list of successful exit statuses
643 is merged. If the empty string is
644 assigned to this option the list is
645 reset, all prior assignments of this
646 option will have no
647 effect.</para></listitem>
648 </varlistentry>
649
650 <varlistentry>
651 <term><varname>RestartPreventExitStatus=</varname></term>
652 <listitem><para>Takes a list of exit
653 status definitions that when returned
654 by the main service process will
655 prevent automatic service restarts
656 regardless of the restart setting
657 configured with
658 <varname>Restart=</varname>. Exit
659 status definitions can either be
660 numeric exit codes or termination
661 signal names, and are separated by
662 spaces. Defaults to the empty list, so
663 that by default no exit status is
664 excluded from the configured restart
665 logic. Example:
666 "<literal>RestartPreventExitStatus=1 6
667 SIGABRT</literal>", ensures that exit
668 codes 1 and 6 and the termination
669 signal SIGABRT will not result in
670 automatic service restarting. This
671 option may appear more than once in
672 which case the list of restart preventing
673 statuses is merged. If the empty
674 string is assigned to this option the
675 list is reset, all prior assignments
676 of this option will have no
677 effect.</para></listitem>
678 </varlistentry>
679
680 <varlistentry>
681 <term><varname>PermissionsStartOnly=</varname></term>
682 <listitem><para>Takes a boolean
683 argument. If true, the permission
684 related execution options as
685 configured with
686 <varname>User=</varname> and similar
687 options (see
688 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
689 for more information) are only applied
690 to the process started with
691 <varname>ExecStart=</varname>, and not
692 to the various other
693 <varname>ExecStartPre=</varname>,
694 <varname>ExecStartPost=</varname>,
695 <varname>ExecReload=</varname>,
696 <varname>ExecStop=</varname>,
697 <varname>ExecStopPost=</varname>
698 commands. If false, the setting is
699 applied to all configured commands the
700 same way. Defaults to
701 false.</para></listitem>
702 </varlistentry>
703
704 <varlistentry>
705 <term><varname>RootDirectoryStartOnly=</varname></term>
706 <listitem><para>Takes a boolean
707 argument. If true, the root directory
708 as configured with the
709 <varname>RootDirectory=</varname>
710 option (see
711 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
712 for more information) is only applied
713 to the process started with
714 <varname>ExecStart=</varname>, and not
715 to the various other
716 <varname>ExecStartPre=</varname>,
717 <varname>ExecStartPost=</varname>,
718 <varname>ExecReload=</varname>,
719 <varname>ExecStop=</varname>,
720 <varname>ExecStopPost=</varname>
721 commands. If false, the setting is
722 applied to all configured commands the
723 same way. Defaults to
724 false.</para></listitem>
725 </varlistentry>
726
727 <varlistentry>
728 <term><varname>NonBlocking=</varname></term>
729 <listitem><para>Set O_NONBLOCK flag
730 for all file descriptors passed via
731 socket-based activation. If true, all
732 file descriptors >= 3 (i.e. all except
733 STDIN/STDOUT/STDERR) will have
734 the O_NONBLOCK flag set and hence are in
735 non-blocking mode. This option is only
736 useful in conjunction with a socket
737 unit, as described in
738 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
739 to false.</para></listitem>
740 </varlistentry>
741
742 <varlistentry>
743 <term><varname>NotifyAccess=</varname></term>
744 <listitem><para>Controls access to the
745 service status notification socket, as
746 accessible via the
747 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
748 call. Takes one of
749 <option>none</option> (the default),
750 <option>main</option> or
751 <option>all</option>. If
752 <option>none</option> no daemon status
753 updates are accepted from the service
754 processes, all status update messages
755 are ignored. If <option>main</option>
756 only service updates sent from the
757 main process of the service are
758 accepted. If <option>all</option> all
759 services updates from all members of
760 the service's control group are
761 accepted. This option should be set to
762 open access to the notification socket
763 when using
764 <varname>Type=notify</varname> or
765 <varname>WatchdogSec=</varname> (see
766 above). If those options are used but
767 <varname>NotifyAccess=</varname> not
768 configured it will be implicitly set
769 to
770 <option>main</option>.</para></listitem>
771 </varlistentry>
772
773 <varlistentry>
774 <term><varname>Sockets=</varname></term>
775 <listitem><para>Specifies the name of
776 the socket units this service shall
777 inherit the sockets from when the
778 service is started. Normally it
779 should not be necessary to use this
780 setting as all sockets whose unit
781 shares the same name as the service
782 (ignoring the different suffix of course)
783 are passed to the spawned
784 process.</para>
785
786 <para>Note that the same socket may be
787 passed to multiple processes at the
788 same time. Also note that a different
789 service may be activated on incoming
790 traffic than inherits the sockets. Or
791 in other words: the
792 <varname>Service=</varname> setting of
793 <filename>.socket</filename> units
794 doesn't have to match the inverse of
795 the <varname>Sockets=</varname>
796 setting of the
797 <filename>.service</filename> it
798 refers to.</para>
799
800 <para>This option may appear more than
801 once, in which case the list of socket
802 units is merged. If the empty string
803 is assigned to this option the list of
804 sockets is reset, all prior uses of
805 this setting will have no
806 effect.</para></listitem>
807 </varlistentry>
808
809 <varlistentry>
810 <term><varname>StartLimitInterval=</varname></term>
811 <term><varname>StartLimitBurst=</varname></term>
812
813 <listitem><para>Configure service
814 start rate limiting. By default
815 services which are started more often
816 than 5 times within 10s are not
817 permitted to start any more times
818 until the 10s interval ends. With
819 these two options this rate limiting
820 may be modified. Use
821 <varname>StartLimitInterval=</varname>
822 to configure the checking interval
823 (defaults to 10s, set to 0 to disable
824 any kind of rate limiting). Use
825 <varname>StartLimitBurst=</varname> to
826 configure how many starts per interval
827 are allowed (defaults to 5). These
828 configuration options are particularly
829 useful in conjunction with
830 <varname>Restart=</varname>, however
831 apply to all kinds of starts
832 (including manual), not just those
833 triggered by the
834 <varname>Restart=</varname> logic.
835 Note that units which are configured
836 for <varname>Restart=</varname> and
837 which reach the start limit are not
838 attempted to be restarted anymore,
839 however they may still be restarted
840 manually at a later point from which
841 point on the restart logic is again
842 activated. Note that
843 <command>systemctl
844 reset-failed</command> will cause the
845 restart rate counter for a service to
846 be flushed, which is useful if the
847 administrator wants to manually start
848 a service and the start limit
849 interferes with
850 that.</para></listitem>
851 </varlistentry>
852
853 <varlistentry>
854 <term><varname>StartLimitAction=</varname></term>
855
856 <listitem><para>Configure the action
857 to take if the rate limit configured
858 with
859 <varname>StartLimitInterval=</varname>
860 and
861 <varname>StartLimitBurst=</varname> is
862 hit. Takes one of
863 <option>none</option>,
864 <option>reboot</option>,
865 <option>reboot-force</option> or
866 <option>reboot-immediate</option>. If
867 <option>none</option> is set,
868 hitting the rate limit will trigger no
869 action besides that the start will not
870 be
871 permitted. <option>reboot</option>
872 causes a reboot following the normal
873 shutdown procedure (i.e. equivalent to
874 <command>systemctl reboot</command>),
875 <option>reboot-force</option> causes
876 an forced reboot which will terminate
877 all processes forcibly but should
878 cause no dirty file systems on reboot
879 (i.e. equivalent to <command>systemctl
880 reboot -f</command>) and
881 <option>reboot-immediate</option>
882 causes immediate execution of the
883 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
884 system call, which might result in
885 data loss. Defaults to
886 <option>none</option>.</para></listitem>
887 </varlistentry>
888
889 </variablelist>
890
891 <para>Check
892 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
893 and
894 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
895 for more settings.</para>
896
897 </refsect1>
898
899 <refsect1>
900 <title>Compatibility Options</title>
901
902 <para>The following options are also available in the
903 <literal>[Service]</literal> section, but exist purely
904 for compatibility reasons and should not be used in
905 newly written service files.</para>
906
907 <variablelist class='unit-directives'>
908 <varlistentry>
909 <term><varname>SysVStartPriority=</varname></term>
910 <listitem><para>Set the SysV start
911 priority to use to order this service
912 in relation to SysV services lacking
913 LSB headers. This option is only
914 necessary to fix ordering in relation
915 to legacy SysV services, that have no
916 ordering information encoded in the
917 script headers. As such it should only
918 be used as temporary compatibility
919 option, and not be used in new unit
920 files. Almost always it is a better
921 choice to add explicit ordering
922 directives via
923 <varname>After=</varname> or
924 <varname>Before=</varname>,
925 instead. For more details see
926 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
927 used, pass an integer value in the
928 range 0-99.</para></listitem>
929 </varlistentry>
930
931 <varlistentry>
932 <term><varname>FsckPassNo=</varname></term>
933 <listitem><para>Set the fsck passno
934 priority to use to order this service
935 in relation to other file system
936 checking services. This option is only
937 necessary to fix ordering in relation
938 to fsck jobs automatically created for
939 all <filename>/etc/fstab</filename>
940 entries with a value in the fs_passno
941 column > 0. As such it should only be
942 used as option for fsck
943 services. Almost always it is a better
944 choice to add explicit ordering
945 directives via
946 <varname>After=</varname> or
947 <varname>Before=</varname>,
948 instead. For more details see
949 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
950 used, pass an integer value in the
951 same range as
952 <filename>/etc/fstab</filename>'s
953 fs_passno column. See
954 <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
955 for details.</para></listitem>
956 </varlistentry>
957
958 </variablelist>
959 </refsect1>
960
961 <refsect1>
962 <title>See Also</title>
963 <para>
964 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
965 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
966 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
967 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
968 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
969 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
970 </para>
971 </refsect1>
972
973 </refentry>