diff options
Diffstat (limited to 'man')
| -rw-r--r-- | man/coredump.conf.xml | 16 | ||||
| -rw-r--r-- | man/coredumpctl.xml | 60 | ||||
| -rw-r--r-- | man/halt.xml | 8 | ||||
| -rw-r--r-- | man/systemctl.xml | 30 | ||||
| -rw-r--r-- | man/systemd-coredump.xml | 98 | ||||
| -rw-r--r-- | man/systemd.exec.xml | 5 | ||||
| -rw-r--r-- | man/systemd.netdev.xml | 9 | ||||
| -rw-r--r-- | man/systemd.network.xml | 15 | ||||
| -rw-r--r-- | man/systemd.resource-control.xml | 223 | ||||
| -rw-r--r-- | man/systemd.timer.xml | 2 | ||||
| -rw-r--r-- | man/systemd.unit.xml | 2 |
11 files changed, 335 insertions, 133 deletions
diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml index 2064a96523..4f95680a3a 100644 --- a/man/coredump.conf.xml +++ b/man/coredump.conf.xml @@ -45,7 +45,7 @@ <refnamediv> <refname>coredump.conf</refname> <refname>coredump.conf.d</refname> - <refpurpose>Coredump storage configuration files</refpurpose> + <refpurpose>Core dump storage configuration files</refpurpose> </refnamediv> <refsynopsisdiv> @@ -86,7 +86,7 @@ <listitem><para>Controls where to store cores. One of <literal>none</literal>, <literal>external</literal>, <literal>journal</literal>, and <literal>both</literal>. When - <literal>none</literal>, the coredumps will be logged but not + <literal>none</literal>, the core dumps will be logged but not stored permanently. When <literal>external</literal> (the default), cores will be stored in <filename>/var/lib/systemd/coredump</filename>. When <literal>journal</literal>, cores will be stored in @@ -114,7 +114,7 @@ <term><varname>ProcessSizeMax=</varname></term> <listitem><para>The maximum size in bytes of a core - which will be processed. Coredumps exceeding this size + which will be processed. Core dumps exceeding this size will be logged, but the backtrace will not be generated and the core will not be stored.</para></listitem> </varlistentry> @@ -132,14 +132,14 @@ <term><varname>KeepFree=</varname></term> <listitem><para>Enforce limits on the disk space taken up by - externally stored coredumps. <option>MaxUse=</option> makes - sure that old coredumps are removed as soon as the total disk - space taken up by coredumps grows beyond this limit (defaults + externally stored core dumps. <option>MaxUse=</option> makes + sure that old core dumps are removed as soon as the total disk + space taken up by core dumps grows beyond this limit (defaults to 10% of the total disk size). <option>KeepFree=</option> controls how much disk space to keep free at least (defaults to 15% of the total disk size). Note that the disk space used - by coredumps might temporarily exceed these limits while - coredumps are processed. Note that old coredumps are also + by core dumps might temporarily exceed these limits while + core dumps are processed. Note that old core dumps are also removed based on time via <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Set either value to 0 to turn off size-based diff --git a/man/coredumpctl.xml b/man/coredumpctl.xml index 0f1afe77c3..abc245be5e 100644 --- a/man/coredumpctl.xml +++ b/man/coredumpctl.xml @@ -45,7 +45,7 @@ <refnamediv> <refname>coredumpctl</refname> - <refpurpose>Retrieve coredumps from the journal</refpurpose> + <refpurpose>Retrieve and process saved core dumps and metadata</refpurpose> </refnamediv> <refsynopsisdiv> @@ -60,9 +60,10 @@ <refsect1> <title>Description</title> - <para><command>coredumpctl</command> may be used to - retrieve coredumps from - <citerefentry><refentrytitle>systemd-journald</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + <para><command>coredumpctl</command> is a tool that can be used to retrieve and process core + dumps and metadata which were saved by + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> </refsect1> <refsect1> @@ -71,18 +72,23 @@ <para>The following options are understood:</para> <variablelist> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <varlistentry> <term><option>--no-legend</option></term> - <listitem><para>Do not print column headers. - </para></listitem> + <listitem><para>Do not print column headers.</para></listitem> </varlistentry> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <varlistentry> <term><option>-1</option></term> - <listitem><para>Show information of a single coredump only, - instead of listing all known coredumps. </para></listitem> + <listitem><para>Show information of a single core dump only, instead of listing + all known core dumps.</para></listitem> </varlistentry> <varlistentry> @@ -90,7 +96,7 @@ <term><option>--field=</option><replaceable>FIELD</replaceable></term> <listitem><para>Print all possible data values the specified - field takes in matching coredump entries of the + field takes in matching core dump entries of the journal.</para></listitem> </varlistentry> @@ -110,11 +116,11 @@ </para></listitem> </varlistentry> - <xi:include href="standard-options.xml" xpointer="help" /> - <xi:include href="standard-options.xml" xpointer="version" /> - <xi:include href="standard-options.xml" xpointer="no-pager" /> - </variablelist> + </refsect1> + + <refsect1> + <title>Commands</title> <para>The following commands are understood:</para> @@ -122,23 +128,31 @@ <varlistentry> <term><command>list</command></term> - <listitem><para>List coredumps captured in the journal + <listitem><para>List core dumps captured in the journal matching specified characteristics. If no command is - specified, this is the implied default.</para></listitem> + specified, this is the implied default.</para> + + <para>It's worth noting that different restrictions apply to + data saved in the journal and core dump files saved in + <filename>/var/lib/systemd/coredump</filename>, see overview in + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Thus it may very well happen that a particular core dump is still listed + in the journal while its corresponding core dump file has already been + removed.</para></listitem> </varlistentry> <varlistentry> <term><command>info</command></term> - <listitem><para>Show detailed information about coredumps + <listitem><para>Show detailed information about core dumps captured in the journal.</para></listitem> </varlistentry> <varlistentry> <term><command>dump</command></term> - <listitem><para>Extract the last coredump matching specified - characteristics. The coredump will be written on standard + <listitem><para>Extract the last core dump matching specified + characteristics. The core dump will be written on standard output, unless an output file is specified with <option>--output=</option>. </para></listitem> </varlistentry> @@ -146,7 +160,7 @@ <varlistentry> <term><command>gdb</command></term> - <listitem><para>Invoke the GNU debugger on the last coredump + <listitem><para>Invoke the GNU debugger on the last core dump matching specified characteristics. </para></listitem> </varlistentry> @@ -197,7 +211,7 @@ <refsect1> <title>Exit status</title> <para>On success, 0 is returned; otherwise, a non-zero failure - code is returned. Not finding any matching coredumps is treated as + code is returned. Not finding any matching core dumps is treated as failure. </para> </refsect1> @@ -206,13 +220,13 @@ <title>Examples</title> <example> - <title>List all the coredumps of a program named foo</title> + <title>List all the core dumps of a program named foo</title> <programlisting># coredumpctl list foo</programlisting> </example> <example> - <title>Invoke gdb on the last coredump</title> + <title>Invoke gdb on the last core dump</title> <programlisting># coredumpctl gdb</programlisting> </example> @@ -225,7 +239,7 @@ </example> <example> - <title>Extract the last coredump of /usr/bin/bar to a file named + <title>Extract the last core dump of /usr/bin/bar to a file named <filename noindex="true">bar.coredump</filename></title> <programlisting># coredumpctl -o bar.coredump dump /usr/bin/bar</programlisting> diff --git a/man/halt.xml b/man/halt.xml index a06dbd0097..e3fa60a915 100644 --- a/man/halt.xml +++ b/man/halt.xml @@ -133,6 +133,14 @@ </varlistentry> <varlistentry> + <term><option>-n</option></term> + <term><option>--no-sync</option></term> + + <listitem><para>Don't sync hard disks/storage media before + halt, power-off, reboot.</para></listitem> + </varlistentry> + + <varlistentry> <term><option>--no-wall</option></term> <listitem><para>Do not send wall message before halt, diff --git a/man/systemctl.xml b/man/systemctl.xml index 991e9bafaf..2288f65d16 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -150,11 +150,11 @@ <term><option>--all</option></term> <listitem> - <para>When listing units, show all loaded units, regardless - of their state, including inactive units. When showing - unit/job/manager properties, show all properties regardless - whether they are set or not.</para> - <para>To list all units installed on the system, use the + <para>When listing units with <command>list-units</command>, also show inactive units and + units which are following other units. When showing unit/job/manager properties, show all + properties regardless whether they are set or not.</para> + + <para>To list all units installed in the file system, use the <command>list-unit-files</command> command instead.</para> </listitem> </varlistentry> @@ -638,10 +638,13 @@ <term><command>list-units <optional><replaceable>PATTERN</replaceable>...</optional></command></term> <listitem> - <para>List known units (subject to limitations specified - with <option>-t</option>). If one or more - <replaceable>PATTERN</replaceable>s are specified, only - units matching one of them are shown.</para> + <para>List units that <command>systemd</command> has loaded. This includes units that + are either referenced directly or through a dependency, or units that were active in the + past and have failed. By default only units which are active, have pending jobs, or have + failed are shown; this can be changed with option <option>--all</option>. If one or more + <replaceable>PATTERN</replaceable>s are specified, only units matching one of them are + shown. The units that are shown are additionally filtered by <option>--type=</option> + and <option>--state=</option> if those options are specified.</para> <para>This is the default command.</para> </listitem> @@ -970,11 +973,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service <term><command>list-unit-files <optional><replaceable>PATTERN...</replaceable></optional></command></term> <listitem> - <para>List installed unit files and their enablement state - (as reported by <command>is-enabled</command>). If one or - more <replaceable>PATTERN</replaceable>s are specified, - only units whose filename (just the last component of the - path) matches one of them are shown.</para> + <para>List unit files installed in the file system and their enablement state + (as reported by <command>is-enabled</command>). If one or more + <replaceable>PATTERN</replaceable>s are specified, only units whose filename + (just the last component of the path) matches one of them are shown.</para> </listitem> </varlistentry> diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml index 51dc27e8d3..a28dc62e5a 100644 --- a/man/systemd-coredump.xml +++ b/man/systemd-coredump.xml @@ -47,7 +47,7 @@ <refname>systemd-coredump</refname> <refname>systemd-coredump.socket</refname> <refname>systemd-coredump@.service</refname> - <refpurpose>Log and store core dumps</refpurpose> + <refpurpose>Acquire, save and process core dumps</refpurpose> </refnamediv> <refsynopsisdiv> @@ -58,59 +58,76 @@ <refsect1> <title>Description</title> + <para><command>systemd-coredump</command> is a system service that can acquire core dumps + from the kernel and handle them in various ways.</para> - <para><command>systemd-coredump</command> can be used as a helper - binary by the kernel when a user space program receives a fatal - signal and dumps core. For it to be used in this capacity, it must - be specified by the - <varname>kernel.core_pattern</varname> <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> - setting. The syntax of this setting is explained in - <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. - Systemd installs <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures - <varname>kernel.core_pattern</varname> to invoke <command>systemd-coredump</command>. - This file may be masked or overridden to use a different setting following normal - <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> - rules.</para> - - <para>The behavior of a specific program upon reception of a - signal is governed by a few factors which are described in detail - in <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. - In particular, the coredump will only be processed when the - related resource limits are high enough. For programs started by - <command>systemd</command>, those may be set using - <varname>LimitCore=</varname> (see - <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + <para>Core dumps can be written to the journal or saved as a file. Once saved they can be retrieved + for further processing, for example in + <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>. </para> - <para>The behaviour of <command>systemd-coredump</command> is configured through - <filename>/etc/systemd/coredump.conf</filename> and other configuration files. See - <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> - for details. By default, <command>systemd-coredump</command> will log the coredump including a - backtrace if possible, and store the core (contents of process' memory contents) in an external - file on disk in <filename>/var/lib/systemd/coredump</filename>.</para> + <para>By default, <command>systemd-coredump</command> will log the core dump including a backtrace + if possible to the journal and store the core dump itself in an external file in + <filename>/var/lib/systemd/coredump</filename>.</para> - <para>When the kernel invokes <command>systemd-coredump</command> to handle a coredump, + <para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it will connect to the socket created by the <filename>systemd-coredump.socket</filename> unit, which in turn will spawn a <filename>systemd-coredump@.service</filename> instance - to process the coredump. Hence <filename>systemd-coredump.socket</filename> + to process the core dump. Hence <filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename> are helper units which do the actual - processing of coredumps and are subject to normal service management.</para> + processing of core dumps and are subject to normal service management.</para> - <para>The log entry and a backtrace are stored in the journal, and can be viewed with - <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. - <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> - may be used to list and extract coredumps or load them in - <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + <para>The behavior of a specific program upon reception of a signal is governed by a few + factors which are described in detail in + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + In particular, the core dump will only be processed when the related resource limits are sufficient. </para> + </refsect1> - <para>The coredump helper is invoked anew each time. Therefore, any configuration - changes will take effect on the invocation of <command>systemd-coredump</command>. + <refsect1> + <title>Configuration</title> + <para>For programs started by <command>systemd</command> process resource limits can be set by directive + <varname>LimitCore=</varname>, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>In order to be used <command>systemd-coredump</command> must be configured in + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + parameter <varname>kernel.core_pattern</varname>. The syntax of this parameter is explained in + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Systemd installs the file <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures + <varname>kernel.core_pattern</varname> accordingly. This file may be masked or overridden to use a different + setting following normal + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + rules. If the sysctl configuration is modified, it must be updated in the kernel before it takes effect, see - <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> and - <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>. </para> + + <para>The behaviour of <command>systemd-coredump</command> itself is configured through the configuration file + <filename>/etc/systemd/coredump.conf</filename> and corresponding snippets + <filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see + <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new + instance of <command>systemd-coredump</command> is invoked upon receiving every core dump. Therefore, changes + in these files will take effect the next time a core dump is received.</para> + + <para>Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired + core dumps and files can be set in files <filename>/etc/systemd/coredump.conf</filename> and snippets mentioned + above. In addition the storage time of core dump files is restricted by <command>systemd-tmpfiles</command>, + corresponding settings are by default in <filename>/usr/lib/tmpfiles.d/systemd.conf</filename>.</para> + </refsect1> + + <refsect1> + <title>Usage</title> + <para>Data stored in the journal can be viewed with + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + as usual. + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + can be used to retrieve saved core dumps independent of their location, to display information and to process + them e.g. by passing to the GNU debugger (gdb).</para> </refsect1> <refsect1> @@ -119,6 +136,7 @@ <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index 2a93760428..3cf6de8256 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -933,7 +933,10 @@ (propagation in the opposite direction continues to work). This means that this setting may not be used for services which shall be able to install mount points in the main mount - namespace.</para></listitem> + namespace. The /dev namespace will be mounted read-only and 'noexec'. + The latter may break old programs which try to set up executable + memory by using <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> + of <filename>/dev/zero</filename> instead of using <constant>MAP_ANON</constant>.</para></listitem> </varlistentry> <varlistentry> diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index 48c283c8df..8d12c305d2 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -321,6 +321,15 @@ </para> </listitem> </varlistentry> + <varlistentry> + <term><varname>MulticastSnooping=</varname></term> + <listitem> + <para>A boolean. This setting controls the IFLA_BR_MCAST_SNOOPING option in the kernel. + If enabled, IGMP snooping monitors the Internet Group Management Protocol (IGMP) traffic + between hosts and multicast routers. When unset, the kernel's default setting applies. + </para> + </listitem> + </varlistentry> </variablelist> </refsect1> diff --git a/man/systemd.network.xml b/man/systemd.network.xml index 70e3804746..821e22aff8 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -105,7 +105,8 @@ <varlistentry> <term><varname>MACAddress=</varname></term> <listitem> - <para>The hardware address.</para> + <para>The hardware address of the interface (use full colon-delimited hexadecimal, e.g., + 01:23:45:67:89:ab).</para> </listitem> </varlistentry> <varlistentry> @@ -198,7 +199,7 @@ <varlistentry> <term><varname>MACAddress=</varname></term> <listitem> - <para>The hardware address.</para> + <para>The hardware address to set for the device.</para> </listitem> </varlistentry> <varlistentry> @@ -982,6 +983,16 @@ </varlistentry> <varlistentry> + <term><varname>EmitRouter=</varname></term> + + <listitem><para>Similar to the <varname>EmitDNS=</varname> + setting described above, this setting configures whether the + DHCP lease should contain the router option. The same syntax, + propagation semantics and defaults apply as for + <varname>EmitDNS=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> <term><varname>EmitTimezone=</varname></term> <term><varname>Timezone=</varname></term> diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml index fd6f7a1b69..066f2cc19b 100644 --- a/man/systemd.resource-control.xml +++ b/man/systemd.resource-control.xml @@ -99,6 +99,31 @@ </refsect1> <refsect1> + <title>Unified and Legacy Control Group Hierarchies</title> + + <para>Unified control group hierarchy is the new version of kernel control group interface. Depending on the + resource type, there are differences in resource control capabilities. Also, because of interface changes, some + resource types have a separate set of options on the unified hierarchy.</para> + + <para> + <variablelist> + <varlistentry> + <term><option>IO</option></term> + <listitem> + <para><varname>IO</varname> prefixed settings are superset of and replace <varname>BlockIO</varname> + prefixed ones. On unified hierarchy, IO resource control also applies to buffered writes.</para> + </listitem> + </varlistentry> + </variablelist> + </para> + + <para>To ease the transition, there is best-effort translation between the two versions of settings. If all + settings of a unit for a given resource type are for the other hierarchy type, the settings are translated and + applied. If there are any valid settings for the hierarchy in use, all translations are disabled for the resource + type. Mixing the two types of settings on a unit can lead to confusing results.</para> + </refsect1> + + <refsect1> <title>Options</title> <para>Units of the types listed above can have settings @@ -249,17 +274,130 @@ </varlistentry> <varlistentry> + <term><varname>IOAccounting=</varname></term> + + <listitem> + <para>Turn on Block I/O accounting for this unit, if the unified control group hierarchy is used on the + system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly + turn it on for all units contained in the same slice and all for its parent slices and the units contained + therein. The system default for this setting may be controlled with <varname>DefaultIOAccounting=</varname> + in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used. Use + <varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOWeight=<replaceable>weight</replaceable></varname></term> + <term><varname>StartupIOWeight=<replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Set the default overall block I/O weight for the executed processes, if the unified control group + hierarchy is used on the system. Takes a single weight value (between 1 and 10000) to set the default block + I/O weight. This controls the <literal>io.weight</literal> control group attribute, which defaults to + 100. For details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>. The available I/O + bandwidth is split up among all units within one slice relative to their block I/O weight.</para> + + <para>While <varname>StartupIOWeight=</varname> only applies + to the startup phase of the system, + <varname>IOWeight=</varname> applies to the later runtime of + the system, and if the former is not set also to the startup + phase. This allows prioritizing specific services at boot-up + differently than during runtime.</para> + + <para>Implies <literal>IOAccounting=true</literal>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used. Use + <varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname> on systems using the legacy + control group hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O weight for the executed processes, if the unified control group + hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify + the device specific weight value, between 1 and 10000. (Example: "/dev/sda 1000"). The file path may be + specified as path to a block device node or as any other file, in which case the backing block device of the + file system of the file is determined. This controls the <literal>io.weight</literal> control group + attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices. For + details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para> + + <para>Implies <literal>IOAccounting=true</literal>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used. Use + <varname>BlockIODeviceWeight=</varname> on systems using the legacy control group hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOReadBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + <term><varname>IOWriteBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified + control group hierarchy is used on the system. This limit is not work-conserving and the executed processes + are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of a file + path and a bandwidth value (in bytes per second) to specify the device specific bandwidth. The file path may + be a path to a block device node, or as any other file in which case the backing block device of the file + system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the <literal>io.max</literal> control + group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details + about this control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>. + </para> + + <para>Implies <literal>IOAccounting=true</literal>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used. Use + <varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOReadIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term> + <term><varname>IOWriteIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the + unified control group hierarchy is used on the system. This limit is not work-conserving and the executed + processes are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of + a file path and an IOPS value to specify the device specific IOPS. The file path may be a path to a block + device node, or as any other file in which case the backing block device of the file system of the file is + used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS, + GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the <literal>io.max</literal> control + group attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about + this control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>. + </para> + + <para>Implies <literal>IOAccounting=true</literal>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used.</para> + </listitem> + </varlistentry> + + <varlistentry> <term><varname>BlockIOAccounting=</varname></term> <listitem> - <para>Turn on Block I/O accounting for this unit. Takes a - boolean argument. Note that turning on block I/O accounting - for one unit will also implicitly turn it on for all units - contained in the same slice and all for its parent slices - and the units contained therein. The system default for this - setting may be controlled with + <para>Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the + system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly + turn it on for all units contained in the same slice and all for its parent slices and the units contained + therein. The system default for this setting may be controlled with <varname>DefaultBlockIOAccounting=</varname> in <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>This setting is supported only if the legacy control group hierarchy is used. Use + <varname>IOAccounting=</varname> on systems using the unified control group hierarchy.</para> </listitem> </varlistentry> @@ -267,15 +405,13 @@ <term><varname>BlockIOWeight=<replaceable>weight</replaceable></varname></term> <term><varname>StartupBlockIOWeight=<replaceable>weight</replaceable></varname></term> - <listitem><para>Set the default overall block I/O weight for - the executed processes. Takes a single weight value (between - 10 and 1000) to set the default block I/O weight. This controls - the <literal>blkio.weight</literal> control group attribute, - which defaults to 500. For details about this control group - attribute, see <ulink + <listitem><para>Set the default overall block I/O weight for the executed processes, if the legacy control + group hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default + block I/O weight. This controls the <literal>blkio.weight</literal> control group attribute, which defaults to + 500. For details about this control group attribute, see <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>. - The available I/O bandwidth is split up among all units within - one slice relative to their block I/O weight.</para> + The available I/O bandwidth is split up among all units within one slice relative to their block I/O + weight.</para> <para>While <varname>StartupBlockIOWeight=</varname> only applies to the startup phase of the system, @@ -286,29 +422,32 @@ <para>Implies <literal>BlockIOAccounting=true</literal>.</para> - </listitem> + + <para>This setting is supported only if the legacy control group hierarchy is used. Use + <varname>IOWeight=</varname> and <varname>StartupIOWeight=</varname> on systems using the unified control group + hierarchy.</para> + + </listitem> </varlistentry> <varlistentry> <term><varname>BlockIODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term> <listitem> - <para>Set the per-device overall block I/O weight for the - executed processes. Takes a space-separated pair of a file - path and a weight value to specify the device specific - weight value, between 10 and 1000. (Example: "/dev/sda - 500"). The file path may be specified as path to a block - device node or as any other file, in which case the backing - block device of the file system of the file is - determined. This controls the - <literal>blkio.weight_device</literal> control group - attribute, which defaults to 1000. Use this option multiple - times to set weights for multiple devices. For details about - this control group attribute, see <ulink + <para>Set the per-device overall block I/O weight for the executed processes, if the legacy control group + hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify + the device specific weight value, between 10 and 1000. (Example: "/dev/sda 500"). The file path may be + specified as path to a block device node or as any other file, in which case the backing block device of the + file system of the file is determined. This controls the <literal>blkio.weight_device</literal> control group + attribute, which defaults to 1000. Use this option multiple times to set weights for multiple devices. For + details about this control group attribute, see <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>.</para> <para>Implies <literal>BlockIOAccounting=true</literal>.</para> + + <para>This setting is supported only if the legacy control group hierarchy is used. Use + <varname>IODeviceWeight=</varname> on systems using the unified control group hierarchy.</para> </listitem> </varlistentry> @@ -317,27 +456,25 @@ <term><varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> <listitem> - <para>Set the per-device overall block I/O bandwidth limit - for the executed processes. Takes a space-separated pair of - a file path and a bandwidth value (in bytes per second) to - specify the device specific bandwidth. The file path may be - a path to a block device node, or as any other file in which - case the backing block device of the file system of the file - is used. If the bandwidth is suffixed with K, M, G, or T, - the specified bandwidth is parsed as Kilobytes, Megabytes, - Gigabytes, or Terabytes, respectively, to the base of - 1000. (Example: - "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This - controls the <literal>blkio.throttle.read_bps_device</literal> and - <literal>blkio.throttle.write_bps_device</literal> control group - attributes. Use this option multiple times to set bandwidth - limits for multiple devices. For details about these control - group attributes, see <ulink + <para>Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control + group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in + bytes per second) to specify the device specific bandwidth. The file path may be a path to a block device + node, or as any other file in which case the backing block device of the file system of the file is used. If + the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes, Megabytes, + Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the + <literal>blkio.throttle.read_bps_device</literal> and <literal>blkio.throttle.write_bps_device</literal> + control group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For + details about these control group attributes, see <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>. </para> <para>Implies <literal>BlockIOAccounting=true</literal>.</para> + + <para>This setting is supported only if the legacy control group hierarchy is used. Use + <varname>IOReadBandwidthMax=</varname> and <varname>IOWriteBandwidthMax=</varname> on systems using the + unified control group hierarchy.</para> </listitem> </varlistentry> diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml index 0d0cccf152..0fa95e97a8 100644 --- a/man/systemd.timer.xml +++ b/man/systemd.timer.xml @@ -288,7 +288,7 @@ starting a timer unit that only elapses once: if <varname>RemainAfterElapse=</varname> is on, it will not be started again, and is guaranteed to elapse only once. However, - if <varname>RemainAfterLeapse=</varname> is off, it might be + if <varname>RemainAfterElapse=</varname> is off, it might be started again if it is already elapsed, and thus be triggered multiple times. Defaults to <varname>yes</varname>.</para></listitem> diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 90a1ec6b9c..341789cd47 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -603,7 +603,7 @@ <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details). If a unit that has this setting set is started, its processes will see the same <filename>/tmp</filename>, - <filename>/tmp/var</filename> and network namespace as one + <filename>/var/tmp</filename> and network namespace as one listed unit that is started. If multiple listed units are already started, it is not defined which namespace is joined. Note that this setting only has an effect if |