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. For each of the
309 specified commands, the first argument
310 must be an absolute and literal path
311 to an executable.</para>
313 <para>When <varname>Type</varname> is
314 not <option>oneshot</option>, only one
315 command may be given. When
316 <varname>Type=oneshot</varname> is
317 used, more than one command may be
318 specified. Multiple command lines may
319 be concatenated in a single directive,
320 by separating them with semicolons
321 (these semicolons must be passed as
322 separate words). Alternatively, this
323 directive may be specified more than
324 once with the same effect.
325 Lone semicolons may be escaped as
326 <literal>\;</literal>. If the empty
327 string is assigned to this option, the
328 list of commands to start is reset,
329 prior assignments of this option will
330 have no effect.</para>
332 <para>Each command line is split on
333 whitespace, with the first item being
334 the command to execute, and the
335 subsequent items being the arguments.
336 Double quotes ("...") and single
337 quotes ('...') may be used, in which
338 case everything until the next
339 matching quote becomes part of the
340 same argument. Quotes themselves are
341 removed after parsing. In addition, a
343 (<literal>\</literal>) may be used to
344 merge lines. This syntax is intended
345 to be very similar to shell syntax,
346 but only the meta-characters and
347 expansions described in the following
348 paragraphs are understood.
349 Specifically, redirection using
350 <literal><</literal>,
351 <literal><<</literal>,
352 <literal>></literal>, and
353 <literal>>></literal>, pipes
354 using <literal>|</literal>, and
355 running programs in the background
356 using <literal>&</literal>
357 and <emphasis>other elements of shell
358 syntax are not supported</emphasis>.
361 <para>If more than one command is
362 specified, the commands are invoked
363 one by one sequentially in the order
364 they appear in the unit file. If one
365 of the commands fails (and is not
366 prefixed with <literal>-</literal>),
367 other lines are not executed and the
368 unit is considered failed.</para>
371 <varname>Type=forking</varname> is
372 set, the process started via this
373 command line will be considered the
374 main process of the daemon.</para>
376 <para>The command line accepts
377 <literal>%</literal> specifiers as
379 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
380 Note that the first argument of the
381 command line (i.e. the program to
382 execute) may not include
385 <para>Basic environment variable
386 substitution is supported. Use
387 <literal>${FOO}</literal> as part of a
388 word, or as a word of its own on the
389 command line, in which case it will be
390 replaced by the value of the
391 environment variable including all
392 whitespace it contains, resulting in a
394 <literal>$FOO</literal> as a separate
395 word on the command line, in which
396 case it will be replaced by the value
397 of the environment variable split up
398 at whitespace, resulting in zero or
399 more arguments. To pass a literal dollar sign,
400 use <literal>$$</literal>. Note that the first
401 argument (i.e. the program to execute)
402 may not be a variable.</para>
404 <para>Optionally, if the absolute file
405 name is prefixed with
406 <literal>@</literal>, the second token
408 <literal>argv[0]</literal> to the
409 executed process, followed by the
410 further arguments specified. If the
411 absolute filename is prefixed with
412 <literal>-</literal>, an exit code of
413 the command normally considered a
414 failure (i.e. non-zero exit status or
415 abnormal exit due to signal) is ignored
416 and considered success. If both
417 <literal>-</literal> and
418 <literal>@</literal> are used, they
419 can appear in either order.</para>
421 <para>Note that this setting does not
422 directly support shell command
423 lines. If shell command lines are to
424 be used, they need to be passed
425 explicitly to a shell implementation
426 of some kind. Example:</para>
427 <programlisting>ExecStart=/bin/sh -c 'dmesg | tac'
430 <para>Only select environment variables
431 are set for executed commands. See
432 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
435 <para>Example:</para>
436 <programlisting>ExecStart=/bin/echo one ; /bin/echo "two two"
438 <para>This will execute
439 <command>/bin/echo</command> two
440 times, each time with one argument,
441 <literal>one</literal> and
442 <literal>two two</literal>,
443 respectively. Since two commands are
445 <varname>Type=oneshot</varname> must
448 <para>Example:</para>
449 <programlisting>ExecStart=/bin/echo / >/dev/null & \; \
452 <para>This will execute
453 <command>/bin/echo</command> with five
454 arguments: <literal>/</literal>,
455 <literal>>/dev/null</literal>,
456 <literal>&</literal>,
457 <literal>;</literal>, and
458 <literal>/bin/ls</literal>.</para>
460 <para>Example:</para>
461 <programlisting>Environment="ONE=one" 'TWO=two two'
462 ExecStart=/bin/echo $ONE $TWO ${TWO}
464 <para>This will execute
465 <command>/bin/echo</command> with four
466 arguments: <literal>one</literal>,
467 <literal>two</literal>,
468 <literal>two</literal>, and
469 <literal>two two</literal>.</para>
474 <term><varname>ExecStartPre=</varname></term>
475 <term><varname>ExecStartPost=</varname></term>
476 <listitem><para>Additional commands
477 that are executed before or after
479 <varname>ExecStart=</varname>, respectively.
480 Syntax is the same as for
481 <varname>ExecStart=</varname>, except
482 that multiple command lines are allowed
483 and the commands are executed one
484 after the other, serially.</para>
486 <para>If any of those commands (not
487 prefixed with <literal>-</literal>)
488 fail, the rest are not executed and
489 the unit is considered failed.</para>
494 <term><varname>ExecReload=</varname></term>
495 <listitem><para>Commands to execute to
496 trigger a configuration reload in the
497 service. This argument takes multiple
498 command lines, following the same
499 scheme as described for
500 <varname>ExecStart=</varname>
501 above. Use of this setting is
502 optional. Specifier and environment
503 variable substitution is supported
504 here following the same scheme as for
505 <varname>ExecStart=</varname>.</para>
507 <para>One additional special
508 environment variables is set: if known
509 <varname>$MAINPID</varname> is set to
510 the main process of the daemon, and
511 may be used for command lines like the
514 <programlisting>/bin/kill -HUP $MAINPID</programlisting>
519 <term><varname>ExecStop=</varname></term>
520 <listitem><para>Commands to execute to
521 stop the service started via
522 <varname>ExecStart=</varname>. This
523 argument takes multiple command lines,
524 following the same scheme as described
525 for <varname>ExecStart=</varname>
526 above. Use of this setting is
527 optional. All processes remaining for
528 a service after the commands
529 configured in this option are run are
530 terminated according to the
531 <varname>KillMode=</varname> setting
533 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If
534 this option is not specified, the
535 process is terminated right-away when
536 service stop is requested. Specifier
537 and environment variable substitution
538 is supported (including
539 <varname>$MAINPID</varname>, see
540 above).</para></listitem>
544 <term><varname>ExecStopPost=</varname></term>
545 <listitem><para>Additional commands
546 that are executed after the service
547 was stopped. This includes cases where
548 the commands configured in
549 <varname>ExecStop=</varname> were used,
550 where the service does not have any
551 <varname>ExecStop=</varname> defined, or
552 where the service exited unexpectedly. This
553 argument takes multiple command lines,
554 following the same scheme as described
555 for <varname>ExecStart</varname>. Use
557 optional. Specifier and environment
558 variable substitution is
559 supported.</para></listitem>
563 <term><varname>RestartSec=</varname></term>
564 <listitem><para>Configures the time to
565 sleep before restarting a service (as
567 <varname>Restart=</varname>). Takes a
568 unit-less value in seconds, or a time
569 span value such as "5min
571 100ms.</para></listitem>
575 <term><varname>TimeoutStartSec=</varname></term>
576 <listitem><para>Configures the time to
577 wait for start-up. If a
578 daemon service does not signal
579 start-up completion within the
580 configured time, the service will be
581 considered failed and be shut down
583 Takes a unit-less value in seconds, or a
584 time span value such as "5min
585 20s". Pass 0 to disable the timeout
586 logic. Defaults to <varname>TimeoutStartSec=</varname> from the
587 manager configuration file, except when
588 <varname>Type=oneshot</varname> is
589 used, in which case the timeout
590 is disabled by default.
595 <term><varname>TimeoutStopSec=</varname></term>
596 <listitem><para>Configures the time to
597 wait for stop. If a service is asked
598 to stop but does not terminate in the
599 specified time, it will be terminated
600 forcibly via <constant>SIGTERM</constant>, and after
601 another delay of this time with
602 <constant>SIGKILL</constant> (See
603 <varname>KillMode=</varname>
604 in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
605 Takes a unit-less value in seconds, or a
606 time span value such as "5min
607 20s". Pass 0 to disable the timeout
608 logic. Defaults to <varname>TimeoutStartSec=</varname> from the
609 manager configuration file.
614 <term><varname>TimeoutSec=</varname></term>
615 <listitem><para>A shorthand for configuring
616 both <varname>TimeoutStartSec=</varname>
617 and <varname>TimeoutStopSec=</varname>
618 to the specified value.
623 <term><varname>WatchdogSec=</varname></term>
624 <listitem><para>Configures the
625 watchdog timeout for a service. The
626 watchdog is activated when the start-up is
627 completed. The service must call
628 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
629 regularly with "WATCHDOG=1" (i.e. the
630 "keep-alive ping"). If the time
631 between two such calls is larger than
632 the configured time, then the service
633 is placed in a failure state. By
634 setting <varname>Restart=</varname> to
635 <option>on-failure</option> or
636 <option>always</option>, the service
637 will be automatically restarted. The
638 time configured here will be passed to
639 the executed service process in the
640 <varname>WATCHDOG_USEC=</varname>
641 environment variable. This allows
642 daemons to automatically enable the
643 keep-alive pinging logic if watchdog
644 support is enabled for the service. If
646 <varname>NotifyAccess=</varname> (see
647 below) should be set to open access to
648 the notification socket provided by
650 <varname>NotifyAccess=</varname> is
651 not set, it will be implicitly set to
652 <option>main</option>. Defaults to 0,
654 feature.</para></listitem>
658 <term><varname>Restart=</varname></term>
659 <listitem><para>Configures whether the
660 service shall be restarted when the
661 service process exits, is killed,
662 or a timeout is reached. The service
663 process may be the main service
664 process, but also one of the processes
666 <varname>ExecStartPre=</varname>,
667 <varname>ExecStartPost=</varname>,
668 <varname>ExecStopPre=</varname>,
669 <varname>ExecStopPost=</varname>, or
670 <varname>ExecReload=</varname>.
671 When the death of the process is a
672 result of systemd operation (e.g. service
673 stop or restart), the service will not be
674 restarted. Timeouts include missing
675 the watchdog "keep-alive ping"
676 deadline and a service start, reload,
677 and stop operation timeouts.</para>
681 <option>on-success</option>,
682 <option>on-failure</option>,
683 <option>on-watchdog</option>,
684 <option>on-abort</option>, or
685 <option>always</option>. If set to
686 <option>no</option> (the default), the
687 service will not be restarted. If set to
688 <option>on-success</option>, it will be
689 restarted only when the service process
691 In this context, a clean exit means
692 an exit code of 0, or one of the signals
693 <constant>SIGHUP</constant>, <constant>SIGINT</constant>, <constant>SIGTERM</constant>, or <constant>SIGPIPE</constant>, and
694 additionally, exit statuses and signals
695 specified in <varname>SuccessExitStatus=</varname>.
696 If set to <option>on-failure</option>,
697 the service will be restarted when the
698 process exits with an nonzero exit code,
699 is terminated by a signal (including on
700 core dump), when an operation (such as
701 service reload) times out, and when the
702 configured watchdog timeout is triggered.
704 <option>on-abort</option>, the service
705 will be restarted only if the service
706 process exits due to an uncaught
707 signal not specified as a clean exit
710 <option>on-watchdog</option>, the service
711 will be restarted only if the watchdog
712 timeout for the service expires.
714 <option>always</option>, the service
715 will be restarted regardless whether
716 it exited cleanly or not, got
717 terminated abnormally by a signal or
718 hit a timeout.</para>
720 <para>In addition to the above settings,
721 the service will not be restarted if the
722 exit code or signal is specified in
723 <varname>RestartPreventExitStatus=</varname>
724 (see below).</para></listitem>
728 <term><varname>SuccessExitStatus=</varname></term>
729 <listitem><para>Takes a list of exit
730 status definitions that when returned
731 by the main service process will be
732 considered successful termination, in
733 addition to the normal successful exit
734 code 0 and the signals <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
735 <constant>SIGTERM</constant> and <constant>SIGPIPE</constant>. Exit status
736 definitions can either be numeric exit
737 codes or termination signal names,
738 separated by spaces. Example:
739 <literal>SuccessExitStatus=1 2 8
740 <constant>SIGKILL</constant></literal>, ensures that exit
741 codes 1, 2, 8 and the termination
742 signal <constant>SIGKILL</constant> are considered clean
743 service terminations. This option may
744 appear more than once in which case
745 the list of successful exit statuses
746 is merged. If the empty string is
747 assigned to this option, the list is
748 reset, all prior assignments of this
750 effect.</para></listitem>
754 <term><varname>RestartPreventExitStatus=</varname></term>
755 <listitem><para>Takes a list of exit
756 status definitions that when returned
757 by the main service process will
758 prevent automatic service restarts
759 regardless of the restart setting
761 <varname>Restart=</varname>. Exit
762 status definitions can either be
763 numeric exit codes or termination
764 signal names, and are separated by
765 spaces. Defaults to the empty list, so
766 that by default no exit status is
767 excluded from the configured restart
769 <literal>RestartPreventExitStatus=1 6
770 SIGABRT</literal>, ensures that exit
771 codes 1 and 6 and the termination
772 signal SIGABRT will not result in
773 automatic service restarting. This
774 option may appear more than once in
775 which case the list of restart preventing
776 statuses is merged. If the empty
777 string is assigned to this option, the
778 list is reset, all prior assignments
779 of this option will have no
780 effect.</para></listitem>
784 <term><varname>PermissionsStartOnly=</varname></term>
785 <listitem><para>Takes a boolean
786 argument. If true, the permission
787 related execution options as
789 <varname>User=</varname> and similar
791 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
792 for more information) are only applied
793 to the process started with
794 <varname>ExecStart=</varname>, and not
796 <varname>ExecStartPre=</varname>,
797 <varname>ExecStartPost=</varname>,
798 <varname>ExecReload=</varname>,
799 <varname>ExecStop=</varname>,
800 <varname>ExecStopPost=</varname>
801 commands. If false, the setting is
802 applied to all configured commands the
803 same way. Defaults to
804 false.</para></listitem>
808 <term><varname>RootDirectoryStartOnly=</varname></term>
809 <listitem><para>Takes a boolean
810 argument. If true, the root directory
811 as configured with the
812 <varname>RootDirectory=</varname>
814 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
815 for more information) is only applied
816 to the process started with
817 <varname>ExecStart=</varname>, and not
819 <varname>ExecStartPre=</varname>,
820 <varname>ExecStartPost=</varname>,
821 <varname>ExecReload=</varname>,
822 <varname>ExecStop=</varname>,
823 <varname>ExecStopPost=</varname>
824 commands. If false, the setting is
825 applied to all configured commands the
826 same way. Defaults to
827 false.</para></listitem>
831 <term><varname>NonBlocking=</varname></term>
832 <listitem><para>Set O_NONBLOCK flag
833 for all file descriptors passed via
834 socket-based activation. If true, all
835 file descriptors >= 3 (i.e. all except
836 STDIN/STDOUT/STDERR) will have
837 the O_NONBLOCK flag set and hence are in
838 non-blocking mode. This option is only
839 useful in conjunction with a socket
840 unit, as described in
841 <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults
842 to false.</para></listitem>
846 <term><varname>NotifyAccess=</varname></term>
847 <listitem><para>Controls access to the
848 service status notification socket, as
850 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
852 <option>none</option> (the default),
853 <option>main</option> or
854 <option>all</option>. If
855 <option>none</option>, no daemon status
856 updates are accepted from the service
857 processes, all status update messages
858 are ignored. If <option>main</option>,
859 only service updates sent from the
860 main process of the service are
861 accepted. If <option>all</option>, all
862 services updates from all members of
863 the service's control group are
864 accepted. This option should be set to
865 open access to the notification socket
867 <varname>Type=notify</varname> or
868 <varname>WatchdogSec=</varname> (see
869 above). If those options are used but
870 <varname>NotifyAccess=</varname> is not
871 configured, it will be implicitly set
873 <option>main</option>.</para></listitem>
877 <term><varname>Sockets=</varname></term>
878 <listitem><para>Specifies the name of
879 the socket units this service shall
880 inherit the sockets from when the
881 service is started. Normally it
882 should not be necessary to use this
883 setting as all sockets whose unit
884 shares the same name as the service
885 (ignoring the different suffix of course)
886 are passed to the spawned
889 <para>Note that the same socket may be
890 passed to multiple processes at the
891 same time. Also note that a different
892 service may be activated on incoming
893 traffic than inherits the sockets. Or
895 <varname>Service=</varname> setting of
896 <filename>.socket</filename> units
897 does not have to match the inverse of
898 the <varname>Sockets=</varname>
900 <filename>.service</filename> it
903 <para>This option may appear more than
904 once, in which case the list of socket
905 units is merged. If the empty string
906 is assigned to this option, the list of
907 sockets is reset, all prior uses of
908 this setting will have no
909 effect.</para></listitem>
913 <term><varname>StartLimitInterval=</varname></term>
914 <term><varname>StartLimitBurst=</varname></term>
916 <listitem><para>Configure service
917 start rate limiting. By default,
918 services which are started more often
919 than 5 times within 10s are not
920 permitted to start any more times
921 until the 10s interval ends. With
922 these two options, this rate limiting
924 <varname>StartLimitInterval=</varname>
925 to configure the checking interval (defaults to
926 <varname>DefaultStartLimitInterval=</varname> in
927 manager configuration file, set to 0 to disable
928 any kind of rate limiting). Use
929 <varname>StartLimitBurst=</varname> to
930 configure how many starts per interval
931 are allowed (defaults to
932 <varname>DefaultStartLimitBurst=</varname> in
933 manager configuration file). These
934 configuration options are particularly
935 useful in conjunction with
936 <varname>Restart=</varname>, however
937 apply to all kinds of starts
938 (including manual), not just those
940 <varname>Restart=</varname> logic.
941 Note that units which are configured
942 for <varname>Restart=</varname> and
943 which reach the start limit are not
944 attempted to be restarted anymore,
945 however they may still be restarted
946 manually at a later point from which
947 point on the restart logic is again
950 reset-failed</command> will cause the
951 restart rate counter for a service to
952 be flushed, which is useful if the
953 administrator wants to manually start
954 a service and the start limit
956 that.</para></listitem>
960 <term><varname>StartLimitAction=</varname></term>
962 <listitem><para>Configure the action
963 to take if the rate limit configured
965 <varname>StartLimitInterval=</varname>
967 <varname>StartLimitBurst=</varname> is
969 <option>none</option>,
970 <option>reboot</option>,
971 <option>reboot-force</option> or
972 <option>reboot-immediate</option>. If
973 <option>none</option> is set,
974 hitting the rate limit will trigger no
975 action besides that the start will not
977 permitted. <option>reboot</option>
978 causes a reboot following the normal
979 shutdown procedure (i.e. equivalent to
980 <command>systemctl reboot</command>),
981 <option>reboot-force</option> causes
982 an forced reboot which will terminate
983 all processes forcibly but should
984 cause no dirty file systems on reboot
985 (i.e. equivalent to <command>systemctl
986 reboot -f</command>) and
987 <option>reboot-immediate</option>
988 causes immediate execution of the
989 <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
990 system call, which might result in
991 data loss. Defaults to
992 <option>none</option>.</para></listitem>
998 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1000 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1001 for more settings.</para>
1006 <title>Compatibility Options</title>
1008 <para>The following options are also available in the
1009 <literal>[Service]</literal> section, but exist purely
1010 for compatibility reasons and should not be used in
1011 newly written service files.</para>
1013 <variablelist class='unit-directives'>
1015 <term><varname>SysVStartPriority=</varname></term>
1016 <listitem><para>Set the SysV start
1017 priority to use to order this service
1018 in relation to SysV services lacking
1019 LSB headers. This option is only
1020 necessary to fix ordering in relation
1021 to legacy SysV services, that have no
1022 ordering information encoded in the
1023 script headers. As such it should only
1024 be used as temporary compatibility
1025 option, and not be used in new unit
1026 files. Almost always it is a better
1027 choice to add explicit ordering
1029 <varname>After=</varname> or
1030 <varname>Before=</varname>,
1031 instead. For more details see
1032 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
1033 used, pass an integer value in the
1034 range 0-99.</para></listitem>
1041 <title>See Also</title>
1043 <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1044 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1045 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1046 <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1047 <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1048 <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1049 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>