]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.service.xml
man: extend watchdog docs a bit
[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, except when <varname>Type=oneshot</varname> is
474 used in which case the timeout
475 is disabled by default.</para></listitem>
476 </varlistentry>
477
478 <varlistentry>
479 <term><varname>WatchdogSec=</varname></term>
480 <listitem><para>Configures the
481 watchdog timeout for a service. This
482 is activated when the start-up is
483 completed. The service must call
484 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
485 regularly with "WATCHDOG=1" (i.e. the
486 "keep-alive ping"). If the time
487 between two such calls is larger than
488 the configured time then the service
489 is placed in a failure state. By
490 setting <varname>Restart=</varname> to
491 <option>on-failure</option> or
492 <option>always</option> the service
493 will be automatically restarted. The
494 time configured here will be passed to
495 the executed service process in the
496 <varname>WATCHDOG_USEC=</varname>
497 environment variable. This allows
498 daemons to automatically enable the
499 keep-alive pinging logic if watchdog
500 support is enabled for the service. If
501 this option is used
502 <varname>NotifyAccess=</varname> (see
503 below) should be set to open access to
504 the notification socket provided by
505 systemd. If
506 <varname>NotifyAccess=</varname> is
507 not set, it will be implicitly set to
508 <option>main</option>. Defaults to 0,
509 which disables this
510 feature.</para></listitem>
511 </varlistentry>
512
513 <varlistentry>
514 <term><varname>Restart=</varname></term>
515 <listitem><para>Configures whether the
516 main service process shall be
517 restarted when it exits. Takes one of
518 <option>no</option>,
519 <option>on-success</option>,
520 <option>on-failure</option>,
521 <option>on-abort</option> or
522 <option>always</option>. If set to
523 <option>no</option> (the default) the
524 service will not be restarted when it
525 exits. If set to
526 <option>on-success</option> it will be
527 restarted only when it exited cleanly,
528 i.e. terminated with an exit code of
529 0. If set to
530 <option>on-failure</option> it will be
531 restarted only when it exited with an
532 exit code not equalling 0, when
533 terminated by a signal, when an
534 operation times out or when the
535 configured watchdog timeout is
536 triggered. If set to
537 <option>on-abort</option> it will be
538 restarted only if it exits due to
539 reception of an uncaught signal. If
540 set to <option>always</option> the
541 service will be restarted regardless
542 whether it exited cleanly or not,
543 got terminated abnormally by a
544 signal or hit a timeout.</para></listitem>
545 </varlistentry>
546
547 <varlistentry>
548 <term><varname>PermissionsStartOnly=</varname></term>
549 <listitem><para>Takes a boolean
550 argument. If true, the permission
551 related execution options as
552 configured with
553 <varname>User=</varname> and similar
554 options (see
555 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
556 for more information) are only applied
557 to the process started with
558 <varname>ExecStart=</varname>, and not
559 to the various other
560 <varname>ExecStartPre=</varname>,
561 <varname>ExecStartPost=</varname>,
562 <varname>ExecReload=</varname>,
563 <varname>ExecStop=</varname>,
564 <varname>ExecStopPost=</varname>
565 commands. If false, the setting is
566 applied to all configured commands the
567 same way. Defaults to
568 false.</para></listitem>
569 </varlistentry>
570
571 <varlistentry>
572 <term><varname>RootDirectoryStartOnly=</varname></term>
573 <listitem><para>Takes a boolean
574 argument. If true, the root directory
575 as configured with the
576 <varname>RootDirectory=</varname>
577 option (see
578 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
579 for more information) is only applied
580 to the process started with
581 <varname>ExecStart=</varname>, and not
582 to the various other
583 <varname>ExecStartPre=</varname>,
584 <varname>ExecStartPost=</varname>,
585 <varname>ExecReload=</varname>,
586 <varname>ExecStop=</varname>,
587 <varname>ExecStopPost=</varname>
588 commands. If false, the setting is
589 applied to all configured commands the
590 same way. Defaults to
591 false.</para></listitem>
592 </varlistentry>
593
594 <varlistentry>
595 <term><varname>KillMode=</varname></term>
596 <listitem><para>Specifies how
597 processes of this service shall be
598 killed. One of
599 <option>control-group</option>,
600 <option>process</option>,
601 <option>none</option>.</para>
602
603 <para>If set to
604 <option>control-group</option> all
605 remaining processes in the control
606 group of this service will be
607 terminated on service stop, after the
608 stop command (as configured with
609 <varname>ExecStop=</varname>) is
610 executed. If set to
611 <option>process</option> only the main
612 process itself is killed. If set to
613 <option>none</option> no process is
614 killed. In this case only the stop
615 command will be executed on service
616 stop, but no process be killed
617 otherwise. Processes remaining alive
618 after stop are left in their control
619 group and the control group continues
620 to exist after stop unless it is
621 empty. Defaults to
622 <option>control-group</option>.</para>
623
624 <para>Processes will first be
625 terminated via SIGTERM (unless the
626 signal to send is changed via
627 <varname>KillSignal=</varname>). If
628 then after a delay (configured via the
629 <varname>TimeoutSec=</varname> option)
630 processes still remain, the
631 termination request is repeated with
632 the SIGKILL signal (unless this is
633 disabled via the
634 <varname>SendSIGKILL=</varname>
635 option). See
636 <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
637 for more
638 information.</para></listitem>
639 </varlistentry>
640
641 <varlistentry>
642 <term><varname>KillSignal=</varname></term>
643 <listitem><para>Specifies which signal
644 to use when killing a
645 service. Defaults to SIGTERM.
646 </para></listitem>
647 </varlistentry>
648
649 <varlistentry>
650 <term><varname>SendSIGKILL=</varname></term>
651 <listitem><para>Specifies whether to
652 send SIGKILL to remaining processes
653 after a timeout, if the normal
654 shutdown procedure left processes of
655 the service around. Takes a boolean
656 value. Defaults to "yes".
657 </para></listitem>
658 </varlistentry>
659
660 <varlistentry>
661 <term><varname>NonBlocking=</varname></term>
662 <listitem><para>Set O_NONBLOCK flag
663 for all file descriptors passed via
664 socket-based activation. If true, all
665 file descriptors >= 3 (i.e. all except
666 STDIN/STDOUT/STDERR) will have
667 the O_NONBLOCK flag set and hence are in
668 non-blocking mode. This option is only
669 useful in conjunction with a socket
670 unit, as described in
671 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
672 to false.</para></listitem>
673 </varlistentry>
674
675 <varlistentry>
676 <term><varname>NotifyAccess=</varname></term>
677 <listitem><para>Controls access to the
678 service status notification socket, as
679 accessible via the
680 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
681 call. Takes one of
682 <option>none</option> (the default),
683 <option>main</option> or
684 <option>all</option>. If
685 <option>none</option> no daemon status
686 updates are accepted from the service
687 processes, all status update messages
688 are ignored. If <option>main</option>
689 only service updates sent from the
690 main process of the service are
691 accepted. If <option>all</option> all
692 services updates from all members of
693 the service's control group are
694 accepted. This option should be set to
695 open access to the notification socket
696 when using
697 <varname>Type=notify</varname> or
698 <varname>WatchdogUsec=</varname> (see
699 above). If those options are used but
700 <varname>NotifyAccess=</varname> not
701 configured it will be implicitly set
702 to
703 <option>main</option>.</para></listitem>
704 </varlistentry>
705
706 <varlistentry>
707 <term><varname>Sockets=</varname></term>
708 <listitem><para>Specifies the name of
709 the socket units this service shall
710 inherit the sockets from when the
711 service is started. Normally it
712 should not be necessary to use this
713 setting as all sockets whose unit
714 shares the same name as the service
715 (ignoring the different suffix of course)
716 are passed to the spawned
717 process.</para>
718
719 <para>Note that the same socket may be
720 passed to multiple processes at the
721 same time. Also note that a different
722 service may be activated on incoming
723 traffic than inherits the sockets. Or
724 in other words: The
725 <varname>Service=</varname> setting of
726 <filename>.socket</filename> units
727 doesn't have to match the inverse of the
728 <varname>Sockets=</varname> setting of
729 the <filename>.service</filename> it
730 refers to.</para></listitem>
731 </varlistentry>
732
733 <varlistentry>
734 <term><varname>StartLimitInterval=</varname></term>
735 <term><varname>StartLimitBurst=</varname></term>
736
737 <listitem><para>Configure service
738 start rate limiting. By default
739 services which are started more often
740 than 5 times within 10s are not
741 permitted to start any more times
742 until the 10s interval ends. With
743 these two options this rate limiting
744 may be modified. Use
745 <varname>StartLimitInterval=</varname>
746 to configure the checking interval
747 (defaults to 10s, set to 0 to disable
748 any kind of rate limiting). Use
749 <varname>StartLimitBurst=</varname> to
750 configure how many starts per interval
751 are allowed (defaults to 5). These
752 configuration options are particularly
753 useful in conjunction with
754 <varname>Restart=</varname>.</para></listitem>
755 </varlistentry>
756
757 <varlistentry>
758 <term><varname>StartLimitAction=</varname></term>
759
760 <listitem><para>Configure the action
761 to take if the rate limit configured
762 with
763 <varname>StartLimitInterval=</varname>
764 and
765 <varname>StartLimitBurst=</varname> is
766 hit. Takes one of
767 <option>none</option>,
768 <option>reboot</option>,
769 <option>reboot-force</option> or
770 <option>reboot-immediate</option>. If
771 <option>none</option> is set,
772 hitting the rate limit will trigger no
773 action besides that the start will not
774 be
775 permitted. <option>reboot</option>
776 causes a reboot following the normal
777 shutdown procedure (i.e. equivalent to
778 <command>systemctl reboot</command>),
779 <option>reboot-force</option> causes
780 an forced reboot which will terminate
781 all processes forcibly but should
782 cause no dirty file systems on reboot
783 (i.e. equivalent to <command>systemctl
784 reboot -f</command>) and
785 <option>reboot-immediate</option>
786 causes immediate execution of the
787 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
788 system call, which might result in
789 data loss. Defaults to
790 <option>none</option>.</para></listitem>
791 </varlistentry>
792
793 </variablelist>
794 </refsect1>
795
796 <refsect1>
797 <title>Compatibility Options</title>
798
799 <para>The following options are also available in the
800 <literal>[Service]</literal> section, but exist purely
801 for compatibility reasons and should not be used in
802 newly written service files.</para>
803
804 <variablelist>
805 <varlistentry>
806 <term><varname>SysVStartPriority=</varname></term>
807 <listitem><para>Set the SysV start
808 priority to use to order this service
809 in relation to SysV services lacking
810 LSB headers. This option is only
811 necessary to fix ordering in relation
812 to legacy SysV services, that have no
813 ordering information encoded in the
814 script headers. As such it should only
815 be used as temporary compatibility
816 option, and not be used in new unit
817 files. Almost always it is a better
818 choice to add explicit ordering
819 directives via
820 <varname>After=</varname> or
821 <varname>Before=</varname>,
822 instead. For more details see
823 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
824 used, pass an integer value in the
825 range 0-99.</para></listitem>
826 </varlistentry>
827
828 <varlistentry>
829 <term><varname>FsckPassNo=</varname></term>
830 <listitem><para>Set the fsck passno
831 priority to use to order this service
832 in relation to other file system
833 checking services. This option is only
834 necessary to fix ordering in relation
835 to fsck jobs automatically created for
836 all <filename>/etc/fstab</filename>
837 entries with a value in the fs_passno
838 column > 0. As such it should only be
839 used as option for fsck
840 services. Almost always it is a better
841 choice to add explicit ordering
842 directives via
843 <varname>After=</varname> or
844 <varname>Before=</varname>,
845 instead. For more details see
846 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
847 used, pass an integer value in the
848 same range as
849 <filename>/etc/fstab</filename>'s
850 fs_passno column. See
851 <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
852 for details.</para></listitem>
853 </varlistentry>
854
855 </variablelist>
856 </refsect1>
857
858 <refsect1>
859 <title>See Also</title>
860 <para>
861 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
862 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
863 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
864 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
865 </para>
866 </refsect1>
867
868 </refentry>