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