<?xml version='1.0'?> <!--*-nxml-*-->

<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"?>

<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"

"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

<refentry id="systemd.service">

<refentryinfo>

<title>systemd.service</title>

<productname>systemd</productname>

<authorgroup>

<author>

<contrib>Developer</contrib>

<firstname>Lennart</firstname>

<surname>Poettering</surname>

<email>lennart@poettering.net</email>

</author>

</authorgroup>

</refentryinfo>

<refmeta>

<refentrytitle>systemd.service</refentrytitle>

<manvolnum>5</manvolnum>

</refmeta>

<refnamediv>

<refname>systemd.service</refname>

<refpurpose>Service unit configuration</refpurpose>

</refnamediv>

<refsynopsisdiv>

<para><filename>systemd.service</filename></para>

</refsynopsisdiv>

<refsect1>

<title>Description</title>

<para>A unit configuration file whose name ends in

<filename>.service</filename> encodes information

about a process controlled and supervised by

systemd.</para>

<para>This man page lists the configuration options

specific to this unit type. See

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for the common options of all unit configuration

files. The common configuration items are configured

in the generic <literal>[Unit]</literal> and

<literal>[Install]</literal> sections. The service

specific configuration options are configured in the

<literal>[Service]</literal> section.</para>

<para>Additional options are listed in

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

which define the execution environment the commands

are executed in, and in

<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>

which define the way the processes of the service are

terminated.</para>

<para>Unless <varname>DefaultDependencies=</varname>

is set to <option>false</option>, service units will

implicitly have dependencies of type

<varname>Requires=</varname> and

<varname>After=</varname> on

<filename>basic.target</filename> as well as

dependencies of type <varname>Conflicts=</varname> and

<varname>Before=</varname> on

<filename>shutdown.target</filename>. These ensure

that normal service units pull in basic system

initialization, and are terminated cleanly prior to

system shutdown. Only services involved with early

boot or late system shutdown should disable this

option.</para>

<para>If a service is requested under a certain name

but no unit configuration file is found, systemd looks

for a SysV init script by the same name (with the

<filename>.service</filename> suffix removed) and

dynamically creates a service unit from that

script. This is useful for compatibility with

SysV. Note that this compatibility is quite

comprehensive but not 100%. For details about the

incomptibilities see the <ulink

url="http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities

with SysV</ulink> document.

</para>

</refsect1>

<refsect1>

<title>Options</title>

<para>Service files must include a

<literal>[Service]</literal> section, which carries

information about the service and the process it

supervises. A number of options that may be used in

this section are shared with other unit types. These

options are documented in

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>

and

<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The

options specific to the <literal>[Service]</literal>

section of service units are the following:</para>

<variablelist>

<varlistentry>

<term><varname>Type=</varname></term>

<listitem><para>Configures the process

start-up type for this service

unit. One of <option>simple</option>,

<option>forking</option>,

<option>oneshot</option>,

<option>dbus</option>,

<option>notify</option> or

<option>idle</option>.</para>

<para>If set to

<option>simple</option> (the default

value if <varname>BusName=</varname>

is not specified) it is expected that

the process configured with

<varname>ExecStart=</varname> is the

main process of the service. In this

mode, if the process offers

functionality to other processes on

the system its communication channels

should be installed before the daemon

is started up (e.g. sockets set up by

systemd, via socket activation), as

systemd will immediately proceed

starting follow-up units.</para>

<para>If set to

<option>forking</option> it is

expected that the process configured

with <varname>ExecStart=</varname>

will call <function>fork()</function>

as part of its start-up. The parent process is

expected to exit when start-up is

complete and all communication

channels set up. The child continues

to run as the main daemon

process. This is the behavior of

traditional UNIX daemons. If this

setting is used, it is recommended to

also use the

<varname>PIDFile=</varname> option, so

that systemd can identify the main

process of the daemon. systemd will

proceed starting follow-up units as

soon as the parent process

exits.</para>

<para>Behavior of

<option>oneshot</option> is similar

to <option>simple</option>, however

it is expected that the process has to

exit before systemd starts follow-up

units. <varname>RemainAfterExit=</varname>

is particularly useful for this type

of service.</para>

<para>Behavior of

<option>dbus</option> is similar to

<option>simple</option>, however it is

expected that the daemon acquires a

name on the D-Bus bus, as configured

by

<varname>BusName=</varname>. systemd

will proceed starting follow-up units

after the D-Bus bus name has been

