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