<filename>user.conf.d</filename> directories. These configuration
files contain a few settings controlling basic manager
operations. See
- <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for a general description of the syntax.</para>
</refsect1>
<title>Options</title>
<para>All options are configured in the
- <literal>[Manager]</literal> section:</para>
+ [Manager] section:</para>
<variablelist class='config-directives'>
<varlistentry>
- <term><varname>LogLevel=</varname></term>
- <term><varname>LogTarget=</varname></term>
<term><varname>LogColor=</varname></term>
+ <term><varname>LogLevel=</varname></term>
<term><varname>LogLocation=</varname></term>
+ <term><varname>LogTarget=</varname></term>
+ <term><varname>LogTime=</varname></term>
<term><varname>DumpCore=yes</varname></term>
<term><varname>CrashChangeVT=no</varname></term>
<term><varname>CrashShell=no</varname></term>
<listitem><para>Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that
<option>default</option> and <option>local</option> NUMA policies don't require explicit NUMA node mask and
- value of the option can be empty. Similarly to <varname>NUMAPolicy=</varname>, value can be overriden
+ value of the option can be empty. Similarly to <varname>NUMAPolicy=</varname>, value can be overridden
by individual services in unit files, see
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>RuntimeWatchdogSec=</varname></term>
- <term><varname>ShutdownWatchdogSec=</varname></term>
+ <term><varname>RebootWatchdogSec=</varname></term>
+ <term><varname>KExecWatchdogSec=</varname></term>
<listitem><para>Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in seconds (or
in other time units if suffixed with <literal>ms</literal>, <literal>min</literal>, <literal>h</literal>,
system manager will ensure to contact it at least once in half the specified timeout interval. This feature
requires a hardware watchdog device to be present, as it is commonly the case in embedded and server
systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in which case
- the closest available timeout is picked. <varname>ShutdownWatchdogSec=</varname> may be used to configure the
+ the closest available timeout is picked. <varname>RebootWatchdogSec=</varname> may be used to configure the
hardware watchdog when the system is asked to reboot. It works as a safety net to ensure that the reboot takes
- place even if a clean reboot attempt times out. Note that the <varname>ShutdownWatchdogSec=</varname> timeout
+ place even if a clean reboot attempt times out. Note that the <varname>RebootWatchdogSec=</varname> timeout
applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and
after the system and service manager process (PID 1) got replaced by the <filename>systemd-shutdown</filename>
binary, see system <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details. During the first phase of the shutdown operation the system and service manager remains running
and hence <varname>RuntimeWatchdogSec=</varname> is still honoured. In order to define a timeout on this first
phase of system shutdown, configure <varname>JobTimeoutSec=</varname> and <varname>JobTimeoutAction=</varname>
- in the <literal>[Unit]</literal> section of the <filename>shutdown.target</filename> unit. By default
- <varname>RuntimeWatchdogSec=</varname> defaults to 0 (off), and <varname>ShutdownWatchdogSec=</varname> to
- 10min. These settings have no effect if a hardware watchdog is not available.</para></listitem>
+ in the [Unit] section of the <filename>shutdown.target</filename> unit. By default
+ <varname>RuntimeWatchdogSec=</varname> defaults to 0 (off), and <varname>RebootWatchdogSec=</varname> to
+ 10min. <varname>KExecWatchdogSec=</varname> may be used to additionally enable the watchdog when kexec
+ is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on kexec (depending
+ on the specific hardware and/or driver), in this case the watchdog might not get disabled after kexec succeeds
+ and thus the system might get rebooted, unless <varname>RuntimeWatchdogSec=</varname> is also enabled at the same time.
+ For this reason it is recommended to enable <varname>KExecWatchdogSec=</varname> only if
+ <varname>RuntimeWatchdogSec=</varname> is also enabled.
+ These settings have no effect if a hardware watchdog is not available.</para></listitem>
</varlistentry>
<varlistentry>
understood too.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>StatusUnitFormat=</varname></term>
+
+ <listitem><para>Takes either <option>name</option> or <option>description</option> as the value. If
+ <option>name</option>, the system manager will use unit names in status messages, instead of the
+ longer and more informative descriptions set with <varname>Description=</varname>, see
+ <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ </para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>DefaultTimerAccuracySec=</varname></term>
<term><varname>DefaultLimitRTPRIO=</varname></term>
<term><varname>DefaultLimitRTTIME=</varname></term>
- <listitem><para>These settings control various default
- resource limits for units. See
- <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
- for details. The resource limit is possible to specify in two formats,
- <option>value</option> to set soft and hard limits to the same value,
- or <option>soft:hard</option> to set both limits individually (e.g. DefaultLimitAS=4G:16G).
- Use the string <varname>infinity</varname> to
- configure no limit on a specific resource. The multiplicative
- suffixes K (=1024), M (=1024*1024) and so on for G, T, P and E
- may be used for resource limits measured in bytes
- (e.g. DefaultLimitAS=16G). For the limits referring to time values,
- the usual time units ms, s, min, h and so on may be used (see
- <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
- for details). Note that if no time unit is specified for
- <varname>DefaultLimitCPU=</varname> the default unit of seconds is
- implied, while for <varname>DefaultLimitRTTIME=</varname> the default
- unit of microseconds is implied. Also, note that the effective
- granularity of the limits might influence their
- enforcement. For example, time limits specified for
- <varname>DefaultLimitCPU=</varname> will be rounded up implicitly to
- multiples of 1s. These settings may be overridden in individual units
- using the corresponding LimitXXX= directives. Note that these resource
- limits are only defaults for units, they are not applied to PID 1
- itself.</para></listitem>
+ <listitem><para>These settings control various default resource limits for processes executed by
+ units. See
+ <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+ details. These settings may be overridden in individual units using the corresponding
+ <varname>LimitXXX=</varname> directives and they accept the same parameter syntax,
+ see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details. Note that these resource limits are only defaults
+ for units, they are not applied to the service manager process (i.e. PID 1) itself.</para></listitem>
</varlistentry>
<varlistentry>
projects / thirdparty / systemd.git / blobdiff