acquired. Service units with this

option configured implicitly gain

dependencies on the

<filename>dbus.socket</filename>

unit. This type is the default if

<varname>BusName=</varname> is

specified.</para>

<para>Behavior of

<option>notify</option> is similar to

<option>simple</option>, however it is

expected that the daemon sends a

notification message via

<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>

or an equivalent call when it finished

starting up. systemd will proceed

starting follow-up units after this

notification message has been sent. If

this option is used

<varname>NotifyAccess=</varname> (see

below) should be set to open access to

the notification socket provided by

systemd. If

<varname>NotifyAccess=</varname> is

not set, it will be implicitly set to

<option>main</option>.</para>

<para>Behavior of

<option>idle</option> is very similar

to <option>simple</option>, however

actual execution of a the service

binary is delayed until all jobs are

dispatched. This may be used to avoid

interleaving of output of shell

services with the status output on the

console.</para>

</listitem>

</varlistentry>

<varlistentry>

<term><varname>RemainAfterExit=</varname></term>

<listitem><para>Takes a boolean value

that specifies whether the service

shall be considered active even when

all its processes exited. Defaults to

<option>no</option>.</para>

</listitem>

</varlistentry>

<varlistentry>

<term><varname>GuessMainPID=</varname></term>

<listitem><para>Takes a boolean value

that specifies whether systemd should

try to guess the main PID of a service

should if it cannot be determined

reliably. This option is ignored

unless <option>Type=forking</option>

is set and <option>PIDFile=</option>

is unset because for the other types

or with an explicitly configured PID

file the main PID is always known. The

guessing algorithm might come to

incorrect conclusions if a daemon

consists of more than one process. If

the main PID cannot be determined

failure detection and automatic

restarting of a service will not work

reliably. Defaults to

<option>yes</option>.</para>

</listitem>

</varlistentry>

<varlistentry>

<term><varname>PIDFile=</varname></term>

<listitem><para>Takes an absolute file

name pointing to the PID file of this

daemon. Use of this option is

recommended for services where

<varname>Type=</varname> is set to

<option>forking</option>. systemd will

read the PID of the main process of

the daemon after start-up of the

service. systemd will not write to the

file configured here.</para>

</listitem>

</varlistentry>

<varlistentry>

<term><varname>BusName=</varname></term>

<listitem><para>Takes a D-Bus bus

name, where this service is reachable

as. This option is mandatory for

services where

<varname>Type=</varname> is set to

<option>dbus</option>, but its use

is otherwise recommended as well if

the process takes a name on the D-Bus

bus.</para>

</listitem>

</varlistentry>

<varlistentry>

<term><varname>ExecStart=</varname></term>

<listitem><para>Takes a command line

that is executed when this service

shall be started up. The first token

of the command line must be an

absolute file name, then followed by

arguments for the process. It is

mandatory to set this option for all

services. This option may not be

specified more than once, except when

<varname>Type=oneshot</varname> is

used in which case more than one

<varname>ExecStart=</varname> line is

accepted which are then invoked one by

one, sequentially in the order they

appear in the unit file.</para>

<para>Optionally, if the absolute file

name is prefixed with

<literal>@</literal>, the second token

will be passed as

<literal>argv[0]</literal> to the

executed process, followed by the

further arguments specified. If the

first token is prefixed with

<literal>-</literal> an exit code of

the command normally considered a

failure (i.e. non-zero exit status or

abnormal exit due to signal) is ignored

and considered success. If both

<literal>-</literal> and

<literal>@</literal> are used for the

same command the former must precede

the latter. Unless

<varname>Type=forking</varname> is

set, the process started via this

command line will be considered the

main process of the daemon. The

command line accepts % specifiers as

described in

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>

<para>On top of that basic environment

variable substitution is

supported. Use

<literal>${FOO}</literal> as part of a

word, or as word of its own on the

command line, in which case it will be

replaced by the value of the

environment variable including all

whitespace it contains, resulting in a

single argument. Use

<literal>$FOO</literal> as a separate

word on the command line, in which

case it will be replaced by the value

of the environment variable split up

at whitespace, resulting in no or more

arguments. Note that the first

argument (i.e. the program to execute)

may not be a variable, and must be a

literal and absolute path

name.</para>

<para>Note that this setting does not

directly support shell command

lines. If shell command lines are to

be used they need to be passed

explicitly to a shell implementation

of some kind. Example:

<literal>ExecStart=/bin/sh -c 'dmesg | tac'</literal></para>

