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.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
80 which configure resource control 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. To pass a literal dollar sign,
373 use <literal>$$</literal>. Note that the first
374 argument (i.e. the program to execute)
375 may not be a variable, since it must
376 be a literal and absolute path
379 <para>Optionally, if the absolute file
380 name is prefixed with
381 <literal>@</literal>, the second token
383 <literal>argv[0]</literal> to the
384 executed process, followed by the
385 further arguments specified. If the
386 absolute filename is prefixed with
387 <literal>-</literal>, an exit code of
388 the command normally considered a
389 failure (i.e. non-zero exit status or
390 abnormal exit due to signal) is ignored
391 and considered success. If both
392 <literal>-</literal> and
393 <literal>@</literal> are used, they
394 can appear in either order.</para>
396 <para>Note that this setting does not
397 directly support shell command
398 lines. If shell command lines are to
399 be used, they need to be passed
400 explicitly to a shell implementation
401 of some kind. Example:</para>
402 <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'
405 <para>For services run by a user
406 instance of systemd the special
408 <varname>$MANAGERPID</varname> is set
409 to the PID of the systemd
415 <term><varname>ExecStartPre=</varname></term>
416 <term><varname>ExecStartPost=</varname></term>
417 <listitem><para>Additional commands
418 that are executed before or after
420 <varname>ExecStart=</varname>, respectively.
421 Syntax is the same as for
422 <varname>ExecStart=</varname>, except
423 that multiple command lines are allowed
424 and the commands are executed one
425 after the other, serially.</para>
427 <para>If any of those commands (not
428 prefixed with <literal>-</literal>)
429 fail, the rest are not executed and
430 the unit is considered failed.</para>
435 <term><varname>ExecReload=</varname></term>
436 <listitem><para>Commands to execute to
437 trigger a configuration reload in the
438 service. This argument takes multiple
439 command lines, following the same
440 scheme as described for
441 <varname>ExecStart=</varname>
442 above. Use of this setting is
443 optional. Specifier and environment
444 variable substitution is supported
445 here following the same scheme as for
446 <varname>ExecStart=</varname>.</para>
448 <para>One additional special
449 environment variables is set: if known
450 <varname>$MAINPID</varname> is set to
451 the main process of the daemon, and
452 may be used for command lines like the
455 <programlisting>/bin/kill -HUP $MAINPID</programlisting>
460 <term><varname>ExecStop=</varname></term>
461 <listitem><para>Commands to execute to
462 stop the service started via
463 <varname>ExecStart=</varname>. This
464 argument takes multiple command lines,
465 following the same scheme as described
466 for <varname>ExecStart=</varname>
467 above. Use of this setting is
468 optional. All processes remaining for
469 a service after the commands
470 configured in this option are run are
471 terminated according to the
472 <varname>KillMode=</varname> setting
474 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
475 this option is not specified, the
476 process is terminated right-away when
477 service stop is requested. Specifier
478 and environment variable substitution
479 is supported (including
480 <varname>$MAINPID</varname>, see
481 above).</para></listitem>
485 <term><varname>ExecStopPost=</varname></term>
486 <listitem><para>Additional commands
487 that are executed after the service
488 was stopped. This includes cases where
489 the commands configured in
490 <varname>ExecStop=</varname> were used,
491 where the service does not have any
492 <varname>ExecStop=</varname> defined, or
493 where the service exited unexpectedly. This
494 argument takes multiple command lines,
495 following the same scheme as described
496 for <varname>ExecStart</varname>. Use
498 optional. Specifier and environment
499 variable substitution is
500 supported.</para></listitem>
504 <term><varname>RestartSec=</varname></term>
505 <listitem><para>Configures the time to
506 sleep before restarting a service (as
508 <varname>Restart=</varname>). Takes a
509 unit-less value in seconds, or a time
510 span value such as "5min
512 100ms.</para></listitem>
516 <term><varname>TimeoutStartSec=</varname></term>
517 <listitem><para>Configures the time to
518 wait for start-up. If a
519 daemon service does not signal
520 start-up completion within the
521 configured time, the service will be
522 considered failed and be shut down
524 Takes a unit-less value in seconds, or a
525 time span value such as "5min
526 20s". Pass 0 to disable the timeout
527 logic. Defaults to <varname>TimeoutStartSec=</varname> from the
528 manager configuration file, except when
529 <varname>Type=oneshot</varname> is
530 used, in which case the timeout
531 is disabled by default.
536 <term><varname>TimeoutStopSec=</varname></term>
537 <listitem><para>Configures the time to
538 wait for stop. If a service is asked
539 to stop but does not terminate in the
540 specified time, it will be terminated
541 forcibly via <constant>SIGTERM</constant>, and after
542 another delay of this time with
543 <constant>SIGKILL</constant> (See
544 <varname>KillMode=</varname>
545 in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
546 Takes a unit-less value in seconds, or a
547 time span value such as "5min
548 20s". Pass 0 to disable the timeout
549 logic. Defaults to <varname>TimeoutStartSec=</varname> from the
550 manager configuration file.
555 <term><varname>TimeoutSec=</varname></term>
556 <listitem><para>A shorthand for configuring
557 both <varname>TimeoutStartSec=</varname>
558 and <varname>TimeoutStopSec=</varname>
559 to the specified value.
564 <term><varname>WatchdogSec=</varname></term>
565 <listitem><para>Configures the
566 watchdog timeout for a service. The
567 watchdog is activated when the start-up is
568 completed. The service must call
569 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
570 regularly with "WATCHDOG=1" (i.e. the
571 "keep-alive ping"). If the time
572 between two such calls is larger than
573 the configured time, then the service
574 is placed in a failure state. By
575 setting <varname>Restart=</varname> to
576 <option>on-failure</option> or
577 <option>always</option>, the service
578 will be automatically restarted. The
579 time configured here will be passed to
580 the executed service process in the
581 <varname>WATCHDOG_USEC=</varname>
582 environment variable. This allows
583 daemons to automatically enable the
584 keep-alive pinging logic if watchdog
585 support is enabled for the service. If
587 <varname>NotifyAccess=</varname> (see
588 below) should be set to open access to
589 the notification socket provided by
591 <varname>NotifyAccess=</varname> is
592 not set, it will be implicitly set to
593 <option>main</option>. Defaults to 0,
595 feature.</para></listitem>
599 <term><varname>Restart=</varname></term>
600 <listitem><para>Configures whether the
601 service shall be restarted when the
602 service process exits, is killed,
603 or a timeout is reached. The service
604 process may be the main service
605 process, but also one of the processes
607 <varname>ExecStartPre=</varname>,
608 <varname>ExecStartPost=</varname>,
609 <varname>ExecStopPre=</varname>,
610 <varname>ExecStopPost=</varname>, or
611 <varname>ExecReload=</varname>.
612 When the death of the process is a
613 result of systemd operation (e.g. service
614 stop or restart), the service will not be
615 restarted. Timeouts include missing
616 the watchdog "keep-alive ping"
617 deadline and a service start, reload,
618 and stop operation timeouts.</para>
622 <option>on-success</option>,
623 <option>on-failure</option>,
624 <option>on-watchdog</option>,
625 <option>on-abort</option>, or
626 <option>always</option>. If set to
627 <option>no</option> (the default), the
628 service will not be restarted. If set to
629 <option>on-success</option>, it will be
630 restarted only when the service process
632 In this context, a clean exit means
633 an exit code of 0, or one of the signals
634 <constant>SIGHUP</constant>, <constant>SIGINT</constant>, <constant>SIGTERM</constant>, or <constant>SIGPIPE</constant>, and
635 additionally, exit statuses and signals
636 specified in <varname>SuccessExitStatus=</varname>.
637 If set to <option>on-failure</option>,
638 the service will be restarted when the
639 process exits with an nonzero exit code,
640 is terminated by a signal (including on
641 core dump), when an operation (such as
642 service reload) times out, and when the
643 configured watchdog timeout is triggered.
645 <option>on-abort</option>, the service
646 will be restarted only if the service
647 process exits due to an uncaught
648 signal not specified as a clean exit
651 <option>on-watchdog</option>, the service
652 will be restarted only if the watchdog
653 timeout for the service expires.
655 <option>always</option>, the service
656 will be restarted regardless whether
657 it exited cleanly or not, got
658 terminated abnormally by a signal or
659 hit a timeout.</para>
661 <para>In addition to the above settings,
662 the service will not be restarted if the
663 exit code or signal is specified in
664 <varname>RestartPreventExitStatus=</varname>
665 (see below).</para></listitem>
669 <term><varname>SuccessExitStatus=</varname></term>
670 <listitem><para>Takes a list of exit
671 status definitions that when returned
672 by the main service process will be
673 considered successful termination, in
674 addition to the normal successful exit
675 code 0 and the signals <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
676 <constant>SIGTERM</constant> and <constant>SIGPIPE</constant>. Exit status
677 definitions can either be numeric exit
678 codes or termination signal names,
679 separated by spaces. Example:
680 <literal>SuccessExitStatus=1 2 8
681 <constant>SIGKILL</constant></literal>, ensures that exit
682 codes 1, 2, 8 and the termination
683 signal <constant>SIGKILL</constant> are considered clean
684 service terminations. This option may
685 appear more than once in which case
686 the list of successful exit statuses
687 is merged. If the empty string is
688 assigned to this option, the list is
689 reset, all prior assignments of this
691 effect.</para></listitem>
695 <term><varname>RestartPreventExitStatus=</varname></term>
696 <listitem><para>Takes a list of exit
697 status definitions that when returned
698 by the main service process will
699 prevent automatic service restarts
700 regardless of the restart setting
702 <varname>Restart=</varname>. Exit
703 status definitions can either be
704 numeric exit codes or termination
705 signal names, and are separated by
706 spaces. Defaults to the empty list, so
707 that by default no exit status is
708 excluded from the configured restart
710 <literal>RestartPreventExitStatus=1 6
711 SIGABRT</literal>, ensures that exit
712 codes 1 and 6 and the termination
713 signal SIGABRT will not result in
714 automatic service restarting. This
715 option may appear more than once in
716 which case the list of restart preventing
717 statuses is merged. If the empty
718 string is assigned to this option, the
719 list is reset, all prior assignments
720 of this option will have no
721 effect.</para></listitem>
725 <term><varname>PermissionsStartOnly=</varname></term>
726 <listitem><para>Takes a boolean
727 argument. If true, the permission
728 related execution options as
730 <varname>User=</varname> and similar
732 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
733 for more information) are only applied
734 to the process started with
735 <varname>ExecStart=</varname>, and not
737 <varname>ExecStartPre=</varname>,
738 <varname>ExecStartPost=</varname>,
739 <varname>ExecReload=</varname>,
740 <varname>ExecStop=</varname>,
741 <varname>ExecStopPost=</varname>
742 commands. If false, the setting is
743 applied to all configured commands the
744 same way. Defaults to
745 false.</para></listitem>
749 <term><varname>RootDirectoryStartOnly=</varname></term>
750 <listitem><para>Takes a boolean
751 argument. If true, the root directory
752 as configured with the
753 <varname>RootDirectory=</varname>
755 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
756 for more information) is only applied
757 to the process started with
758 <varname>ExecStart=</varname>, and not
760 <varname>ExecStartPre=</varname>,
761 <varname>ExecStartPost=</varname>,
762 <varname>ExecReload=</varname>,
763 <varname>ExecStop=</varname>,
764 <varname>ExecStopPost=</varname>
765 commands. If false, the setting is
766 applied to all configured commands the
767 same way. Defaults to
768 false.</para></listitem>
772 <term><varname>NonBlocking=</varname></term>
773 <listitem><para>Set O_NONBLOCK flag
774 for all file descriptors passed via
775 socket-based activation. If true, all
776 file descriptors >= 3 (i.e. all except
777 STDIN/STDOUT/STDERR) will have
778 the O_NONBLOCK flag set and hence are in
779 non-blocking mode. This option is only
780 useful in conjunction with a socket
781 unit, as described in
782 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
783 to false.</para></listitem>
787 <term><varname>NotifyAccess=</varname></term>
788 <listitem><para>Controls access to the
789 service status notification socket, as
791 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
793 <option>none</option> (the default),
794 <option>main</option> or
795 <option>all</option>. If
796 <option>none</option>, no daemon status
797 updates are accepted from the service
798 processes, all status update messages
799 are ignored. If <option>main</option>,
800 only service updates sent from the
801 main process of the service are
802 accepted. If <option>all</option>, all
803 services updates from all members of
804 the service's control group are
805 accepted. This option should be set to
806 open access to the notification socket
808 <varname>Type=notify</varname> or
809 <varname>WatchdogSec=</varname> (see
810 above). If those options are used but
811 <varname>NotifyAccess=</varname> is not
812 configured, it will be implicitly set
814 <option>main</option>.</para></listitem>
818 <term><varname>Sockets=</varname></term>
819 <listitem><para>Specifies the name of
820 the socket units this service shall
821 inherit the sockets from when the
822 service is started. Normally it
823 should not be necessary to use this
824 setting as all sockets whose unit
825 shares the same name as the service
826 (ignoring the different suffix of course)
827 are passed to the spawned
830 <para>Note that the same socket may be
831 passed to multiple processes at the
832 same time. Also note that a different
833 service may be activated on incoming
834 traffic than inherits the sockets. Or
836 <varname>Service=</varname> setting of
837 <filename>.socket</filename> units
838 does not have to match the inverse of
839 the <varname>Sockets=</varname>
841 <filename>.service</filename> it
844 <para>This option may appear more than
845 once, in which case the list of socket
846 units is merged. If the empty string
847 is assigned to this option, the list of
848 sockets is reset, all prior uses of
849 this setting will have no
850 effect.</para></listitem>
854 <term><varname>StartLimitInterval=</varname></term>
855 <term><varname>StartLimitBurst=</varname></term>
857 <listitem><para>Configure service
858 start rate limiting. By default,
859 services which are started more often
860 than 5 times within 10s are not
861 permitted to start any more times
862 until the 10s interval ends. With
863 these two options, this rate limiting
865 <varname>StartLimitInterval=</varname>
866 to configure the checking interval (defaults to
867 <varname>DefaultStartLimitInterval=</varname> in
868 manager configuration file, set to 0 to disable
869 any kind of rate limiting). Use
870 <varname>StartLimitBurst=</varname> to
871 configure how many starts per interval
872 are allowed (defaults to
873 <varname>DefaultStartLimitBurst=</varname> in
874 manager configuration file). These
875 configuration options are particularly
876 useful in conjunction with
877 <varname>Restart=</varname>, however
878 apply to all kinds of starts
879 (including manual), not just those
881 <varname>Restart=</varname> logic.
882 Note that units which are configured
883 for <varname>Restart=</varname> and
884 which reach the start limit are not
885 attempted to be restarted anymore,
886 however they may still be restarted
887 manually at a later point from which
888 point on the restart logic is again
891 reset-failed</command> will cause the
892 restart rate counter for a service to
893 be flushed, which is useful if the
894 administrator wants to manually start
895 a service and the start limit
897 that.</para></listitem>
901 <term><varname>StartLimitAction=</varname></term>
903 <listitem><para>Configure the action
904 to take if the rate limit configured
906 <varname>StartLimitInterval=</varname>
908 <varname>StartLimitBurst=</varname> is
910 <option>none</option>,
911 <option>reboot</option>,
912 <option>reboot-force</option> or
913 <option>reboot-immediate</option>. If
914 <option>none</option> is set,
915 hitting the rate limit will trigger no
916 action besides that the start will not
918 permitted. <option>reboot</option>
919 causes a reboot following the normal
920 shutdown procedure (i.e. equivalent to
921 <command>systemctl reboot</command>),
922 <option>reboot-force</option> causes
923 an forced reboot which will terminate
924 all processes forcibly but should
925 cause no dirty file systems on reboot
926 (i.e. equivalent to <command>systemctl
927 reboot -f</command>) and
928 <option>reboot-immediate</option>
929 causes immediate execution of the
930 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
931 system call, which might result in
932 data loss. Defaults to
933 <option>none</option>.</para></listitem>
939 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
941 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
942 for more settings.</para>
947 <title>Compatibility Options</title>
949 <para>The following options are also available in the
950 <literal>[Service]</literal> section, but exist purely
951 for compatibility reasons and should not be used in
952 newly written service files.</para>
954 <variablelist class='unit-directives'>
956 <term><varname>SysVStartPriority=</varname></term>
957 <listitem><para>Set the SysV start
958 priority to use to order this service
959 in relation to SysV services lacking
960 LSB headers. This option is only
961 necessary to fix ordering in relation
962 to legacy SysV services, that have no
963 ordering information encoded in the
964 script headers. As such it should only
965 be used as temporary compatibility
966 option, and not be used in new unit
967 files. Almost always it is a better
968 choice to add explicit ordering
970 <varname>After=</varname> or
971 <varname>Before=</varname>,
972 instead. For more details see
973 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
974 used, pass an integer value in the
975 range 0-99.</para></listitem>
982 <title>See Also</title>
984 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
985 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
986 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
987 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
988 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
989 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
990 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>