]> git.ipfire.org Git - thirdparty/systemd.git/blob - man/systemd.service.xml
Reword sentences that contain psuedo-English "resp."
[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 behavior 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>Behavior 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>Behavior 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>Behavior 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>Behavior 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>
360
361 <para>Note that this setting does not
362 directly support shell command
363 lines. If shell command lines are to
364 be used they need to be passed
365 explicitly to a shell implementation
366 of some kind. Example:
367 <literal>ExecStart=/bin/sh -c 'dmesg | tac'</literal></para>
368 </listitem>
369 </varlistentry>
370
371 <varlistentry>
372 <term><varname>ExecStartPre=</varname></term>
373 <term><varname>ExecStartPost=</varname></term>
374 <listitem><para>Additional commands
375 that are executed before or after
376 the command in
377 <varname>ExecStart=</varname>, respectively. Multiple
378 command lines may be concatenated in a
379 single directive, by separating them
380 by semicolons (these semicolons must
381 be passed as separate words). In that
382 case, the commands are executed one
383 after the other,
384 serially. Alternatively, these
385 directives may be specified more than
386 once with the same effect. However,
387 the latter syntax is not recommended
388 for compatibility with parsers
389 suitable for XDG
390 <filename>.desktop</filename> files.
391 Use of these settings is
392 optional. Specifier and environment
393 variable substitution is
394 supported.</para></listitem>
395 </varlistentry>
396
397 <varlistentry>
398 <term><varname>ExecReload=</varname></term>
399 <listitem><para>Commands to execute to
400 trigger a configuration reload in the
401 service. This argument takes multiple
402 command lines, following the same
403 scheme as pointed out for
404 <varname>ExecStartPre=</varname>
405 above. Use of this setting is
406 optional. Specifier and environment
407 variable substitution is supported
408 here following the same scheme as for
409 <varname>ExecStart=</varname>. One
410 special environment variable is set:
411 if known <literal>$MAINPID</literal> is
412 set to the main process of the
413 daemon, and may be used for command
414 lines like the following:
415 <command>/bin/kill -HUP
416 $MAINPID</command>.</para></listitem>
417 </varlistentry>
418
419 <varlistentry>
420 <term><varname>ExecStop=</varname></term>
421 <listitem><para>Commands to execute to
422 stop the service started via
423 <varname>ExecStart=</varname>. This
424 argument takes multiple command lines,
425 following the same scheme as pointed
426 out for
427 <varname>ExecStartPre=</varname>
428 above. Use of this setting is
429 optional. All processes remaining for
430 a service after the commands
431 configured in this option are run are
432 terminated according to the
433 <varname>KillMode=</varname> setting
434 (see
435 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
436 this option is not specified the
437 process is terminated right-away when
438 service stop is requested. Specifier
439 and environment variable substitution
440 is supported (including
441 <literal>$MAINPID</literal>, see
442 above).</para></listitem>
443 </varlistentry>
444
445 <varlistentry>
446 <term><varname>ExecStopPost=</varname></term>
447 <listitem><para>Additional commands
448 that are executed after the service
449 was stopped using the commands
450 configured in
451 <varname>ExecStop=</varname>. This
452 argument takes multiple command lines,
453 following the same scheme as pointed
454 out for
455 <varname>ExecStartPre</varname>. Use
456 of these settings is
457 optional. Specifier and environment
458 variable substitution is
459 supported.</para></listitem>
460 </varlistentry>
461
462 <varlistentry>
463 <term><varname>RestartSec=</varname></term>
464 <listitem><para>Configures the time to
465 sleep before restarting a service (as
466 configured with
467 <varname>Restart=</varname>). Takes a
468 unit-less value in seconds, or a time
469 span value such as "5min
470 20s". Defaults to
471 100ms.</para></listitem>
472 </varlistentry>
473
474 <varlistentry>
475 <term><varname>TimeoutStartSec=</varname></term>
476 <listitem><para>Configures the time to
477 wait for start-up. If a
478 daemon service does not signal
479 start-up completion within the
480 configured time, the service will be
481 considered failed and be shut down
482 again.
483 Takes a unit-less value in seconds, or a
484 time span value such as "5min
485 20s". Pass 0 to disable the timeout
486 logic. Defaults to 90s, except when
487 <varname>Type=oneshot</varname> is
488 used in which case the timeout
489 is disabled by default.
490 </para></listitem>
491 </varlistentry>
492
493 <varlistentry>
494 <term><varname>TimeoutStopSec=</varname></term>
495 <listitem><para>Configures the time to
496 wait for stop. If a service is asked
497 to stop but does not terminate in the
498 specified time, it will be terminated
499 forcibly via SIGTERM, and after
500 another delay of this time with
501 SIGKILL (See
502 <varname>KillMode=</varname>
503 in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
504 Takes a unit-less value in seconds, or a
505 time span value such as "5min
506 20s". Pass 0 to disable the timeout
507 logic. Defaults to 90s.
508 </para></listitem>
509 </varlistentry>
510
511 <varlistentry>
512 <term><varname>TimeoutSec=</varname></term>
513 <listitem><para>A shorthand for configuring
514 both <varname>TimeoutStartSec=</varname>
515 and <varname>TimeoutStopSec=</varname>
516 to the specified value.
517 </para></listitem>
518 </varlistentry>
519
520 <varlistentry>
521 <term><varname>WatchdogSec=</varname></term>
522 <listitem><para>Configures the
523 watchdog timeout for a service. This
524 is activated when the start-up is
525 completed. The service must call
526 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
527 regularly with "WATCHDOG=1" (i.e. the
528 "keep-alive ping"). If the time
529 between two such calls is larger than
530 the configured time then the service
531 is placed in a failure state. By
532 setting <varname>Restart=</varname> to
533 <option>on-failure</option> or
534 <option>always</option> the service
535 will be automatically restarted. The
536 time configured here will be passed to
537 the executed service process in the
538 <varname>WATCHDOG_USEC=</varname>
539 environment variable. This allows
540 daemons to automatically enable the
541 keep-alive pinging logic if watchdog
542 support is enabled for the service. If
543 this option is used
544 <varname>NotifyAccess=</varname> (see
545 below) should be set to open access to
546 the notification socket provided by
547 systemd. If
548 <varname>NotifyAccess=</varname> is
549 not set, it will be implicitly set to
550 <option>main</option>. Defaults to 0,
551 which disables this
552 feature.</para></listitem>
553 </varlistentry>
554
555 <varlistentry>
556 <term><varname>Restart=</varname></term>
557 <listitem><para>Configures whether the
558 main service process shall be
559 restarted when it exits. Takes one of
560 <option>no</option>,
561 <option>on-success</option>,
562 <option>on-failure</option>,
563 <option>on-abort</option> or
564 <option>always</option>. If set to
565 <option>no</option> (the default) the
566 service will not be restarted when it
567 exits. If set to
568 <option>on-success</option> it will be
569 restarted only when it exited cleanly,
570 i.e. terminated with an exit code of
571 0. If set to
572 <option>on-failure</option> it will be
573 restarted only when it exited with an
574 exit code not equalling 0, when
575 terminated by a signal (including on
576 core dump), when an operation (such as
577 service reload) times out or when the
578 configured watchdog timeout is
579 triggered. If set to
580 <option>on-abort</option> it will be
581 restarted only if it exits due to
582 reception of an uncaught signal
583 (including on core dump). If set to
584 <option>always</option> the service
585 will be restarted regardless whether
586 it exited cleanly or not, got
587 terminated abnormally by a signal or
588 hit a timeout.</para></listitem>
589 </varlistentry>
590
591 <varlistentry>
592 <term><varname>SuccessExitStatus=</varname></term>
593 <listitem><para>Takes a list of exit
594 status definitions that when returned
595 by the main service process will be
596 considered successful termination, in
597 addition to the normal successful exit
598 code 0 and the signals SIGHUP, SIGINT,
599 SIGTERM and SIGPIPE. Exit status
600 definitions can either be numeric exit
601 codes or termination signal names, and
602 are separated by spaces. Example:
603 "<literal>SuccessExitStatus=1 2 8
604 SIGKILL</literal>", ensures that exit
605 codes 1, 2, 8 and the termination
606 signal SIGKILL are considered clean
607 service
608 terminations.</para></listitem>
609 </varlistentry>
610
611 <varlistentry>
612 <term><varname>RestartPreventExitStatus=</varname></term>
613 <listitem><para>Takes a list of exit
614 status definitions that when returned
615 by the main service process will
616 prevent automatic service restarts
617 regardless of the restart setting
618 configured with
619 <varname>Restart=</varname>. Exit
620 status definitions can either be
621 numeric exit codes or termination
622 signal names, and are separated by
623 spaces. Defaults to the empty list, so
624 that by default no exit status is
625 excluded from the configured restart
626 logic. Example:
627 "<literal>RestartPreventExitStatus=1 6
628 SIGABRT</literal>", ensures that exit
629 codes 1 and 6 and the termination signal
630 SIGABRT will not result in automatic
631 service restarting.</para></listitem>
632 </varlistentry>
633
634 <varlistentry>
635 <term><varname>PermissionsStartOnly=</varname></term>
636 <listitem><para>Takes a boolean
637 argument. If true, the permission
638 related execution options as
639 configured with
640 <varname>User=</varname> and similar
641 options (see
642 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
643 for more information) are only applied
644 to the process started with
645 <varname>ExecStart=</varname>, and not
646 to the various other
647 <varname>ExecStartPre=</varname>,
648 <varname>ExecStartPost=</varname>,
649 <varname>ExecReload=</varname>,
650 <varname>ExecStop=</varname>,
651 <varname>ExecStopPost=</varname>
652 commands. If false, the setting is
653 applied to all configured commands the
654 same way. Defaults to
655 false.</para></listitem>
656 </varlistentry>
657
658 <varlistentry>
659 <term><varname>RootDirectoryStartOnly=</varname></term>
660 <listitem><para>Takes a boolean
661 argument. If true, the root directory
662 as configured with the
663 <varname>RootDirectory=</varname>
664 option (see
665 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
666 for more information) is only applied
667 to the process started with
668 <varname>ExecStart=</varname>, and not
669 to the various other
670 <varname>ExecStartPre=</varname>,
671 <varname>ExecStartPost=</varname>,
672 <varname>ExecReload=</varname>,
673 <varname>ExecStop=</varname>,
674 <varname>ExecStopPost=</varname>
675 commands. If false, the setting is
676 applied to all configured commands the
677 same way. Defaults to
678 false.</para></listitem>
679 </varlistentry>
680
681 <varlistentry>
682 <term><varname>NonBlocking=</varname></term>
683 <listitem><para>Set O_NONBLOCK flag
684 for all file descriptors passed via
685 socket-based activation. If true, all
686 file descriptors >= 3 (i.e. all except
687 STDIN/STDOUT/STDERR) will have
688 the O_NONBLOCK flag set and hence are in
689 non-blocking mode. This option is only
690 useful in conjunction with a socket
691 unit, as described in
692 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
693 to false.</para></listitem>
694 </varlistentry>
695
696 <varlistentry>
697 <term><varname>NotifyAccess=</varname></term>
698 <listitem><para>Controls access to the
699 service status notification socket, as
700 accessible via the
701 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
702 call. Takes one of
703 <option>none</option> (the default),
704 <option>main</option> or
705 <option>all</option>. If
706 <option>none</option> no daemon status
707 updates are accepted from the service
708 processes, all status update messages
709 are ignored. If <option>main</option>
710 only service updates sent from the
711 main process of the service are
712 accepted. If <option>all</option> all
713 services updates from all members of
714 the service's control group are
715 accepted. This option should be set to
716 open access to the notification socket
717 when using
718 <varname>Type=notify</varname> or
719 <varname>WatchdogUsec=</varname> (see
720 above). If those options are used but
721 <varname>NotifyAccess=</varname> not
722 configured it will be implicitly set
723 to
724 <option>main</option>.</para></listitem>
725 </varlistentry>
726
727 <varlistentry>
728 <term><varname>Sockets=</varname></term>
729 <listitem><para>Specifies the name of
730 the socket units this service shall
731 inherit the sockets from when the
732 service is started. Normally it
733 should not be necessary to use this
734 setting as all sockets whose unit
735 shares the same name as the service
736 (ignoring the different suffix of course)
737 are passed to the spawned
738 process.</para>
739
740 <para>Note that the same socket may be
741 passed to multiple processes at the
742 same time. Also note that a different
743 service may be activated on incoming
744 traffic than inherits the sockets. Or
745 in other words: The
746 <varname>Service=</varname> setting of
747 <filename>.socket</filename> units
748 doesn't have to match the inverse of the
749 <varname>Sockets=</varname> setting of
750 the <filename>.service</filename> it
751 refers to.</para></listitem>
752 </varlistentry>
753
754 <varlistentry>
755 <term><varname>StartLimitInterval=</varname></term>
756 <term><varname>StartLimitBurst=</varname></term>
757
758 <listitem><para>Configure service
759 start rate limiting. By default
760 services which are started more often
761 than 5 times within 10s are not
762 permitted to start any more times
763 until the 10s interval ends. With
764 these two options this rate limiting
765 may be modified. Use
766 <varname>StartLimitInterval=</varname>
767 to configure the checking interval
768 (defaults to 10s, set to 0 to disable
769 any kind of rate limiting). Use
770 <varname>StartLimitBurst=</varname> to
771 configure how many starts per interval
772 are allowed (defaults to 5). These
773 configuration options are particularly
774 useful in conjunction with
775 <varname>Restart=</varname>, however
776 apply to all kinds of starts
777 (including manual), not just those
778 triggered by the
779 <varname>Restart=</varname> logic.
780 Note that units which are configured
781 for <varname>Restart=</varname> and
782 which reach the start limit are not
783 attempted to be restarted anymore,
784 however they may still be restarted
785 manually at a later point from which
786 point on the restart logic is again
787 activated. Note that
788 <command>systemctl
789 reset-failed</command> will cause the
790 restart rate counter for a service to
791 be flushed, which is useful if the
792 administrator wants to manually start
793 a service and the start limit
794 interferes with
795 that.</para></listitem>
796 </varlistentry>
797
798 <varlistentry>
799 <term><varname>StartLimitAction=</varname></term>
800
801 <listitem><para>Configure the action
802 to take if the rate limit configured
803 with
804 <varname>StartLimitInterval=</varname>
805 and
806 <varname>StartLimitBurst=</varname> is
807 hit. Takes one of
808 <option>none</option>,
809 <option>reboot</option>,
810 <option>reboot-force</option> or
811 <option>reboot-immediate</option>. If
812 <option>none</option> is set,
813 hitting the rate limit will trigger no
814 action besides that the start will not
815 be
816 permitted. <option>reboot</option>
817 causes a reboot following the normal
818 shutdown procedure (i.e. equivalent to
819 <command>systemctl reboot</command>),
820 <option>reboot-force</option> causes
821 an forced reboot which will terminate
822 all processes forcibly but should
823 cause no dirty file systems on reboot
824 (i.e. equivalent to <command>systemctl
825 reboot -f</command>) and
826 <option>reboot-immediate</option>
827 causes immediate execution of the
828 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
829 system call, which might result in
830 data loss. Defaults to
831 <option>none</option>.</para></listitem>
832 </varlistentry>
833
834 </variablelist>
835
836 <para>Check
837 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
838 and
839 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
840 for more settings.</para>
841
842 </refsect1>
843
844 <refsect1>
845 <title>Compatibility Options</title>
846
847 <para>The following options are also available in the
848 <literal>[Service]</literal> section, but exist purely
849 for compatibility reasons and should not be used in
850 newly written service files.</para>
851
852 <variablelist>
853 <varlistentry>
854 <term><varname>SysVStartPriority=</varname></term>
855 <listitem><para>Set the SysV start
856 priority to use to order this service
857 in relation to SysV services lacking
858 LSB headers. This option is only
859 necessary to fix ordering in relation
860 to legacy SysV services, that have no
861 ordering information encoded in the
862 script headers. As such it should only
863 be used as temporary compatibility
864 option, and not be used in new unit
865 files. Almost always it is a better
866 choice to add explicit ordering
867 directives via
868 <varname>After=</varname> or
869 <varname>Before=</varname>,
870 instead. For more details see
871 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
872 used, pass an integer value in the
873 range 0-99.</para></listitem>
874 </varlistentry>
875
876 <varlistentry>
877 <term><varname>FsckPassNo=</varname></term>
878 <listitem><para>Set the fsck passno
879 priority to use to order this service
880 in relation to other file system
881 checking services. This option is only
882 necessary to fix ordering in relation
883 to fsck jobs automatically created for
884 all <filename>/etc/fstab</filename>
885 entries with a value in the fs_passno
886 column > 0. As such it should only be
887 used as option for fsck
888 services. Almost always it is a better
889 choice to add explicit ordering
890 directives via
891 <varname>After=</varname> or
892 <varname>Before=</varname>,
893 instead. For more details see
894 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
895 used, pass an integer value in the
896 same range as
897 <filename>/etc/fstab</filename>'s
898 fs_passno column. See
899 <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
900 for details.</para></listitem>
901 </varlistentry>
902
903 </variablelist>
904 </refsect1>
905
906 <refsect1>
907 <title>See Also</title>
908 <para>
909 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
910 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
911 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
912 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
913 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
914 </para>
915 </refsect1>
916
917 </refentry>