mirror of
https://github.com/systemd/systemd.git
synced 2024-12-25 01:34:28 +03:00
c485d3ba09
This moves FsckPassNo= and SysVStartPriority= into its own "Compatibility Options" section in the man page to clarify that these options are not useful for anything but establishing a limited amount of compatibility. Also stop exposing these options on the bus.
864 lines
49 KiB
XML
864 lines
49 KiB
XML
<?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">
|
|
|
|
<!--
|
|
This file is part of systemd.
|
|
|
|
Copyright 2010 Lennart Poettering
|
|
|
|
systemd is free software; you can redistribute it and/or modify it
|
|
under the terms of the GNU Lesser General Public License as published by
|
|
the Free Software Foundation; either version 2.1 of the License, or
|
|
(at your option) any later version.
|
|
|
|
systemd is distributed in the hope that it will be useful, but
|
|
WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
Lesser General Public License for more details.
|
|
|
|
You should have received a copy of the GNU Lesser General Public License
|
|
along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|
-->
|
|
|
|
<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>systemd service configuration files</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.</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.</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>. 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 behaviour 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>Behaviour 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>Behaviour 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>Behaviour 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>Behaviour 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></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>ExecStartPre=</varname></term>
|
|
<term><varname>ExecStartPost=</varname></term>
|
|
<listitem><para>Additional commands
|
|
that are executed before (resp. after)
|
|
the command in
|
|
<varname>ExecStart=</varname>. 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 below). 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>TimeoutSec=</varname></term>
|
|
<listitem><para>Configures the time to
|
|
wait for start-up and stop. 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. 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>
|
|
below.) 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>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". 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. 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, when an
|
|
operation 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. 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>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>KillMode=</varname></term>
|
|
<listitem><para>Specifies how
|
|
processes of this service shall be
|
|
killed. One of
|
|
<option>control-group</option>,
|
|
<option>process</option>,
|
|
<option>none</option>.</para>
|
|
|
|
<para>If set to
|
|
<option>control-group</option> all
|
|
remaining processes in the control
|
|
group of this service will be
|
|
terminated on service stop, after the
|
|
stop command (as configured with
|
|
<varname>ExecStop=</varname>) is
|
|
executed. If set to
|
|
<option>process</option> only the main
|
|
process itself is killed. If set to
|
|
<option>none</option> no process is
|
|
killed. In this case only the stop
|
|
command will be executed on service
|
|
stop, but no process be killed
|
|
otherwise. Processes remaining alive
|
|
after stop are left in their control
|
|
group and the control group continues
|
|
to exist after stop unless it is
|
|
empty. Defaults to
|
|
<option>control-group</option>.</para>
|
|
|
|
<para>Processes will first be
|
|
terminated via SIGTERM (unless the
|
|
signal to send is changed via
|
|
<varname>KillSignal=</varname>). If
|
|
then after a delay (configured via the
|
|
<varname>TimeoutSec=</varname> option)
|
|
processes still remain, the
|
|
termination request is repeated with
|
|
the SIGKILL signal (unless this is
|
|
disabled via the
|
|
<varname>SendSIGKILL=</varname>
|
|
option). See
|
|
<citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
|
for more
|
|
information.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>KillSignal=</varname></term>
|
|
<listitem><para>Specifies which signal
|
|
to use when killing a
|
|
service. Defaults to SIGTERM.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><varname>SendSIGKILL=</varname></term>
|
|
<listitem><para>Specifies whether to
|
|
send SIGKILL to remaining processes
|
|
after a timeout, if the normal
|
|
shutdown procedure left processes of
|
|
the service around. Takes a boolean
|
|
value. Defaults to "yes".
|
|
</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>.</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>
|
|
</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>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|