diff options
| author | Anthony G. Basile <blueness@gentoo.org> | 2012-11-15 10:33:16 -0500 |
|---|---|---|
| committer | Anthony G. Basile <blueness@gentoo.org> | 2012-11-15 10:33:16 -0500 |
| commit | 7d4a62f8c1404ed426500b97af03d4ef8d034a71 (patch) | |
| tree | 2436cd4f0460a3a3d589875d4ffba55556f3c582 /man/systemd.service.xml | |
| parent | 2944f347d087ff24ec808e4b70fe104a772a97a0 (diff) | |
Isolation of udev code from remaining systemd
This commit is a first attempt to isolate the udev code from the
remaining code base. It intentionally does not modify any files
but purely delete files which, on a first examination, appear to
not be needed. This is a sweeping commit which may easily have
missed needed code. Files can be retrieved by doing a checkout
from the previous commit:
git checkout 2944f347d0 -- <filename>
Diffstat (limited to 'man/systemd.service.xml')
| -rw-r--r-- | man/systemd.service.xml | 924 |
1 files changed, 0 insertions, 924 deletions
diff --git a/man/systemd.service.xml b/man/systemd.service.xml deleted file mode 100644 index 00a6398a1e..0000000000 --- a/man/systemd.service.xml +++ /dev/null @@ -1,924 +0,0 @@ -<?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>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 - incompatibilities 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 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 - 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, that 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 a 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> - - <para>For services run by a user - instance of systemd the special - environment variable - <literal>MANAGERPID</literal> is set - to the PID of the systemd - instance.</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 - additional special environment - variables 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 equaling 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> |