Copyright 2010 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
+ 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
- General Public License for more details.
+ Lesser General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see <http://www.gnu.org/licenses/>.
-->
<refnamediv>
<refname>systemd.service</refname>
- <refpurpose>systemd service configuration files</refpurpose>
+ <refpurpose>Service unit configuration</refpurpose>
</refnamediv>
<refsynopsisdiv>
<refsect1>
<title>Description</title>
- <para>A configuration file ending in .service encodes
- information about a process controlled and supervised
- by systemd.</para>
+ <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.</para>
+ 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>One of
- <literal>forking</literal>,
- <literal>simple</literal>,
- <literal>finish</literal>,
- <literal>dbus</literal>.</para>
-
- <para>If set to
- <literal>forking</literal>
- (the default) it is expected
- that the process configured
- with
- <varname>ExecStart=</varname>
- will start up and call
- <function>fork()</function>. The
- parent process is expected to
- finish 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>If set to
- <literal>simple</literal> (the
- recommended value) it is
- expected that the process
- configured with
- <varname>ExecStart=</varname>
- is the main process of the
- daemon. In this mode,
- communication channels must be
- available before the daemon is
- started up (sockets set up by systemd),
- as systemd will immediately proceed
- starting follow-up units.</para>
-
- <para>Behaviour of
- <literal>finish</literal> is
- similar to
- <literal>simple</literal>,
- however it is expected that
- the process has to exit before
- systemd starts follow-up
- units. <varname>ValidNoProcess=</varname>
- is particularly useful for
- this type of service.</para>
-
- <para>Behaviour of
- <literal>dbus</literal> is
- similar to
- <literal>simple</literal>,
- 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.</para>
+
+ <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>ValidNoProcess=</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 <literal>no</literal>.</para>
+ <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
- <literal>forking</literal>.</para>
+
+ <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
- <literal>dbus</literal>, but
- its use is otherwise
- recommended as well if the
- process takes a name on the
- D-Bus bus.</para>
+
+ <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 word of the
- command line must be an
- absolute file name. It is
- mandatory to set this option
- for all services.</para>
- </listitem>
+ <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
+ <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>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>
+ 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, except when <varname>Type=oneshot</varname> is
+ used in which case the timeout
+ is disabled by default.</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>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>
<title>See Also</title>
<para>
- <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
- <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <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>
~ianmdlvl / elogind.git / blobdiff