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