</refnamediv>
<refsynopsisdiv>
- <para><filename>system.conf</filename></para>
- <para><filename>user.conf</filename></para>
+ <para><filename>/etc/systemd/system.conf</filename></para>
+ <para><filename>/etc/systemd/user.conf</filename></para>
</refsynopsisdiv>
<refsect1>
<term><varname>DumpCore=yes</varname></term>
<term><varname>CrashShell=no</varname></term>
<term><varname>ShowStatus=yes</varname></term>
- <term><varname>SysVConsole=yes</varname></term>
<term><varname>CrashChVT=1</varname></term>
<term><varname>DefaultStandardOutput=journal</varname></term>
<term><varname>DefaultStandardError=inherit</varname></term>
hierarchy. By default systemd will
mount all controllers which are
enabled in the kernel in individual
- hierachies, with the exception of
+ hierarchies, with the exception of
those listed in this setting. Takes a
space separated list of comma
separated controller names, in order
available.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>CapabilityBoundingSet=</varname></term>
+
+ <listitem><para>Controls which
+ capabilities to include in the
+ capability bounding set for PID 1 and
+ its children. See
+ <citerefentry><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ for details. Takes a whitespace
+ separated list of capability names as
+ read by
+ <citerefentry><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ Capabilities listed will be included
+ in the bounding set, all others are
+ removed. If the list of capabilities
+ is prefixed with ~ all but the listed
+ capabilities will be included, the
+ effect of the assignment
+ inverted. Note that this option also
+ effects the respective capabilities in
+ the effective, permitted and
+ inheritable capability sets. The
+ capability bounding set may also be
+ individually configured for units
+ using the
+ <varname>CapabilityBoundingSet=</varname>
+ directive for units, but note that
+ capabilities dropped for PID 1 cannot
+ be regained in individual units, they
+ are lost for good.</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><varname>TimerSlackNSec=</varname></term>
+
+ <listitem><para>Sets the timer slack
+ in nanoseconds for PID 1 which is then
+ inherited to all executed processes,
+ unless overriden individually, for
+ example with the
+ <varname>TimerSlackNSec=</varname>
+ setting in service units (for details
+ see
+ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). The
+ timer slack controls the accuracy of
+ wake-ups triggered by timers. See
+ <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+ for more information. Note that in
+ contrast to most other time span
+ definitions this parameter takes an
+ integer value in nano-seconds if no
+ unit is specified. The usual time
+ units are understood
+ too.</para></listitem>
+ </varlistentry>
+
<varlistentry>
<term><varname>DefaultLimitCPU=</varname></term>
<term><varname>DefaultLimitFSIZE=</varname></term>
<term><varname>DefaultLimitNICE=</varname></term>
<term><varname>DefaultLimitRTPRIO=</varname></term>
<term><varname>DefaultLimitRTTIME=</varname></term>
+
<listitem><para>These settings control
- various default resource limits for units. See
+ various default resource limits for
+ units. See
<citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for details. Use the string
<varname>infinity</varname> to
configure no limit on a specific
- resource. They can be overriden in units files
- using corresponding LimitXXXX parameter.</para></listitem>
+ resource. These settings may be
+ overriden 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>
</varlistentry>
</variablelist>
</refsect1>
~ianmdlvl / elogind.git / blobdiff