]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.service.xml
service: default to Type=dbus if BusName= is specified
[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>systemd service configuration files</refpurpose>
48 </refnamediv>
49
50 <refsynopsisdiv>
51 <para><filename>systemd.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.</para>
76
77 <para>Unless <varname>DefaultDependencies=</varname>
78 is set to <option>false</option>, service units will
79 implicitly have dependencies of type
80 <varname>Requires=</varname> and
81 <varname>After=</varname> on
82 <filename>basic.target</filename> as well as
83 dependencies of type <varname>Conflicts=</varname> and
84 <varname>Before=</varname> on
85 <filename>shutdown.target</filename>. These ensure
86 that normal service units pull in basic system
87 initialization, and are terminated cleanly prior to
88 system shutdown. Only services involved with early
89 boot or late system shutdown should disable this
90 option.</para>
91
92 <para>If a service is requested under a certain name
93 but no unit configuration file is found, systemd looks
94 for a SysV init script by the same name (with the
95 <filename>.service</filename> suffix removed) and
96 dynamically creates a service unit from that
97 script. This is useful for compatibility with
98 SysV.</para>
99 </refsect1>
100
101 <refsect1>
102 <title>Options</title>
103
104 <para>Service files must include a
105 <literal>[Service]</literal> section, which carries
106 information about the service and the process it
107 supervises. A number of options that may be used in
108 this section are shared with other unit types. These
109 options are documented in
110 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
111 options specific to the <literal>[Service]</literal>
112 section of service units are the following:</para>
113
114 <variablelist>
115 <varlistentry>
116 <term><varname>Type=</varname></term>
117
118 <listitem><para>Configures the process
119 start-up type for this service
120 unit. One of <option>simple</option>,
121 <option>forking</option>,
122 <option>oneshot</option>,
123 <option>dbus</option>,
124 <option>notify</option> or
125 <option>idle</option>.</para>
126
127 <para>If set to
128 <option>simple</option> (the default
129 value if <varname>BusName=</varname>
130 is not specified) it is expected that
131 the process configured with
132 <varname>ExecStart=</varname> is the
133 main process of the service. In this
134 mode, if the process offers
135 functionality to other processes on
136 the system its communication channels
137 should be installed before the daemon
138 is started up (e.g. sockets set up by
139 systemd, via socket activation), as
140 systemd will immediately proceed
141 starting follow-up units.</para>
142
143 <para>If set to
144 <option>forking</option> it is
145 expected that the process configured
146 with <varname>ExecStart=</varname>
147 will call <function>fork()</function>
148 as part of its start-up. The parent process is
149 expected to exit when start-up is
150 complete and all communication
151 channels set up. The child continues
152 to run as the main daemon
153 process. This is the behaviour of
154 traditional UNIX daemons. If this
155 setting is used, it is recommended to
156 also use the
157 <varname>PIDFile=</varname> option, so
158 that systemd can identify the main
159 process of the daemon. systemd will
160 proceed starting follow-up units as
161 soon as the parent process
162 exits.</para>
163
164 <para>Behaviour of
165 <option>oneshot</option> is similar
166 to <option>simple</option>, however
167 it is expected that the process has to
168 exit before systemd starts follow-up
169 units. <varname>RemainAfterExit=</varname>
170 is particularly useful for this type
171 of service.</para>
172
173 <para>Behaviour of
174 <option>dbus</option> is similar to
175 <option>simple</option>, however it is
176 expected that the daemon acquires a
177 name on the D-Bus bus, as configured
178 by
179 <varname>BusName=</varname>. systemd
180 will proceed starting follow-up units
181 after the D-Bus bus name has been
182 acquired. Service units with this
183 option configured implicitly gain
184 dependencies on the
185 <filename>dbus.socket</filename>
186 unit. This type is the default if
187 <varname>BusName=</varname> is
188 specified.</para>
189
190 <para>Behaviour of
191 <option>notify</option> is similar to
192 <option>simple</option>, however it is
193 expected that the daemon sends a
194 notification message via
195 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
196 or an equivalent call when it finished
197 starting up. systemd will proceed
198 starting follow-up units after this
199 notification message has been sent. If
200 this option is used
201 <varname>NotifyAccess=</varname> (see
202 below) should be set to open access to
203 the notification socket provided by
204 systemd. If
205 <varname>NotifyAccess=</varname> is
206 not set, it will be implicitly set to
207 <option>main</option>.</para>
208
209 <para>Behaviour of
210 <option>idle</option> is very similar
211 to <option>simple</option>, however
212 actual execution of a the service
213 binary is delayed until all jobs are
214 dispatched. This may be used to avoid
215 interleaving of output of shell
216 services with the status output on the
217 console.</para>
218 </listitem>
219 </varlistentry>
220
221 <varlistentry>
222 <term><varname>RemainAfterExit=</varname></term>
223
224 <listitem><para>Takes a boolean value
225 that specifies whether the service
226 shall be considered active even when
227 all its processes exited. Defaults to
228 <option>no</option>.</para>
229 </listitem>
230 </varlistentry>
231
232 <varlistentry>
233 <term><varname>GuessMainPID=</varname></term>
234
235 <listitem><para>Takes a boolean value
236 that specifies whether systemd should
237 try to guess the main PID of a service
238 should if it cannot be determined
239 reliably. This option is ignored
240 unless <option>Type=forking</option>
241 is set and <option>PIDFile=</option>
242 is unset because for the other types
243 or with an explicitly configured PID
244 file the main PID is always known. The
245 guessing algorithm might come to
246 incorrect conclusions if a daemon
247 consists of more than one process. If
248 the main PID cannot be determined
249 failure detection and automatic
250 restarting of a service will not work
251 reliably. Defaults to
252 <option>yes</option>.</para>
253 </listitem>
254 </varlistentry>
255
256 <varlistentry>
257 <term><varname>PIDFile=</varname></term>
258
259 <listitem><para>Takes an absolute file
260 name pointing to the PID file of this
261 daemon. Use of this option is
262 recommended for services where
263 <varname>Type=</varname> is set to
264 <option>forking</option>. systemd will
265 read the PID of the main process of
266 the daemon after start-up of the
267 service. systemd will not write to the
268 file configured here.</para>
269 </listitem>
270 </varlistentry>
271
272 <varlistentry>
273 <term><varname>BusName=</varname></term>
274
275 <listitem><para>Takes a D-Bus bus
276 name, where this service is reachable
277 as. This option is mandatory for
278 services where
279 <varname>Type=</varname> is set to
280 <option>dbus</option>, but its use
281 is otherwise recommended as well if
282 the process takes a name on the D-Bus
283 bus.</para>
284 </listitem>
285 </varlistentry>
286
287 <varlistentry>
288 <term><varname>ExecStart=</varname></term>
289 <listitem><para>Takes a command line
290 that is executed when this service
291 shall be started up. The first token
292 of the command line must be an
293 absolute file name, then followed by
294 arguments for the process. It is
295 mandatory to set this option for all
296 services. This option may not be
297 specified more than once, except when
298 <varname>Type=oneshot</varname> is
299 used in which case more than one
300 <varname>ExecStart=</varname> line is
301 accepted which are then invoked one by
302 one, sequentially in the order they
303 appear in the unit file.</para>
304
305 <para>Optionally, if the absolute file
306 name is prefixed with
307 <literal>@</literal>, the second token
308 will be passed as
309 <literal>argv[0]</literal> to the
310 executed process, followed by the
311 further arguments specified. If the
312 first token is prefixed with
313 <literal>-</literal> an exit code of
314 the command normally considered a
315 failure (i.e. non-zero exit status or
316 abnormal exit due to signal) is ignored
317 and considered success. If both
318 <literal>-</literal> and
319 <literal>@</literal> are used for the
320 same command the former must precede
321 the latter. Unless
322 <varname>Type=forking</varname> is
323 set, the process started via this
324 command line will be considered the
325 main process of the daemon. The
326 command line accepts % specifiers as
327 described in
328 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
329
330 <para>On top of that basic environment
331 variable substitution is
332 supported. Use
333 <literal>${FOO}</literal> as part of a
334 word, or as word of its own on the
335 command line, in which case it will be
336 replaced by the value of the
337 environment variable including all
338 whitespace it contains, resulting in a
339 single argument. Use
340 <literal>$FOO</literal> as a separate
341 word on the command line, in which
342 case it will be replaced by the value
343 of the environment variable split up
344 at whitespace, resulting in no or more
345 arguments. Note that the first
346 argument (i.e. the program to execute)
347 may not be a variable, and must be a
348 literal and absolute path
349 name.</para></listitem>
350 </varlistentry>
351
352 <varlistentry>
353 <term><varname>ExecStartPre=</varname></term>
354 <term><varname>ExecStartPost=</varname></term>
355 <listitem><para>Additional commands
356 that are executed before (resp. after)
357 the command in
358 <varname>ExecStart=</varname>. Multiple
359 command lines may be concatenated in a
360 single directive, by separating them
361 by semicolons (these semicolons must
362 be passed as separate words). In that
363 case, the commands are executed one
364 after the other,
365 serially. Alternatively, these
366 directives may be specified more than
367 once with the same effect. However,
368 the latter syntax is not recommended
369 for compatibility with parsers
370 suitable for XDG
371 <filename>.desktop</filename> files.
372 Use of these settings is
373 optional. Specifier and environment
374 variable substitution is
375 supported.</para></listitem>
376 </varlistentry>
377
378 <varlistentry>
379 <term><varname>ExecReload=</varname></term>
380 <listitem><para>Commands to execute to
381 trigger a configuration reload in the
382 service. This argument takes multiple
383 command lines, following the same
384 scheme as pointed out for
385 <varname>ExecStartPre=</varname>
386 above. Use of this setting is
387 optional. Specifier and environment
388 variable substitution is supported
389 here following the same scheme as for
390 <varname>ExecStart=</varname>. One
391 special environment variable is set:
392 if known <literal>$MAINPID</literal> is
393 set to the main process of the
394 daemon, and may be used for command
395 lines like the following:
396 <command>/bin/kill -HUP
397 $MAINPID</command>.</para></listitem>
398 </varlistentry>
399
400 <varlistentry>
401 <term><varname>ExecStop=</varname></term>
402 <listitem><para>Commands to execute to
403 stop the service started via
404 <varname>ExecStart=</varname>. This
405 argument takes multiple command lines,
406 following the same scheme as pointed
407 out for
408 <varname>ExecStartPre=</varname>
409 above. Use of this setting is
410 optional. All processes remaining for
411 a service after the commands
412 configured in this option are run are
413 terminated according to the
414 <varname>KillMode=</varname> setting
415 (see below). If this option is not
416 specified the process is terminated
417 right-away when service stop is
418 requested. Specifier and environment
419 variable substitution is supported
420 (including
421 <literal>$MAINPID</literal>, see
422 above).</para></listitem>
423 </varlistentry>
424
425 <varlistentry>
426 <term><varname>ExecStopPost=</varname></term>
427 <listitem><para>Additional commands
428 that are executed after the service
429 was stopped using the commands
430 configured in
431 <varname>ExecStop=</varname>. This
432 argument takes multiple command lines,
433 following the same scheme as pointed
434 out for
435 <varname>ExecStartPre</varname>. Use
436 of these settings is
437 optional. Specifier and environment
438 variable substitution is
439 supported.</para></listitem>
440 </varlistentry>
441
442 <varlistentry>
443 <term><varname>RestartSec=</varname></term>
444 <listitem><para>Configures the time to
445 sleep before restarting a service (as
446 configured with
447 <varname>Restart=</varname>). Takes a
448 unit-less value in seconds, or a time
449 span value such as "5min
450 20s". Defaults to
451 100ms.</para></listitem>
452 </varlistentry>
453
454 <varlistentry>
455 <term><varname>TimeoutSec=</varname></term>
456 <listitem><para>Configures the time to
457 wait for start-up and stop. If a
458 daemon service does not signal
459 start-up completion within the
460 configured time the service will be
461 considered failed and be shut down
462 again. If a service is asked to stop
463 but does not terminate in the
464 specified time it will be terminated
465 forcibly via SIGTERM, and after
466 another delay of this time with
467 SIGKILL. (See
468 <varname>KillMode=</varname>
469 below.) Takes a unit-less value in seconds, or a
470 time span value such as "5min
471 20s". Pass 0 to disable the timeout
472 logic. Defaults to
473 90s.</para></listitem>
474 </varlistentry>
475
476 <varlistentry>
477 <term><varname>WatchdogSec=</varname></term>
478 <listitem><para>Configures the
479 watchdog timeout for a service. This
480 is activated when the start-up is
481 completed. The service must call
482 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
483 regularly with "WATCHDOG=1". If the
484 time between two such calls is larger
485 than the configured time then the
486 service is placed in a failure
487 state. By setting
488 <varname>Restart=</varname>
489 to <option>on-failure</option> or
490 <option>always</option> the service
491 will be automatically restarted. The
492 time configured here will be passed to
493 the executed service process in the
494 <varname>WATCHDOG_USEC=</varname>
495 environment variable. If
496 this option is used
497 <varname>NotifyAccess=</varname> (see
498 below) should be set to open access to
499 the notification socket provided by
500 systemd. If
501 <varname>NotifyAccess=</varname> is not
502 set, it will be implicitly set to
503 <option>main</option>. Defaults to 0,
504 which disables this
505 feature.</para></listitem>
506 </varlistentry>
507
508 <varlistentry>
509 <term><varname>Restart=</varname></term>
510 <listitem><para>Configures whether the
511 main service process shall be
512 restarted when it exits. Takes one of
513 <option>no</option>,
514 <option>on-success</option>,
515 <option>on-failure</option>,
516 <option>on-abort</option> or
517 <option>always</option>. If set to
518 <option>no</option> (the default) the
519 service will not be restarted when it
520 exits. If set to
521 <option>on-success</option> it will be
522 restarted only when it exited cleanly,
523 i.e. terminated with an exit code of
524 0. If set to
525 <option>on-failure</option> it will be
526 restarted only when it exited with an
527 exit code not equalling 0, when
528 terminated by a signal, when an
529 operation times out or when the
530 configured watchdog timeout is
531 triggered. If set to
532 <option>on-abort</option> it will be
533 restarted only if it exits due to
534 reception of an uncaught signal. If
535 set to <option>always</option> the
536 service will be restarted regardless
537 whether it exited cleanly or not,
538 got terminated abnormally by a
539 signal or hit a timeout.</para></listitem>
540 </varlistentry>
541
542 <varlistentry>
543 <term><varname>PermissionsStartOnly=</varname></term>
544 <listitem><para>Takes a boolean
545 argument. If true, the permission
546 related execution options as
547 configured with
548 <varname>User=</varname> and similar
549 options (see
550 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
551 for more information) are only applied
552 to the process started with
553 <varname>ExecStart=</varname>, and not
554 to the various other
555 <varname>ExecStartPre=</varname>,
556 <varname>ExecStartPost=</varname>,
557 <varname>ExecReload=</varname>,
558 <varname>ExecStop=</varname>,
559 <varname>ExecStopPost=</varname>
560 commands. If false, the setting is
561 applied to all configured commands the
562 same way. Defaults to
563 false.</para></listitem>
564 </varlistentry>
565
566 <varlistentry>
567 <term><varname>RootDirectoryStartOnly=</varname></term>
568 <listitem><para>Takes a boolean
569 argument. If true, the root directory
570 as configured with the
571 <varname>RootDirectory=</varname>
572 option (see
573 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
574 for more information) is only applied
575 to the process started with
576 <varname>ExecStart=</varname>, and not
577 to the various other
578 <varname>ExecStartPre=</varname>,
579 <varname>ExecStartPost=</varname>,
580 <varname>ExecReload=</varname>,
581 <varname>ExecStop=</varname>,
582 <varname>ExecStopPost=</varname>
583 commands. If false, the setting is
584 applied to all configured commands the
585 same way. Defaults to
586 false.</para></listitem>
587 </varlistentry>
588
589 <varlistentry>
590 <term><varname>SysVStartPriority=</varname></term>
591 <listitem><para>Set the SysV start
592 priority to use to order this service
593 in relation to SysV services lacking
594 LSB headers. This option is only
595 necessary to fix ordering in relation
596 to legacy SysV services, that have no
597 ordering information encoded in the
598 script headers. As such it should only
599 be used as temporary compatibility
600 option, and not be used in new unit
601 files. Almost always it is a better
602 choice to add explicit ordering
603 directives via
604 <varname>After=</varname> or
605 <varname>Before=</varname>,
606 instead. For more details see
607 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
608 used, pass an integer value in the
609 range 0-99.</para></listitem>
610 </varlistentry>
611
612 <varlistentry>
613 <term><varname>KillMode=</varname></term>
614 <listitem><para>Specifies how
615 processes of this service shall be
616 killed. One of
617 <option>control-group</option>,
618 <option>process</option>,
619 <option>none</option>.</para>
620
621 <para>If set to
622 <option>control-group</option> all
623 remaining processes in the control
624 group of this service will be
625 terminated on service stop, after the
626 stop command (as configured with
627 <varname>ExecStop=</varname>) is
628 executed. If set to
629 <option>process</option> only the main
630 process itself is killed. If set to
631 <option>none</option> no process is
632 killed. In this case only the stop
633 command will be executed on service
634 stop, but no process be killed
635 otherwise. Processes remaining alive
636 after stop are left in their control
637 group and the control group continues
638 to exist after stop unless it is
639 empty. Defaults to
640 <option>control-group</option>.</para>
641
642 <para>Processes will first be
643 terminated via SIGTERM (unless the
644 signal to send is changed via
645 <varname>KillSignal=</varname>). If
646 then after a delay (configured via the
647 <varname>TimeoutSec=</varname> option)
648 processes still remain, the
649 termination request is repeated with
650 the SIGKILL signal (unless this is
651 disabled via the
652 <varname>SendSIGKILL=</varname>
653 option). See
654 <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
655 for more
656 information.</para></listitem>
657 </varlistentry>
658
659 <varlistentry>
660 <term><varname>KillSignal=</varname></term>
661 <listitem><para>Specifies which signal
662 to use when killing a
663 service. Defaults to SIGTERM.
664 </para></listitem>
665 </varlistentry>
666
667 <varlistentry>
668 <term><varname>SendSIGKILL=</varname></term>
669 <listitem><para>Specifies whether to
670 send SIGKILL to remaining processes
671 after a timeout, if the normal
672 shutdown procedure left processes of
673 the service around. Takes a boolean
674 value. Defaults to "yes".
675 </para></listitem>
676 </varlistentry>
677
678 <varlistentry>
679 <term><varname>NonBlocking=</varname></term>
680 <listitem><para>Set O_NONBLOCK flag
681 for all file descriptors passed via
682 socket-based activation. If true, all
683 file descriptors >= 3 (i.e. all except
684 STDIN/STDOUT/STDERR) will have
685 the O_NONBLOCK flag set and hence are in
686 non-blocking mode. This option is only
687 useful in conjunction with a socket
688 unit, as described in
689 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
690 to false.</para></listitem>
691 </varlistentry>
692
693 <varlistentry>
694 <term><varname>NotifyAccess=</varname></term>
695 <listitem><para>Controls access to the
696 service status notification socket, as
697 accessible via the
698 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
699 call. Takes one of
700 <option>none</option> (the default),
701 <option>main</option> or
702 <option>all</option>. If
703 <option>none</option> no daemon status
704 updates are accepted from the service
705 processes, all status update messages
706 are ignored. If <option>main</option>
707 only service updates sent from the
708 main process of the service are
709 accepted. If <option>all</option> all
710 services updates from all members of
711 the service's control group are
712 accepted. This option should be set to
713 open access to the notification socket
714 when using
715 <varname>Type=notify</varname> or
716 <varname>WatchdogUsec=</varname> (see
717 above). If those options are used but
718 <varname>NotifyAccess=</varname> not
719 configured it will be implicitly set
720 to
721 <option>main</option>.</para></listitem>
722 </varlistentry>
723
724 <varlistentry>
725 <term><varname>Sockets=</varname></term>
726 <listitem><para>Specifies the name of
727 the socket units this service shall
728 inherit the sockets from when the
729 service is started. Normally it
730 should not be necessary to use this
731 setting as all sockets whose unit
732 shares the same name as the service
733 (ignoring the different suffix of course)
734 are passed to the spawned
735 process.</para>
736
737 <para>Note that the same socket may be
738 passed to multiple processes at the
739 same time. Also note that a different
740 service may be activated on incoming
741 traffic than inherits the sockets. Or
742 in other words: The
743 <varname>Service=</varname> setting of
744 <filename>.socket</filename> units
745 doesn't have to match the inverse of the
746 <varname>Sockets=</varname> setting of
747 the <filename>.service</filename> it
748 refers to.</para></listitem>
749 </varlistentry>
750
751 <varlistentry>
752 <term><varname>FsckPassNo=</varname></term>
753 <listitem><para>Set the fsck passno
754 priority to use to order this service
755 in relation to other file system
756 checking services. This option is only
757 necessary to fix ordering in relation
758 to fsck jobs automatically created for
759 all <filename>/etc/fstab</filename>
760 entries with a value in the fs_passno
761 column > 0. As such it should only be
762 used as option for fsck
763 services. Almost always it is a better
764 choice to add explicit ordering
765 directives via
766 <varname>After=</varname> or
767 <varname>Before=</varname>,
768 instead. For more details see
769 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
770 used, pass an integer value in the
771 same range as
772 <filename>/etc/fstab</filename>'s
773 fs_passno column. See
774 <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
775 for details.</para></listitem>
776 </varlistentry>
777
778 <varlistentry>
779 <term><varname>StartLimitInterval=</varname></term>
780 <term><varname>StartLimitBurst=</varname></term>
781
782 <listitem><para>Configure service
783 start rate limiting. By default
784 services which are started more often
785 than 5 times within 10s are not
786 permitted to start any more times
787 until the 10s interval ends. With
788 these two options this rate limiting
789 may be modified. Use
790 <varname>StartLimitInterval=</varname>
791 to configure the checking interval
792 (defaults to 10s, set to 0 to disable
793 any kind of rate limiting). Use
794 <varname>StartLimitBurst=</varname> to
795 configure how many starts per interval
796 are allowed (defaults to 5). These
797 configuration options are particularly
798 useful in conjunction with
799 <varname>Restart=</varname>.</para></listitem>
800 </varlistentry>
801
802 <varlistentry>
803 <term><varname>StartLimitAction=</varname></term>
804
805 <listitem><para>Configure the action
806 to take if the rate limit configured
807 with
808 <varname>StartLimitInterval=</varname>
809 and
810 <varname>StartLimitBurst=</varname> is
811 hit. Takes one of
812 <option>none</option>,
813 <option>reboot</option>,
814 <option>reboot-force</option> or
815 <option>reboot-immediate</option>. If
816 <option>none</option> is set,
817 hitting the rate limit will trigger no
818 action besides that the start will not
819 be
820 permitted. <option>reboot</option>
821 causes a reboot following the normal
822 shutdown procedure (i.e. equivalent to
823 <command>systemctl reboot</command>),
824 <option>reboot-force</option> causes
825 an forced reboot which will terminate
826 all processes forcibly but should
827 cause no dirty file systems on reboot
828 (i.e. equivalent to <command>systemctl
829 reboot -f</command>) and
830 <option>reboot-immediate</option>
831 causes immediate execution of the
832 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
833 system call, which might result in
834 data loss. Defaults to
835 <option>none</option>.</para></listitem>
836 </varlistentry>
837
838 </variablelist>
839 </refsect1>
840
841 <refsect1>
842 <title>See Also</title>
843 <para>
844 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
845 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
846 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
847 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
848 </para>
849 </refsect1>
850
851 </refentry>