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