</listitem>

</varlistentry>

<varlistentry>

<term><varname>ExecStartPre=</varname></term>

<term><varname>ExecStartPost=</varname></term>

<listitem><para>Additional commands

that are executed before or after

the command in

<varname>ExecStart=</varname>, respectively. Multiple

command lines may be concatenated in a

single directive, by separating them

by semicolons (these semicolons must

be passed as separate words). In that

case, the commands are executed one

after the other,

serially. Alternatively, these

directives may be specified more than

once with the same effect. However,

the latter syntax is not recommended

for compatibility with parsers

suitable for XDG

<filename>.desktop</filename> files.

Use of these settings is

optional. Specifier and environment

variable substitution is

supported.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>ExecReload=</varname></term>

<listitem><para>Commands to execute to

trigger a configuration reload in the

service. This argument takes multiple

command lines, following the same

scheme as pointed out for

<varname>ExecStartPre=</varname>

above. Use of this setting is

optional. Specifier and environment

variable substitution is supported

here following the same scheme as for

<varname>ExecStart=</varname>. One

special environment variable is set:

if known <literal>$MAINPID</literal> is

set to the main process of the

daemon, and may be used for command

lines like the following:

<command>/bin/kill -HUP

$MAINPID</command>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>ExecStop=</varname></term>

<listitem><para>Commands to execute to

stop the service started via

<varname>ExecStart=</varname>. This

argument takes multiple command lines,

following the same scheme as pointed

out for

<varname>ExecStartPre=</varname>

above. Use of this setting is

optional. All processes remaining for

a service after the commands

configured in this option are run are

terminated according to the

<varname>KillMode=</varname> setting

