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