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">
7 This file is part of systemd.
9 Copyright 2010 Lennart Poettering
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.
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.
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/>.
25 <refentry id="systemd.service">
27 <title>systemd.service</title>
28 <productname>systemd</productname>
32 <contrib>Developer</contrib>
33 <firstname>Lennart</firstname>
34 <surname>Poettering</surname>
35 <email>lennart@poettering.net</email>
41 <refentrytitle>systemd.service</refentrytitle>
42 <manvolnum>5</manvolnum>
46 <refname>systemd.service</refname>
47 <refpurpose>Service unit configuration</refpurpose>
51 <para><filename><replaceable>service</replaceable>.service</filename></para>
55 <title>Description</title>
57 <para>A unit configuration file whose name ends in
58 <filename>.service</filename> encodes information
59 about a process controlled and supervised by
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>
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
79 <citerefentry><refentrytitle>systemd.cgroup</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
80 which configure control group settings for the
81 processes of the service.</para>
83 <para>Unless <varname>DefaultDependencies=</varname>
84 is set to <option>false</option>, service units will
85 implicitly have dependencies of type
86 <varname>Requires=</varname> and
87 <varname>After=</varname> on
88 <filename>basic.target</filename> as well as
89 dependencies of type <varname>Conflicts=</varname> and
90 <varname>Before=</varname> on
91 <filename>shutdown.target</filename>. These ensure
92 that normal service units pull in basic system
93 initialization, and are terminated cleanly prior to
94 system shutdown. Only services involved with early
95 boot or late system shutdown should disable this
98 <para>If a service is requested under a certain name
99 but no unit configuration file is found, systemd looks
100 for a SysV init script by the same name (with the
101 <filename>.service</filename> suffix removed) and
102 dynamically creates a service unit from that
103 script. This is useful for compatibility with
104 SysV. Note that this compatibility is quite
105 comprehensive but not 100%. For details about the
106 incompatibilities see the <ulink
107 url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities
108 with SysV</ulink> document.
113 <title>Options</title>
115 <para>Service files must include a
116 <literal>[Service]</literal> section, which carries
117 information about the service and the process it
118 supervises. A number of options that may be used in
119 this section are shared with other unit types. These
120 options are documented in
121 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
123 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
124 options specific to the <literal>[Service]</literal>
125 section of service units are the following:</para>
127 <variablelist class='unit-directives'>
129 <term><varname>Type=</varname></term>
131 <listitem><para>Configures the process
132 start-up type for this service
133 unit. One of <option>simple</option>,
134 <option>forking</option>,
135 <option>oneshot</option>,
136 <option>dbus</option>,
137 <option>notify</option> or
138 <option>idle</option>.</para>
141 <option>simple</option> (the default
142 value if <varname>BusName=</varname>
143 is not specified), it is expected that
144 the process configured with
145 <varname>ExecStart=</varname> is the
146 main process of the service. In this
147 mode, if the process offers
148 functionality to other processes on
149 the system, its communication channels
150 should be installed before the daemon
151 is started up (e.g. sockets set up by
152 systemd, via socket activation), as
153 systemd will immediately proceed
154 starting follow-up units.</para>
157 <option>forking</option>, it is
158 expected that the process configured
159 with <varname>ExecStart=</varname>
160 will call <function>fork()</function>
161 as part of its start-up. The parent process is
162 expected to exit when start-up is
163 complete and all communication
164 channels are set up. The child continues
165 to run as the main daemon
166 process. This is the behavior of
167 traditional UNIX daemons. If this
168 setting is used, it is recommended to
170 <varname>PIDFile=</varname> option, so
171 that systemd can identify the main
172 process of the daemon. systemd will
173 proceed starting follow-up units as
174 soon as the parent process
178 <option>oneshot</option> is similar
179 to <option>simple</option>, however
180 it is expected that the process has to
181 exit before systemd starts follow-up
182 units. <varname>RemainAfterExit=</varname>
183 is particularly useful for this type
187 <option>dbus</option> is similar to
188 <option>simple</option>, however it is
189 expected that the daemon acquires a
190 name on the D-Bus bus, as configured
192 <varname>BusName=</varname>. systemd
193 will proceed starting follow-up units
194 after the D-Bus bus name has been
195 acquired. Service units with this
196 option configured implicitly gain
198 <filename>dbus.socket</filename>
199 unit. This type is the default if
200 <varname>BusName=</varname> is
204 <option>notify</option> is similar to
205 <option>simple</option>, however it is
206 expected that the daemon sends a
207 notification message via
208 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
209 or an equivalent call when it finished
210 starting up. systemd will proceed
211 starting follow-up units after this
212 notification message has been sent. If
214 <varname>NotifyAccess=</varname> (see
215 below) should be set to open access to
216 the notification socket provided by
218 <varname>NotifyAccess=</varname> is
219 not set, it will be implicitly set to
220 <option>main</option>. Note that
222 <varname>Type=</varname><option>notify</option>
223 will not work if used in combination with
224 <varname>PrivateNetwork=</varname><option>yes</option>.</para>
227 <option>idle</option> is very similar
228 to <option>simple</option>, however
229 actual execution of the service
230 binary is delayed until all jobs are
231 dispatched. This may be used to avoid
232 interleaving of output of shell
233 services with the status output on the
239 <term><varname>RemainAfterExit=</varname></term>
241 <listitem><para>Takes a boolean value
242 that specifies whether the service
243 shall be considered active even when
244 all its processes exited. Defaults to
245 <option>no</option>.</para>
250 <term><varname>GuessMainPID=</varname></term>
252 <listitem><para>Takes a boolean value
253 that specifies whether systemd should
254 try to guess the main PID of a service
255 if it cannot be determined
256 reliably. This option is ignored
257 unless <option>Type=forking</option>
258 is set and <option>PIDFile=</option>
259 is unset because for the other types
260 or with an explicitly configured PID
261 file the main PID is always known. The
262 guessing algorithm might come to
263 incorrect conclusions if a daemon
264 consists of more than one process. If
265 the main PID cannot be determined,
266 failure detection and automatic
267 restarting of a service will not work
268 reliably. Defaults to
269 <option>yes</option>.</para>
274 <term><varname>PIDFile=</varname></term>
276 <listitem><para>Takes an absolute file
277 name pointing to the PID file of this
278 daemon. Use of this option is
279 recommended for services where
280 <varname>Type=</varname> is set to
281 <option>forking</option>. systemd will
282 read the PID of the main process of
283 the daemon after start-up of the
284 service. systemd will not write to the
285 file configured here.</para>
290 <term><varname>BusName=</varname></term>
292 <listitem><para>Takes a D-Bus bus
293 name, that this service is reachable
294 as. This option is mandatory for
296 <varname>Type=</varname> is set to
297 <option>dbus</option>, but its use
298 is otherwise recommended as well if
299 the process takes a name on the D-Bus
305 <term><varname>ExecStart=</varname></term>
306 <listitem><para>Commands with their
307 arguments that are executed when this
308 service is started. The first
309 argument must be an absolute path
312 <para>When <varname>Type</varname> is
313 not <option>oneshot</option>, only one
314 command may be given. When
315 <varname>Type=oneshot</varname> is
316 used, more than one command may be
317 specified. Multiple command lines may
318 be concatenated in a single directive,
319 by separating them with semicolons
320 (these semicolons must be passed as
321 separate words). Alternatively, this
322 directive may be specified more than
323 once with the same effect. However,
324 the latter syntax is not recommended
325 for compatibility with parsers
327 <filename>.desktop</filename> files.
328 Lone semicolons may be escaped as
329 <literal>\;</literal>. If the empty
330 string is assigned to this option, the
331 list of commands to start is reset,
332 prior assignments of this option will
333 have no effect.</para>
335 <para>If more than one command is
336 specified, the commands are invoked
337 one by one sequentially in the order
338 they appear in the unit file. If one
339 of the commands fails (and is not
340 prefixed with <literal>-</literal>),
341 other lines are not executed and the
342 unit is considered failed.</para>
345 <varname>Type=forking</varname> is
346 set, the process started via this
347 command line will be considered the
348 main process of the daemon.</para>
350 <para>The command line accepts
351 <literal>%</literal> specifiers as
353 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
354 that the first argument of the command
355 line (i.e. the program to execute) may
356 not include specifiers.</para>
358 <para>Basic environment variable
359 substitution is supported. Use
360 <literal>${FOO}</literal> as part of a
361 word, or as a word of its own on the
362 command line, in which case it will be
363 replaced by the value of the
364 environment variable including all
365 whitespace it contains, resulting in a
367 <literal>$FOO</literal> as a separate
368 word on the command line, in which
369 case it will be replaced by the value
370 of the environment variable split up
371 at whitespace, resulting in zero or
372 more arguments. Note that the first
373 argument (i.e. the program to execute)
374 may not be a variable, since it must
375 be a literal and absolute path
378 <para>Optionally, if the absolute file
379 name is prefixed with
380 <literal>@</literal>, the second token
382 <literal>argv[0]</literal> to the
383 executed process, followed by the
384 further arguments specified. If the
385 absolute filename is prefixed with
386 <literal>-</literal>, an exit code of
387 the command normally considered a
388 failure (i.e. non-zero exit status or
389 abnormal exit due to signal) is ignored
390 and considered success. If both
391 <literal>-</literal> and
392 <literal>@</literal> are used, they
393 can appear in either order.</para>
395 <para>Note that this setting does not
396 directly support shell command
397 lines. If shell command lines are to
398 be used, they need to be passed
399 explicitly to a shell implementation
400 of some kind. Example:</para>
401 <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'
404 <para>For services run by a user
405 instance of systemd the special
407 <varname>$MANAGERPID</varname> is set
408 to the PID of the systemd
414 <term><varname>ExecStartPre=</varname></term>
415 <term><varname>ExecStartPost=</varname></term>
416 <listitem><para>Additional commands
417 that are executed before or after
419 <varname>ExecStart=</varname>, respectively.
420 Syntax is the same as for
421 <varname>ExecStart=</varname>, except
422 that multiple command lines are allowed
423 and the commands are executed one
424 after the other, serially.</para>
426 <para>If any of those commands (not
427 prefixed with <literal>-</literal>)
428 fail, the rest are not executed and
429 the unit is considered failed.</para>
434 <term><varname>ExecReload=</varname></term>
435 <listitem><para>Commands to execute to
436 trigger a configuration reload in the
437 service. This argument takes multiple
438 command lines, following the same
439 scheme as described for
440 <varname>ExecStart=</varname>
441 above. Use of this setting is
442 optional. Specifier and environment
443 variable substitution is supported
444 here following the same scheme as for
445 <varname>ExecStart=</varname>.</para>
447 <para>One additional special
448 environment variables is set: if known
449 <varname>$MAINPID</varname> is set to
450 the main process of the daemon, and
451 may be used for command lines like the
454 <programlisting>/bin/kill -HUP $MAINPID</programlisting>
459 <term><varname>ExecStop=</varname></term>
460 <listitem><para>Commands to execute to
461 stop the service started via
462 <varname>ExecStart=</varname>. This
463 argument takes multiple command lines,
464 following the same scheme as described
465 for <varname>ExecStart=</varname>
466 above. Use of this setting is
467 optional. All processes remaining for
468 a service after the commands
469 configured in this option are run are
470 terminated according to the
471 <varname>KillMode=</varname> setting
473 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
474 this option is not specified, the
475 process is terminated right-away when
476 service stop is requested. Specifier
477 and environment variable substitution
478 is supported (including
479 <varname>$MAINPID</varname>, see
480 above).</para></listitem>
484 <term><varname>ExecStopPost=</varname></term>
485 <listitem><para>Additional commands
486 that are executed after the service
487 was stopped. This includes cases where
488 the commands configured in
489 <varname>ExecStop=</varname> were used,
490 where the service does not have any
491 <varname>ExecStop=</varname> defined, or
492 where the service exited unexpectedly. This
493 argument takes multiple command lines,
494 following the same scheme as described
495 for <varname>ExecStart</varname>. Use
497 optional. Specifier and environment
498 variable substitution is
499 supported.</para></listitem>
503 <term><varname>RestartSec=</varname></term>
504 <listitem><para>Configures the time to
505 sleep before restarting a service (as
507 <varname>Restart=</varname>). Takes a
508 unit-less value in seconds, or a time
509 span value such as "5min
511 100ms.</para></listitem>
515 <term><varname>TimeoutStartSec=</varname></term>
516 <listitem><para>Configures the time to
517 wait for start-up. If a
518 daemon service does not signal
519 start-up completion within the
520 configured time, the service will be
521 considered failed and be shut down
523 Takes a unit-less value in seconds, or a
524 time span value such as "5min
525 20s". Pass 0 to disable the timeout
526 logic. Defaults to 90s, except when
527 <varname>Type=oneshot</varname> is
528 used in which case the timeout
529 is disabled by default.
534 <term><varname>TimeoutStopSec=</varname></term>
535 <listitem><para>Configures the time to
536 wait for stop. If a service is asked
537 to stop but does not terminate in the
538 specified time, it will be terminated
539 forcibly via <constant>SIGTERM</constant>, and after
540 another delay of this time with
541 <constant>SIGKILL</constant> (See
542 <varname>KillMode=</varname>
543 in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
544 Takes a unit-less value in seconds, or a
545 time span value such as "5min
546 20s". Pass 0 to disable the timeout
547 logic. Defaults to 90s.
552 <term><varname>TimeoutSec=</varname></term>
553 <listitem><para>A shorthand for configuring
554 both <varname>TimeoutStartSec=</varname>
555 and <varname>TimeoutStopSec=</varname>
556 to the specified value.
561 <term><varname>WatchdogSec=</varname></term>
562 <listitem><para>Configures the
563 watchdog timeout for a service. The
564 watchdog is activated when the start-up is
565 completed. The service must call
566 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
567 regularly with "WATCHDOG=1" (i.e. the
568 "keep-alive ping"). If the time
569 between two such calls is larger than
570 the configured time, then the service
571 is placed in a failure state. By
572 setting <varname>Restart=</varname> to
573 <option>on-failure</option> or
574 <option>always</option>, the service
575 will be automatically restarted. The
576 time configured here will be passed to
577 the executed service process in the
578 <varname>WATCHDOG_USEC=</varname>
579 environment variable. This allows
580 daemons to automatically enable the
581 keep-alive pinging logic if watchdog
582 support is enabled for the service. If
584 <varname>NotifyAccess=</varname> (see
585 below) should be set to open access to
586 the notification socket provided by
588 <varname>NotifyAccess=</varname> is
589 not set, it will be implicitly set to
590 <option>main</option>. Defaults to 0,
592 feature.</para></listitem>
596 <term><varname>Restart=</varname></term>
597 <listitem><para>Configures whether the
598 service shall be restarted when the
599 service process exits, is killed,
600 or a timeout is reached. The service
601 process may be the main service
602 process, but also one of the processes
604 <varname>ExecStartPre=</varname>,
605 <varname>ExecStartPost=</varname>,
606 <varname>ExecStopPre=</varname>,
607 <varname>ExecStopPost=</varname>, or
608 <varname>ExecReload=</varname>.
609 When the death of the process is a
610 result of systemd operation (e.g. service
611 stop or restart), the service will not be
612 restarted. Timeouts include missing
613 the watchdog "keep-alive ping"
614 deadline and a service start, reload,
615 and stop operation timeouts.</para>
619 <option>on-success</option>,
620 <option>on-failure</option>,
621 <option>on-watchdog</option>,
622 <option>on-abort</option>, or
623 <option>always</option>. If set to
624 <option>no</option> (the default), the
625 service will not be restarted. If set to
626 <option>on-success</option>, it will be
627 restarted only when the service process
629 In this context, a clean exit means
630 an exit code of 0, or one of the signals
631 <constant>SIGHUP</constant>, <constant>SIGINT</constant>, <constant>SIGTERM</constant>, or <constant>SIGPIPE</constant>, and
632 additionally, exit statuses and signals
633 specified in <varname>SuccessExitStatus=</varname>.
634 If set to <option>on-failure</option>,
635 the service will be restarted when the
636 process exits with an nonzero exit code,
637 is terminated by a signal (including on
638 core dump), when an operation (such as
639 service reload) times out, and when the
640 configured watchdog timeout is triggered.
642 <option>on-abort</option>, the service
643 will be restarted only if the service
644 process exits due to an uncaught
645 signal not specified as a clean exit
648 <option>on-watchdog</option>, the service
649 will be restarted only if the watchdog
650 timeout for the service expires.
652 <option>always</option>, the service
653 will be restarted regardless whether
654 it exited cleanly or not, got
655 terminated abnormally by a signal or
656 hit a timeout.</para>
658 <para>In addition to the above settings,
659 the service will not be restarted if the
660 exit code or signal is specified in
661 <varname>RestartPreventExitStatus=</varname>
662 (see below).</para></listitem>
666 <term><varname>SuccessExitStatus=</varname></term>
667 <listitem><para>Takes a list of exit
668 status definitions that when returned
669 by the main service process will be
670 considered successful termination, in
671 addition to the normal successful exit
672 code 0 and the signals <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
673 <constant>SIGTERM</constant> and <constant>SIGPIPE</constant>. Exit status
674 definitions can either be numeric exit
675 codes or termination signal names,
676 separated by spaces. Example:
677 <literal>SuccessExitStatus=1 2 8
678 <constant>SIGKILL</constant></literal>, ensures that exit
679 codes 1, 2, 8 and the termination
680 signal <constant>SIGKILL</constant> are considered clean
681 service terminations. This option may
682 appear more than once in which case
683 the list of successful exit statuses
684 is merged. If the empty string is
685 assigned to this option, the list is
686 reset, all prior assignments of this
688 effect.</para></listitem>
692 <term><varname>RestartPreventExitStatus=</varname></term>
693 <listitem><para>Takes a list of exit
694 status definitions that when returned
695 by the main service process will
696 prevent automatic service restarts
697 regardless of the restart setting
699 <varname>Restart=</varname>. Exit
700 status definitions can either be
701 numeric exit codes or termination
702 signal names, and are separated by
703 spaces. Defaults to the empty list, so
704 that by default no exit status is
705 excluded from the configured restart
707 <literal>RestartPreventExitStatus=1 6
708 SIGABRT</literal>, ensures that exit
709 codes 1 and 6 and the termination
710 signal SIGABRT will not result in
711 automatic service restarting. This
712 option may appear more than once in
713 which case the list of restart preventing
714 statuses is merged. If the empty
715 string is assigned to this option, the
716 list is reset, all prior assignments
717 of this option will have no
718 effect.</para></listitem>
722 <term><varname>PermissionsStartOnly=</varname></term>
723 <listitem><para>Takes a boolean
724 argument. If true, the permission
725 related execution options as
727 <varname>User=</varname> and similar
729 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
730 for more information) are only applied
731 to the process started with
732 <varname>ExecStart=</varname>, and not
734 <varname>ExecStartPre=</varname>,
735 <varname>ExecStartPost=</varname>,
736 <varname>ExecReload=</varname>,
737 <varname>ExecStop=</varname>,
738 <varname>ExecStopPost=</varname>
739 commands. If false, the setting is
740 applied to all configured commands the
741 same way. Defaults to
742 false.</para></listitem>
746 <term><varname>RootDirectoryStartOnly=</varname></term>
747 <listitem><para>Takes a boolean
748 argument. If true, the root directory
749 as configured with the
750 <varname>RootDirectory=</varname>
752 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
753 for more information) is only applied
754 to the process started with
755 <varname>ExecStart=</varname>, and not
757 <varname>ExecStartPre=</varname>,
758 <varname>ExecStartPost=</varname>,
759 <varname>ExecReload=</varname>,
760 <varname>ExecStop=</varname>,
761 <varname>ExecStopPost=</varname>
762 commands. If false, the setting is
763 applied to all configured commands the
764 same way. Defaults to
765 false.</para></listitem>
769 <term><varname>NonBlocking=</varname></term>
770 <listitem><para>Set O_NONBLOCK flag
771 for all file descriptors passed via
772 socket-based activation. If true, all
773 file descriptors >= 3 (i.e. all except
774 STDIN/STDOUT/STDERR) will have
775 the O_NONBLOCK flag set and hence are in
776 non-blocking mode. This option is only
777 useful in conjunction with a socket
778 unit, as described in
779 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
780 to false.</para></listitem>
784 <term><varname>NotifyAccess=</varname></term>
785 <listitem><para>Controls access to the
786 service status notification socket, as
788 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
790 <option>none</option> (the default),
791 <option>main</option> or
792 <option>all</option>. If
793 <option>none</option>, no daemon status
794 updates are accepted from the service
795 processes, all status update messages
796 are ignored. If <option>main</option>,
797 only service updates sent from the
798 main process of the service are
799 accepted. If <option>all</option>, all
800 services updates from all members of
801 the service's control group are
802 accepted. This option should be set to
803 open access to the notification socket
805 <varname>Type=notify</varname> or
806 <varname>WatchdogSec=</varname> (see
807 above). If those options are used but
808 <varname>NotifyAccess=</varname> is not
809 configured, it will be implicitly set
811 <option>main</option>.</para></listitem>
815 <term><varname>Sockets=</varname></term>
816 <listitem><para>Specifies the name of
817 the socket units this service shall
818 inherit the sockets from when the
819 service is started. Normally it
820 should not be necessary to use this
821 setting as all sockets whose unit
822 shares the same name as the service
823 (ignoring the different suffix of course)
824 are passed to the spawned
827 <para>Note that the same socket may be
828 passed to multiple processes at the
829 same time. Also note that a different
830 service may be activated on incoming
831 traffic than inherits the sockets. Or
833 <varname>Service=</varname> setting of
834 <filename>.socket</filename> units
835 does not have to match the inverse of
836 the <varname>Sockets=</varname>
838 <filename>.service</filename> it
841 <para>This option may appear more than
842 once, in which case the list of socket
843 units is merged. If the empty string
844 is assigned to this option, the list of
845 sockets is reset, all prior uses of
846 this setting will have no
847 effect.</para></listitem>
851 <term><varname>StartLimitInterval=</varname></term>
852 <term><varname>StartLimitBurst=</varname></term>
854 <listitem><para>Configure service
855 start rate limiting. By default,
856 services which are started more often
857 than 5 times within 10s are not
858 permitted to start any more times
859 until the 10s interval ends. With
860 these two options, this rate limiting
862 <varname>StartLimitInterval=</varname>
863 to configure the checking interval
864 (defaults to 10s, set to 0 to disable
865 any kind of rate limiting). Use
866 <varname>StartLimitBurst=</varname> to
867 configure how many starts per interval
868 are allowed (defaults to 5). These
869 configuration options are particularly
870 useful in conjunction with
871 <varname>Restart=</varname>, however
872 apply to all kinds of starts
873 (including manual), not just those
875 <varname>Restart=</varname> logic.
876 Note that units which are configured
877 for <varname>Restart=</varname> and
878 which reach the start limit are not
879 attempted to be restarted anymore,
880 however they may still be restarted
881 manually at a later point from which
882 point on the restart logic is again
885 reset-failed</command> will cause the
886 restart rate counter for a service to
887 be flushed, which is useful if the
888 administrator wants to manually start
889 a service and the start limit
891 that.</para></listitem>
895 <term><varname>StartLimitAction=</varname></term>
897 <listitem><para>Configure the action
898 to take if the rate limit configured
900 <varname>StartLimitInterval=</varname>
902 <varname>StartLimitBurst=</varname> is
904 <option>none</option>,
905 <option>reboot</option>,
906 <option>reboot-force</option> or
907 <option>reboot-immediate</option>. If
908 <option>none</option> is set,
909 hitting the rate limit will trigger no
910 action besides that the start will not
912 permitted. <option>reboot</option>
913 causes a reboot following the normal
914 shutdown procedure (i.e. equivalent to
915 <command>systemctl reboot</command>),
916 <option>reboot-force</option> causes
917 an forced reboot which will terminate
918 all processes forcibly but should
919 cause no dirty file systems on reboot
920 (i.e. equivalent to <command>systemctl
921 reboot -f</command>) and
922 <option>reboot-immediate</option>
923 causes immediate execution of the
924 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
925 system call, which might result in
926 data loss. Defaults to
927 <option>none</option>.</para></listitem>
933 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
935 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
936 for more settings.</para>
941 <title>Compatibility Options</title>
943 <para>The following options are also available in the
944 <literal>[Service]</literal> section, but exist purely
945 for compatibility reasons and should not be used in
946 newly written service files.</para>
948 <variablelist class='unit-directives'>
950 <term><varname>SysVStartPriority=</varname></term>
951 <listitem><para>Set the SysV start
952 priority to use to order this service
953 in relation to SysV services lacking
954 LSB headers. This option is only
955 necessary to fix ordering in relation
956 to legacy SysV services, that have no
957 ordering information encoded in the
958 script headers. As such it should only
959 be used as temporary compatibility
960 option, and not be used in new unit
961 files. Almost always it is a better
962 choice to add explicit ordering
964 <varname>After=</varname> or
965 <varname>Before=</varname>,
966 instead. For more details see
967 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
968 used, pass an integer value in the
969 range 0-99.</para></listitem>
973 <term><varname>FsckPassNo=</varname></term>
974 <listitem><para>Set the fsck passno
975 priority to use to order this service
976 in relation to other file system
977 checking services. This option is only
978 necessary to fix ordering in relation
979 to fsck jobs automatically created for
980 all <filename>/etc/fstab</filename>
981 entries with a value in the fs_passno
982 column > 0. As such it should only be
983 used as option for fsck
984 services. Almost always it is a better
985 choice to add explicit ordering
987 <varname>After=</varname> or
988 <varname>Before=</varname>,
989 instead. For more details see
990 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
991 used, pass an integer value in the
993 <filename>/etc/fstab</filename>'s
994 fs_passno column. See
995 <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
996 for details.</para></listitem>
1003 <title>See Also</title>
1005 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1006 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1007 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1008 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1009 <citerefentry><refentrytitle>systemd.cgroup</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1010 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1011 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>