(see

<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If

this option is not specified the

process is terminated right-away when

service stop is requested. Specifier

and environment variable substitution

is supported (including

<literal>$MAINPID</literal>, see

above).</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>ExecStopPost=</varname></term>

<listitem><para>Additional commands

that are executed after the service

was stopped using the commands

configured in

<varname>ExecStop=</varname>. This

argument takes multiple command lines,

following the same scheme as pointed

out for

<varname>ExecStartPre</varname>. Use

of these settings is

optional. Specifier and environment

variable substitution is

supported.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>RestartSec=</varname></term>

<listitem><para>Configures the time to

sleep before restarting a service (as

configured with

<varname>Restart=</varname>). Takes a

unit-less value in seconds, or a time

span value such as "5min

20s". Defaults to

100ms.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>TimeoutStartSec=</varname></term>

<listitem><para>Configures the time to

wait for start-up. If a

daemon service does not signal

start-up completion within the

configured time, the service will be

considered failed and be shut down

again.

Takes a unit-less value in seconds, or a

time span value such as "5min

20s". Pass 0 to disable the timeout

logic. Defaults to 90s, except when

<varname>Type=oneshot</varname> is

used in which case the timeout

is disabled by default.

</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>TimeoutStopSec=</varname></term>

<listitem><para>Configures the time to

wait for stop. If a service is asked

to stop but does not terminate in the

specified time, it will be terminated

forcibly via SIGTERM, and after

another delay of this time with

SIGKILL (See

<varname>KillMode=</varname>

in <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).

Takes a unit-less value in seconds, or a

time span value such as "5min

20s". Pass 0 to disable the timeout

logic. Defaults to 90s.

</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>TimeoutSec=</varname></term>

<listitem><para>A shorthand for configuring

both <varname>TimeoutStartSec=</varname>

and <varname>TimeoutStopSec=</varname>

to the specified value.

</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>WatchdogSec=</varname></term>

<listitem><para>Configures the

watchdog timeout for a service. This

is activated when the start-up is

completed. The service must call

<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>

regularly with "WATCHDOG=1" (i.e. the

"keep-alive ping"). If the time

between two such calls is larger than

the configured time then the service

is placed in a failure state. By

setting <varname>Restart=</varname> to

<option>on-failure</option> or

<option>always</option> the service

will be automatically restarted. The

time configured here will be passed to

the executed service process in the

<varname>WATCHDOG_USEC=</varname>

environment variable. This allows

daemons to automatically enable the

keep-alive pinging logic if watchdog

support is enabled for the service. If

this option is used

<varname>NotifyAccess=</varname> (see

below) should be set to open access to

the notification socket provided by

systemd. If

<varname>NotifyAccess=</varname> is

not set, it will be implicitly set to

<option>main</option>. Defaults to 0,

which disables this

feature.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>Restart=</varname></term>

<listitem><para>Configures whether the

main service process shall be

restarted when it exits. Takes one of

<option>no</option>,

<option>on-success</option>,

<option>on-failure</option>,

<option>on-abort</option> or

<option>always</option>. If set to

<option>no</option> (the default) the

service will not be restarted when it

exits. If set to

<option>on-success</option> it will be

restarted only when it exited cleanly,

i.e. terminated with an exit code of

0. If set to

<option>on-failure</option> it will be

restarted only when it exited with an

exit code not equalling 0, when

terminated by a signal (including on

core dump), when an operation (such as

service reload) times out or when the

configured watchdog timeout is

triggered. If set to

<option>on-abort</option> it will be

restarted only if it exits due to

reception of an uncaught signal

(including on core dump). If set to

<option>always</option> the service

will be restarted regardless whether

it exited cleanly or not, got

terminated abnormally by a signal or

hit a timeout.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>SuccessExitStatus=</varname></term>

<listitem><para>Takes a list of exit

status definitions that when returned

by the main service process will be

considered successful termination, in

addition to the normal successful exit

code 0 and the signals SIGHUP, SIGINT,

SIGTERM and SIGPIPE. Exit status

definitions can either be numeric exit

codes or termination signal names, and

are separated by spaces. Example:

"<literal>SuccessExitStatus=1 2 8

SIGKILL</literal>", ensures that exit

codes 1, 2, 8 and the termination

signal SIGKILL are considered clean

service

terminations.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>RestartPreventExitStatus=</varname></term>

<listitem><para>Takes a list of exit

status definitions that when returned

by the main service process will

prevent automatic service restarts

regardless of the restart setting

configured with

<varname>Restart=</varname>. Exit

status definitions can either be

numeric exit codes or termination

signal names, and are separated by

spaces. Defaults to the empty list, so

that by default no exit status is

excluded from the configured restart

logic. Example:

"<literal>RestartPreventExitStatus=1 6

SIGABRT</literal>", ensures that exit

codes 1 and 6 and the termination signal

SIGABRT will not result in automatic

service restarting.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>PermissionsStartOnly=</varname></term>

<listitem><para>Takes a boolean

argument. If true, the permission

related execution options as

configured with

<varname>User=</varname> and similar

options (see

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for more information) are only applied

to the process started with

<varname>ExecStart=</varname>, and not

to the various other

<varname>ExecStartPre=</varname>,

<varname>ExecStartPost=</varname>,

<varname>ExecReload=</varname>,

<varname>ExecStop=</varname>,

<varname>ExecStopPost=</varname>

commands. If false, the setting is

applied to all configured commands the

same way. Defaults to

false.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>RootDirectoryStartOnly=</varname></term>

<listitem><para>Takes a boolean

argument. If true, the root directory

as configured with the

<varname>RootDirectory=</varname>

option (see

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for more information) is only applied

to the process started with

<varname>ExecStart=</varname>, and not

to the various other

<varname>ExecStartPre=</varname>,

<varname>ExecStartPost=</varname>,

<varname>ExecReload=</varname>,

<varname>ExecStop=</varname>,

<varname>ExecStopPost=</varname>

commands. If false, the setting is

applied to all configured commands the

same way. Defaults to

false.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>NonBlocking=</varname></term>

<listitem><para>Set O_NONBLOCK flag

for all file descriptors passed via

socket-based activation. If true, all

file descriptors >= 3 (i.e. all except

STDIN/STDOUT/STDERR) will have

the O_NONBLOCK flag set and hence are in

non-blocking mode. This option is only

useful in conjunction with a socket

unit, as described in

<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Defaults

to false.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>NotifyAccess=</varname></term>

<listitem><para>Controls access to the

service status notification socket, as

accessible via the

<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>

call. Takes one of

<option>none</option> (the default),

<option>main</option> or

<option>all</option>. If

<option>none</option> no daemon status

updates are accepted from the service

processes, all status update messages

are ignored. If <option>main</option>

only service updates sent from the

main process of the service are

accepted. If <option>all</option> all

services updates from all members of

the service's control group are

accepted. This option should be set to

open access to the notification socket

when using

<varname>Type=notify</varname> or

<varname>WatchdogUsec=</varname> (see

above). If those options are used but

<varname>NotifyAccess=</varname> not

configured it will be implicitly set

to

<option>main</option>.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>Sockets=</varname></term>

<listitem><para>Specifies the name of

the socket units this service shall

inherit the sockets from when the

service is started. Normally it

should not be necessary to use this

setting as all sockets whose unit

shares the same name as the service

(ignoring the different suffix of course)

are passed to the spawned

process.</para>

<para>Note that the same socket may be

passed to multiple processes at the

same time. Also note that a different

service may be activated on incoming

traffic than inherits the sockets. Or

in other words: The

<varname>Service=</varname> setting of

<filename>.socket</filename> units

doesn't have to match the inverse of the

<varname>Sockets=</varname> setting of

the <filename>.service</filename> it

refers to.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>StartLimitInterval=</varname></term>

<term><varname>StartLimitBurst=</varname></term>

<listitem><para>Configure service

start rate limiting. By default

services which are started more often

than 5 times within 10s are not

permitted to start any more times

until the 10s interval ends. With

these two options this rate limiting

may be modified. Use

<varname>StartLimitInterval=</varname>

to configure the checking interval

(defaults to 10s, set to 0 to disable

any kind of rate limiting). Use

<varname>StartLimitBurst=</varname> to

configure how many starts per interval

are allowed (defaults to 5). These

configuration options are particularly

useful in conjunction with

<varname>Restart=</varname>, however

apply to all kinds of starts

(including manual), not just those

triggered by the

<varname>Restart=</varname> logic.

Note that units which are configured

for <varname>Restart=</varname> and

which reach the start limit are not

attempted to be restarted anymore,

however they may still be restarted

manually at a later point from which

point on the restart logic is again

activated. Note that

<command>systemctl

reset-failed</command> will cause the

restart rate counter for a service to

be flushed, which is useful if the

administrator wants to manually start

a service and the start limit

interferes with

that.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>StartLimitAction=</varname></term>

<listitem><para>Configure the action

to take if the rate limit configured

with

<varname>StartLimitInterval=</varname>

and

<varname>StartLimitBurst=</varname> is

hit. Takes one of

<option>none</option>,

<option>reboot</option>,

<option>reboot-force</option> or

<option>reboot-immediate</option>. If

<option>none</option> is set,

hitting the rate limit will trigger no

action besides that the start will not

be

permitted. <option>reboot</option>

causes a reboot following the normal

shutdown procedure (i.e. equivalent to

<command>systemctl reboot</command>),

<option>reboot-force</option> causes

an forced reboot which will terminate

all processes forcibly but should

cause no dirty file systems on reboot

(i.e. equivalent to <command>systemctl

reboot -f</command>) and

<option>reboot-immediate</option>

causes immediate execution of the

<citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>

system call, which might result in

data loss. Defaults to

<option>none</option>.</para></listitem>

</varlistentry>

</variablelist>

<para>Check

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>

and

<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for more settings.</para>

</refsect1>

<refsect1>

<title>Compatibility Options</title>

<para>The following options are also available in the

<literal>[Service]</literal> section, but exist purely

for compatibility reasons and should not be used in

newly written service files.</para>

<variablelist>

<varlistentry>

<term><varname>SysVStartPriority=</varname></term>

<listitem><para>Set the SysV start

priority to use to order this service

in relation to SysV services lacking

LSB headers. This option is only

necessary to fix ordering in relation

to legacy SysV services, that have no

ordering information encoded in the

script headers. As such it should only

be used as temporary compatibility

option, and not be used in new unit

files. Almost always it is a better

choice to add explicit ordering

directives via

<varname>After=</varname> or

<varname>Before=</varname>,

instead. For more details see

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If

used, pass an integer value in the

range 0-99.</para></listitem>

</varlistentry>

<varlistentry>

<term><varname>FsckPassNo=</varname></term>

<listitem><para>Set the fsck passno

priority to use to order this service

in relation to other file system

checking services. This option is only

necessary to fix ordering in relation

to fsck jobs automatically created for

all <filename>/etc/fstab</filename>

entries with a value in the fs_passno

column > 0. As such it should only be

used as option for fsck

services. Almost always it is a better

choice to add explicit ordering

directives via

<varname>After=</varname> or

<varname>Before=</varname>,

instead. For more details see

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If

used, pass an integer value in the

same range as

<filename>/etc/fstab</filename>'s

fs_passno column. See

<citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>

for details.</para></listitem>

</varlistentry>

</variablelist>

</refsect1>

<refsect1>

<title>See Also</title>

<para>

<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,

<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>

</para>

</refsect1>

</refentry>