diff options
author | Adrian Szyndela <adrian.s@samsung.com> | 2020-03-27 09:27:11 +0100 |
---|---|---|
committer | Adrian Szyndela <adrian.s@samsung.com> | 2020-03-27 11:13:45 +0100 |
commit | 5f3f628ebc0867b7d078849c614958e09ce74850 (patch) | |
tree | e6cabc7e68ae658b13db8857d3c308de691f73db /man | |
parent | 31e58df2dbd9a3b2afcebd654cc1ad29589dd6c0 (diff) | |
parent | efb536d0cbe2e58f80e501d19999928c75e08f6a (diff) | |
download | systemd-5f3f628ebc0867b7d078849c614958e09ce74850.tar.gz systemd-5f3f628ebc0867b7d078849c614958e09ce74850.tar.bz2 systemd-5f3f628ebc0867b7d078849c614958e09ce74850.zip |
Merge v243 into tizen
systemd v243
Diffstat (limited to 'man')
91 files changed, 3940 insertions, 1039 deletions
diff --git a/man/50-xdg-data-dirs.sh b/man/50-xdg-data-dirs.sh index 073174cb40..89e9fbb599 100755 --- a/man/50-xdg-data-dirs.sh +++ b/man/50-xdg-data-dirs.sh @@ -5,7 +5,7 @@ XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share}" # add a directory if it exists if [[ -d /opt/foo/share ]]; then - XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS} + XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS} fi # write our output diff --git a/man/bootctl.xml b/man/bootctl.xml index a80a37309c..822d07a606 100644 --- a/man/bootctl.xml +++ b/man/bootctl.xml @@ -45,32 +45,42 @@ <varlistentry> <term><option>--esp-path=</option></term> <listitem><para>Path to the EFI System Partition (ESP). If not specified, <filename>/efi/</filename>, - <filename>/boot/</filename>, and <filename>/boot/efi</filename> are checked in turn. It is recommended to mount - the ESP to <filename>/efi/</filename>, if possible.</para></listitem> + <filename>/boot/</filename>, and <filename>/boot/efi/</filename> are checked in turn. It is + recommended to mount the ESP to <filename>/efi/</filename>, if possible.</para></listitem> </varlistentry> <varlistentry> <term><option>--boot-path=</option></term> <listitem><para>Path to the Extended Boot Loader partition, as defined in the <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>. If not - specified, <filename>/boot/</filename> are checked. It is recommended to mount the Extended Boot + specified, <filename>/boot/</filename> is checked. It is recommended to mount the Extended Boot Loader partition to <filename>/boot/</filename>, if possible.</para></listitem> </varlistentry> <varlistentry> <term><option>-p</option></term> <term><option>--print-esp-path</option></term> - <listitem><para>This option modifies the behaviour of <command>status</command>. Prints only the - path to the EFI System Partition (ESP) to standard output and exits.</para></listitem> + <listitem><para>This option modifies the behaviour of <command>status</command>. Only prints the path + to the EFI System Partition (ESP) to standard output and exits.</para></listitem> </varlistentry> <varlistentry> + <term><option>-x</option></term> <term><option>--print-boot-path</option></term> - <listitem><para>This option modifies the behaviour of <command>status</command>. Prints only the - path to the Extended Boot Loader partition if it exists, and the path to the ESP otherwise to - standard output and exit. This command is useful to determine where to place boot loader entries, as - they are preferably placed in the Extended Boot Loader partition if it exists and in the ESP - otherwise.</para></listitem> + <listitem><para>This option modifies the behaviour of <command>status</command>. Only prints the path + to the Extended Boot Loader partition if it exists, and the path to the ESP otherwise to standard + output and exit. This command is useful to determine where to place boot loader entries, as they are + preferably placed in the Extended Boot Loader partition if it exists and in the ESP otherwise.</para> + + <para>Boot Loader Specification Type #1 entries should generally be placed in the directory + <literal>$(bootctl -x)/loader/entries/</literal>. Existence of that directory may also be used as + indication that boot loader entry support is available on the system. Similarly, Boot Loader + Specification Type #2 entries should be placed in the directory <literal>$(bootctl + -x)/EFI/Linux/</literal>.</para> + + <para>Note that this option (similar to the <option>--print-booth-path</option> option mentioned + above), is available independently from the boot loader used, i.e. also without + <command>systemd-boot</command> being installed.</para></listitem> </varlistentry> <varlistentry> @@ -124,6 +134,31 @@ </varlistentry> <varlistentry> + <term><option>random-seed</option></term> + + <listitem><para>Generates a random seed and stores it in the EFI System Partition, for use by the + <command>systemd-boot</command> boot loader. Also, generates a random 'system token' and stores it + persistently as an EFI variable, if one has not been set before. If the boot loader finds the random + seed in the ESP and the system token in the EFI variable it will derive a random seed to pass to the + OS and a new seed to store in the ESP from the combination of both. The random seed passed to the OS + is credited to the kernel's entropy pool by the system manager during early boot, and permits + userspace to boot up with an entropy pool fully initialized very early on. Also see + <citerefentry><refentrytitle>systemd-boot-system-token.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para>See <ulink url="https://systemd.io/RANDOM_SEEDS">Random Seeds</ulink> for further + information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>is-installed</option></term> + + <listitem><para>Checks whether <command>systemd-boot</command> is installed in the ESP. Note that a + single ESP might host multiple boot loaders; this hence checks whether + <command>systemd-boot</command> is one (of possibly many) installed boot loaders — and neither + whether it is the default nor whether it is registered in any EFI variables.</para></listitem> + </varlistentry> + + <varlistentry> <term><option>list</option></term> <listitem><para>Shows all available boot loader entries implementing the <ulink @@ -164,7 +199,8 @@ <para> <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, - <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink> + <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>, + <citerefentry><refentrytitle>systemd-boot-system-token.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> </para> </refsect1> </refentry> diff --git a/man/bootup.xml b/man/bootup.xml index 9468a61319..d371523400 100644 --- a/man/bootup.xml +++ b/man/bootup.xml @@ -156,7 +156,9 @@ using systemd as well. In this case, boot up inside the initrd follows the following structure.</para> - <para>The default target in the initrd is + <para>systemd detects that it is run within an initrd by checking + for the file <filename>/etc/initrd-release</filename>. + The default target in the initrd is <filename>initrd.target</filename>. The bootup process begins identical to the system manager bootup (see above) until it reaches <filename>basic.target</filename>. From there, systemd diff --git a/man/busctl.xml b/man/busctl.xml index e4c7fcb283..328c101622 100644 --- a/man/busctl.xml +++ b/man/busctl.xml @@ -141,6 +141,16 @@ </varlistentry> <varlistentry> + <term><option>--xml-interface</option></term> + + <listitem> + <para>When used with the <command>introspect</command> call, dump the XML description received from + the D-Bus <constant>org.freedesktop.DBus.Introspectable.Introspect</constant> call instead of the + normal output.</para> + </listitem> + </varlistentry> + + <varlistentry> <term><option>--json=</option><replaceable>MODE</replaceable></term> <listitem> diff --git a/man/crypttab.xml b/man/crypttab.xml index 5eb1c12232..76eef06bed 100644 --- a/man/crypttab.xml +++ b/man/crypttab.xml @@ -152,6 +152,17 @@ </varlistentry> <varlistentry> + <term><option>keyfile-timeout=</option></term> + + <listitem><para> Specifies the timeout for the device on + which the key file resides and falls back to a password if + it could not be mounted. See + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for key files on external devices. + </para></listitem> + </varlistentry> + + <varlistentry> <term><option>luks</option></term> <listitem><para>Force LUKS mode. When this mode is used, the @@ -438,7 +449,8 @@ <programlisting>luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b swap /dev/sda7 /dev/urandom swap truecrypt /dev/sda2 /etc/container_password tcrypt -hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile</programlisting> +hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile +external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s</programlisting> </example> </refsect1> diff --git a/man/custom-entities.ent.in b/man/custom-entities.ent.in index e2bd44e5e7..85805777a0 100644 --- a/man/custom-entities.ent.in +++ b/man/custom-entities.ent.in @@ -8,3 +8,4 @@ <!ENTITY CERTIFICATE_ROOT @CERTIFICATE_ROOT@> <!ENTITY MEMORY_ACCOUNTING_DEFAULT @MEMORY_ACCOUNTING_DEFAULT_YES_NO@> <!ENTITY KILL_USER_PROCESSES @KILL_USER_PROCESSES_YES_NO@> +<!ENTITY DEBUGTTY @DEBUGTTY@> diff --git a/man/html.in b/man/html.in new file mode 100755 index 0000000000..bc9a668c23 --- /dev/null +++ b/man/html.in @@ -0,0 +1,12 @@ +#!/bin/sh +set -e + +if [ -z "$1" ]; then + echo "Use: $0 page-name (with no section suffix)" + exit 1 +fi + +target="man/$1.html" +ninja -C "@BUILD_ROOT@" "$target" +set -x +exec xdg-open "@BUILD_ROOT@/$target" diff --git a/man/journalctl.xml b/man/journalctl.xml index a3c67f5e82..f6703b06d6 100644 --- a/man/journalctl.xml +++ b/man/journalctl.xml @@ -544,7 +544,12 @@ the unit (<literal>_SYSTEMD_UNIT=<replaceable>UNIT</replaceable></literal>), along with additional matches for messages from systemd and - messages about coredumps for the specified unit.</para> + messages about coredumps for the specified unit. A match + is also added for <literal>_SYSTEMD_SLICE=<replaceable>UNIT</replaceable></literal>, + such that if the provided <replaceable>UNIT</replaceable> is a + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry> + unit, all logs of the children of the slice will be logged. + </para> <para>This parameter can be specified multiple times.</para> </listitem> @@ -558,7 +563,11 @@ (<literal>_SYSTEMD_USER_UNIT=</literal> and <literal>_UID=</literal>) and additional matches for messages from session systemd and messages about coredumps for the - specified unit.</para> + specified unit. A match + is also added for <literal>_SYSTEMD_USER_SLICE=<replaceable>UNIT</replaceable></literal>, + such that if the provided <replaceable>UNIT</replaceable> is a + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry> + unit, all logs of the children of the unit will be logged.</para> <para>This parameter can be specified multiple times.</para> </listitem> @@ -887,18 +896,34 @@ <varlistentry> <term><option>--flush</option></term> - <listitem><para>Asks the journal daemon to flush any log data - stored in <filename>/run/log/journal</filename> into - <filename>/var/log/journal</filename>, if persistent storage - is enabled. This call does not return until the operation is - complete. Note that this call is idempotent: the data is only - flushed from <filename>/run/log/journal</filename> into - <filename>/var/log/journal</filename> once during system - runtime, and this command exits cleanly without executing any - operation if this has already happened. This command - effectively guarantees that all data is flushed to - <filename>/var/log/journal</filename> at the time it - returns.</para></listitem> + <listitem><para>Asks the journal daemon to flush any log data stored in + <filename>/run/log/journal/</filename> into <filename>/var/log/journal/</filename>, if persistent + storage is enabled. This call does not return until the operation is complete. Note that this call is + idempotent: the data is only flushed from <filename>/run/log/journal/</filename> into + <filename>/var/log/journal</filename> once during system runtime (but see + <option>--relinquish-var</option> below), and this command exits cleanly without executing any + operation if this has already happened. This command effectively guarantees that all data is flushed + to <filename>/var/log/journal</filename> at the time it returns.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--relinquish-var</option></term> + + <listitem><para>Asks the journal daemon for the reverse operation to <option>--flush</option>: if + requested the daemon will write further log data to <filename>/run/log/journal/</filename> and stops + writing to <filename>/var/log/journal/</filename>. A subsequent call to <option>--flush</option> + causes the log output to switch back to <filename>/var/log/journal/</filename>, see + above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--smart-relinquish-var</option></term> + + <listitem><para>Similar to <option>--relinquish-var</option> but executes no operation if the root file + system and <filename>/var/lib/journal/</filename> reside on the same mount point. This operation is + used during system shutdown in order to make the journal daemon stop writing data to + <filename>/var/log/journal/</filename> in case that directory is located on a mount point that needs + to be unmounted.</para></listitem> </varlistentry> <varlistentry> diff --git a/man/journald.conf.xml b/man/journald.conf.xml index 57c2256567..44fd0d2f3d 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -288,21 +288,25 @@ <term><varname>ForwardToConsole=</varname></term> <term><varname>ForwardToWall=</varname></term> - <listitem><para>Control whether log messages received by the journal daemon shall - be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to - the system console, or sent as wall messages to all logged-in users. These - options take boolean arguments. If forwarding to syslog is enabled but nothing - reads messages from the socket, forwarding to syslog has no effect. By default, - only forwarding to wall is enabled. These settings may be overridden at boot time - with the kernel command line options - <literal>systemd.journald.forward_to_syslog</literal>, + <listitem><para>Control whether log messages received by the journal daemon shall be forwarded to a + traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall + messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is + enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default, + only forwarding to wall is enabled. These settings may be overridden at boot time with the kernel + command line options <literal>systemd.journald.forward_to_syslog</literal>, <literal>systemd.journald.forward_to_kmsg</literal>, <literal>systemd.journald.forward_to_console</literal>, and - <literal>systemd.journald.forward_to_wall</literal>. If the option name is - specified without <literal>=</literal> and the following argument, true is - assumed. Otherwise, the argument is parsed as a boolean. When forwarding to the - console, the TTY to log to can be changed with <varname>TTYPath=</varname>, - described below.</para></listitem> + <literal>systemd.journald.forward_to_wall</literal>. If the option name is specified without + <literal>=</literal> and the following argument, true is assumed. Otherwise, the argument is parsed + as a boolean.</para> + + <para>When forwarding to the console, the TTY to log to can be changed with + <varname>TTYPath=</varname>, described below.</para> + + <para>When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for + the log buffer, and ensure the kernel's rate-limiting applied to userspace processes is turned + off. Specifically, add <literal>log_buf_len=8M</literal> and <literal>printk.devkmsg=on</literal> (or + similar) to the kernel command line.</para></listitem> </varlistentry> <varlistentry> diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml index 40b7766214..f9408a028d 100644 --- a/man/kernel-command-line.xml +++ b/man/kernel-command-line.xml @@ -59,6 +59,7 @@ <term><varname>systemd.confirm_spawn</varname></term> <term><varname>systemd.service_watchdogs</varname></term> <term><varname>systemd.show_status</varname></term> + <term><varname>systemd.status_unit_format=</varname></term> <term><varname>systemd.log_target=</varname></term> <term><varname>systemd.log_level=</varname></term> <term><varname>systemd.log_location=</varname></term> @@ -402,10 +403,11 @@ <varlistentry> <term><varname>resume=</varname></term> + <term><varname>resumeflags=</varname></term> <listitem> <para>Enables resume from hibernation using the specified - device. All + device and mount options. All <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-like paths are supported. For details, see <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> diff --git a/man/less-variables.xml b/man/less-variables.xml index c80534b960..38cb18be2e 100644 --- a/man/less-variables.xml +++ b/man/less-variables.xml @@ -25,11 +25,36 @@ <listitem><para>Override the options passed to <command>less</command> (by default <literal>FRSXMK</literal>).</para> - <para>If the value of <varname>$SYSTEMD_LESS</varname> does not include <literal>K</literal>, - and the pager that is invoked is <command>less</command>, - <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> will be ignored by the - executable. This allows <command>less</command> to handle - <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> itself.</para></listitem> + <para>Users might want to change two options in particular:</para> + + <variablelist class='environment-variables'> + <varlistentry> + <term><option>K</option></term> + + <para>This option instructs the pager to exit immediately when + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> is pressed. To allow + <command>less</command> to handle <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> + itself to switch back to the pager command prompt, unset this option.</para> + + <para>If the value of <varname>$SYSTEMD_LESS</varname> does not include <literal>K</literal>, + and the pager that is invoked is <command>less</command>, + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> will be ignored by the + executable, and needs to be handled by the pager.</para> + </varlistentry> + + <varlistentry> + <term><option>X</option></term> + + <para>This option instructs the pager to not send termcap initialization and deinitialization + strings to the terminal. It is set by default to allow command output to remain visible in the + terminal even after the pager exits. Nevertheless, this prevents some pager functionality from + working, in particular paged output cannot be scrolled with the mouse.</para> + </varlistentry> + </variablelist> + + <para>See + <citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for more discussion.</para></listitem> </varlistentry> <varlistentry id='lesscharset'> diff --git a/man/loader.conf.xml b/man/loader.conf.xml index 38a80861b8..14f84c13ee 100644 --- a/man/loader.conf.xml +++ b/man/loader.conf.xml @@ -153,6 +153,25 @@ <listitem><para>Takes a boolean argument. Enable (the default) or disable the "Reboot into firmware" entry.</para></listitem> </varlistentry> + + <varlistentry> + <term>random-seed-mode</term> + + <listitem><para>Takes one of <literal>off</literal>, <literal>with-system-token</literal> and + <literal>always</literal>. If <literal>off</literal> no random seed data is read off the ESP, nor + passed to the OS. If <literal>with-system-token</literal> (the default) + <command>systemd-boot</command> will read a random seed from the ESP (from the file + <filename>/loader/random-seed</filename>) only if the <varname>LoaderSystemToken</varname> EFI + variable is set, and then derive the random seed to pass to the OS from the combination. If + <literal>always</literal> the boot loader will do so even if <varname>LoaderSystemToken</varname> is + not set. This mode is useful in environments where protection against OS image reuse is not a + concern, and the random seed shall be used even with no further setup in place. User <command>bootctl + random-seed</command> to initialize both the random seed file in the ESP and the system token EFI + variable.</para> + + <para>See <ulink url="https://systemd.io/RANDOM_SEEDS">Random Seeds</ulink> for further + information.</para></listitem> + </varlistentry> </variablelist> </refsect1> diff --git a/man/machine-id.xml b/man/machine-id.xml index f4d94e8800..ebee065a61 100644 --- a/man/machine-id.xml +++ b/man/machine-id.xml @@ -99,8 +99,8 @@ be used. If this file is empty or missing, <filename>systemd</filename> will attempt to use the D-Bus machine ID from <filename>/var/lib/dbus/machine-id</filename>, the value of the kernel command line option <varname>container_uuid</varname>, the KVM DMI - <filename>product_uuid</filename> (on KVM systems), and finally a randomly generated - UUID.</para> + <filename>product_uuid</filename> or the devicetree <filename>vm,uuid</filename> + (on KVM systems), and finally a randomly generated UUID.</para> <para>After the machine ID is established, <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> diff --git a/man/man.in b/man/man.in new file mode 100755 index 0000000000..75680b860c --- /dev/null +++ b/man/man.in @@ -0,0 +1,16 @@ +#!/bin/sh +set -e + +if [ -z "$1" ]; then + echo "Use: $0 page-name (with no section suffix)" + exit 1 +fi + +page="$(echo "$1" | sed 's/\./\\./')" +target=$(ninja -C "@BUILD_ROOT@" -t query man/man | grep -E -m1 "man/$page\.[0-9]$" | awk '{print $2}') +if [ -z "$target" ]; then + echo "Cannot find page $1" + exit 1 +fi +ninja -C "@BUILD_ROOT@" "$target" +exec man "@BUILD_ROOT@/$target" diff --git a/man/meson.build b/man/meson.build index ae9c941fcd..f3992b2834 100644 --- a/man/meson.build +++ b/man/meson.build @@ -204,3 +204,15 @@ if git.found() 'mv t @0@/rules/meson.build'.format(meson.current_source_dir())], depend_files : custom_entities_ent) endif + +############################################################ + +configure_file( + input : 'man.in', + output : 'man', + configuration : substs) + +configure_file( + input : 'html.in', + output : 'html', + configuration : substs) diff --git a/man/networkctl.xml b/man/networkctl.xml index 6c28c4bb2d..7f68f249e4 100644 --- a/man/networkctl.xml +++ b/man/networkctl.xml @@ -58,6 +58,17 @@ </listitem> </varlistentry> + <varlistentry> + <term> + <option>-s</option> + <option>--stats</option> + </term> + + <listitem> + <para>Show link statistics with <command>status</command>.</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-legend" /> @@ -271,6 +282,13 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR) </listitem> </varlistentry> + <varlistentry> + <term> + <command>delete</command> + </term> + <listitem><para>Deletes virtual netdevs. Takes interface name or index number.</para></listitem> + </varlistentry> + </variablelist> </refsect1> diff --git a/man/nss-mymachines.xml b/man/nss-mymachines.xml index ed03035e57..40b0abee34 100644 --- a/man/nss-mymachines.xml +++ b/man/nss-mymachines.xml @@ -98,8 +98,8 @@ MACHINE CLASS SERVICE OS VERSION ADDRESSES rawhide container systemd-nspawn fedora 30 169.254.40.164 fe80::94aa:3aff:fe7b:d4b9 $ getent passwd vu-rawhide-0 vu-rawhide-81 -vu-rawhide-0:*:20119552:65534:vu-rawhide-0:/:/sbin/nologin -vu-rawhide-81:*:20119633:65534:vu-rawhide-81:/:/sbin/nologin +vu-rawhide-0:*:20119552:65534:vu-rawhide-0:/:/usr/sbin/nologin +vu-rawhide-81:*:20119633:65534:vu-rawhide-81:/:/usr/sbin/nologin $ getent group vg-rawhide-0 vg-rawhide-81 vg-rawhide-0:*:20119552: diff --git a/man/pstore.conf.xml b/man/pstore.conf.xml new file mode 100644 index 0000000000..2b9c8b1a71 --- /dev/null +++ b/man/pstore.conf.xml @@ -0,0 +1,89 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<refentry id="pstore.conf" conditional="ENABLE_PSTORE" + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>pstore.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>pstore.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>pstore.conf</refname> + <refname>pstore.conf.d</refname> + <refpurpose>PStore configuration file</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para> + <filename>/etc/systemd/pstore.conf</filename> + <filename>/etc/systemd/pstore.conf.d/*</filename> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>This file configures the behavior of + <citerefentry><refentrytitle>systemd-pstore</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + a tool for archiving the contents of the persistent storage filesystem, + <ulink url="https://www.kernel.org/doc/Documentation/ABI/testing/pstore">pstore</ulink>. + </para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the + <literal>[PStore]</literal> section:</para> + + <variablelist class='config-directives'> + + <varlistentry> + <term><varname>Storage=</varname></term> + + <listitem><para>Controls where to archive (i.e. copy) files from the pstore filesystem. One of <literal>none</literal>, + <literal>external</literal>, and <literal>journal</literal>. When + <literal>none</literal>, the tool exits without processing files in the pstore filesystem. + When <literal>external</literal> (the default), files are archived into <filename>/var/lib/systemd/pstore/</filename>, + and logged into the journal. + When <literal>journal</literal>, pstore file contents are logged only in the journal.</para> + </listitem> + + </varlistentry> + + <varlistentry> + <term><varname>Unlink=</varname></term> + + <listitem><para>Controls whether or not files are removed from pstore after processing. + Takes a boolean value. When true, a pstore file is removed from the pstore once it has been + archived (either to disk or into the journal). When false, processing of pstore files occurs + normally, but the files remain in the pstore. + The default is true in order to maintain the pstore in a nearly empty state, so that the pstore + has storage available for the next kernel error event. + </para></listitem> + </varlistentry> + </variablelist> + + <para>The defaults for all values are listed as comments in the + template <filename>/etc/systemd/pstore.conf</filename> file that + is installed by default.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/resolvectl.xml b/man/resolvectl.xml index f986e98ba3..ccc1b378f8 100644 --- a/man/resolvectl.xml +++ b/man/resolvectl.xml @@ -200,7 +200,7 @@ <varlistentry> <term><option>status [<replaceable>LINK</replaceable>…]</option></term> - <listitem><para>Shows the global and per-link DNS settings in currently in effect. If no command is specified, + <listitem><para>Shows the global and per-link DNS settings currently in effect. If no command is specified, this is the implied default.</para></listitem> </varlistentry> @@ -247,15 +247,12 @@ <listitem> <para>Get/set per-interface DNS configuration. These commands may be used to configure various DNS settings - for network interfaces that aren't managed by - <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. (These - commands will fail when used on interfaces that are managed by <command>systemd-networkd</command>, please - configure their DNS settings directly inside the <filename>.network</filename> files instead.) These commands - may be used to inform <command>systemd-resolved</command> about per-interface DNS configuration determined + for network interfaces. These commands may be used to inform <command>systemd-resolved</command> or + <command>systemd-networkd</command> about per-interface DNS configuration determined through external means. The <option>dns</option> command expects IPv4 or IPv6 address specifications of DNS servers to use. The <option>domain</option> command expects valid DNS domains, possibly prefixed with <literal>~</literal>, and configures a per-interface search or route-only domain. The - <option>default-route</option> command expects a boolean paremeter, and configures whether the link may be + <option>default-route</option> command expects a boolean parameter, and configures whether the link may be used as default route for DNS lookups, i.e. if it is suitable for lookups on domains no other link explicitly is configured for. The <option>llmnr</option>, <option>mdns</option>, <option>dnssec</option> and <option>dnsovertls</option> commands may be used to configure the per-interface LLMNR, MulticastDNS, DNSSEC diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml index c8ab6942c1..213be1d7b2 100644 --- a/man/resolved.conf.xml +++ b/man/resolved.conf.xml @@ -193,8 +193,11 @@ <varlistentry> <term><varname>DNSOverTLS=</varname></term> <listitem> - <para>Takes false or - <literal>opportunistic</literal>. When set to <literal>opportunistic</literal> + <para>Takes a boolean argument or <literal>opportunistic</literal>. + If true all connections to the server will be encrypted. Note that + this mode requires a DNS server that supports DNS-over-TLS and has + a valid certificate for it's IP. If the DNS server does not support + DNS-over-TLS all DNS requests will fail. When set to <literal>opportunistic</literal> DNS request are attempted to send encrypted with DNS-over-TLS. If the DNS server does not support TLS, DNS-over-TLS is disabled. Note that this mode makes DNS-over-TLS vulnerable to "downgrade" @@ -224,10 +227,11 @@ <varlistentry> <term><varname>Cache=</varname></term> - <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default), resolving a domain name + <listitem><para>Takes a boolean or <literal>no-negative</literal> as argument. If <literal>yes</literal> (the default), resolving a domain name which already got queried earlier will return the previous result as long as it is still valid, and thus does not result in a new network request. Be aware that turning off caching comes at a performance penalty, which is particularly high when DNSSEC is used.</para> + If <literal>no-negative</literal>, only positive answers are cached. <para>Note that caching is turned off implicitly if the configured DNS server is on a host-local IP address (such as 127.0.0.1 or ::1), in order to avoid duplicate local caching.</para></listitem> diff --git a/man/rules/meson.build b/man/rules/meson.build index d949900ddc..3b63311d7b 100644 --- a/man/rules/meson.build +++ b/man/rules/meson.build @@ -1,4 +1,6 @@ # Do not edit. Generated by make-man-rules.py. +# Update with: +# ninja -C build man/update-man-rules manpages = [ ['binfmt.d', '5', [], 'ENABLE_BINFMT'], ['bootctl', '1', [], 'ENABLE_EFI'], @@ -44,6 +46,7 @@ manpages = [ ['os-release', '5', [], ''], ['pam_systemd', '8', [], 'HAVE_PAM'], ['portablectl', '1', [], 'ENABLE_PORTABLED'], + ['pstore.conf', '5', ['pstore.conf.d'], 'ENABLE_PSTORE'], ['resolvectl', '1', ['resolvconf'], 'ENABLE_RESOLVE'], ['resolved.conf', '5', ['resolved.conf.d'], 'ENABLE_RESOLVE'], ['runlevel', '8', [], 'ENABLE_UTMP'], @@ -101,6 +104,7 @@ manpages = [ 'SD_ID128_MAKE', 'SD_ID128_MAKE_STR', 'SD_ID128_NULL', + 'SD_ID128_UUID_FORMAT_STR', 'sd_id128_equal', 'sd_id128_is_null', 'sd_id128_t'], @@ -114,6 +118,21 @@ manpages = [ 'sd_bus_match_signal', 'sd_bus_match_signal_async'], ''], + ['sd_bus_add_object_vtable', + '3', + ['SD_BUS_METHOD', + 'SD_BUS_METHOD_WITH_NAMES', + 'SD_BUS_METHOD_WITH_NAMES_OFFSET', + 'SD_BUS_METHOD_WITH_OFFSET', + 'SD_BUS_PARAM', + 'SD_BUS_PROPERTY', + 'SD_BUS_SIGNAL', + 'SD_BUS_SIGNAL_WITH_NAMES', + 'SD_BUS_VTABLE_END', + 'SD_BUS_VTABLE_START', + 'SD_BUS_WRITABLE_PROPERTY', + 'sd_bus_add_fallback_vtable'], + ''], ['sd_bus_attach_event', '3', ['sd_bus_detach_event', 'sd_bus_get_event'], ''], ['sd_bus_close', '3', ['sd_bus_flush'], ''], ['sd_bus_creds_get_pid', @@ -429,7 +448,10 @@ manpages = [ ['sd_event_source_set_userdata', '3', ['sd_event_source_get_userdata'], ''], ['sd_event_source_unref', '3', - ['sd_event_source_ref', 'sd_event_source_unrefp'], + ['sd_event_source_disable_unref', + 'sd_event_source_disable_unrefp', + 'sd_event_source_ref', + 'sd_event_source_unrefp'], ''], ['sd_event_wait', '3', @@ -633,6 +655,7 @@ manpages = [ ['systemd-bless-boot-generator', '8', [], 'ENABLE_EFI'], ['systemd-bless-boot.service', '8', [], 'ENABLE_EFI'], ['systemd-boot-check-no-failures.service', '8', [], ''], + ['systemd-boot-system-token.service', '8', [], 'ENABLE_EFI'], ['systemd-boot', '7', ['sd-boot'], 'ENABLE_EFI'], ['systemd-cat', '1', [], ''], ['systemd-cgls', '1', [], ''], @@ -725,6 +748,7 @@ manpages = [ ['systemd-nspawn', '1', [], ''], ['systemd-path', '1', [], ''], ['systemd-portabled.service', '8', ['systemd-portabled'], 'ENABLE_PORTABLED'], + ['systemd-pstore', '8', ['systemd-pstore.service'], 'ENABLE_PSTORE'], ['systemd-quotacheck.service', '8', ['systemd-quotacheck'], @@ -774,6 +798,7 @@ manpages = [ 'systemd-tmpfiles-setup.service'], ''], ['systemd-tty-ask-password-agent', '1', [], ''], + ['systemd-udev-settle.service', '8', [], ''], ['systemd-udevd.service', '8', ['systemd-udevd', @@ -807,6 +832,7 @@ manpages = [ ['systemd.kill', '5', [], ''], ['systemd.link', '5', [], ''], ['systemd.mount', '5', [], ''], + ['systemd.net-naming-scheme', '7', [], ''], ['systemd.netdev', '5', [], 'ENABLE_NETWORKD'], ['systemd.network', '5', [], 'ENABLE_NETWORKD'], ['systemd.nspawn', '5', [], ''], diff --git a/man/runlevel.xml b/man/runlevel.xml index d8bfcd73fc..87e2ed234a 100644 --- a/man/runlevel.xml +++ b/man/runlevel.xml @@ -4,8 +4,7 @@ <!-- SPDX-License-Identifier: LGPL-2.1+ --> <refentry id="runlevel" - xmlns:xi="http://www.w3.org/2001/XInclude" - conditional="ENABLE_UTMP"> + xmlns:xi="http://www.w3.org/2001/XInclude"> <refentryinfo> <title>runlevel</title> diff --git a/man/sd-bus.xml b/man/sd-bus.xml index 6c925e3161..e9a66d87dd 100644 --- a/man/sd-bus.xml +++ b/man/sd-bus.xml @@ -41,6 +41,7 @@ <para>See <literallayout><citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_object_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, diff --git a/man/sd-id128.xml b/man/sd-id128.xml index 74d838df2e..22d5e0e3ed 100644 --- a/man/sd-id128.xml +++ b/man/sd-id128.xml @@ -24,6 +24,7 @@ <refname>SD_ID128_NULL</refname> <refname>SD_ID128_CONST_STR</refname> <refname>SD_ID128_FORMAT_STR</refname> + <refname>SD_ID128_UUID_FORMAT_STR</refname> <refname>SD_ID128_FORMAT_VAL</refname> <refname>sd_id128_equal</refname> <refname>sd_id128_is_null</refname> @@ -119,6 +120,11 @@ int main(int argc, char **argv) { return 0; }</programlisting> + <para><function>SD_ID128_UUID_FORMAT_STR()</function> is similar to + <function>SD_ID128_FORMAT_STR()</function> but includes separating hyphens to conform to the + "<ulink url="https://en.wikipedia.org/wiki/Universally_unique_identifier#Format">canonical representation</ulink>". + </para> + <para>Use <function>sd_id128_equal()</function> to compare two 128-bit IDs:</para> <programlisting>int main(int argc, char *argv[]) { diff --git a/man/sd_bus_add_object_vtable.xml b/man/sd_bus_add_object_vtable.xml new file mode 100644 index 0000000000..9d7e30a504 --- /dev/null +++ b/man/sd_bus_add_object_vtable.xml @@ -0,0 +1,473 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<refentry id="sd_bus_add_object_vtable" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_add_object_vtable</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_add_object_vtable</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_add_object_vtable</refname> + <refname>sd_bus_add_fallback_vtable</refname> + <refname>SD_BUS_VTABLE_START</refname> + <refname>SD_BUS_VTABLE_END</refname> + <refname>SD_BUS_METHOD_WITH_NAMES_OFFSET</refname> + <refname>SD_BUS_METHOD_WITH_NAMES</refname> + <refname>SD_BUS_METHOD_WITH_OFFSET</refname> + <refname>SD_BUS_METHOD</refname> + <refname>SD_BUS_SIGNAL_WITH_NAMES</refname> + <refname>SD_BUS_SIGNAL</refname> + <refname>SD_BUS_WRITABLE_PROPERTY</refname> + <refname>SD_BUS_PROPERTY</refname> + <refname>SD_BUS_PARAM</refname> + + <refpurpose>Declare properties and methods for a D-Bus path</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus-vtable.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_bus_message_handler_t</function>)</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>typedef int (*<function>sd_bus_property_get_t</function>)</funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>property</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>reply</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>typedef int (*<function>sd_bus_property_set_t</function>)</funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>property</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>value</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>typedef int (*<function>sd_bus_object_find_t</function>)</funcdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>void **<parameter>ret_found</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_add_object_vtable</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const sd_bus_vtable *<parameter>vtable</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_add_fallback_vtable</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>prefix</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const sd_bus_vtable *<parameter>vtable</parameter></paramdef> + <paramdef>sd_bus_object_find_t <parameter>find</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <para> + <constant>SD_BUS_VTABLE_START(<replaceable>flags</replaceable>)</constant> + </para> + <para> + <constant>SD_BUS_VTABLE_END</constant> + </para> + <para> + <constant>SD_BUS_METHOD_WITH_NAMES_OFFSET( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>in_names</replaceable>, + <replaceable>result</replaceable>, + <replaceable>out_names</replaceable>, + <replaceable>handler</replaceable>, + <replaceable>offset</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_METHOD_WITH_NAMES( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>in_names</replaceable>, + <replaceable>result</replaceable>, + <replaceable>out_names</replaceable>, + <replaceable>handler</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_METHOD_WITH_OFFSET( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>result</replaceable>, + <replaceable>handler</replaceable>, + <replaceable>offset</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_METHOD( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>result</replaceable>, + <replaceable>handler</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_SIGNAL_WITH_NAMES( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>names</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_SIGNAL( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_WRITABLE_PROPERTY( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>get</replaceable>, + <replaceable>set</replaceable>, + <replaceable>offset</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_PROPERTY( + <replaceable>member</replaceable>, + <replaceable>signature</replaceable>, + <replaceable>get</replaceable>, + <replaceable>offset</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_PARAM(<replaceable>name</replaceable>)</constant> + </para> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_add_object_vtable()</function> is used to declare attributes for the path object + path <parameter>path</parameter> connected to the bus connection <parameter>bus</parameter> under the + interface <parameter>interface</parameter>. The table <parameter>vtable</parameter> may contain property + declarations using <constant>SD_BUS_PROPERTY()</constant> or + <constant>SD_BUS_WRITABLE_PROPERTY()</constant>, method declarations using + <constant>SD_BUS_METHOD()</constant>, <constant>SD_BUS_METHOD_WITH_NAMES()</constant>, + <constant>SD_BUS_METHOD_WITH_OFFSET()</constant>, or + <constant>SD_BUS_METHOD_WITH_NAMES_OFFSET()</constant>, and signal declarations using + <constant>SD_BUS_SIGNAL_WITH_NAMES()</constant> or <constant>SD_BUS_SIGNAL()</constant>, see below. The + <replaceable>userdata</replaceable> parameter contains a pointer that will be passed to various callback + functions. It may be specified as <constant>NULL</constant> if no value is necessary.</para> + + <para><function>sd_bus_add_fallback_vtable()</function> is similar to + <function>sd_bus_add_object_vtable()</function>, but is used to register "fallback" attributes. When + looking for an attribute declaration, bus object paths registered with + <function>sd_bus_add_object_vtable()</function> are checked first. If no match is found, the fallback + vtables are checked for each prefix of the bus object path, i.e. with the last slash-separated components + successively removed. This allows the vtable to be used for an arbitrary number of dynamically created + objects.</para> + + <para>Parameter <replaceable>find</replaceable> is a function which is used to locate the target object + based on the bus object path <replaceable>path</replaceable>. It must return <constant>1</constant> and + set the <parameter>ret_found</parameter> output parameter if the object is found, return + <constant>0</constant> if the object was not found, and return a negative errno-style error code or + initialize the error structure <replaceable>ret_error</replaceable> on error. The pointer passed in + <parameter>ret_found</parameter> will be used as the <parameter>userdata</parameter> parameter for the + callback functions (offset by the <parameter>offset</parameter> offsets as specified in the vtable + entries).</para> + + <para>For both functions, a match slot is created internally. If the output parameter + <replaceable>slot</replaceable> is <constant>NULL</constant>, a "floating" slot object is created, see + <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot object + should be dropped when the vtable is not needed anymore, see + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <refsect2> + <title>The <structname>sd_bus_vtable</structname> array</title> + + <para>The array consists of the structures of type <structname>sd_bus_vtable</structname>, but it + should never be filled in manually, but through one of the following macros:</para> + + <variablelist> + <varlistentry> + <term><constant>SD_BUS_VTABLE_START()</constant></term> + <term><constant>SD_BUS_VTABLE_END</constant></term> + + <listitem><para>Those must always be the first and last element.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_METHOD_WITH_NAMES_OFFSET()</constant></term> + <term><constant>SD_BUS_METHOD_WITH_NAMES()</constant></term> + <term><constant>SD_BUS_METHOD_WITH_OFFSET()</constant></term> + <term><constant>SD_BUS_METHOD()</constant></term> + + <listitem><para>Declare a D-Bus method with the name <replaceable>member</replaceable>, parameter + signature <replaceable>signature</replaceable>, result signature <replaceable>result</replaceable>. + Parameters <replaceable>in_names</replaceable> and <replaceable>out_names</replaceable> specify the + argument names of the input and output arguments in the function signature. The handler function + <replaceable>handler</replaceable> must be of type <function>sd_bus_message_handler_t</function>. + It will be called to handle the incoming messages that call this method. It receives a pointer that + is the <replaceable>userdata</replaceable> parameter passed to the registration function offset by + <replaceable>offset</replaceable> bytes. This may be used to pass pointers to different fields in + the same data structure to different methods in the same + vtable. <replaceable>in_names</replaceable> and <replaceable>out_names</replaceable> should be + created using the <constant>SD_BUS_PARAM()</constant> macro, see below. Parameter + <replaceable>flags</replaceable> is a combination of flags, see below.</para> + + <para><constant>SD_BUS_METHOD_WITH_NAMES()</constant>, + <constant>SD_BUS_METHOD_WITH_OFFSET()</constant>, and <constant>SD_BUS_METHOD()</constant> are + variants which specify zero offset (<replaceable>userdata</replaceable> parameter is passed with + no change), leave the names unset (i.e. no parameter names), or both.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_SIGNAL_WITH_NAMES()</constant></term> + <term><constant>SD_BUS_SIGNAL()</constant></term> + + <listitem><para>Declare a D-Bus signal with the name <replaceable>member</replaceable>, + parameter signature <replaceable>signature</replaceable>, and argument names + <replaceable>names</replaceable>. <replaceable>names</replaceable> should be + created using the <constant>SD_BUS_PARAM()</constant> macro, see below. + Parameter <replaceable>flags</replaceable> is a combination of flags, see below. + </para> + + <para>Equivalent to <constant>SD_BUS_SIGNAL_WITH_NAMES()</constant> with the + <replaceable>names</replaceable> parameter unset (i.e. no parameter names).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_WRITABLE_PROPERTY()</constant></term> + <term><constant>SD_BUS_PROPERTY()</constant></term> + + <listitem><para>Declare a D-Bus property with the name <replaceable>member</replaceable> and value + signature <replaceable>signature</replaceable>. Parameters <replaceable>get</replaceable> and + <replaceable>set</replaceable> are the getter and setter methods. They are called with a pointer + that is the <replaceable>userdata</replaceable> parameter passed to the registration function + offset by <replaceable>offset</replaceable> bytes. This may be used pass pointers to different + fields in the same data structure to different setters and getters in the same vtable. Parameter + <replaceable>flags</replaceable> is a combination of flags, see below.</para> + + <para>The setter and getter methods may be omitted (specified as <constant>NULL</constant>), if the + property has one of the basic types or <literal>as</literal> in case of read-only properties. In + those cases, the <replaceable>userdata</replaceable> and <replaceable>offset</replaceable> + parameters must together point to valid variable of the corresponding type. A default setter and + getters will be provided, which simply copy the argument between this variable and the message. + </para> + + <para><constant>SD_BUS_PROPERTY()</constant> is used to define a read-only property.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_PARAM()</constant></term> + <listitem><para>Parameter names should be wrapped in this macro, see the example below.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Flags</title> + + <para>The <replaceable>flags</replaceable> parameter is used to specify a combination of + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format">D-Bus annotations</ulink>. + </para> + + <variablelist> + <varlistentry> + <term><constant>SD_BUS_VTABLE_DEPRECATED</constant></term> + + <listitem><para>Mark this vtable entry as deprecated using the + <constant>org.freedesktop.DBus.Deprecated</constant> annotation in introspection data. If + specified for <constant>SD_BUS_VTABLE_START()</constant>, the annotation is applied to the + enclosing interface.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_HIDDEN</constant></term> + + <listitem><para>Make this vtable entry hidden. It will not be shown in introspection data. If + specified for <constant>SD_BUS_VTABLE_START()</constant>, all entries in the array are hidden. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_UNPRIVILEGED</constant></term> + + <listitem><para>Mark this vtable entry as unprivileged. If not specified, the + <constant>org.freedesktop.systemd1.Privileged</constant> annotation with value + <literal>true</literal> will be shown in introspection data.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_METHOD_NO_REPLY</constant></term> + + <listitem><para>Mark his vtable entry as a method that will not return a reply using the + <constant>org.freedesktop.DBus.Method.NoReply</constant> annotation in introspection data. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_PROPERTY_CONST</constant></term> + <term><constant>SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE</constant></term> + <term><constant>SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION</constant></term> + + <listitem><para>Those three flags correspond to different values of the + <constant>org.freedesktop.DBus.Property.EmitsChangedSignal</constant> annotation, which specifies + whether the <constant>org.freedesktop.DBus.Properties.PropertiesChanged</constant> signal is + emitted whenever the property changes. <constant>SD_BUS_VTABLE_PROPERTY_CONST</constant> corresponds to + <constant>const</constant> and means that the property never changes during the lifetime of the + object it belongs to, so no signal needs to be emitted. + <constant>SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE</constant> corresponds to <constant>true</constant> and means + that the signal is emitted. <constant>SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION</constant> corresponds to + <constant>invalidates</constant> and means that the signal is emitted, but the value is not included + in the signal.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_PROPERTY_EXPLICIT</constant></term> + + <listitem><para>Mark this vtable property entry as requiring explicit request to for the value to + be shown (generally because the value is large or slow to calculate). This entry cannot be combined + with <constant>SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE</constant>, and will not be shown in property listings by + default (e.g. <command>busctl introspect</command>). This corresponds to the + <constant>org.freedesktop.systemd1.Explicit</constant> annotation in introspection data.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Create a simple listener on the bus</title> + + <programlisting><xi:include href="vtable-example.c" parse="text" /></programlisting> + + <para>This creates a simple client on the bus (the user bus, when run as normal user). + We may use the D-Bus <constant>org.freedesktop.DBus.Introspectable.Introspect</constant> + call to acquire the XML description of the interface:</para> + + <programlisting><xi:include href="vtable-example.xml" parse="text" /></programlisting> + </example> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_add_object_vtable</function> and + <function>sd_bus_add_fallback_vtable</function> calls return 0 or a positive integer. On failure, they + return a negative errno-style error code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>One of the required parameters is <constant>NULL</constant> or invalid. A reserved + D-Bus interface was passed as the <replaceable>interface</replaceable> parameter.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus cannot be resolved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus was created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPROTOTYPE</constant></term> + + <listitem><para><function>sd_bus_add_object_vtable</function> and + <function>sd_bus_add_fallback_vtable</function> have been both called + for the same bus object path, which is not allowed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EEXIST</constant></term> + + <listitem><para>This vtable has already been registered for this + <replaceable>interface</replaceable> and <replaceable>path</replaceable>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_close.xml b/man/sd_bus_close.xml index b09f488874..d81c593878 100644 --- a/man/sd_bus_close.xml +++ b/man/sd_bus_close.xml @@ -44,7 +44,7 @@ <para><function>sd_bus_close()</function> disconnects the specified bus connection. When this call is invoked and the specified bus object refers to an active connection it is immediately terminated. No further messages may be - sent or receieved on it. Any messages queued in the bus object (both incoming and outgoing) are released. If + sent or received on it. Any messages queued in the bus object (both incoming and outgoing) are released. If invoked on <constant>NULL</constant> bus object or when the bus connection is already closed this function executes no operation. This call does not free or unreference the bus object itself. Use <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> for that.</para> diff --git a/man/sd_bus_creds_get_pid.xml b/man/sd_bus_creds_get_pid.xml index 8b759f4a62..8440e66b2d 100644 --- a/man/sd_bus_creds_get_pid.xml +++ b/man/sd_bus_creds_get_pid.xml @@ -325,12 +325,14 @@ <filename>/proc/<replaceable>pid</replaceable>/task/<replaceable>tid</replaceable>/comm</filename>). </para> - <para><function>sd_bus_creds_get_exe()</function> will retrieve - the path to the program executable (as stored in the - <filename>/proc/<replaceable>pid</replaceable>/exe</filename> - link, but with the <literal> (deleted)</literal> suffix removed). Note - that kernel threads do not have an executable path, in which case - -ENXIO is returned.</para> + <para><function>sd_bus_creds_get_exe()</function> will retrieve the path to the program executable (as + stored in the <filename>/proc/<replaceable>pid</replaceable>/exe</filename> link, but with the <literal> + (deleted)</literal> suffix removed). Note that kernel threads do not have an executable path, in which + case -ENXIO is returned. Note that this property should not be used for more than explanatory + information, in particular it should not be used for security-relevant decisions. That's because the + executable might have been replaced or removed by the time the value can be processed. Moreover, the + kernel exports this information in an ambiguous way (i.e. a deleted executable cannot be safely + distinguished from one whose name suffix is <literal> (deleted)</literal>.</para> <para><function>sd_bus_creds_get_cmdline()</function> will retrieve an array of command line arguments (as stored in diff --git a/man/sd_bus_message_new_method_error.xml b/man/sd_bus_message_new_method_error.xml index 27cec8ed01..0c471c534f 100644 --- a/man/sd_bus_message_new_method_error.xml +++ b/man/sd_bus_message_new_method_error.xml @@ -116,7 +116,7 @@ project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> format string <parameter>format</parameter> and corresponding arguments. <literal>%m</literal> may be used in the format string to refer to the error - string corresponding to the specified errno code. The error message is initalized + string corresponding to the specified errno code. The error message is initialized using the error identifier generated from <constant>error</constant> and the formatted string. (If <parameter>error</parameter> is zero, no error is actually set, and an error reply with no information is created.)</para> diff --git a/man/sd_bus_message_rewind.xml b/man/sd_bus_message_rewind.xml index aa8aea987b..cbfa2511d2 100644 --- a/man/sd_bus_message_rewind.xml +++ b/man/sd_bus_message_rewind.xml @@ -19,7 +19,7 @@ <refnamediv> <refname>sd_bus_message_rewind</refname> - <refpurpose>Return to begining of message or current container</refpurpose> + <refpurpose>Return to beginning of message or current container</refpurpose> </refnamediv> <refsynopsisdiv> @@ -38,7 +38,7 @@ <title>Description</title> <para><function>sd_bus_message_rewind()</function> moves the "read pointer" in the message - <parameter>m</parameter> to either the begining of the message (if + <parameter>m</parameter> to either the beginning of the message (if <parameter>complete</parameter> is true) or to the beginning of the currently open container. If no container is open, <parameter>complete</parameter> has no effect.</para> </refsect1> diff --git a/man/sd_bus_message_verify_type.xml b/man/sd_bus_message_verify_type.xml index c3230e5833..e03a253885 100644 --- a/man/sd_bus_message_verify_type.xml +++ b/man/sd_bus_message_verify_type.xml @@ -70,7 +70,7 @@ <listitem><para><parameter>m</parameter> or both <parameter>type</parameter> and <parameter>contents</parameter> are <constant>NULL</constant>.</para> - <para>Arguments do not satisfy other contraints listed above.</para> + <para>Arguments do not satisfy other constraints listed above.</para> </listitem> </varlistentry> diff --git a/man/sd_bus_request_name.xml b/man/sd_bus_request_name.xml index 0f6a4ec313..7229ef517a 100644 --- a/man/sd_bus_request_name.xml +++ b/man/sd_bus_request_name.xml @@ -65,9 +65,9 @@ <refsect1> <title>Description</title> - <para><function>sd_bus_request_name()</function> requests a well-known service name on a bus. It takes a bus - connection, a valid bus name and a flags parameter. The flags parameter is a combination of the following - flags:</para> + <para><function>sd_bus_request_name()</function> requests a well-known service name on a bus. It takes a + bus connection, a valid bus name, and a flags parameter. The flags parameter is a combination of zero or + more of the following flags:</para> <variablelist> <varlistentry> @@ -82,8 +82,9 @@ <varlistentry> <term><constant>SD_BUS_NAME_REPLACE_EXISTING</constant></term> - <listitem><para>Take over the name if it is already acquired by another peer, and that other peer has permitted - takeover by setting <constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant> while acquiring it.</para></listitem> + <listitem><para>Take over the name if it was already acquired by another peer, and that other peer + has permitted takeover by setting <constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant> while acquiring + it.</para></listitem> </varlistentry> <varlistentry> diff --git a/man/sd_bus_set_description.xml b/man/sd_bus_set_description.xml index cfcebdfb29..3c5580e27c 100644 --- a/man/sd_bus_set_description.xml +++ b/man/sd_bus_set_description.xml @@ -130,33 +130,25 @@ <listitem><para>An argument is invalid.</para></listitem> </varlistentry> - </variablelist> - <variablelist> <varlistentry> <term><constant>-ENOPKG</constant></term> <listitem><para>The bus cannot be resolved.</para></listitem> </varlistentry> - </variablelist> - <variablelist> <varlistentry> <term><constant>-EPERM</constant></term> <listitem><para>The bus has already been started.</para></listitem> </varlistentry> - </variablelist> - <variablelist> <varlistentry> <term><constant>-ECHILD</constant></term> <listitem><para>The bus was created in a different process.</para></listitem> </varlistentry> - </variablelist> - <variablelist> <varlistentry> <term><constant>-ENOMEM</constant></term> diff --git a/man/sd_bus_slot_set_description.xml b/man/sd_bus_slot_set_description.xml index 13dd6f8815..9bc2ba8592 100644 --- a/man/sd_bus_slot_set_description.xml +++ b/man/sd_bus_slot_set_description.xml @@ -72,17 +72,13 @@ <listitem><para>An required argument is <constant>NULL</constant>.</para></listitem> </varlistentry> - </variablelist> - <variablelist> <varlistentry> <term><constant>-ENXIO</constant></term> <listitem><para>The bus slot object has no description.</para></listitem> </varlistentry> - </variablelist> - <variablelist> <varlistentry> <term><constant>-ENOMEM</constant></term> diff --git a/man/sd_event_set_watchdog.xml b/man/sd_event_set_watchdog.xml index faaaad39d9..cacc683b57 100644 --- a/man/sd_event_set_watchdog.xml +++ b/man/sd_event_set_watchdog.xml @@ -69,7 +69,7 @@ this feature disabled.</para> <para>The first watchdog notification message is sent immediately - when <function>set_event_set_watchdog()</function> is invoked with + when <function>sd_event_set_watchdog()</function> is invoked with a true <parameter>b</parameter> parameter.</para> <para>The watchdog logic is designed to allow the service manager diff --git a/man/sd_event_source_unref.xml b/man/sd_event_source_unref.xml index 01e3008eed..81131fa737 100644 --- a/man/sd_event_source_unref.xml +++ b/man/sd_event_source_unref.xml @@ -19,6 +19,8 @@ <refname>sd_event_source_unref</refname> <refname>sd_event_source_unrefp</refname> <refname>sd_event_source_ref</refname> + <refname>sd_event_source_disable_unref</refname> + <refname>sd_event_source_disable_unrefp</refname> <refpurpose>Increase or decrease event source reference counters</refpurpose> </refnamediv> @@ -42,6 +44,15 @@ <paramdef>sd_event_source *<parameter>source</parameter></paramdef> </funcprototype> + <funcprototype> + <funcdef>sd_event_source* <function>sd_event_source_disable_unref</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_event_source_disable_unrefp</function></funcdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + </funcprototype> </funcsynopsis> </refsynopsisdiv> @@ -77,23 +88,32 @@ the passed event source object is <constant>NULL</constant>.</para> - <para>Note that event source objects stay alive and may be - dispatched as long as they have a reference counter greater than - zero. In order to drop a reference of an event source and make - sure the associated event source handler function is not called - anymore it is recommended to combine a call of + <para>Note that event source objects stay alive and may be dispatched as long as they have a reference + counter greater than zero. In order to drop a reference of an event source and make sure the associated + event source handler function is not called anymore it is recommended to combine a call of <function>sd_event_source_unref()</function> with a prior call to - <function>sd_event_source_set_enabled()</function> with - <constant>SD_EVENT_OFF</constant>.</para> + <function>sd_event_source_set_enabled()</function> with <constant>SD_EVENT_OFF</constant> or call + <function>sd_event_source_disable_unref()</function>, see below.</para> + + <para><function>sd_event_source_disable_unref()</function> combines a call to + <function>sd_event_source_set_enabled()</function> with <constant>SD_EVENT_OFF</constant> with + <function>sd_event_source_unref()</function>. This ensures that the source is disabled before the local + reference to it is lost. The <parameter>source</parameter> parameter is allowed to be + <constant>NULL</constant>.</para> + + <para><function>sd_event_source_disable_unrefp()</function> is similar to + <function>sd_event_source_unrefp()</function>, but in addition disables the source first. This call is + useful in conjunction with GCC's and LLVM's + <ulink url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up Variable + Attribute</ulink>. Note that this function is defined as inline function.</para> </refsect1> <refsect1> <title>Return Value</title> - <para><function>sd_event_source_unref()</function> always returns - <constant>NULL</constant>. - <function>sd_event_source_ref()</function> always returns the - event source object passed in.</para> + <para><function>sd_event_source_unref()</function> and + <function>sd_event_source_disable_unref()</function> always return <constant>NULL</constant>. + <function>sd_event_source_ref()</function> always returns the event source object passed in.</para> </refsect1> <xi:include href="libsystemd-pkgconfig.xml" /> diff --git a/man/sd_journal_has_runtime_files.xml b/man/sd_journal_has_runtime_files.xml index 4b0075cbe0..7e6e7d4b9d 100644 --- a/man/sd_journal_has_runtime_files.xml +++ b/man/sd_journal_has_runtime_files.xml @@ -4,8 +4,6 @@ <!-- SPDX-License-Identifier: LGPL-2.1+ - - Copyright © 2016 Jan Synáček --> <refentry id="sd_journal_has_runtime_files" xmlns:xi="http://www.w3.org/2001/XInclude"> diff --git a/man/sd_notify.xml b/man/sd_notify.xml index 0084bf3882..3046ca88ee 100644 --- a/man/sd_notify.xml +++ b/man/sd_notify.xml @@ -174,6 +174,18 @@ </varlistentry> <varlistentry> + <term>WATCHDOG=trigger</term> + + <listitem><para>Tells the service manager that the service detected an internal error that should be handled by + the configured watchdog options. This will trigger the same behaviour as if <varname>WatchdogSec=</varname> is + enabled and the service did not send <literal>WATCHDOG=1</literal> in time. Note that + <varname>WatchdogSec=</varname> does not need to be enabled for <literal>WATCHDOG=trigger</literal> to trigger + the watchdog action. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + information about the watchdog behavior. </para></listitem> + </varlistentry> + + <varlistentry> <term>WATCHDOG_USEC=…</term> <listitem><para>Reset <varname>watchdog_usec</varname> value during runtime. @@ -188,7 +200,7 @@ <listitem><para>Tells the service manager to extend the startup, runtime or shutdown service timeout corresponding the current state. The value specified is a time in microseconds during which the service must send a new message. A service timeout will occur if the message isn't received, but only if the runtime of the - current state is beyond the original maximium times of <varname>TimeoutStartSec=</varname>, <varname>RuntimeMaxSec=</varname>, + current state is beyond the original maximum times of <varname>TimeoutStartSec=</varname>, <varname>RuntimeMaxSec=</varname>, and <varname>TimeoutStopSec=</varname>. See <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for effects on the service timeouts.</para></listitem> diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml index 0a8eeb62a4..4932948178 100644 --- a/man/sysctl.d.xml +++ b/man/sysctl.d.xml @@ -59,6 +59,12 @@ <filename>/proc/sys/net/ipv4/conf/enp3s0.200/forwarding</filename>. </para> + <para>Any access permission errors and attempts to write variables not defined on the local system are + logged, but do not cause the the service to fail. Moreover, if a variable assignment is prefixed with a + single <literal>-</literal> character, failure to set the variable will be logged, but will not cause the + service to fail. All other errors when setting variables cause the service to return failure at the end + (other variables are still processed).</para> + <para>The settings configured with <filename>sysctl.d</filename> files will be applied early on boot. The network interface-specific options will also be applied individually for diff --git a/man/systemctl.xml b/man/systemctl.xml index d991e979f1..0f06a88f42 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -507,6 +507,21 @@ </varlistentry> <varlistentry> + <term><option>--what=</option></term> + + <listitem> + <para>Select what type of per-unit resources to remove when the <command>clean</command> command is + invoked, see below. Takes one of <constant>configuration</constant>, <constant>state</constant>, + <constant>cache</constant>, <constant>logs</constant>, <constant>runtime</constant> to select the + type of resource. This option may be specified more than once, in which case all specified resource + types are removed. Also accepts the special value <constant>all</constant> as a shortcut for + specifiying all five resource types. If this option is not specified defaults to the combination of + <constant>cache</constant> and <constant>runtime</constant>, i.e. the two kinds of resources that + are generally considered to be redundant and can be reconstructed on next invocation.</para> + </listitem> + </varlistentry> + + <varlistentry> <term><option>-f</option></term> <term><option>--force</option></term> @@ -801,8 +816,14 @@ Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago <term><command>stop <replaceable>PATTERN</replaceable>…</command></term> <listitem> - <para>Stop (deactivate) one or more units specified on the - command line.</para> + <para>Stop (deactivate) one or more units specified on the command line.</para> + + <para>This command will fail if the unit does exist or if stopping of the unit is prohibited (see + <varname>RefuseManualStop=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + It will <emphasis>not</emphasis> fail if any of the commands configured to stop the unit + (<varname>ExecStop=</varname>, etc.) fail, because the manager will still forcibly terminate the + unit.</para> </listitem> </varlistentry> <varlistentry> @@ -905,6 +926,24 @@ Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago </listitem> </varlistentry> <varlistentry> + <term><command>clean <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Remove the configuration, state, cache, logs or runtime data of the specified units. Use + <option>--what=</option> to select which kind of resource to remove. For service units this may + be used to remove the directories configured with <varname>ConfigurationDirectory=</varname>, + <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname>, + <varname>LogsDirectory=</varname> and <varname>RuntimeDirectory=</varname>, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. For timer units this may be used to clear out the persistent timestamp data if + <varname>Persistent=</varname> is used and <option>--what=state</option> is selected, see + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This + command only applies to units that use either of these settings. If <option>--what=</option> is + not specified, both the cache and runtime data are removed (as these two types of data are + generally redundant and reproducible on the next invocation of the unit).</para> + </listitem> + </varlistentry> + <varlistentry> <term><command>is-active <replaceable>PATTERN</replaceable>…</command></term> <listitem> @@ -1058,18 +1097,22 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err next reboot. The syntax of the property assignment follows closely the syntax of assignments in unit files.</para> - <para>Example: <command>systemctl set-property foobar.service CPUShares=777</command></para> + <para>Example: <command>systemctl set-property foobar.service CPUWeight=200</command></para> <para>If the specified unit appears to be inactive, the changes will be only stored on disk as described previously hence they will be effective when the unit will be started.</para> - <para>Note that this command allows changing multiple - properties at the same time, which is preferable over - setting them individually. Like with unit file configuration - settings, assigning an empty list will reset the property. - </para> + <para>Note that this command allows changing multiple properties at the same time, which is + preferable over setting them individually.</para> + + <para>Example: <command>systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes</command></para> + + <para>Like with unit file configuration settings, assigning an empty setting usually resets a + property to its defaults.</para> + + <para>Example: <command>systemctl set-property avahi-daemon.service IPAddressDeny=</command></para> </listitem> </varlistentry> @@ -1341,7 +1384,7 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err </row> <row> <entry><literal>indirect</literal></entry> - <entry>The unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the <literal>[Install]</literal> unit file section, listing other unit files that might be enabled, or it has an alias under a different name through a symlink that is not specified in Also=. For template unit file, an instance different than the one specified in <varname>DefaultInstance=</varname> is enabled.</entry> + <entry>The unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the <literal>[Install]</literal> unit file section, listing other unit files that might be enabled, or it has an alias under a different name through a symlink that is not specified in <varname>Also=</varname>. For template unit file, an instance different than the one specified in <varname>DefaultInstance=</varname> is enabled.</entry> <entry>0</entry> </row> <row> diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index f559b858f9..7e842ac201 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -86,6 +86,18 @@ <cmdsynopsis> <command>systemd-analyze</command> <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">exit-status</arg> + <arg choice="opt" rep="repeat"><replaceable>STATUS</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">condition</arg> + <arg choice="plain"><replaceable>CONDITION</replaceable>…</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="plain">syscall-filter</arg> <arg choice="opt"><replaceable>SET</replaceable>…</arg> </cmdsynopsis> @@ -93,7 +105,13 @@ <command>systemd-analyze</command> <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="plain">calendar</arg> - <arg choice="plain" rep="repeat"><replaceable>SPECS</replaceable></arg> + <arg choice="plain" rep="repeat"><replaceable>SPEC</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">timestamp</arg> + <arg choice="plain" rep="repeat"><replaceable>TIMESTAMP</replaceable></arg> </cmdsynopsis> <cmdsynopsis> <command>systemd-analyze</command> @@ -166,7 +184,13 @@ multi-user.target reached after 47.820s in userspace initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: <command>systemd-analyze blame</command> doesn't display results for services with <varname>Type=simple</varname>, because systemd considers such services to be started - immediately, hence no measurement of the initialization delays can be done.</para> + immediately, hence no measurement of the initialization delays can be done. Also note that this command + only shows the time units took for starting up, it does not show how long unit jobs spent in the + execution queue. In particular it shows the time units spent in <literal>activating</literal> state, + which is not defined for units such as device units that transition directly from + <literal>inactive</literal> to <literal>active</literal>. This command hence gives an impression of the + performance of program code, but cannot accurately reflect latency introduced by waiting for + hardware and similar events.</para> <example> <title><command>Show which units took the most time during boot</command></title> @@ -190,7 +214,12 @@ multi-user.target reached after 47.820s in userspace <replaceable>UNIT</replaceable>s or for the default target otherwise). The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. Note that the output might be misleading as the initialization of services might - depend on socket activation and because of the parallel execution of units.</para> + depend on socket activation and because of the parallel execution of units. Also, similar to the + <command>blame</command> command, this only takes into account the time units spent in + <literal>activating</literal> state, and hence does not cover units that never went through an + <literal>activating</literal> state (such as device units that transition directly from + <literal>inactive</literal> to <literal>active</literal>). Moreover it does not show information on + jobs (and in particular not jobs that timed out).</para> <example> <title><command>systemd-analyze time</command></title> @@ -337,12 +366,63 @@ $ eog targets.svg</programlisting> </example> <para>Note that this verb prints the list that is compiled into <command>systemd-analyze</command> - itself, and does not comunicate with the running manager. Use + itself, and does not communicate with the running manager. Use <programlisting>systemctl [--user] [--global] show -p UnitPath --value</programlisting> to retrieve the actual list that the manager uses, with any empty directories omitted.</para> </refsect2> <refsect2> + <title><command>systemd-analyze exit-status <optional><replaceable>STATUS</replaceable>...</optional></command></title> + + <para>This command prints a list of exit statuses along with their "class", i.e. the source of the + definition (one of <literal>glibc</literal>, <literal>systemd</literal>, <literal>LSB</literal>, or + <literal>BSD</literal>), see the Process Exit Codes section in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + If no additional arguments are specified, all known statuses are are shown. Otherwise, only the + definitions for the specified codes are shown.</para> + + <example> + <title><command>Show some example exit status names</command></title> + + <programlisting>$ systemd-analyze exit-status 0 1 {63..65} +NAME STATUS CLASS +SUCCESS 0 glibc +FAILURE 1 glibc +- 63 - +USAGE 64 BSD +DATAERR 65 BSD +</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze condition <replaceable>CONDITION</replaceable>...</command></title> + + <para>This command will evaluate <varname noindex='true'>Condition*=...</varname> and + <varname noindex='true'>Assert*=...</varname> assignments, and print their values, and + the resulting value of the combined condition set. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a list of available conditions and asserts.</para> + + <example> + <title>Evaluate conditions that check kernel versions</title> + + <programlisting>$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \ + 'ConditionKernelVersion = >=5.1' \ + 'ConditionACPower=|false' \ + 'ConditionArchitecture=|!arm' \ + 'AssertPathExists=/etc/os-release' +test.service: AssertPathExists=/etc/os-release succeeded. +Asserts succeeded. +test.service: ConditionArchitecture=|!arm succeeded. +test.service: ConditionACPower=|false failed. +test.service: ConditionKernelVersion=>=5.1 succeeded. +test.service: ConditionKernelVersion=!<4.0 succeeded. +Conditions succeeded.</programlisting> + </example> + </refsect2> + + <refsect2> <title><command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>...</optional></command></title> <para>This command will list system calls contained in the specified system call set @@ -360,7 +440,8 @@ $ eog targets.svg</programlisting> <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. By default, only the next time the calendar expression will elapse is shown; use <option>--iterations=</option> to show the specified number of next times the expression - elapses.</para> + elapses. Each time the expression elapses forms a timestamp, see the <command>timestamp</command> + verb below.</para> <example> <title>Show leap days in the near future</title> @@ -383,12 +464,46 @@ Normalized form: *-02-29 00:00:00 </refsect2> <refsect2> + <title><command>systemd-analyze timestamp <replaceable>TIMESTAMP</replaceable>...</command></title> + + <para>This command parses a timestamp (i.e. a single point in time) and outputs the normalized form and + the difference between this timestamp and now. The timestamp should adhere to the syntax documented in + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + section "PARSING TIMESTAMPS".</para> + + <example> + <title>Show parsing of timestamps</title> + + <programlisting>$ systemd-analyze timestamp yesterday now tomorrow + Original form: yesterday +Normalized form: Mon 2019-05-20 00:00:00 CEST + (in UTC): Sun 2019-05-19 22:00:00 UTC + UNIX seconds: @15583032000 + From now: 1 day 9h ago + + Original form: now +Normalized form: Tue 2019-05-21 09:48:39 CEST + (in UTC): Tue 2019-05-21 07:48:39 UTC + UNIX seconds: @1558424919.659757 + From now: 43us ago + + Original form: tomorrow +Normalized form: Wed 2019-05-22 00:00:00 CEST + (in UTC): Tue 2019-05-21 22:00:00 UTC + UNIX seconds: @15584760000 + From now: 14h left +</programlisting> + </example> + </refsect2> + + <refsect2> <title><command>systemd-analyze timespan <replaceable>EXPRESSION</replaceable>...</command></title> - <para>This command parses a time span and outputs the normalized form and the equivalent value in - microseconds. The time span should adhere to the same syntax documented in - <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. - Values without associated magnitudes are parsed as seconds.</para> + <para>This command parses a time span (i.e. a difference between two timestamps) and outputs the + normalized form and the equivalent value in microseconds. The time span should adhere to the syntax + documented in + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + section "PARSING TIME SPANS". Values without units are parsed as seconds.</para> <example> <title>Show parsing of timespans</title> diff --git a/man/systemd-boot-system-token.service.xml b/man/systemd-boot-system-token.service.xml new file mode 100644 index 0000000000..b2948a5c4b --- /dev/null +++ b/man/systemd-boot-system-token.service.xml @@ -0,0 +1,76 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<refentry id="systemd-boot-system-token.service" conditional='ENABLE_EFI' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-boot-system-token.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-boot-system-token.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-boot-system-token.service</refname> + <refpurpose>Generate an initial boot loader system token and random seed</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-boot-system-token.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-boot-system-token.service</filename> is a system service that automatically + generates a 'system token' to store in an EFI variable in the system's NVRAM and a random seed to store + on the EFI System Partition ESP on disk. The boot loader may then combine these two randomized data + fields by cryptographic hashing, and pass it to the OS it boots as initialization seed for its entropy + pool. The random seed stored in the ESP is refreshed on each reboot ensuring that multiple subsequent + boots will boot with different seeds. The 'system token' is generated randomly once, and then + persistently stored in the system's EFI variable storage.</para> + + <para>The <filename>systemd-boot-system-token.service</filename> unit invokes the <command>bootctl + random-seed</command> command, which updates the random seed in the ESP, and initializes the 'system + token' if it's not initialized yet. The service is conditionalized so that it is run only when all of the + below apply:</para> + + <itemizedlist> + <listitem><para>A boot loader is used that implements the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink> (which defines the 'system + token' concept).</para></listitem> + + <listitem><para>Either a 'system token' was not set yet, or the boot loader has not passed the OS a + random seed yet (and thus most likely has been missing the random seed file in the + ESP).</para></listitem> + + <listitem><para>The system is not running in a VM environment. This case is explicitly excluded since + on VM environments the ESP backing storage and EFI variable storage is typically not physically + separated and hence booting the same OS image in multiple instances would replicate both, thus reusing + the same random seed and 'system token' among all instances, which defeats its purpose. Note that it's + still possible to use boot loader random seed provisioning in this mode, but the automatic logic + implemented by this service has no effect then, and the user instead has to manually invoke the + <command>bootctl random-seed</command> acknowledging these restrictions.</para></listitem> + </itemizedlist> + + <para>For further details see + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, regarding + the command this service invokes.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml index 3b1319687f..da8ddb5f84 100644 --- a/man/systemd-boot.xml +++ b/man/systemd-boot.xml @@ -28,13 +28,14 @@ manager. It provides a graphical menu to select the entry to boot and an editor for the kernel command line. <command>systemd-boot</command> supports systems with UEFI firmware only.</para> - <para>systemd-boot loads boot entry information from the EFI system partition (ESP), usually mounted at - <filename>/efi/</filename>, <filename>/boot/</filename>, or <filename>/boot/efi/</filename> during OS - runtime, as well as from the Extended Boot Loader partition if it exists (usually mounted to - <filename>/boot/</filename>). Configuration file fragments, kernels, initrds and other EFI images to boot - generally need to reside on the ESP or the Extended Boot Loader partition. Linux kernels must be built - with <option>CONFIG_EFI_STUB</option> to be able to be directly executed as an EFI image. During boot - systemd-boot automatically assembles a list of boot entries from the following sources:</para> + <para><command>systemd-boot</command> loads boot entry information from the EFI system partition (ESP), + usually mounted at <filename>/efi/</filename>, <filename>/boot/</filename>, or + <filename>/boot/efi/</filename> during OS runtime, as well as from the Extended Boot Loader partition if + it exists (usually mounted to <filename>/boot/</filename>). Configuration file fragments, kernels, + initrds and other EFI images to boot generally need to reside on the ESP or the Extended Boot Loader + partition. Linux kernels must be built with <option>CONFIG_EFI_STUB</option> to be able to be directly + executed as an EFI image. During boot <command>systemd-boot</command> automatically assembles a list of + boot entries from the following sources:</para> <itemizedlist> <listitem><para>Boot entries defined with <ulink @@ -57,17 +58,50 @@ <listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware</para></listitem> </itemizedlist> - <para><citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry> - may be used to copy kernel images onto the ESP or the Extended Boot Loader Partition and to generate - description files compliant with the Boot Loader - Specification. <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + <para><command>systemd-boot</command> supports the following features:</para> + + <itemizedlist> + <listitem><para>Basic boot manager configuration changes (such as timeout + configuration, default boot entry selection, …) may be made directly from the boot loader UI at + boot-time, as well as during system runtime with EFI variables.</para></listitem> + + <listitem><para>The boot manager integrates with the <command>systemctl</command> command to implement + features such as <command>systemctl reboot --boot-loader-entry=…</command> (for rebooting into a + specific boot menu entry, i.e. "reboot into Windows") and <command>systemctl reboot + --boot-loader-menu=…</command> (for rebooting into the boot loader menu), by implementing the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + + <listitem><para>An EFI variable set by the boot loader informs the OS about the ESP partition used + during boot. This is then used to automatically mount the correct ESP partition to + <filename>/efi/</filename> or <filename>/boot/</filename> during OS runtime. See + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details.</para></listitem> + + <listitem><para>The boot manager provides information about the boot time spent in UEFI firmware using + the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. This + information can be displayed using + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + + <listitem><para>The boot manager implements boot counting and automatic fallback to older, working boot + entries on failure. See <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot + Assessment</ulink>.</para></listitem> + + <listitem><para>The boot manager optionally reads a random seed from the ESP partition, combines it + with a 'system token' stored in a persistant EFI variable and derives a random seed to use by the OS as + entropy pool initializaton, providing a full entropy pool during early boot.</para></listitem> + </itemizedlist> + + <para><citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be used from a running system to locate the ESP and the Extended Boot Loader Partition, list available entries, and install <command>systemd-boot</command> itself.</para> - <para>systemd-boot will provide information about the time spent in UEFI firmware using the <ulink - url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. This information can be displayed - using <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>. - </para> + <para><citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry> + may be used to copy kernel images onto the ESP or the Extended Boot Loader Partition and to generate + description files compliant with the Boot Loader + Specification.</para> </refsect1> <refsect1> @@ -238,7 +272,9 @@ Loader Specification</ulink> are read from <filename>/loader/entries/</filename> on the ESP and the Extended Boot Loader partition. Unified kernel boot entries following the <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> are read from - <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader partition.</para> + <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader partition. Optionally, a random + seed for early boot entropy pool provisioning is stored in <filename>/loader/random-seed</filename> in + the ESP.</para> </refsect1> <refsect1> @@ -346,10 +382,42 @@ <listitem><para>Information about the time spent in various parts of the boot loader. Set by the boot loader. Use <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> - to view this data. These variables are defined by the <ulink - url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para></listitem> + to view this data. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderRandomSeed</varname></term> + + <listitem><para>A binary random seed <command>systemd-boot</command> may optionally pass to the + OS. This is a volatile EFI variable that is hashed at boot from the combination of a random seed + stored in the ESP (in <filename>/loader/random-seed</filename>) and a "system token" persistently + stored in the EFI variable <varname>LoaderSystemToken</varname> (see below). During early OS boot the + system manager reads this variable and passes it to the OS kernel's random pool, crediting the full + entropy it contains. This is an efficient way to ensure the system starts up with a fully initialized + kernel random pool — as early as the initial RAM disk phase. <command>systemd-boot</command> reads + the random seed from the ESP, combines it with the "system token", and both derives a new random seed + to update in-place the seed stored in the ESP, and the random seed to pass to the OS from it via + SHA256 hashing in counter mode. This ensures that different physical systems that boot the same + "golden" OS image — i.e. containing the same random seed file in the ESP — will still pass a + different random seed to the OS. It is made sure the random seed stored in the ESP is fully + overwritten before the OS is booted, to ensure different random seed data is used between subsequent + boots.</para> + + <para>See <ulink url="https://systemd.io/RANDOM_SEEDS">Random Seeds</ulink> for + further information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderSystemToken</varname></term> + + <listitem><para>A binary random data field, that is used for generating the random see to pass to the + OS (see above). Note that this random data is generally only generated once, during OS installation, + and is then never updated again.</para></listitem> </varlistentry> </variablelist> + + <para>Many of these variables are defined by the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para> </refsect1> <refsect1> @@ -357,7 +425,7 @@ <para><command>systemd-boot</command> implements a simple boot counting mechanism on top of the <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, for automatic and unattended - fallback to older kernel versions/boot loader entries when a specific entry continously fails. Any boot loader + fallback to older kernel versions/boot loader entries when a specific entry continuously fails. Any boot loader entry file and unified kernel image file that contains a <literal>+</literal> followed by one or two numbers (if two they need to be separated by a <literal>-</literal>), before the <filename>.conf</filename> or <filename>.efi</filename> suffix is subject to boot counting: the first of the two numbers ('tries left') is @@ -413,6 +481,7 @@ <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, <citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-boot-system-token.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink> diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml index 1f9a79db82..305dc2ff37 100644 --- a/man/systemd-debug-generator.xml +++ b/man/systemd-debug-generator.xml @@ -1,7 +1,10 @@ <?xml version="1.0"?> <!--*-nxml-*--> <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> <!-- SPDX-License-Identifier: LGPL-2.1+ --> <refentry id="systemd-debug-generator"> @@ -56,9 +59,10 @@ <option>rd.systemd.debug_shell</option> option is specified, the debug shell service <literal>debug-shell.service</literal> is pulled into the boot - transaction. It will spawn a debug shell on tty9 during early - system startup. Note that the shell may also be turned on - persistently by enabling it with + transaction and a debug shell will be spawned during early boot. + By default, <filename>&DEBUGTTY;</filename> is used, but a specific tty can also be set, + either with or without the <filename>/dev/</filename> prefix. + Note that the shell may also be turned on persistently by enabling it with <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s <command>enable</command> command. <option>rd.systemd.debug_shell=</option> is honored only by initial diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml index 28d997cfa9..d599ac20f1 100644 --- a/man/systemd-detect-virt.xml +++ b/man/systemd-detect-virt.xml @@ -62,7 +62,7 @@ </thead> <tbody> <row> - <entry valign="top" morerows="11">VM</entry> + <entry valign="top" morerows="12">VM</entry> <entry><varname>qemu</varname></entry> <entry>QEMU software virtualization, without KVM</entry> </row> @@ -128,7 +128,7 @@ </row> <row> - <entry valign="top" morerows="6">Container</entry> + <entry valign="top" morerows="7">Container</entry> <entry><varname>openvz</varname></entry> <entry>OpenVZ/Virtuozzo</entry> </row> @@ -154,6 +154,11 @@ </row> <row> + <entry><varname>podman</varname></entry> + <entry><ulink url="https://podman.io">Podman</ulink> container manager</entry> + </row> + + <row> <entry><varname>rkt</varname></entry> <entry>rkt app container runtime</entry> </row> diff --git a/man/systemd-gpt-auto-generator.xml b/man/systemd-gpt-auto-generator.xml index 0d6d4e307e..22cd638f1f 100644 --- a/man/systemd-gpt-auto-generator.xml +++ b/man/systemd-gpt-auto-generator.xml @@ -187,6 +187,12 @@ <filename>/dev/mapper/home</filename> and <filename>/dev/mapper/srv</filename>. Note that this might create conflicts if the same partition is listed in <filename>/etc/crypttab</filename> with a different device mapper device name.</para> + + <para>When systemd is running in the initrd the <filename>/</filename> partition may be encrypted in LUKS + format as well. In this case, a device mapper device is set up under the name <filename>/dev/mapper/root</filename>, + and a <filename>sysroot.mount</filename> is set up that mounts the device under <filename>/sysroot</filename>. + For more information, see <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> <para>Mount and automount units for the EFI System Partition (ESP) are generated on EFI systems. The ESP is mounted to <filename>/boot/</filename> (except if an Extended Boot Loader partition exists, see @@ -234,7 +240,7 @@ <term><varname>root=</varname></term> <listitem><para>When used with the special value <literal>gpt-auto</literal>, automatic discovery of - the root parition based on the GPT partition type is enabled. Any other value disables this + the root partition based on the GPT partition type is enabled. Any other value disables this generator.</para></listitem> </varlistentry> diff --git a/man/systemd-hibernate-resume-generator.xml b/man/systemd-hibernate-resume-generator.xml index ff105d435c..f532a19a48 100644 --- a/man/systemd-hibernate-resume-generator.xml +++ b/man/systemd-hibernate-resume-generator.xml @@ -56,6 +56,13 @@ </varlistentry> <varlistentry> + <term><varname>resumeflags=</varname></term> + + <listitem><para>Takes the resume device mount options to + use. Defaults <varname>rootflags=</varname> if not specified.</para></listitem> + </varlistentry> + + <varlistentry> <term><varname>noresume</varname></term> <listitem><para>Do not try to resume from hibernation. If this parameter is diff --git a/man/systemd-mount.xml b/man/systemd-mount.xml index e557ee80a1..4a7c33f558 100644 --- a/man/systemd-mount.xml +++ b/man/systemd-mount.xml @@ -211,11 +211,11 @@ </varlistentry> <varlistentry> - <term><option>--bind-device=</option></term> + <term><option>--bind-device</option></term> - <listitem><para>Takes a boolean argument, defaults to off. This option only has an effect in automount mode, - and controls whether the automount unit shall be bound to the backing device's lifetime. If enabled, the - automount point will be removed automatically when the backing device vanishes. If disabled the automount point + <listitem><para>This option only has an effect in automount mode, + and controls whether the automount unit shall be bound to the backing device's lifetime. If set, the + automount point will be removed automatically when the backing device vanishes. By default the automount point stays around, and subsequent accesses will block until backing device is replugged. This option has no effect in case of non-device mounts, such as network or virtual file system mounts.</para> diff --git a/man/systemd-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml index 7c82f68fb3..51b865dc0b 100644 --- a/man/systemd-networkd-wait-online.service.xml +++ b/man/systemd-networkd-wait-online.service.xml @@ -55,7 +55,7 @@ one is necessary to access some network resources. When used, all other interfaces are ignored. This option may be used more than once to wait for multiple network interfaces. When this option is specified multiple times, then <command>systemd-networkd-wait-online</command> waits - for all specified interfaces to be online. Optinally, required minimum operational state can be + for all specified interfaces to be online. Optionally, required minimum operational state can be specified after a colon <literal>:</literal>. Please see <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for possible operational states. If the operational state is not specified here, then diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index 5ba162b93c..db3f10c3a2 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -1,8 +1,8 @@ <?xml version='1.0'?> <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ -<!ENTITY fedora_latest_version "28"> -<!ENTITY fedora_cloud_release "1.1"> +<!ENTITY fedora_latest_version "30"> +<!ENTITY fedora_cloud_release "1.2"> ]> <!-- SPDX-License-Identifier: LGPL-2.1+ --> @@ -368,12 +368,16 @@ <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details.</para> - <para>Note that setting this option to <option>yes</option> or <option>state</option> will only work correctly - with operating systems in the container that can boot up with only <filename>/usr</filename> mounted, and are - able to automatically populate <filename>/var</filename>, and also <filename>/etc</filename> in case of - <literal>--volatile=yes</literal>. The <option>overlay</option> option does not require any particular - preparations in the OS, but do note that <literal>overlayfs</literal> behaviour differs from regular file - systems in a number of ways, and hence compatibility is limited.</para></listitem> + <para>Note that setting this option to <option>yes</option> or <option>state</option> will only work + correctly with operating systems in the container that can boot up with only + <filename>/usr/</filename> mounted, and are able to automatically populate <filename>/var/</filename> + (and <filename>/etc/</filename> in case of <literal>--volatile=yes</literal>). Specifically, this + means that operating systems that follow the historic split of <filename>/bin/</filename> and + <filename>/lib/</filename> (and related directories) from <filename>/usr/</filename> (i.e. where the + former are not symlinks into the latter) are not supported by <literal>--volatile=yes</literal> as + container payload. The <option>overlay</option> option does not require any particular preparations + in the OS, but do note that <literal>overlayfs</literal> behaviour differs from regular file systems + in a number of ways, and hence compatibility is limited.</para></listitem> </varlistentry> <varlistentry> @@ -709,10 +713,10 @@ <varlistentry> <term><option>--private-users-chown</option></term> - <listitem><para>If specified, all files and directories in the container's directory tree will adjusted so that - they are owned to the appropriate UIDs/GIDs selected for the container (see above). This operation is - potentially expensive, as it involves descending and iterating through the full directory tree of the - container. Besides actual file ownership, file ACLs are adjusted as well.</para> + <listitem><para>If specified, all files and directories in the container's directory tree will be + adjusted so that they are owned by the appropriate UIDs/GIDs selected for the container (see above). + This operation is potentially expensive, as it involves iterating through the full directory tree of + the container. Besides actual file ownership, file ACLs are adjusted as well.</para> <para>This option is implied if <option>--private-users=pick</option> is used. This option has no effect if user namespacing is not used.</para></listitem> @@ -1343,7 +1347,7 @@ <programlisting># machinectl pull-raw --verify=no \ https://download.fedoraproject.org/pub/fedora/linux/releases/&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw.xz -# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw</programlisting> +# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64</programlisting> <para>This downloads an image using <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> @@ -1390,7 +1394,7 @@ <title>Boot a minimal <ulink url="https://www.archlinux.org">Arch Linux</ulink> distribution in a container</title> - <programlisting># pacstrap -c -d ~/arch-tree/ base + <programlisting># pacstrap -c ~/arch-tree/ base # systemd-nspawn -bD ~/arch-tree/</programlisting> <para>This installs a minimal Arch Linux distribution into the diff --git a/man/systemd-pstore.xml b/man/systemd-pstore.xml new file mode 100644 index 0000000000..dd1aa5e83b --- /dev/null +++ b/man/systemd-pstore.xml @@ -0,0 +1,99 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<refentry id="systemd-pstore" conditional='ENABLE_PSTORE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-pstore</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-pstore</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-pstore</refname> + <refname>systemd-pstore.service</refname> + <refpurpose>Tool to archive contents of the persistent storage filesytem</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/systemd-pstore</filename></para> + <para><filename>systemd-pstore.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para><filename>systemd-pstore.service</filename> is a system service that archives the + contents of the Linux persistent storage filesystem, pstore, to other storage, + thus preserving the existing information contained in the pstore, and clearing + pstore storage for future error events.</para> + + <para>Linux provides a persistent storage file system, pstore, that can store + error records when the kernel dies (or reboots or powers-off). These records in + turn can be referenced to debug kernel problems (currently the kernel stuffs + the tail of the dmesg, which also contains a stack backtrace, into pstore).</para> + + <para>The pstore file system supports a variety of backends that map onto persistent + storage, such as the ACPI ERST and UEFI variables. The pstore backends + typically offer a relatively small amount of persistent storage, e.g. 64KiB, + which can quickly fill up and thus prevent subsequent kernel crashes from + recording errors. Thus there is a need to monitor and extract the pstore + contents so that future kernel problems can also record information in the + pstore.</para> + + <para>The pstore service is independent of the kdump service. In cloud environments + specifically, host and guest filesystems are on remote filesystems (eg. iSCSI + or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation + of networking software *and* hardware *and* infrastructure. Thus it may not be + possible to capture a kernel coredump to a file since writes over the network + may not be possible.</para> + + <para>The pstore backend, on the other hand, is completely local and provides a path + to store error records which will survive a reboot and aid in post-mortem + debugging.</para> + + <para>The <command>systemd-pstore</command> executable does the actual work. Upon starting, + the <filename>pstore.conf</filename> is read to obtain options, then the /sys/fs/pstore + directory contents are processed according to the options. Pstore files are written to the + journal, and optionally saved into /var/lib/systemd/pstore.</para> + </refsect1> + + <refsect1> + <title>Configuration</title> + + <para>The behavior of <command>systemd-pstore</command> is configured through the configuration file + <filename>/etc/systemd/pstore.conf</filename> and corresponding snippets + <filename>/etc/systemd/pstore.conf.d/*.conf</filename>, see + <citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <refsect2> + <title>Disabling pstore processing</title> + + <para>To disable pstore processing by <command>systemd-pstore</command>, + set <programlisting>Storage=none</programlisting> in + <citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </refsect2> + </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.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-random-seed.service.xml b/man/systemd-random-seed.service.xml index 35c6e2fd0b..28783a15e9 100644 --- a/man/systemd-random-seed.service.xml +++ b/man/systemd-random-seed.service.xml @@ -29,21 +29,63 @@ <refsect1> <title>Description</title> - <para><filename>systemd-random-seed.service</filename> is a - service that restores the random seed of the system at early boot - and saves it at shutdown. See - <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> - for details. Saving/restoring the random seed across boots - increases the amount of available entropy early at boot. On disk - the random seed is stored in - <filename>/var/lib/systemd/random-seed</filename>.</para> + <para><filename>systemd-random-seed.service</filename> is a service that loads an on-disk random seed + into the kernel entropy pool during boot and saves it at shutdown. See + <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for + details. By default, no entropy is credited when the random seed is written into the kernel entropy pool, + but this may be changed with <varname>$SYSTEMD_RANDOM_SEED_CREDIT</varname>, see below. On disk the random + seed is stored in <filename>/var/lib/systemd/random-seed</filename>.</para> + + <para>Note that this service runs relatively late during the early boot phase, i.e. generally after the + initial RAM disk (initrd) completed its work, and the <filename>/var/</filename> file system has been + mounted writable. Many system services require entropy much earlier than this — this service is hence of + limited use for complex system. It is recommended to use a boot loader that can pass an initial random + seed to the kernel to ensure that entropy is available from earliest boot on, for example + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, with + its <command>bootctl random-seed</command> functionality.</para> + + <para>When loading the random seed from disk its file is immediately updated with a new seed retrieved + from the kernel, in order to ensure no two boots operate with the same random seed. This new seed is + retrieved synchronously from the kernel, which means the service will not complete start-up until the + random pool is fully initialized. On entropy-starved systems this may take a while. This functionality is + intended to be used as synchronization point for ordering services that require an initialized entropy + pool to function securely (i.e. services that access <filename>/dev/urandom</filename> without any + further precautions).</para> + + <para>Care should be taken when creating OS images that are replicated to multiple systems: if the random + seed file is included unmodified each system will initialize its entropy pool with the same data, and + thus — if otherwise entropy-starved — generate the same or at least guessable random seed streams. As a + safety precaution crediting entropy is thus disabled by default. It is recommended to remove the random + seed from OS images intended for replication on multiple systems, in which case it is safe to enable + entropy crediting, see below.</para> + + <para>See <ulink url="https://systemd.io/RANDOM_SEEDS">Random Seeds</ulink> for further + information.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$SYSTEMD_RANDOM_SEED_CREDIT</varname></term> + <listitem><para>By default, <filename>systemd-random-seed.service</filename> does not credit any + entropy when loading the random seed. With this option this behaviour may be changed: it either takes + a boolean parameter or the special string <literal>force</literal>. Defaults to false, in which case + no entropy is credited. If true, entropy is credited if the random seed file and system state pass + various superficial concisistency checks. If set to <literal>force</literal> entropy is credited, + regardless of these checks, as long as the random seed file exists.</para></listitem> + </varlistentry> + </variablelist> </refsect1> <refsect1> <title>See Also</title> <para> <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, - <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> + <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>4</manvolnum></citerefentry> </para> </refsect1> diff --git a/man/systemd-rc-local-generator.xml b/man/systemd-rc-local-generator.xml index 514d1021d6..81744c2025 100644 --- a/man/systemd-rc-local-generator.xml +++ b/man/systemd-rc-local-generator.xml @@ -17,7 +17,7 @@ <refnamediv> <refname>systemd-rc-local-generator</refname> - <refpurpose>Compatibility generator for starting <filename>/etc/rc.local</filename> and <filename>/usr/sbin/halt.local</filename> during boot and shutdown</refpurpose> + <refpurpose>Compatibility generator for starting <filename>/etc/rc.local</filename> during boot</refpurpose> </refnamediv> <refsynopsisdiv> @@ -35,14 +35,10 @@ script is run after <filename>network.target</filename>, but in parallel with most other regular system services.</para> - <para><filename>systemd-rc-local-generator</filename> also checks whether <filename>/usr/sbin/halt.local</filename> - exists and is executable, and if it is pulls the <filename>halt-local.service</filename> unit into the shutdown - process. This unit is responsible for running this script during later shutdown.</para> - - <para>Support for both <filename>/etc/rc.local</filename> and <filename>/usr/sbin/halt.local</filename> is provided + <para>Support for <filename>/etc/rc.local</filename> is provided for compatibility with specific System V systems only. However, it is strongly recommended to avoid making use of - these scripts today, and instead provide proper unit files with appropriate dependencies for any scripts to run - during the boot or shutdown processes.</para> + this script today, and instead provide proper unit files with appropriate dependencies for any scripts to run + during the boot process.</para> <para><filename>systemd-rc-local-generator</filename> implements <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml index 807c3238b8..53c46a1018 100644 --- a/man/systemd-resolved.service.xml +++ b/man/systemd-resolved.service.xml @@ -163,7 +163,7 @@ <listitem><para>Otherwise the query is failed as no suitable DNS servers could be determined.</para></listitem> </itemizedlist> - <para>The "DNS default route" option is a boolean setting configureable with <command>resolvectl</command> or in + <para>The "DNS default route" option is a boolean setting configurable with <command>resolvectl</command> or in <filename>.network</filename> files. If not set, it is implicitly determined based on the configured DNS domains for a link: if there's any route-only domain (not matching <literal>~.</literal>) it defaults to false, otherwise to true.</para> diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml index 3311a046ca..a6949b0c3b 100644 --- a/man/systemd-sleep.conf.xml +++ b/man/systemd-sleep.conf.xml @@ -168,11 +168,10 @@ <varlistentry> <term><varname>HibernateDelaySec=</varname></term> - <listitem><para>The amount of time in seconds - that will pass before the system is automatically - put into hibernate when using - <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. - </para></listitem> + <listitem><para>The amount of time the system spends in suspend mode before the system is + automatically put into hibernate mode, when using + <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Defaults + to 2h.</para></listitem> </varlistentry> </variablelist> </refsect1> diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml index d23b3fb45d..e403fa5308 100644 --- a/man/systemd-system.conf.xml +++ b/man/systemd-system.conf.xml @@ -96,16 +96,39 @@ <varlistentry> <term><varname>CPUAffinity=</varname></term> - <listitem><para>Configures the CPU affinity for the service manager as well as the default CPU affinity for all - forked off processes. Takes a list of CPU indices or ranges separated by either whitespace or commas. CPU - ranges are specified by the lower and upper CPU indices separated by a dash. Individual services may override - the CPU affinity for their processes with the <varname>CPUAffinity=</varname> setting in unit files, see + <listitem><para>Configures the CPU affinity for the service manager as well as the default CPU + affinity for all forked off processes. Takes a list of CPU indices or ranges separated by either + whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a + dash. This option may be specified more than once, in which case the specified CPU affinity masks are + merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have + no effect. Individual services may override the CPU affinity for their processes with the + <varname>CPUAffinity=</varname> setting in unit files, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NUMAPolicy=</varname></term> + + <listitem><para>Configures the NUMA memory policy for the service manager and the default NUMA memory policy + for all forked off processes. Individual services may override the default policy with the + <varname>NUMAPolicy=</varname> setting in unit files, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NUMAMask=</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 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>, @@ -116,9 +139,9 @@ 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> @@ -126,8 +149,14 @@ 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> + <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> @@ -223,6 +252,16 @@ </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> <listitem><para>Sets the default accuracy of timer units. This @@ -239,13 +278,15 @@ <varlistentry> <term><varname>DefaultTimeoutStartSec=</varname></term> <term><varname>DefaultTimeoutStopSec=</varname></term> + <term><varname>DefaultTimeoutAbortSec=</varname></term> <term><varname>DefaultRestartSec=</varname></term> - <listitem><para>Configures the default timeouts for starting - and stopping of units, as well as the default time to sleep + <listitem><para>Configures the default timeouts for starting, + stopping and aborting of units, as well as the default time to sleep between automatic restarts of units, as configured per-unit in <varname>TimeoutStartSec=</varname>, - <varname>TimeoutStopSec=</varname> and + <varname>TimeoutStopSec=</varname>, + <varname>TimeoutAbortSec=</varname> and <varname>RestartSec=</varname> (for services, see <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details on the per-unit settings). Disabled by default, when @@ -255,7 +296,9 @@ <varname>TimeoutSec=</varname> value. <varname>DefaultTimeoutStartSec=</varname> and <varname>DefaultTimeoutStopSec=</varname> default to - 90s. <varname>DefaultRestartSec=</varname> defaults to + 90s. <varname>DefaultTimeoutAbortSec=</varname> is not set by default + so that all units fall back to <varname>TimeoutStopSec=</varname>. + <varname>DefaultRestartSec=</varname> defaults to 100ms.</para></listitem> </varlistentry> @@ -364,6 +407,17 @@ limits are only defaults for units, they are not applied to PID 1 itself.</para></listitem> </varlistentry> + + <varlistentry> + <term><varname>DefaultOOMPolicy=</varname></term> + + <listitem><para>Configure the default policy for reacting to processes being killed by the Linux + Out-Of-Memory (OOM) killer. This may be used to pick a global default for the per-unit + <varname>OOMPolicy=</varname> setting. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. Note that this default is not used for services that have <varname>Delegate=</varname> + turned on.</para></listitem> + </varlistentry> </variablelist> </refsect1> diff --git a/man/systemd-timedated.service.xml b/man/systemd-timedated.service.xml index 3626e8bc51..f981848cb2 100644 --- a/man/systemd-timedated.service.xml +++ b/man/systemd-timedated.service.xml @@ -31,7 +31,7 @@ <para><filename>systemd-timedated</filename> is a system service that may be used as a mechanism to change the system clock and - timezone, as well as to enable/disable NTP time synchronization. + timezone, as well as to enable/disable network time synchronization. <filename>systemd-timedated</filename> is automatically activated on request and terminates itself when it is unused.</para> @@ -46,25 +46,36 @@ </refsect1> <refsect1> - <title>Environment</title> - - <variablelist class='environment-variables'> - <varlistentry> - <term><varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname></term> - - <listitem><para>Colon-separated list of unit names of NTP client services. - If not set, then - <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> - is used. See the entries of NTP related commands of - <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> - for details about this.</para> - - <para>Example: - <programlisting>SYSTEMD_TIMEDATED_NTP_SERVICES=ntpd.service:chronyd.service:systemd-timesyncd.service</programlisting> - </para></listitem> - </varlistentry> - </variablelist> + <title>List of network time synchronization services</title> + + <para><command>systemd-timesyncd</command> will look for files with a <literal>.list</literal> extension + in <filename>ntp-units.d/</filename> directories. Each file is parsed as a list of unit names, one per + line. Empty lines and lines with comments (<literal>#</literal>) are ignored. Files are read from + <filename>/usr/lib/systemd/ntp-units.d/</filename> and the corresponding directories under + <filename>/etc/</filename>, <filename>/run/</filename>, <filename>/usr/local/lib/</filename>. Files in + <filename>/etc/</filename> override files with the same name in <filename>/run/</filename>, + <filename>/usr/local/lib/</filename>, and <filename>/usr/lib/</filename>. Files in + <filename>/run/</filename> override files with the same name under <filename>/usr/</filename>. Packages + should install their configuration files in <filename>/usr/lib/</filename> (distribution packages) or + <filename>/usr/local/lib/</filename> (local installs).</para> + + <example> + <title><filename>ntp-units.d/</filename> entry for <command>systemd-timesyncd</command></title> + <programlisting># /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list +systemd-timesyncd.service +</programlisting> + </example> + + <para>If the environment variable <varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname> is set, + <command>systemd-timesyncd</command> will parse the contents of that variable as a colon-separated list + of unit names. When set, this variable overrides the file-based list described above.</para> + + <example> + <title>An override that specifies that <command>chronyd</command> should be used if available</title> + <programlisting>SYSTEMD_TIMEDATED_NTP_SERVICES=chronyd.service:systemd-timesyncd.service</programlisting> + </example> </refsect1> + <refsect1> <title>See Also</title> <para> diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml index f05e5ea2e5..7720ef53fa 100644 --- a/man/systemd-tmpfiles.xml +++ b/man/systemd-tmpfiles.xml @@ -65,6 +65,22 @@ <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> are searched for a matching file and the file found that has the highest priority is executed.</para> + + <para>System services (<filename>systemd-tmpfiles-setup.service</filename>, + <filename>systemd-tmpfiles-setup-dev.service</filename>, + <filename>systemd-tmpfiles-clean.service</filename>) invoke <command>systemd-tmpfiles</command> to create + system files and to perform system wide cleanup. Those services read administrator-controlled + configuration files in <filename>tmpfiles.d/</filename> directories. User services + (<filename>systemd-tmpfiles-setup.service</filename>, + <filename>systemd-tmpfiles-clean.service</filename>) also invoke <command>systemd-tmpfiles</command>, but + it reads a separate set of files, which includes user-controlled files under + <filename>~/.config/user-tmpfiles.d/</filename> and <filename>~/.local/share/user-tmpfiles.d/</filename>, + and administrator-controller files under <filename>/usr/share/user-tmpfiles.d/</filename>. Users may use + this to create and clean up files under their control, but the system instance performs global cleanup + and is not influenced by user configuration. Note that this means a time-based cleanup configured in the + system instance, such as the one typically configured for <filename>/tmp</filename>, will thus also + affect files created by the user instance if they are placed in <filename>/tmp</filename>, even if the + user instance's time-based cleanup is turned off.</para> </refsect1> <refsect1> @@ -174,7 +190,7 @@ </variablelist> <para>It is possible to combine <option>--create</option>, <option>--clean</option>, and <option>--remove</option> - in one invocation (in which case removal and clean-up are executed before creation of new files). For example, + in one invocation (in which case removal and cleanup are executed before creation of new files). For example, during boot the following command line is executed to ensure that all temporary and volatile directories are removed and created according to the configuration file:</para> diff --git a/man/systemd-udev-settle.service.xml b/man/systemd-udev-settle.service.xml new file mode 100644 index 0000000000..3698bfaf19 --- /dev/null +++ b/man/systemd-udev-settle.service.xml @@ -0,0 +1,51 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<refentry id="systemd-udev-settle.service" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-udev-settle.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-udev-settle.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-udev-settle.service</refname> + <refpurpose>Wait for all pending udev events to be handled</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-udev-settle.service</filename></para> + </refsynopsisdiv> + + <refsect1><title>Description</title> + <para>This service calls <command>udevadm settle</command> to wait until all events that have been queued + by <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> have been + processed. It is a crude way to wait until "all" hardware has been discovered. Services may pull in this + service and order themselves after it to wait for the udev queue to be empty.</para> + + <para><emphasis>Using this service is not recommended.</emphasis> There can be no guarantee that hardware + is fully discovered at any specific time, because the kernel does hardware detection asynchronously, and + certain buses and devices take a very long time to become ready, and also additional hardware may be + plugged in at any time. Instead, services should subscribe to udev events and react to any new hardware as + it is discovered. Services that, based on configuration, expect certain devices to appear, may warn or + report failure after a timeout. This timeout should be tailored to the hardware type. Waiting for + <filename>systemd-udev-settle.service</filename> usually slows boot significantly, because it means waiting + for all unrelated events too.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-udevd.service.xml b/man/systemd-udevd.service.xml index cf8087ccb3..c267bb2b11 100644 --- a/man/systemd-udevd.service.xml +++ b/man/systemd-udevd.service.xml @@ -171,15 +171,12 @@ <term><varname>net.naming-scheme=</varname></term> <listitem> <para>Network interfaces are renamed to give them predictable names when possible (unless - <varname>net.ifnames=0</varname> is specified, see above). The names are derived from various - device metadata fields. Newer versions of <filename>systemd-udevd.service</filename> take more of - these fields into account, improving (and thus possibly changing) the names used for the same - devices. With this kernel command line option it is possible to pick a specific version of this - algorithm. It expects a naming scheme identifier as argument. Currently the following identifiers - are known: <literal>v238</literal>, <literal>v239</literal>, <literal>v240</literal> which each - implement the naming scheme that was the default in the indicated systemd version. In addition, - <literal>latest</literal> may be used to designate the latest scheme known (to this particular - version of <filename>systemd-udevd.service</filename>).</para> + <varname>net.ifnames=0</varname> is specified, see above). With this kernel command line option it + is possible to pick a specific version of this algorithm and override the default chosen at + compilation time. Expects one of the naming scheme identifiers listed in + <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + or <literal>latest</literal> to select the latest scheme known (to this particular version of + <filename>systemd-udevd.service</filename>).</para> <para>Note that selecting a specific scheme is not sufficient to fully stabilize interface naming: the naming is generally derived from driver attributes exposed by the kernel. As the kernel is @@ -188,9 +185,8 @@ </listitem> </varlistentry> </variablelist> - <!-- when adding entries here, consider also adding them - in kernel-command-line.xml --> - </refsect1> + <!-- when adding entries here, consider also adding them in kernel-command-line.xml --> + </refsect1> <refsect1> <title>See Also</title> diff --git a/man/systemd-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml index 268e69c0e7..7e76383720 100644 --- a/man/systemd-vconsole-setup.service.xml +++ b/man/systemd-vconsole-setup.service.xml @@ -33,7 +33,7 @@ <title>Description</title> <para><filename>systemd-vconsole-setup</filename> sets up and configures either all virtual consoles, or — if the - optional <replaceable>TTY</replaceable> parameter is provided — a specific one. When the system is booting up it's + optional <replaceable>TTY</replaceable> parameter is provided — a specific one. When the system is booting up, it's called by <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry> during VT console subsystem initialization. Also, <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> invokes diff --git a/man/systemd-veritysetup-generator.xml b/man/systemd-veritysetup-generator.xml index 305dda4b8e..bcacd59cf9 100644 --- a/man/systemd-veritysetup-generator.xml +++ b/man/systemd-veritysetup-generator.xml @@ -28,12 +28,12 @@ <title>Description</title> <para><filename>systemd-veritysetup-generator</filename> is a generator that translates kernel command line options - configuring integrity protected block devices (verity) into native systemd units early at boot and when + configuring integrity-protected block devices (verity) into native systemd units early at boot and when configuration of the system manager is reloaded. This will create <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> units as necessary.</para> - <para>Currently, only a single verity device may be se up with this generator, backing the root file system of the + <para>Currently, only a single verity device may be set up with this generator, backing the root file system of the OS.</para> <para><filename>systemd-veritysetup-generator</filename> implements @@ -61,7 +61,7 @@ <term><varname>roothash=</varname></term> <listitem><para>Takes a root hash value for the root file system. Expects a hash value formatted in hexadecimal - characters, of the appropriate length (i.e. most likely 256 bit/64 characters, or longer). If not specified via + characters of the appropriate length (i.e. most likely 256 bit/64 characters, or longer). If not specified via <varname>systemd.verity_root_data=</varname> and <varname>systemd.verity_root_hash=</varname>, the hash and data devices to use are automatically derived from the specified hash value. Specifically, the data partition device is looked for under a GPT partition UUID derived from the first 128bit of the root hash, the hash @@ -75,8 +75,8 @@ <term><varname>systemd.verity_root_data=</varname></term> <term><varname>systemd.verity_root_hash=</varname></term> - <listitem><para>These two settings take block device paths as arguments, and may be use to explicitly configure - the data partition and hash partition to use for setting up the integrity protection for the root file + <listitem><para>These two settings take block device paths as arguments and may be used to explicitly + configure the data partition and hash partition to use for setting up the integrity protection for the root file system. If not specified, these paths are automatically derived from the <varname>roothash=</varname> argument (see above).</para></listitem> </varlistentry> diff --git a/man/systemd.automount.xml b/man/systemd.automount.xml index 48deb0220e..75302e07e9 100644 --- a/man/systemd.automount.xml +++ b/man/systemd.automount.xml @@ -35,9 +35,9 @@ 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 [Unit] and - [Install] sections. The automount specific configuration options - are configured in the [Automount] section.</para> + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. The automount specific configuration options + are configured in the <literal>[Automount]</literal> section.</para> <para>Automount units must be named after the automount directories they control. Example: the automount point <filename noindex='true'>/home/lennart</filename> must be configured in a unit file diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index ef1c392bc9..6d65175e16 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -180,6 +180,13 @@ is used. In this case the source path refers to a path on the host file system, while the destination path refers to a path below the root directory of the unit.</para> + <para>Note that the destination directory must exist or systemd must be able to create it. Thus, it + is not possible to use those options for mount points nested underneath paths specified in + <varname>InaccessiblePaths=</varname>, or under <filename>/home/</filename> and other protected + directories if <varname>ProtectHome=yes</varname> is + specified. <varname>TemporaryFileSystem=</varname> with <literal>:ro</literal> or + <varname>ProtectHome=tmpfs</varname> should be used instead.</para> + <xi:include href="system-only.xml" xpointer="singular"/></listitem> </varlistentry> @@ -219,7 +226,12 @@ specified user and group must have been created statically in the user database no later than the moment the service is started, for example using the <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> facility, which - is applied at boot or package install time.</para></listitem> + is applied at boot or package install time.</para> + + <para>If the <varname>User=</varname> setting is used the supplementary group list is initialized + from the specified user's default group list, as defined in the system's user and group + database. Additional groups may be configured through the <varname>SupplementaryGroups=</varname> + setting (see below).</para></listitem> </varlistentry> <varlistentry> @@ -247,14 +259,15 @@ part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories. If <varname>DynamicUser=</varname> is enabled, - <varname>RemoveIPC=</varname>, <varname>PrivateTmp=</varname> are implied. This ensures that the - lifetime of IPC objects and temporary files created by the executed processes is bound to the runtime - of the service, and hence the lifetime of the dynamic user/group. Since <filename>/tmp</filename> and - <filename>/var/tmp</filename> are usually the only world-writable directories on a system this - ensures that a unit making use of dynamic user/group allocation cannot leave files around after unit - termination. Furthermore <varname>NoNewPrivileges=</varname> and <varname>RestrictSUIDSGID=</varname> - are implicitly enabled to ensure that processes invoked cannot take benefit or create SUID/SGID files - or directories. Moreover <varname>ProtectSystem=strict</varname> and + <varname>RemoveIPC=</varname> and <varname>PrivateTmp=</varname> are implied (and cannot be turned + off). This ensures that the lifetime of IPC objects and temporary files created by the executed + processes is bound to the runtime of the service, and hence the lifetime of the dynamic + user/group. Since <filename>/tmp/</filename> and <filename>/var/tmp/</filename> are usually the only + world-writable directories on a system this ensures that a unit making use of dynamic user/group + allocation cannot leave files around after unit termination. Furthermore + <varname>NoNewPrivileges=</varname> and <varname>RestrictSUIDSGID=</varname> are implicitly enabled + (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID + files or directories. Moreover <varname>ProtectSystem=strict</varname> and <varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to arbitrary file system locations. In order to allow the service to write to certain directories, they have to be whitelisted using <varname>ReadWritePaths=</varname>, but care must be taken so that @@ -651,11 +664,17 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting> <varlistentry> <term><varname>OOMScoreAdjust=</varname></term> - <listitem><para>Sets the adjustment level for the Out-Of-Memory killer for executed processes. Takes an integer - between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory - pressure very likely). See <ulink - url="https://www.kernel.org/doc/Documentation/filesystems/proc.txt">proc.txt</ulink> for - details.</para></listitem> + <listitem><para>Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for + executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit) + and 1000 (to make killing of processes of this unit under memory pressure very likely). See <ulink + url="https://www.kernel.org/doc/Documentation/filesystems/proc.txt">proc.txt</ulink> for details. If + not specified defaults to the OOM score adjustment level of the service manager itself, which is + normally at 0.</para> + + <para>Use the <varname>OOMPolicy=</varname> setting of service units to configure how the service + manager shall react to the kernel OOM killer terminating a process of the service. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> </varlistentry> <varlistentry> @@ -741,7 +760,7 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting> <listitem><para>Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges separated by either whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated - by a dash. This option may be specified more than once, in which case the specified CPU affinity masks are + by a dash. This option may be specified more than once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have no effect. See <citerefentry><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for @@ -749,6 +768,28 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting> </varlistentry> <varlistentry> + <term><varname>NUMAPolicy=</varname></term> + + <listitem><para>Controls the NUMA memory policy of the executed processes. Takes a policy type, one of: + <option>default</option>, <option>preferred</option>, <option>bind</option>, <option>interleave</option> and + <option>local</option>. A list of NUMA nodes that should be associated with the policy must be specified + in <varname>NUMAMask=</varname>. For more details on each policy please see, + <citerefentry><refentrytitle>set_mempolicy</refentrytitle><manvolnum>2</manvolnum></citerefentry>. For overall + overview of NUMA support in Linux see, + <citerefentry><refentrytitle>numa</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NUMAMask=</varname></term> + + <listitem><para>Controls the NUMA node list which will be applied alongside with selected NUMA policy. + Takes a list of NUMA nodes and has the same syntax as a list of CPUs for <varname>CPUAffinity=</varname> + option. Note that the list of NUMA nodes is not required for <option>default</option> and <option>local</option> + policies and for <option>preferred</option> policy we expect a single NUMA node.</para></listitem> + </varlistentry> + + <varlistentry> <term><varname>IOSchedulingClass=</varname></term> <listitem><para>Sets the I/O scheduling class for executed processes. Takes an integer between 0 and 3 or one @@ -816,23 +857,25 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting> <term><varname>ProtectHome=</varname></term> <listitem><para>Takes a boolean argument or the special values <literal>read-only</literal> or - <literal>tmpfs</literal>. If true, the directories <filename>/home</filename>, <filename>/root</filename> and - <filename>/run/user</filename> are made inaccessible and empty for processes invoked by this unit. If set to - <literal>read-only</literal>, the three directories are made read-only instead. If set to <literal>tmpfs</literal>, - temporary file systems are mounted on the three directories in read-only mode. The value <literal>tmpfs</literal> - is useful to hide home directories not relevant to the processes invoked by the unit, while necessary directories - are still visible by combining with <varname>BindPaths=</varname> or <varname>BindReadOnlyPaths=</varname>.</para> + <literal>tmpfs</literal>. If true, the directories <filename>/home</filename>, + <filename>/root</filename>, and <filename>/run/user</filename> are made inaccessible and empty for + processes invoked by this unit. If set to <literal>read-only</literal>, the three directories are + made read-only instead. If set to <literal>tmpfs</literal>, temporary file systems are mounted on the + three directories in read-only mode. The value <literal>tmpfs</literal> is useful to hide home + directories not relevant to the processes invoked by the unit, while still allowing necessary + directories to be made visible when listed in <varname>BindPaths=</varname> or + <varname>BindReadOnlyPaths=</varname>.</para> <para>Setting this to <literal>yes</literal> is mostly equivalent to set the three directories in <varname>InaccessiblePaths=</varname>. Similarly, <literal>read-only</literal> is mostly equivalent to <varname>ReadOnlyPaths=</varname>, and <literal>tmpfs</literal> is mostly equivalent to - <varname>TemporaryFileSystem=</varname>.</para> + <varname>TemporaryFileSystem=</varname> with <literal>:ro</literal>.</para> - <para> It is recommended to enable this setting for all long-running services (in particular network-facing - ones), to ensure they cannot get access to private user data, unless the services actually require access to - the user's private data. This setting is implied if <varname>DynamicUser=</varname> is set. This setting cannot - ensure protection in all cases. In general it has the same limitations as <varname>ReadOnlyPaths=</varname>, - see below.</para> + <para>It is recommended to enable this setting for all long-running services (in particular + network-facing ones), to ensure they cannot get access to private user data, unless the services + actually require access to the user's private data. This setting is implied if + <varname>DynamicUser=</varname> is set. This setting cannot ensure protection in all cases. In + general it has the same limitations as <varname>ReadOnlyPaths=</varname>, see below.</para> <xi:include href="system-only.xml" xpointer="singular"/></listitem> </varlistentry> @@ -934,6 +977,20 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting> configuration or lifetime guarantees, please consider using <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + <para>The directories defined by these options are always created under the standard paths used by systemd + (<filename>/var</filename>, <filename>/run</filename>, <filename>/etc</filename>, …). If the service needs + directories in a different location, a different mechanism has to be used to create them.</para> + + <para><citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> provides + functionality that overlaps with these options. Using these options is recommended, because the lifetime of + the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the + <filename>tmpfiles.d</filename> configuration is executed before the unit is started.</para> + + <para>To remove any of the directories created by these settings, use the <command>systemctl clean + …</command> command on the relevant units, see + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para> + <para>Example: if a system service unit has the following, <programlisting>RuntimeDirectory=foo/bar baz</programlisting> the service manager creates <filename>/run/foo</filename> (if it does not exist), @@ -1061,7 +1118,7 @@ StateDirectory=aaa/bbb ccc</programlisting> <para>This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary files or directories can be still accessed by combining with <varname>BindPaths=</varname> or - <varname>BindReadOnlyPaths=</varname>. See the example below.</para> + <varname>BindReadOnlyPaths=</varname>:</para> <para>Example: if a unit has the following, <programlisting>TemporaryFileSystem=/var:ro @@ -1303,7 +1360,7 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting> running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=nobody</varname>), <varname>NoNewPrivileges=yes</varname> is implied. By default, no restrictions apply, all address families are accessible to processes. If assigned the empty string, any - previous address familiy restriction changes are undone. This setting does not affect commands prefixed with + previous address family restriction changes are undone. This setting does not affect commands prefixed with <literal>+</literal>.</para> <para>Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive @@ -1516,24 +1573,29 @@ RestrictNamespaces=~cgroup net</programlisting> <varlistentry> <term><varname>SystemCallFilter=</varname></term> - <listitem><para>Takes a space-separated list of system call names. If this setting is used, all system calls - executed by the unit processes except for the listed ones will result in immediate process termination with the - <constant>SIGSYS</constant> signal (whitelisting). If the first character of the list is <literal>~</literal>, - the effect is inverted: only the listed system calls will result in immediate process termination - (blacklisting). Blacklisted system calls and system call groups may optionally be suffixed with a colon - (<literal>:</literal>) and <literal>errno</literal> error number (between 0 and 4095) or errno name such as - <constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>. This value will be - returned when a blacklisted system call is triggered, instead of terminating the processes immediately. This - value takes precedence over the one given in <varname>SystemCallErrorNumber=</varname>. If running in user - mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting - <varname>User=nobody</varname>), <varname>NoNewPrivileges=yes</varname> is implied. This feature makes use of - the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful for enforcing a - minimal sandboxing environment. Note that the <function>execve</function>, <function>exit</function>, - <function>exit_group</function>, <function>getrlimit</function>, <function>rt_sigreturn</function>, - <function>sigreturn</function> system calls and the system calls for querying time and sleeping are implicitly - whitelisted and do not need to be listed explicitly. This option may be specified more than once, in which case - the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will - have no effect. This does not affect commands prefixed with <literal>+</literal>.</para> + <listitem><para>Takes a space-separated list of system call names. If this setting is used, all + system calls executed by the unit processes except for the listed ones will result in immediate + process termination with the <constant>SIGSYS</constant> signal (whitelisting). (See + <varname>SystemCallErrorNumber=</varname> below for changing the default action). If the first + character of the list is <literal>~</literal>, the effect is inverted: only the listed system calls + will result in immediate process termination (blacklisting). Blacklisted system calls and system call + groups may optionally be suffixed with a colon (<literal>:</literal>) and <literal>errno</literal> + error number (between 0 and 4095) or errno name such as <constant>EPERM</constant>, + <constant>EACCES</constant> or <constant>EUCLEAN</constant> (see <citerefentry + project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> for a + full list). This value will be returned when a blacklisted system call is triggered, instead of + terminating the processes immediately. This value takes precedence over the one given in + <varname>SystemCallErrorNumber=</varname>, see below. If running in user mode, or in system mode, + but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting + <varname>User=nobody</varname>), <varname>NoNewPrivileges=yes</varname> is implied. This feature + makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful + for enforcing a minimal sandboxing environment. Note that the <function>execve</function>, + <function>exit</function>, <function>exit_group</function>, <function>getrlimit</function>, + <function>rt_sigreturn</function>, <function>sigreturn</function> system calls and the system calls + for querying time and sleeping are implicitly whitelisted and do not need to be listed + explicitly. This option may be specified more than once, in which case the filter masks are + merged. If the empty string is assigned, the filter is reset, all prior assignments will have no + effect. This does not affect commands prefixed with <literal>+</literal>.</para> <para>Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this @@ -1693,6 +1755,22 @@ RestrictNamespaces=~cgroup net</programlisting> SystemCallFilter=@system-service SystemCallErrorNumber=EPERM</programlisting> + <para>Note that various kernel system calls are defined redundantly: there are multiple system calls + for executing the same operation. For example, the <function>pidfd_send_signal()</function> system + call may be used to execute operations similar to what can be done with the older + <function>kill()</function> system call, hence blocking the latter without the former only provides + weak protection. Since new system calls are added regularly to the kernel as development progresses, + keeping system call blacklists comprehensive requires constant work. It is thus recommended to use + whitelisting instead, which offers the benefit that new system calls are by default implicitly + blocked until the whitelist is updated.</para> + + <para>Also note that a number of system calls are required to be accessible for the dynamic linker to + work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF + binaries, which is how most distributions build packaged programs). This means that blocking these + system calls (which include <function>open()</function>, <function>openat()</function> or + <function>mmap()</function>) will make most programs typically shipped with generic distributions + unusable.</para> + <para>It is recommended to combine the file system namespacing related options with <varname>SystemCallFilter=~@mount</varname>, in order to prohibit the unit's processes to undo the mappings. Specifically these are the options <varname>PrivateTmp=</varname>, @@ -1705,11 +1783,13 @@ SystemCallErrorNumber=EPERM</programlisting> <varlistentry> <term><varname>SystemCallErrorNumber=</varname></term> - <listitem><para>Takes an <literal>errno</literal> error number (between 1 and 4095) or errno name such as - <constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>, to return when the - system call filter configured with <varname>SystemCallFilter=</varname> is triggered, instead of terminating - the process immediately. When this setting is not used, or when the empty string is assigned, the process will - be terminated immediately when the filter is triggered.</para></listitem> + <listitem><para>Takes an <literal>errno</literal> error number (between 1 and 4095) or errno name + such as <constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>, to + return when the system call filter configured with <varname>SystemCallFilter=</varname> is triggered, + instead of terminating the process immediately. See <citerefentry + project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> for a + full list of error codes. When this setting is not used, or when the empty string is assigned, the + process will be terminated immediately when the filter is triggered.</para></listitem> </varlistentry> <varlistentry> @@ -1927,19 +2007,19 @@ SystemCallErrorNumber=EPERM</programlisting> <para>Note that services which specify <option>DefaultDependencies=no</option> and use <varname>StandardInput=</varname> or <varname>StandardOutput=</varname> with <option>tty</option>/<option>tty-force</option>/<option>tty-fail</option>, should specify - <option>After=systemd-vconsole-setup.service</option>, to make sure that the tty intialization is + <option>After=systemd-vconsole-setup.service</option>, to make sure that the tty initialization is finished before they start.</para></listitem> </varlistentry> <varlistentry> <term><varname>StandardOutput=</varname></term> - <listitem><para>Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one - of <option>inherit</option>, <option>null</option>, <option>tty</option>, <option>journal</option>, - <option>syslog</option>, <option>kmsg</option>, <option>journal+console</option>, - <option>syslog+console</option>, <option>kmsg+console</option>, - <option>file:<replaceable>path</replaceable></option>, <option>append:<replaceable>path</replaceable></option>, - <option>socket</option> or <option>fd:<replaceable>name</replaceable></option>.</para> + <listitem><para>Controls where file descriptor 1 (STDOUT) of the executed processes is connected + to. Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>, + <option>journal</option>, <option>kmsg</option>, <option>journal+console</option>, + <option>kmsg+console</option>, <option>file:<replaceable>path</replaceable></option>, + <option>append:<replaceable>path</replaceable></option>, <option>socket</option> or + <option>fd:<replaceable>name</replaceable></option>.</para> <para><option>inherit</option> duplicates the file descriptor of standard input for standard output.</para> @@ -1950,23 +2030,20 @@ SystemCallErrorNumber=EPERM</programlisting> see below). If the TTY is used for output only, the executed process will not become the controlling process of the terminal, and will not fail or wait for other processes to release the terminal.</para> - <para><option>journal</option> connects standard output with the journal which is accessible via - <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Note that - everything that is written to syslog or kmsg (see below) is implicitly stored in the journal as well, the - specific two options listed below are hence supersets of this one.</para> - - <para><option>syslog</option> connects standard output to the <citerefentry - project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> system syslog - service, in addition to the journal. Note that the journal daemon is usually configured to forward everything - it receives to syslog anyway, in which case this option is no different from <option>journal</option>.</para> + <para><option>journal</option> connects standard output with the journal, which is accessible via + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Note + that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the + specific option listed below is hence a superset of this one. (Also note that any external, + additional syslog daemons receive their log data from the journal, too, hence this is the option to + use when logging shall be processed with such a daemon.)</para> <para><option>kmsg</option> connects standard output with the kernel log buffer which is accessible via <citerefentry project='man-pages'><refentrytitle>dmesg</refentrytitle><manvolnum>1</manvolnum></citerefentry>, in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which case this option is no different from <option>journal</option>.</para> - <para><option>journal+console</option>, <option>syslog+console</option> and <option>kmsg+console</option> work - in a similar way as the three options above but copy the output to the system console as well.</para> + <para><option>journal+console</option> and <option>kmsg+console</option> work in a similar way as the + two options above but copy the output to the system console as well.</para> <para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file system object to standard output. The semantics are similar to the same option of @@ -1995,13 +2072,14 @@ SystemCallErrorNumber=EPERM</programlisting> <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more details about named descriptors and their ordering.</para> - <para>If the standard output (or error output, see below) of a unit is connected to the journal, syslog or the - kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname> on - <filename>systemd-journald.socket</filename> (also see the "Implicit Dependencies" section above). Also note - that in this case stdout (or stderr, see below) will be an <constant>AF_UNIX</constant> stream socket, and not - a pipe or FIFO that can be re-opened. This means when executing shell scripts the construct <command>echo - "hello" > /dev/stderr</command> for writing text to stderr will not work. To mitigate this use the construct - <command>echo "hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para> + <para>If the standard output (or error output, see below) of a unit is connected to the journal or + the kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname> + on <filename>systemd-journald.socket</filename> (also see the "Implicit Dependencies" section + above). Also note that in this case stdout (or stderr, see below) will be an + <constant>AF_UNIX</constant> stream socket, and not a pipe or FIFO that can be re-opened. This means + when executing shell scripts the construct <command>echo "hello" > /dev/stderr</command> for + writing text to stderr will not work. To mitigate this use the construct <command>echo "hello" + >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para> <para>This setting defaults to the value set with <varname>DefaultStandardOutput=</varname> in <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, which @@ -2088,16 +2166,17 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <varlistentry> <term><varname>LogExtraFields=</varname></term> - <listitem><para>Configures additional log metadata fields to include in all log records generated by processes - associated with this unit. This setting takes one or more journal field assignments in the format - <literal>FIELD=VALUE</literal> separated by whitespace. See - <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> for - details on the journal field concept. Even though the underlying journal implementation permits binary field - values, this setting accepts only valid UTF-8 values. To include space characters in a journal field value, - enclose the assignment in double quotes ("). The usual specifiers are expanded in all assignments (see - below). Note that this setting is not only useful for attaching additional metadata to log records of a unit, - but given that all fields and values are indexed may also be used to implement cross-unit log record - matching. Assign an empty string to reset the list.</para></listitem> + <listitem><para>Configures additional log metadata fields to include in all log records generated by + processes associated with this unit. This setting takes one or more journal field assignments in the + format <literal>FIELD=VALUE</literal> separated by whitespace. See + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details on the journal field concept. Even though the underlying journal implementation permits + binary field values, this setting accepts only valid UTF-8 values. To include space characters in a + journal field value, enclose the assignment in double quotes ("). <!-- " fake closing quote for emacs--> + The usual specifiers are expanded in all assignments (see below). Note that this setting is not only + useful for attaching additional metadata to log records of a unit, but given that all fields and + values are indexed may also be used to implement cross-unit log record matching. Assign an empty + string to reset the list.</para></listitem> </varlistentry> <varlistentry> @@ -2119,12 +2198,12 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <varlistentry> <term><varname>SyslogIdentifier=</varname></term> - <listitem><para>Sets the process name ("<command>syslog</command> tag") to prefix log lines sent to the logging - system or the kernel log buffer with. If not set, defaults to the process name of the executed process. This - option is only useful when <varname>StandardOutput=</varname> or <varname>StandardError=</varname> are set to - <option>journal</option>, <option>syslog</option> or <option>kmsg</option> (or to the same settings in - combination with <option>+console</option>) and only applies to log messages written to stdout or - stderr.</para></listitem> + <listitem><para>Sets the process name ("<command>syslog</command> tag") to prefix log lines sent to + the logging system or the kernel log buffer with. If not set, defaults to the process name of the + executed process. This option is only useful when <varname>StandardOutput=</varname> or + <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to + the same settings in combination with <option>+console</option>) and only applies to log messages + written to stdout or stderr.</para></listitem> </varlistentry> <varlistentry> @@ -2135,12 +2214,13 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <option>auth</option>, <option>syslog</option>, <option>lpr</option>, <option>news</option>, <option>uucp</option>, <option>cron</option>, <option>authpriv</option>, <option>ftp</option>, <option>local0</option>, <option>local1</option>, <option>local2</option>, <option>local3</option>, - <option>local4</option>, <option>local5</option>, <option>local6</option> or <option>local7</option>. See - <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> - for details. This option is only useful when <varname>StandardOutput=</varname> or - <varname>StandardError=</varname> are set to <option>journal</option>, <option>syslog</option> or - <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies - to log messages written to stdout or stderr. Defaults to <option>daemon</option>.</para></listitem> + <option>local4</option>, <option>local5</option>, <option>local6</option> or + <option>local7</option>. See <citerefentry + project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details. This option is only useful when <varname>StandardOutput=</varname> or + <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to + the same settings in combination with <option>+console</option>), and only applies to log messages + written to stdout or stderr. Defaults to <option>daemon</option>.</para></listitem> </varlistentry> <varlistentry> @@ -2152,7 +2232,7 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <option>debug</option>. See <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for details. This option is only useful when <varname>StandardOutput=</varname> or - <varname>StandardError=</varname> are set to <option>journal</option>, <option>syslog</option> or + <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies to log messages written to stdout or stderr. Note that individual lines output by executed processes may be prefixed with a different log level which can be used to override the default log level specified here. The @@ -2165,12 +2245,13 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <term><varname>SyslogLevelPrefix=</varname></term> <listitem><para>Takes a boolean argument. If true and <varname>StandardOutput=</varname> or - <varname>StandardError=</varname> are set to <option>journal</option>, <option>syslog</option> or - <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), log lines - written by the executed process that are prefixed with a log level will be processed with this log level set - but the prefix removed. If set to false, the interpretation of these prefixes is disabled and the logged lines - are passed on as-is. This only applies to log messages written to stdout or stderr. For details about this - prefixing see <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to + the same settings in combination with <option>+console</option>), log lines written by the executed + process that are prefixed with a log level will be processed with this log level set but the prefix + removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are + passed on as-is. This only applies to log messages written to stdout or stderr. For details about + this prefixing see + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Defaults to true.</para></listitem> </varlistentry> @@ -2289,10 +2370,16 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <varlistentry> <term><varname>$PATH</varname></term> - <listitem><para>Colon-separated list of directories to use - when launching executables. systemd uses a fixed value of - <filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename>:<filename>/sbin</filename>:<filename>/bin</filename>. - </para></listitem> + <listitem><para>Colon-separated list of directories to use when launching + executables. <command>systemd</command> uses a fixed value of + <literal><filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename></literal> + in the system manager. When compiled for systems with "unmerged /usr" (<filename>/bin</filename> is + not a symlink to <filename>/usr/bin</filename>), + <literal>:<filename>/sbin</filename>:<filename>/bin</filename></literal> is appended. In case of the + the user manager, each <filename>bin/</filename> and <filename>sbin/</filename> pair is switched, so + that programs from <filename>/usr/bin</filename> have higher priority than programs from + <filename>/usr/sbin</filename>, etc. It is recommended to not rely on this in any way, and have only + one program with a given name in <varname>$PATH</varname>.</para></listitem> </varlistentry> <varlistentry> @@ -2652,8 +2739,7 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy </table> <para>The following service exit codes are defined by the <ulink - url="https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB specification - </ulink>. + url="https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB specification</ulink>. </para> <table> @@ -2916,6 +3002,12 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy <entry><constant>EXIT_CONFIGURATION_DIRECTORY</constant></entry> <entry>Failed to set up unit's configuration directory. See <varname>ConfigurationDirectory=</varname> above.</entry> </row> + <row> + <entry>242</entry> + <entry><constant>EXIT_NUMA_POLICY</constant></entry> + <entry>Failed to set up unit's NUMA memory policy. See <varname>NUMAPolicy=</varname> and <varname>NUMAMask=</varname>above.</entry> + </row> + </tbody> </tgroup> </table> diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml index 960b2ec633..c11ec050e5 100644 --- a/man/systemd.journal-fields.xml +++ b/man/systemd.journal-fields.xml @@ -104,6 +104,11 @@ usually derived from glibc's <varname>program_invocation_short_name</varname> variable, see <citerefentry project='die-net'><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para> + <para>Note that the journal service does not validate the values of any structured + journal fields whose name is not prefixed with an underscore, and this includes any + syslog related fields such as these. Hence, applications that supply a facility, PID, + or log level are expected to do so properly formatted, i.e. as numeric integers formatted + as decimal strings.</para> </listitem> </varlistentry> @@ -183,6 +188,7 @@ <term><varname>_SYSTEMD_SLICE=</varname></term> <term><varname>_SYSTEMD_UNIT=</varname></term> <term><varname>_SYSTEMD_USER_UNIT=</varname></term> + <term><varname>_SYSTEMD_USER_SLICE=</varname></term> <term><varname>_SYSTEMD_SESSION=</varname></term> <term><varname>_SYSTEMD_OWNER_UID=</varname></term> diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml index 1f9d622ce9..2c6fea7493 100644 --- a/man/systemd.kill.xml +++ b/man/systemd.kill.xml @@ -79,7 +79,7 @@ signal (see below) is sent to all remaining processes of the unit's control group. If set to <option>none</option>, no process is killed. In this case, only the stop command will be - executed on unit stop, but no process be killed otherwise. + executed on unit stop, but no process will be killed otherwise. Processes remaining alive after stop are left in their control group and the control group continues to exist after stop unless it is empty.</para> diff --git a/man/systemd.link.xml b/man/systemd.link.xml index af9799e8c0..7ea9a71107 100644 --- a/man/systemd.link.xml +++ b/man/systemd.link.xml @@ -60,8 +60,13 @@ <refsect1> <title>[Match] Section Options</title> - <para>A link file is said to match a device if each of the entries in the [Match] section matches, or if - the section is empty. The following keys are accepted:</para> + <para>A link file is said to match a device if all matches specified by the + <literal>[Match]</literal> section are satisfied. When a link file does not contain valid settings + in <literal>[Match]</literal> section, then the file will match all devices and + <command>systemd-udevd</command> warns about that. Hint: to avoid the warning and to make it clear + that all interfaces shall be matched, add the following: + <programlisting>OriginalName=*</programlisting> + The following keys are accepted:</para> <variablelist class='network-directives'> <varlistentry> @@ -98,7 +103,7 @@ <term><varname>Driver=</varname></term> <listitem> <para>A whitespace-separated list of shell-style globs matching the driver currently bound to the - device, as exposed by the udev property <varname>DRIVER</varname> of its parent device, or if that + device, as exposed by the udev property <varname>ID_NET_DRIVER</varname> of its parent device, or if that is not set, the driver as exposed by <command>ethtool -i</command> of the device itself.</para> </listitem> </varlistentry> @@ -111,6 +116,21 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>Property=</varname></term> + <listitem> + <para>A whitespace-separated list of udev property name with its value after a equal + (<literal>=</literal>). If multiple properties are specified, the test results are ANDed. + If the list is prefixed with a "!", the test is inverted. If a value contains white + spaces, then please quote whole key and value pair. If a value contains quotation, then + please escape the quotation with <literal>\</literal>.</para> + + <para>Example: if a .link file has the following: + <programlisting>Property=ID_MODEL_ID=9999 "ID_VENDOR_FROM_DATABASE=vendor name" "KEY=with \"quotation\""</programlisting> + then, the .link file matches only when an interface has all the above three properties. + </para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>Host=</varname></term> <listitem> <para>Matches against the hostname or machine ID of the host. See <varname>ConditionHost=</varname> in @@ -273,6 +293,7 @@ <para>The name is set based on information given by the firmware for on-board devices, as exported by the udev property <varname>ID_NET_NAME_ONBOARD</varname>. + See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>. </para> </listitem> </varlistentry> @@ -282,6 +303,7 @@ <para>The name is set based on information given by the firmware for hot-plug devices, as exported by the udev property <varname>ID_NET_NAME_SLOT</varname>. + See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>. </para> </listitem> </varlistentry> @@ -290,7 +312,9 @@ <listitem> <para>The name is set based on the device's physical location, as exported by the udev property - <varname>ID_NET_NAME_PATH</varname>.</para> + <varname>ID_NET_NAME_PATH</varname>. + See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> </listitem> </varlistentry> <varlistentry> @@ -298,7 +322,9 @@ <listitem> <para>The name is set based on the device's persistent MAC address, as exported by the udev property - <varname>ID_NET_NAME_MAC</varname>.</para> + <varname>ID_NET_NAME_MAC</varname>. + See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> </listitem> </varlistentry> <varlistentry> diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml index d0ccd39e38..a72a33240d 100644 --- a/man/systemd.mount.xml +++ b/man/systemd.mount.xml @@ -34,9 +34,9 @@ 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 [Unit] and - [Install] sections. The mount specific configuration options are - configured in the [Mount] section.</para> + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. The mount specific configuration options are + configured in the <literal>[Mount]</literal> section.</para> <para>Additional options are listed in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, @@ -182,7 +182,7 @@ mount options are understood by systemd which influence how dependencies are created for mount points. systemd will create a dependency of type <varname>Wants=</varname> or - <option>Requires</option> (see option <option>nofail</option> + <option>Requires=</option> (see option <option>nofail</option> below), from either <filename>local-fs.target</filename> or <filename>remote-fs.target</filename>, depending whether the file system is local or remote.</para> @@ -312,7 +312,7 @@ <listitem><para>The file system will be initialized on the device. If the device is not "empty", i.e. it contains any signature, the operation will be skipped. It is hence expected that this option - remains set even after the device has been initalized.</para> + remains set even after the device has been initialized.</para> <para>Note that this option can only be used in <filename>/etc/fstab</filename>, and will be ignored when part of the diff --git a/man/systemd.net-naming-scheme.xml b/man/systemd.net-naming-scheme.xml new file mode 100644 index 0000000000..91ad57df03 --- /dev/null +++ b/man/systemd.net-naming-scheme.xml @@ -0,0 +1,436 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<refentry id="systemd.net-naming-scheme"> + <refentryinfo> + <title>systemd.net-naming-scheme</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.net-naming-scheme</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.net-naming-scheme</refname> + <refpurpose>Network device naming schemes</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>Network interfaces names and MAC addresses may be generated based on certain stable interface + attributes. This is possible when there is enough information about the device to generate those + attributes and the use of this information is configured. This page describes interface naming, i.e. what + possible names may be generated. Those names are generated by the + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + builtin <command>net_id</command> and exported as udev properties + (<varname>ID_NET_NAME_ONBOARD=</varname>, <varname>ID_NET_LABEL_ONBOARD=</varname>, + <varname>ID_NET_NAME_PATH=</varname>, <varname>ID_NET_NAME_SLOT=</varname>).</para> + + <para>Names and MAC addresses are derived from various stable device metadata attributes. Newer versions + of udev take more of these attributes into account, improving (and thus possibly changing) the names and + addresses used for the same devices. Different versions of those generation rules are called "naming + schemes". The default naming scheme is chosen at compilation time. Usually this will be the latest + implemented version, but it is also possible to set one of the older versions to preserve + compatibility. This may be useful for example for distributions, which may introduce new versions of + systemd in stable releases without changing the naming scheme. The naming scheme may also be overridden + using the <varname>net.naming-scheme=</varname> kernel command line switch, see + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Available naming schemes are described below.</para> + + <para>After the udev proprties have been generated, appropriate udev rules may be used to actually rename + devices based on those properties. See the description of <varname>NamePolicy=</varname> and + <varname>MACAddressPolicy=</varname> in + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Naming</title> + + <para>All names start with a two-character prefix that signifies the interface type.</para> + + <table> + <title>Two character prefixes based on the type of interface</title> + + <tgroup cols='2'> + <thead> + <row> + <entry>Prefix</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry><constant>en</constant></entry> + <entry>Ethernet</entry> + </row> + <row> + <entry><constant>ib</constant></entry> + <entry>InfiniBand</entry> + </row> + <row> + <entry><constant>sl</constant></entry> + <entry>serial line IP (slip)</entry> + </row> + <row> + <entry><constant>wl</constant></entry> + <entry>Wireless local area network (WLAN)</entry> + </row> + <row> + <entry><constant>ww</constant></entry> + <entry>Wireless wide area network (WWAN)</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The udev <command>net_id</command> builtin exports the following udev device properties:</para> + + <variablelist> + <varlistentry> + <term><varname>ID_NET_NAME_ONBOARD=<replaceable>prefix</replaceable><constant>o</constant><replaceable>number</replaceable></varname></term> + + <listitem><para>This name is set based on the ordering information given by the firmware for + on-board devices. The name consists of the prefix, letter <constant>o</constant>, and a number + specified by the firmware. This is only available for PCI devices.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ID_NET_LABEL_ONBOARD=<replaceable>prefix</replaceable> <replaceable>label</replaceable></varname></term> + + <listitem><para>This property is set based on label given by the firmware for on-board devices. The + name consists of the prefix concatenated with the label. This is only available for PCI devices. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ID_NET_NAME_MAC=<replaceable>prefix</replaceable><constant>x</constant><replaceable>AABBCCDDEEFF</replaceable></varname></term> + + <listitem><para>This name consists of the prefix, letter <constant>x</constant>, and 12 hexadecimal + digits of the MAC address. It is available if the device has a fixed MAC address. Because this name + is based on an attribute of the card itself, it remains "stable" when the device is moved (even + between machines), but will change when the hardware is replaced.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]</varname></term> + <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>b</constant><replaceable>number</replaceable></varname></term> + <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>u</constant><replaceable>port</replaceable>…[<constant>c</constant><replaceable>config</replaceable>][<constant>i</constant><replaceable>interface</replaceable>]</varname></term> + <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>v</constant><replaceable>slot</replaceable></varname></term> + + <listitem><para>This property describes the slot position. Different schemes are used depending on + the bus type, as described in the table below. In all cases, PCI slot information must be known. In + case of USB, BCMA, and SR-VIO devices, the full name consists of the prefix, PCI slot identifier, + and USB or BCMA or SR-VIO slot identifier. The first two parts are denoted as "…" in the table + below.</para> + + <table> + <title>Slot naming schemes</title> + + <tgroup cols='2'> + <thead> + <row> + <entry>Format</entry> + <entry>Description</entry> + </row> + </thead> + + <tbody> + <row> + <entry><replaceable>prefix</replaceable> [<constant>P</constant><replaceable>domain</replaceable>] <constant>s</constant><replaceable>slot</replaceable> [<constant>f</constant><replaceable>function</replaceable>] [<constant>n</constant><replaceable>port_name</replaceable> | <constant>d</constant><replaceable>dev_port</replaceable>]</entry> + <entry>PCI slot number</entry> + </row> + + <row> + <entry>… <constant>b</constant><replaceable>number</replaceable></entry> + <entry>Broadcom bus (BCMA) core number</entry> + </row> + + <row> + <entry>… <constant>u</constant><replaceable>port</replaceable>… [<constant>c</constant><replaceable>config</replaceable>] [<constant>i</constant><replaceable>interface</replaceable>]</entry> + <entry>USB port number chain</entry> + </row> + + <row> + <entry>… <constant>v</constant><replaceable>slot</replaceable></entry> + <entry>SR-VIO slot number</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The PCI domain is only prepended when it is not 0. All multi-function PCI devices will carry + the <constant>f<replaceable>function</replaceable></constant> number in the device name, including + the function 0 device. For non-multi-function devices, the number is suppressed if 0. The port name + <replaceable>port_name</replaceable> is used, or the port number + <constant>d</constant><replaceable>dev_port</replaceable> if the name is not known.</para> + + <para>For BCMA devices, the core number is suppressed when 0.</para> + + <para>For USB devices the full chain of port numbers of hubs is composed. If the name gets longer + than the maximum number of 15 characters, the name is not exported. The usual USB configuration + number 1 and interface number 0 values are suppressed.</para> + </listitem> + + <para>SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of + <constant>v</constant> and the virtual device number, with any leading zeros removed. The bus + number is ignored. This device type is found in IBM PowerVMs.</para> + </varlistentry> + + <varlistentry> + <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>c</constant><replaceable>bus_id</replaceable></varname></term> + <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>a</constant><replaceable>vendor</replaceable><replaceable>model</replaceable><constant>i</constant><replaceable>instance</replaceable></varname></term> + <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>i</constant><replaceable>address</replaceable><constant>n</constant><replaceable>port_name</replaceable></varname></term> + <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>p</constant><replaceable>bus</replaceable><constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>phys_port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]</varname></term> + <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>p</constant><replaceable>bus</replaceable><constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>phys_port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>b</constant><replaceable>number</replaceable></varname></term> + <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>p</constant><replaceable>bus</replaceable><constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>phys_port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>u</constant><replaceable>port</replaceable>…[<constant>c</constant><replaceable>config</replaceable>][<constant>i</constant><replaceable>interface</replaceable>]</varname></term> + + <listitem><para>This property describes the device installation location. Different schemes are + used depending on the bus type, as described in the table below. For BCMA and USB devices, PCI path + information must known, and the full name consists of the prefix, PCI slot identifier, and USB or + BCMA location. The first two parts are denoted as "…" in the table below.</para> + + <table> + <title>Path naming schemes</title> + + <tgroup cols='2'> + <thead> + <row> + <entry>Format</entry> + <entry>Description</entry> + </row> + </thead> + + <tbody> + <row> + <entry><replaceable>prefix</replaceable> <constant>c</constant><replaceable>bus_id</replaceable></entry> + <entry>CCW or grouped CCW device identifier</entry> + </row> + + <row> + <entry><replaceable>prefix</replaceable> <constant>a</constant><replaceable>vendor</replaceable> <replaceable>model</replaceable> <constant>i</constant><replaceable>instance</replaceable></entry> + <entry>ACPI path names for ARM64 platform devices</entry> + </row> + + <row> + <entry><replaceable>prefix</replaceable> <constant>i</constant><replaceable>address</replaceable> <constant>n</constant><replaceable>port_name</replaceable></entry> + <entry>Netdevsim (simulated networking device) device number and port name</entry> + </row> + + <row> + <entry><replaceable>prefix</replaceable> [<constant>P</constant><replaceable>domain</replaceable>] <constant>p</constant><replaceable>bus</replaceable> <constant>s</constant><replaceable>slot</replaceable> [<constant>f</constant><replaceable>function</replaceable>] [<constant>n</constant><replaceable>phys_port_name</replaceable> | <constant>d</constant><replaceable>dev_port</replaceable>]</entry> + <entry>PCI geographical location</entry> + </row> + + <row> + <entry>… <constant>b</constant><replaceable>number</replaceable></entry> + <entry>Broadcom bus (BCMA) core number</entry> + </row> + + <row> + <entry>… <constant>u</constant><replaceable>port</replaceable>… [<constant>c</constant><replaceable>config</replaceable>] [<constant>i</constant><replaceable>interface</replaceable>]</entry> + <entry>USB port number chain</entry> + </row> + + </tbody> + </tgroup> + </table> + + <para>CCW and grouped CCW devices are found in IBM System Z mainframes. Any leading zeros and + dots are suppressed.</para> + + <para>For PCI, BCMA, and USB devices, the same rules as described above for slot naming are + used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>History</title> + + <para>The following "naming schemes" have been defined:</para> + + <variablelist> + <varlistentry> + <term><constant>v238</constant></term> + + <listitem><para>This is the naming naming that was implemented in systemd 238.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>v239</constant></term> + + <listitem><para>Naming was changed for virtual network interfaces created with SR-IOV and NPAR and + for devices where the PCI network controller device does not have a slot number associated.</para> + + <para>SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of + <literal>v<replaceable>port</replaceable></literal>, where <replaceable>port</replaceable> is the + virtual device number. Previously those virtual devices were named as if completely independent. + </para> + + <para>The ninth and later NPAR virtual devices are named following the scheme used for the first + eight NPAR partitions. Previously those devices were not renamed and the kernel default + ("eth<replaceable>N</replaceable>") was used.</para> + + <para>Names are also generated for PCI devices where the PCI network controller device does not + have an associated slot number itself, but one of its parents does. Previously those devices were + not renamed and the kernel default was used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>v240</constant></term> + + <listitem><para>The <literal>ib</literal> prefix and stable names for infiniband devices are + introduced. Previously those devices were not renamed.</para> + + <para>The ACPI index field (used in <varname>ID_NET_NAME_ONBOARD=</varname>) is now also used when + 0.</para> + + <para>A new naming policy <varname>NamePolicy=keep</varname> was introduced. With this policy, if + the network device name was already set by userspace, the device will not be renamed + again. Previously, this naming policy applied implicitly, and now it must be explicitly + requested. Effectively, this means that network devices will be renamed according to the + configuration, even if they have been renamed already, if <constant>keep</constant> is not + specified as the naming policy in the <filename noindex='true'>.link</filename> file. See + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of <varname>NamePolicy=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>v241</constant></term> + + <listitem><para><option>MACAddressPolicy=persistent</option> was extended to set MAC addresses + based on the device name. Previously addresses were only based on the + <varname noindex='true'>ID_NET_NAME_*</varname> attributes, which meant that interface names would + never be generated for virtual devices. Now a persistent address will be generated for most + devices, including in particular bridges.</para> + + <para>Note: when userspace does not set a MAC address for a bridge device, the kernel will + initially assign a random address, and then change it when the first device is enslaved to the + bridge. With this naming policy change, bridges get a persistent MAC address based on the bridge + name instead of the first enslaved device.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>v243</constant></term> + + <listitem><para>Support for renaming netdevsim (simulated networking) devices was added. Previously + those devices were not renamed.</para> + + <para>Previously two-letter interface type prefix was prepended to + <varname>ID_NET_LABEL_ONBOARD=</varname>. This is not done anymore.</para></listitem> + </varlistentry> + </variablelist> + + <para>Note that <constant>latest</constant> may be used to denote the latest scheme known (to this + particular version of systemd.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Using <command>udevadm test-builtin</command> to display device properties</title> + + <programlisting>$ udevadm test-builtin net_id /sys/class/net/enp0s31f6 +... +Using default interface naming scheme 'v243'. +ID_NET_NAMING_SCHEME=v243 +ID_NET_NAME_MAC=enx54ee75cb1dc0 +ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd. +ID_NET_NAME_PATH=enp0s31f6 +...</programlisting> + </example> + + <example> + <title>PCI Ethernet card with firmware index "1"</title> + + <programlisting>ID_NET_NAME_ONBOARD=eno1 +ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1 + </programlisting> + </example> + + <example> + <title>PCI Ethernet card in hotplug slot with firmware index number</title> + + <programlisting># /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1 +ID_NET_NAME_MAC=enx000000000466 +ID_NET_NAME_PATH=enp5s0 +ID_NET_NAME_SLOT=ens1</programlisting> + </example> + + <example> + <title>PCI Ethernet multi-function card with 2 ports</title> + + <programlisting># /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0 +ID_NET_NAME_MAC=enx78e7d1ea46da +ID_NET_NAME_PATH=enp2s0f0 + +# /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1 +ID_NET_NAME_MAC=enx78e7d1ea46dc +ID_NET_NAME_PATH=enp2s0f1</programlisting> + </example> + + <example> + <title>PCI WLAN card</title> + + <programlisting># /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0 +ID_NET_NAME_MAC=wlx0024d7e31130 +ID_NET_NAME_PATH=wlp3s0</programlisting> + </example> + + <example> + <title>PCI IB host adapter with 2 ports</title> + + <programlisting># /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/net/ibp21s0f0 +ID_NET_NAME_PATH=ibp21s0f0 + +# /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.1/net/ibp21s0f1 +ID_NET_NAME_PATH=ibp21s0f1</programlisting> + </example> + + <example> + <title>USB built-in 3G modem</title> + + <programlisting># /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6 +ID_NET_NAME_MAC=wwx028037ec0200 +ID_NET_NAME_PATH=wwp0s29u1u4i6</programlisting> + </example> + + <example> + <title>USB Android phone</title> + + <programlisting># /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2 +ID_NET_NAME_MAC=enxd626b3450fb5 +ID_NET_NAME_PATH=enp0s29u1u2</programlisting> + </example> + + <example> + <title>s390 grouped CCW interface</title> + + <programlisting># /sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0 +ID_NET_NAME_MAC=enx026d3c00000a +ID_NET_NAME_PATH=encf5f0</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames">the + original page describing stable interface names</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index 1836b5fe00..0775e00bd2 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -115,6 +115,9 @@ <row><entry><varname>ipvlan</varname></entry> <entry>An ipvlan device is a stacked device which receives packets from its underlying device based on IP address filtering.</entry></row> + <row><entry><varname>ipvtap</varname></entry> + <entry>An ipvtap device is a stacked device which receives packets from its underlying device based on IP address filtering and can be accessed using the tap user space interface.</entry></row> + <row><entry><varname>macvlan</varname></entry> <entry>A macvlan device is a stacked device which receives packets from its underlying device based on MAC address filtering.</entry></row> @@ -151,6 +154,9 @@ <row><entry><varname>l2tp</varname></entry> <entry>A Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It does not provide any encryption or confidentiality by itself</entry></row> + <row><entry><varname>macsec</varname></entry> + <entry>Media Access Control Security (MACsec) is an 802.1AE IEEE industry-standard security technology that provides secure communication for all traffic on Ethernet links. MACsec provides point-to-point security on Ethernet links between directly connected nodes and is capable of identifying and preventing most security threats.</entry></row> + <row><entry><varname>vrf</varname></entry> <entry>A Virtual Routing and Forwarding (<ulink url="https://www.kernel.org/doc/Documentation/networking/vrf.txt">VRF</ulink>) interface to create separate routing and forwarding domains.</entry></row> @@ -165,11 +171,17 @@ <entry>WireGuard Secure Network Tunnel.</entry></row> <row><entry><varname>netdevsim</varname></entry> - <entry> A simulator. This simulated networking device is used for testing various networking APIs and at this time is particularly focused on testing hardware offloading related interfaces.</entry></row> + <entry>A simulator. This simulated networking device is used for testing various networking APIs and at this time is particularly focused on testing hardware offloading related interfaces.</entry></row> + + <row><entry><varname>nlmon</varname></entry> + <entry>A Netlink monitor device. Use an nlmon device when you want to monitor system Netlink messages.</entry></row> <row><entry><varname>fou</varname></entry> <entry>Foo-over-UDP tunneling.</entry></row> + <row><entry><varname>xfrm</varname></entry> + <entry>A virtual tunnel interface like vti/vti6 but with several advantages.</entry></row> + </tbody> </tgroup> </table> @@ -241,219 +253,226 @@ </listitem> </varlistentry> </variablelist> - </refsect1> <refsect1> <title>[NetDev] Section Options</title> - <para>The <literal>[NetDev]</literal> section accepts the - following keys:</para> - - <variablelist class='network-directives'> - <varlistentry> - <term><varname>Description=</varname></term> - <listitem> - <para>A free-form description of the netdev.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>Name=</varname></term> - <listitem> - <para>The interface name used when creating the netdev. - This option is compulsory.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>Kind=</varname></term> - <listitem> - <para>The netdev kind. This option is compulsory. See the - <literal>Supported netdev kinds</literal> section for the - valid keys.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MTUBytes=</varname></term> - <listitem> - <para>The maximum transmission unit in bytes to set for the device. The usual suffixes K, M, G, - are supported and are understood to the base of 1024. For <literal>tun</literal> or - <literal>tap</literal> devices, <varname>MTUBytes=</varname> setting is not currently supported in - <literal>[NetDev]</literal> section. Please specify it in <literal>[Link]</literal> section of - corresponding - <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> - files.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MACAddress=</varname></term> - <listitem> - <para>The MAC address to use for the device. For <literal>tun</literal> or <literal>tap</literal> - devices, setting <varname>MACAddress=</varname> in the <literal>[NetDev]</literal> section is not - supported. Please specify it in <literal>[Link]</literal> section of the corresponding - <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> - file. If this option is not set, <literal>vlan</literal> devices inherit the MAC address of the - physical interface. For other kind of netdevs, if this option is not set, then MAC address is - generated based on the interface name and the - <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. - </para> - </listitem> - </varlistentry> - </variablelist> + <para>The <literal>[NetDev]</literal> section accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Description=</varname></term> + <listitem> + <para>A free-form description of the netdev.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>The interface name used when creating the netdev. + This option is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Kind=</varname></term> + <listitem> + <para>The netdev kind. This option is compulsory. See the + <literal>Supported netdev kinds</literal> section for the + valid keys.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MTUBytes=</varname></term> + <listitem> + <para>The maximum transmission unit in bytes to set for the device. The usual suffixes K, M, G, + are supported and are understood to the base of 1024. For <literal>tun</literal> or + <literal>tap</literal> devices, <varname>MTUBytes=</varname> setting is not currently supported in + <literal>[NetDev]</literal> section. Please specify it in <literal>[Link]</literal> section of + corresponding + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + files.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The MAC address to use for the device. For <literal>tun</literal> or <literal>tap</literal> + devices, setting <varname>MACAddress=</varname> in the <literal>[NetDev]</literal> section is not + supported. Please specify it in <literal>[Link]</literal> section of the corresponding + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + file. If this option is not set, <literal>vlan</literal> devices inherit the MAC address of the + physical interface. For other kind of netdevs, if this option is not set, then MAC address is + generated based on the interface name and the + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + </variablelist> </refsect1> - <refsect1> + <refsect1> <title>[Bridge] Section Options</title> - <para>The <literal>[Bridge]</literal> section only applies for - netdevs of kind <literal>bridge</literal>, and accepts the - following keys:</para> - - <variablelist class='network-directives'> - <varlistentry> - <term><varname>HelloTimeSec=</varname></term> - <listitem> - <para>HelloTimeSec specifies the number of seconds between two hello packets - sent out by the root bridge and the designated bridges. Hello packets are - used to communicate information about the topology throughout the entire - bridged local area network.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MaxAgeSec=</varname></term> - <listitem> - <para>MaxAgeSec specifies the number of seconds of maximum message age. - If the last seen (received) hello packet is more than this number of - seconds old, the bridge in question will start the takeover procedure - in attempt to become the Root Bridge itself.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>ForwardDelaySec=</varname></term> - <listitem> - <para>ForwardDelaySec specifies the number of seconds spent in each - of the Listening and Learning states before the Forwarding state is entered.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>AgeingTimeSec=</varname></term> - <listitem> - <para>This specifies the number of seconds a MAC Address will be kept in - the forwarding database after having a packet received from this MAC Address.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>Priority=</varname></term> - <listitem> - <para>The priority of the bridge. An integer between 0 and 65535. A lower value - means higher priority. The bridge having the lowest priority will be elected as root bridge.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>GroupForwardMask=</varname></term> - <listitem> - <para>A 16-bit bitmask represented as an integer which allows forwarding of link - local frames with 802.1D reserved addresses (01:80:C2:00:00:0X). A logical AND - is performed between the specified bitmask and the exponentiation of 2^X, the - lower nibble of the last octet of the MAC address. For example, a value of 8 - would allow forwarding of frames addressed to 01:80:C2:00:00:03 (802.1X PAE).</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>DefaultPVID=</varname></term> - <listitem> - <para>This specifies the default port VLAN ID of a newly attached bridge port. - Set this to an integer in the range 1–4094 or <literal>none</literal> to disable the PVID.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MulticastQuerier=</varname></term> - <listitem> - <para>Takes a boolean. This setting controls the IFLA_BR_MCAST_QUERIER option in the kernel. - If enabled, the kernel will send general ICMP queries from a zero source address. - This feature should allow faster convergence on startup, but it causes some - multicast-aware switches to misbehave and disrupt forwarding of multicast packets. - When unset, the kernel's default will be used. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MulticastSnooping=</varname></term> - <listitem> - <para>Takes 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 will be used. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>VLANFiltering=</varname></term> - <listitem> - <para>Takes a boolean. This setting controls the IFLA_BR_VLAN_FILTERING option in the kernel. - If enabled, the bridge will be started in VLAN-filtering mode. When unset, the kernel's default will be used. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>STP=</varname></term> - <listitem> - <para>Takes a boolean. This enables the bridge's Spanning Tree Protocol (STP). - When unset, the kernel's default will be used. - </para> - </listitem> - </varlistentry> - </variablelist> + <para>The <literal>[Bridge]</literal> section only applies for + netdevs of kind <literal>bridge</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>HelloTimeSec=</varname></term> + <listitem> + <para>HelloTimeSec specifies the number of seconds between two hello packets + sent out by the root bridge and the designated bridges. Hello packets are + used to communicate information about the topology throughout the entire + bridged local area network.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MaxAgeSec=</varname></term> + <listitem> + <para>MaxAgeSec specifies the number of seconds of maximum message age. + If the last seen (received) hello packet is more than this number of + seconds old, the bridge in question will start the takeover procedure + in attempt to become the Root Bridge itself.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ForwardDelaySec=</varname></term> + <listitem> + <para>ForwardDelaySec specifies the number of seconds spent in each + of the Listening and Learning states before the Forwarding state is entered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AgeingTimeSec=</varname></term> + <listitem> + <para>This specifies the number of seconds a MAC Address will be kept in + the forwarding database after having a packet received from this MAC Address.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Priority=</varname></term> + <listitem> + <para>The priority of the bridge. An integer between 0 and 65535. A lower value + means higher priority. The bridge having the lowest priority will be elected as root bridge.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GroupForwardMask=</varname></term> + <listitem> + <para>A 16-bit bitmask represented as an integer which allows forwarding of link + local frames with 802.1D reserved addresses (01:80:C2:00:00:0X). A logical AND + is performed between the specified bitmask and the exponentiation of 2^X, the + lower nibble of the last octet of the MAC address. For example, a value of 8 + would allow forwarding of frames addressed to 01:80:C2:00:00:03 (802.1X PAE).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DefaultPVID=</varname></term> + <listitem> + <para>This specifies the default port VLAN ID of a newly attached bridge port. + Set this to an integer in the range 1–4094 or <literal>none</literal> to disable the PVID.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastQuerier=</varname></term> + <listitem> + <para>Takes a boolean. This setting controls the IFLA_BR_MCAST_QUERIER option in the kernel. + If enabled, the kernel will send general ICMP queries from a zero source address. + This feature should allow faster convergence on startup, but it causes some + multicast-aware switches to misbehave and disrupt forwarding of multicast packets. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastSnooping=</varname></term> + <listitem> + <para>Takes 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 will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>VLANFiltering=</varname></term> + <listitem> + <para>Takes a boolean. This setting controls the IFLA_BR_VLAN_FILTERING option in the kernel. + If enabled, the bridge will be started in VLAN-filtering mode. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>STP=</varname></term> + <listitem> + <para>Takes a boolean. This enables the bridge's Spanning Tree Protocol (STP). + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastIGMPVersion=</varname></term> + <listitem> + <para>Allows to change bridge's multicast Internet Group Management Protocol (IGMP) version. + Takes an interger 2 or 3. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + </variablelist> </refsect1> <refsect1> <title>[VLAN] Section Options</title> - <para>The <literal>[VLAN]</literal> section only applies for - netdevs of kind <literal>vlan</literal>, and accepts the - following key:</para> - - <variablelist class='network-directives'> - <varlistentry> - <term><varname>Id=</varname></term> - <listitem> - <para>The VLAN ID to use. An integer in the range 0–4094. - This option is compulsory.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>GVRP=</varname></term> - <listitem> - <para>Takes a boolean. The Generic VLAN Registration Protocol (GVRP) is a protocol that - allows automatic learning of VLANs on a network. - When unset, the kernel's default will be used. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MVRP=</varname></term> - <listitem> - <para>Takes a boolean. Multiple VLAN Registration Protocol (MVRP) formerly known as GARP VLAN - Registration Protocol (GVRP) is a standards-based Layer 2 network protocol, - for automatic configuration of VLAN information on switches. It was defined - in the 802.1ak amendment to 802.1Q-2005. When unset, the kernel's default will be used. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>LooseBinding=</varname></term> - <listitem> - <para>Takes a boolean. The VLAN loose binding mode, in which only the operational state is passed - from the parent to the associated VLANs, but the VLAN device state is not changed. - When unset, the kernel's default will be used.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>ReorderHeader=</varname></term> - <listitem> - <para>Takes a boolean. The VLAN reorder header is set VLAN interfaces behave like physical interfaces. - When unset, the kernel's default will be used.</para> - </listitem> - </varlistentry> - </variablelist> + <para>The <literal>[VLAN]</literal> section only applies for + netdevs of kind <literal>vlan</literal>, and accepts the + following key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>The VLAN ID to use. An integer in the range 0–4094. + This option is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GVRP=</varname></term> + <listitem> + <para>Takes a boolean. The Generic VLAN Registration Protocol (GVRP) is a protocol that + allows automatic learning of VLANs on a network. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MVRP=</varname></term> + <listitem> + <para>Takes a boolean. Multiple VLAN Registration Protocol (MVRP) formerly known as GARP VLAN + Registration Protocol (GVRP) is a standards-based Layer 2 network protocol, + for automatic configuration of VLAN information on switches. It was defined + in the 802.1ak amendment to 802.1Q-2005. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LooseBinding=</varname></term> + <listitem> + <para>Takes a boolean. The VLAN loose binding mode, in which only the operational state is passed + from the parent to the associated VLANs, but the VLAN device state is not changed. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ReorderHeader=</varname></term> + <listitem> + <para>Takes a boolean. The VLAN reorder header is set VLAN interfaces behave like physical interfaces. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> <refsect1> @@ -476,17 +495,15 @@ </listitem> </varlistentry> </variablelist> - </refsect1> - <refsect1> + <refsect1> <title>[MACVTAP] Section Options</title> <para>The <literal>[MACVTAP]</literal> section applies for netdevs of kind <literal>macvtap</literal> and accepts the same key as <literal>[MACVLAN]</literal>.</para> - - </refsect1> + </refsect1> <refsect1> <title>[IPVLAN] Section Options</title> @@ -498,35 +515,43 @@ <variablelist class='network-directives'> <varlistentry> <term><varname>Mode=</varname></term> - <listitem> - <para>The IPVLAN mode to use. The supported options are - <literal>L2</literal>,<literal>L3</literal> and <literal>L3S</literal>. - </para> - </listitem> + <listitem> + <para>The IPVLAN mode to use. The supported options are + <literal>L2</literal>,<literal>L3</literal> and <literal>L3S</literal>. + </para> + </listitem> </varlistentry> - <varlistentry> + <varlistentry> <term><varname>Flags=</varname></term> - <listitem> - <para>The IPVLAN flags to use. The supported options are - <literal>bridge</literal>,<literal>private</literal> and <literal>vepa</literal>. - </para> - </listitem> + <listitem> + <para>The IPVLAN flags to use. The supported options are + <literal>bridge</literal>,<literal>private</literal> and <literal>vepa</literal>. + </para> + </listitem> </varlistentry> </variablelist> + </refsect1> + + <refsect1> + <title>[IPVTAP] Section Options</title> + <para>The <literal>[IPVTAP]</literal> section only applies for + netdevs of kind <literal>ipvtap</literal> and accepts the + same key as <literal>[IPVLAN]</literal>.</para> </refsect1> <refsect1> <title>[VXLAN] Section Options</title> + <para>The <literal>[VXLAN]</literal> section only applies for netdevs of kind <literal>vxlan</literal>, and accepts the following keys:</para> <variablelist class='network-directives'> <varlistentry> - <term><varname>Id=</varname></term> + <term><varname>VNI=</varname></term> <listitem> - <para>The VXLAN ID to use.</para> + <para>The VXLAN Network Identifier (or VXLAN Segment ID). Takes a number in the range 1-16777215.</para> </listitem> </varlistentry> <varlistentry> @@ -541,7 +566,13 @@ <para>Configures local IP address.</para> </listitem> </varlistentry> - <varlistentry> + <varlistentry> + <term><varname>Group=</varname></term> + <listitem> + <para>Configures VXLAN multicast group IP address. All members of a VXLAN must use the same multicast group address.</para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>TOS=</varname></term> <listitem> <para>The Type Of Service byte value for a vxlan interface.</para> @@ -550,10 +581,10 @@ <varlistentry> <term><varname>TTL=</varname></term> <listitem> - <para>A fixed Time To Live N on Virtual eXtensible Local - Area Network packets. N is a number in the range 1–255. 0 - is a special value meaning that packets inherit the TTL - value.</para> + <para>A fixed Time To Live N on Virtual eXtensible Local Area Network packets. + Takes <literal>inherit</literal> or a number in the range 0–255. 0 is a special + value meaning inherit the inner protocol's TTL value. <literal>inherit</literal> + means that it will inherit the outer protocol's TTL value.</para> </listitem> </varlistentry> <varlistentry> @@ -637,26 +668,36 @@ <para>Takes a boolean. When true, remote receive checksum offload in VXLAN is turned on.</para> </listitem> </varlistentry> - <varlistentry> - <term><varname>GroupPolicyExtension=</varname></term> - <listitem> - <para>Takes a boolean. When true, it enables Group Policy VXLAN extension security label mechanism - across network peers based on VXLAN. For details about the Group Policy VXLAN, see the - <ulink url="https://tools.ietf.org/html/draft-smith-vxlan-group-policy"> - VXLAN Group Policy </ulink> document. Defaults to false.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>DestinationPort=</varname></term> - <listitem> - <para>Configures the default destination UDP port on a per-device basis. - If destination port is not specified then Linux kernel default will be used. - Set destination port 4789 to get the IANA assigned value. If not set or if the - destination port is assigned the empty string the default port of 4789 is used.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>PortRange=</varname></term> + <varlistentry> + <term><varname>GroupPolicyExtension=</varname></term> + <listitem> + <para>Takes a boolean. When true, it enables Group Policy VXLAN extension security label mechanism + across network peers based on VXLAN. For details about the Group Policy VXLAN, see the + <ulink url="https://tools.ietf.org/html/draft-smith-vxlan-group-policy"> + VXLAN Group Policy </ulink> document. Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GenericProtocolExtension=</varname></term> + <listitem> + <para>Takes a boolean. When true, Generic Protocol Extension extends the existing VXLAN protocol + to provide protocol typing, OAM, and versioning capabilities. For details about the VXLAN GPE + Header, see the <ulink url="https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-07"> + Generic Protocol Extension for VXLAN </ulink> document. If destination port is not specified and + Generic Protocol Extension is set then default port of 4790 is used. Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DestinationPort=</varname></term> + <listitem> + <para>Configures the default destination UDP port on a per-device basis. + If destination port is not specified then Linux kernel default will be used. + Set destination port 4789 to get the IANA assigned value. If not set or if the + destination port is assigned the empty string the default port of 4789 is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PortRange=</varname></term> <listitem> <para>Configures VXLAN port range. VXLAN bases source UDP port based on flow to help the receiver to be able @@ -665,18 +706,29 @@ ports, and allows overriding via configuration.</para> </listitem> </varlistentry> - <varlistentry> - <term><varname>FlowLabel=</varname></term> + <varlistentry> + <term><varname>FlowLabel=</varname></term> <listitem> <para>Specifies the flow label to use in outgoing packets. The valid range is 0-1048575. </para> </listitem> </varlistentry> + <varlistentry> + <term><varname>IPDoNotFragment=</varname></term> + <listitem> + <para>Allows to set the IPv4 Do not Fragment (DF) bit in outgoing packets, or to inherit its + value from the IPv4 inner header. Takes a boolean value, or <literal>inherit</literal>. Set + to <literal>inherit</literal> if the encapsulated protocol is IPv6. When unset, the kernel's + default will be used.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> + <refsect1> <title>[GENEVE] Section Options</title> + <para>The <literal>[GENEVE]</literal> section only applies for netdevs of kind <literal>geneve</literal>, and accepts the following keys:</para> @@ -685,7 +737,7 @@ <varlistentry> <term><varname>Id=</varname></term> <listitem> - <para>Specifies the Virtual Network Identifier (VNI) to use. Ranges [0-16777215].</para> + <para>Specifies the Virtual Network Identifier (VNI) to use. Ranges [0-16777215]. This field is mandatory.</para> </listitem> </varlistentry> <varlistentry> @@ -703,7 +755,9 @@ <varlistentry> <term><varname>TTL=</varname></term> <listitem> - <para>Specifies the TTL value to use in outgoing packets. Ranges [1-255].</para> + <para>Accepts the same key in <literal>[VXLAN]</literal> section except when unset or + set to 0, the kernel's default will be used meaning that packets TTL will be set from + <filename>/proc/sys/net/ipv4/ip_default_ttl</filename>.</para> </listitem> </varlistentry> <varlistentry> @@ -724,23 +778,31 @@ <para>Takes a boolean. When true, allows incoming UDP packets over IPv6 with zero checksum field.</para> </listitem> </varlistentry> - <varlistentry> - <term><varname>DestinationPort=</varname></term> - <listitem> - <para>Specifies destination port. Defaults to 6081. If not set or assigned the empty string, the default - port of 6081 is used.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>FlowLabel=</varname></term> + <varlistentry> + <term><varname>DestinationPort=</varname></term> + <listitem> + <para>Specifies destination port. Defaults to 6081. If not set or assigned the empty string, the default + port of 6081 is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FlowLabel=</varname></term> <listitem> <para>Specifies the flow label to use in outgoing packets.</para> </listitem> </varlistentry> + <varlistentry> + <term><varname>IPDoNotFragment=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[VXLAN]</literal> section.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> + <refsect1> <title>[L2TP] Section Options</title> + <para>The <literal>[L2TP]</literal> section only applies for netdevs of kind <literal>l2tp</literal>, and accepts the following keys:</para> @@ -817,8 +879,10 @@ </varlistentry> </variablelist> </refsect1> + <refsect1> <title>[L2TPSession] Section Options</title> + <para>The <literal>[L2TPSession]</literal> section only applies for netdevs of kind <literal>l2tp</literal>, and accepts the following keys:</para> @@ -826,13 +890,13 @@ <varlistentry> <term><varname>Name=</varname></term> <listitem> - <para>Specifies the name of the sesssion. This option is compulsory.</para> + <para>Specifies the name of the session. This option is compulsory.</para> </listitem> </varlistentry> <varlistentry> <term><varname>SessionId=</varname></term> <listitem> - <para>Specifies the sesssion id. The value used must match the <literal>SessionId=</literal> value being used at the peer. + <para>Specifies the session id. The value used must match the <literal>SessionId=</literal> value being used at the peer. Ranges a number between 1 and 4294967295). This option is compulsory.</para> </listitem> </varlistentry> @@ -851,6 +915,169 @@ </varlistentry> </variablelist> </refsect1> + + <refsect1> + <title>[MACsec] Section Options</title> + + <para>The <literal>[MACsec]</literal> section only applies for network devices of kind + <literal>macsec</literal>, and accepts the following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Port=</varname></term> + <listitem> + <para>Specifies the port to be used for the MACsec transmit channel. The port is used to make + secure channel identifier (SCI). Takes a value between 1 and 65535. Defaults to unset. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Encrypt=</varname></term> + <listitem> + <para>Takes a boolean. When true, enable encryption. Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACsecReceiveChannel] Section Options</title> + <para>The <literal>[MACsecReceiveChannel]</literal> section only applies for network devices of + kind <literal>macsec</literal>, and accepts the following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Port=</varname></term> + <listitem> + <para>Specifies the port to be used for the MACsec receive channel. The port is used to make + secure channel identifier (SCI). Takes a value between 1 and 65535. This option is + compulsory, and is not set by default.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>Specifies the MAC address to be used for the MACsec receive channel. The MAC address + used to make secure channel identifier (SCI). This option is compulsory, and is not set by + default.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACsecTransmitAssociation] Section Options</title> + + <para>The <literal>[MACsecTransmitAssociation]</literal> section only applies for network devices + of kind <literal>macsec</literal>, and accepts the following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>PacketNumber=</varname></term> + <listitem> + <para>Specifies the packet number to be used for replay protection and the construction of + the initialization vector (along with the secure channel identifier [SCI]). Takes a value + between 1-4,294,967,295. Defaults to unset. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeyId=</varname></term> + <listitem> + <para>Specifies the identification for the key. Takes a number between 0-255. This option + is compulsory, and is not set by default.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Key=</varname></term> + <listitem> + <para>Specifies the encryption key used in the transmission channel. The same key must be + configured on the peer’s matching receive channel. This option is compulsory, and is not set + by default. Takes a 128-bit key encoded in a hexadecimal string, for example + <literal>dffafc8d7b9a43d5b9a3dfbbf6a30c16</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeyFile=</varname></term> + <listitem> + <para>Takes a absolute path to a file which contains a 128-bit key encoded in a hexadecimal + string, which will be used in the transmission channel. When this option is specified, + <varname>Key=</varname> is ignored. Note that the file must be readable by the user + <literal>systemd-network</literal>, so it should be, e.g., owned by + <literal>root:systemd-network</literal> with a <literal>0640</literal> file mode.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Activate=</varname></term> + <listitem> + <para>Takes a boolean. If enabled, then the security association is activated. Defaults to + unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseForEncoding=</varname></term> + <listitem> + <para>Takes a boolean. If enabled, then the security association is used for encoding. Only + one <literal>[MACsecTransmitAssociation]</literal> section can enable this option. When enabled, + <varname>Activate=yes</varname> is implied. Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACsecReceiveAssociation] Section Options</title> + + <para>The <literal>[MACsecReceiveAssociation]</literal> section only applies for + network devices of kind <literal>macsec</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Port=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecReceiveChannel]</literal> section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecReceiveChannel]</literal> section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PacketNumber=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecTransmitAssociation]</literal> section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeyId=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecTransmitAssociation]</literal> section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Key=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecTransmitAssociation]</literal> section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeyFile=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecTransmitAssociation]</literal> section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Activate=</varname></term> + <listitem> + <para>Accepts the same key in <literal>[MACsecTransmitAssociation]</literal> section.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> <title>[Tunnel] Section Options</title> @@ -997,6 +1224,13 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>AssignToLoopback=</varname></term> + <listitem> + <para>Takes a boolean. If set to <literal>yes</literal>, the loopback interface <literal>lo</literal> + is used as the underlying device of the tunnel interface. Defaults to <literal>no</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>AllowLocalRemote=</varname></term> <listitem> <para>Takes a boolean. When true allows tunnel traffic on <varname>ip6tnl</varname> devices where the remote endpoint is a local host address. @@ -1096,7 +1330,13 @@ will arrive with the encapsulation will be removed. Then they will be manually fed back into the network stack, and sent ahead for delivery to the real destination. This option is mandatory.</para> </listitem> - </varlistentry> + </varlistentry> + <varlistentry> + <term><varname>PeerPort=</varname></term> + <listitem> + <para>Specifies the peer port number. Defaults to unset. Note that when peer port is set <literal>Peer=</literal> address is mandotory.</para> + </listitem> + </varlistentry> <varlistentry> <term><varname>Protocol=</varname></term> <listitem> @@ -1107,49 +1347,65 @@ <varname>Encapsulation=GenericUDPEncapsulation</varname>, this must not be specified.</para> </listitem> </varlistentry> + <varlistentry> + <term><varname>Peer=</varname></term> + <listitem> + <para>Configures peer IP address. Note that when peer address is set <literal>PeerPort=</literal> is mandotory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Local=</varname></term> + <listitem> + <para>Configures local IP address.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> + <refsect1> <title>[Peer] Section Options</title> - <para>The <literal>[Peer]</literal> section only applies for - netdevs of kind <literal>veth</literal> and accepts the - following keys:</para> - - <variablelist class='network-directives'> - <varlistentry> - <term><varname>Name=</varname></term> - <listitem> - <para>The interface name used when creating the netdev. - This option is compulsory.</para> - </listitem> - </varlistentry> - <varlistentry> - <term><varname>MACAddress=</varname></term> - <listitem> - <para>The peer MACAddress, if not set, it is generated in - the same way as the MAC address of the main - interface.</para> - </listitem> - </varlistentry> - </variablelist> + <para>The <literal>[Peer]</literal> section only applies for + netdevs of kind <literal>veth</literal> and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>The interface name used when creating the netdev. + This option is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The peer MACAddress, if not set, it is generated in + the same way as the MAC address of the main + interface.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> + <refsect1> - <title>[VXCAN] Section Options</title> - <para>The <literal>[VXCAN]</literal> section only applies for - netdevs of kind <literal>vxcan</literal> and accepts the - following key:</para> - - <variablelist class='network-directives'> - <varlistentry> - <term><varname>Peer=</varname></term> - <listitem> - <para>The peer interface name used when creating the netdev. - This option is compulsory.</para> - </listitem> - </varlistentry> - </variablelist> + <title>[VXCAN] Section Options</title> + + <para>The <literal>[VXCAN]</literal> section only applies for + netdevs of kind <literal>vxcan</literal> and accepts the + following key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Peer=</varname></term> + <listitem> + <para>The peer interface name used when creating the netdev. + This option is compulsory.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> + <refsect1> <title>[Tun] Section Options</title> @@ -1159,15 +1415,6 @@ <variablelist class='network-directives'> <varlistentry> - <term><varname>OneQueue=</varname></term> - <listitem><para>Takes a boolean. Configures whether - all packets are queued at the device (enabled), or a fixed - number of packets are queued at the device and the rest at the - <literal>qdisc</literal>. Defaults to - <literal>no</literal>.</para> - </listitem> - </varlistentry> - <varlistentry> <term><varname>MultiQueue=</varname></term> <listitem><para>Takes a boolean. Configures whether to use multiple file descriptors (queues) to parallelize @@ -1187,7 +1434,7 @@ <varlistentry> <term><varname>VNetHeader=</varname></term> <listitem><para>Takes a boolean. Configures - IFF_VNET_HDR flag for a tap device. It allows sending + IFF_VNET_HDR flag for a tun or tap device. It allows sending and receiving larger Generic Segmentation Offload (GSO) packets. This may increase throughput significantly. Defaults to @@ -1206,9 +1453,7 @@ <filename>/dev/net/tun</filename> device.</para> </listitem> </varlistentry> - </variablelist> - </refsect1> <refsect1> @@ -1230,12 +1475,12 @@ <term><varname>PrivateKey=</varname></term> <listitem> <para>The Base64 encoded private key for the interface. It can be - generated using the <command>wg genkey</command> command - (see <citerefentry project="wireguard"><refentrytitle>wg</refentrytitle><manvolnum>8</manvolnum></citerefentry>). - This option or <varname>PrivateKeyFile=</varname> is mandatory to use WireGuard. - Note that because this information is secret, you may want to set - the permissions of the .netdev file to be owned by <literal>root:systemd-network</literal> - with a <literal>0640</literal> file mode.</para> + generated using the <command>wg genkey</command> command + (see <citerefentry project="wireguard"><refentrytitle>wg</refentrytitle><manvolnum>8</manvolnum></citerefentry>). + This option or <varname>PrivateKeyFile=</varname> is mandatory to use WireGuard. + Note that because this information is secret, you may want to set + the permissions of the .netdev file to be owned by <literal>root:systemd-network</literal> + with a <literal>0640</literal> file mode.</para> </listitem> </varlistentry> <varlistentry> @@ -1252,15 +1497,15 @@ <term><varname>ListenPort=</varname></term> <listitem> <para>Sets UDP port for listening. Takes either value between 1 and 65535 - or <literal>auto</literal>. If <literal>auto</literal> is specified, - the port is automatically generated based on interface name. - Defaults to <literal>auto</literal>.</para> + or <literal>auto</literal>. If <literal>auto</literal> is specified, + the port is automatically generated based on interface name. + Defaults to <literal>auto</literal>.</para> </listitem> </varlistentry> <varlistentry> - <term><varname>FwMark=</varname></term> + <term><varname>FirewallMark=</varname></term> <listitem> - <para>Sets a firewall mark on outgoing WireGuard packets from this interface.</para> + <para>Sets a firewall mark on outgoing WireGuard packets from this interface. Takes a number between 1 and 4294967295.</para> </listitem> </varlistentry> </variablelist> @@ -1277,23 +1522,23 @@ <term><varname>PublicKey=</varname></term> <listitem> <para>Sets a Base64 encoded public key calculated by <command>wg pubkey</command> - (see <citerefentry project="wireguard"><refentrytitle>wg</refentrytitle><manvolnum>8</manvolnum></citerefentry>) - from a private key, and usually transmitted out of band to the - author of the configuration file. This option is mandatory for this - section.</para> + (see <citerefentry project="wireguard"><refentrytitle>wg</refentrytitle><manvolnum>8</manvolnum></citerefentry>) + from a private key, and usually transmitted out of band to the + author of the configuration file. This option is mandatory for this + section.</para> </listitem> </varlistentry> <varlistentry> <term><varname>PresharedKey=</varname></term> <listitem> <para>Optional preshared key for the interface. It can be generated - by the <command>wg genpsk</command> command. This option adds an - additional layer of symmetric-key cryptography to be mixed into the - already existing public-key cryptography, for post-quantum - resistance. - Note that because this information is secret, you may want to set - the permissions of the .netdev file to be owned by <literal>root:systemd-networkd</literal> - with a <literal>0640</literal> file mode.</para> + by the <command>wg genpsk</command> command. This option adds an + additional layer of symmetric-key cryptography to be mixed into the + already existing public-key cryptography, for post-quantum + resistance. + Note that because this information is secret, you may want to set + the permissions of the .netdev file to be owned by <literal>root:systemd-networkd</literal> + with a <literal>0640</literal> file mode.</para> </listitem> </varlistentry> <varlistentry> @@ -1310,33 +1555,33 @@ <term><varname>AllowedIPs=</varname></term> <listitem> <para>Sets a comma-separated list of IP (v4 or v6) addresses with CIDR masks - from which this peer is allowed to send incoming traffic and to - which outgoing traffic for this peer is directed. The catch-all - 0.0.0.0/0 may be specified for matching all IPv4 addresses, and - ::/0 may be specified for matching all IPv6 addresses. </para> + from which this peer is allowed to send incoming traffic and to + which outgoing traffic for this peer is directed. The catch-all + 0.0.0.0/0 may be specified for matching all IPv4 addresses, and + ::/0 may be specified for matching all IPv6 addresses. </para> </listitem> </varlistentry> <varlistentry> <term><varname>Endpoint=</varname></term> <listitem> <para>Sets an endpoint IP address or hostname, followed by a colon, and then - a port number. This endpoint will be updated automatically once to - the most recent source IP address and port of correctly - authenticated packets from the peer at configuration time.</para> + a port number. This endpoint will be updated automatically once to + the most recent source IP address and port of correctly + authenticated packets from the peer at configuration time.</para> </listitem> </varlistentry> <varlistentry> <term><varname>PersistentKeepalive=</varname></term> <listitem> <para>Sets a seconds interval, between 1 and 65535 inclusive, of how often - to send an authenticated empty packet to the peer for the purpose - of keeping a stateful firewall or NAT mapping valid persistently. - For example, if the interface very rarely sends traffic, but it - might at anytime receive traffic from a peer, and it is behind NAT, - the interface might benefit from having a persistent keepalive - interval of 25 seconds. If set to 0 or "off", this option is - disabled. By default or when unspecified, this option is off. - Most users will not need this.</para> + to send an authenticated empty packet to the peer for the purpose + of keeping a stateful firewall or NAT mapping valid persistently. + For example, if the interface very rarely sends traffic, but it + might at anytime receive traffic from a peer, and it is behind NAT, + the interface might benefit from having a persistent keepalive + interval of 25 seconds. If set to 0 or "off", this option is + disabled. By default or when unspecified, this option is off. + Most users will not need this.</para> </listitem> </varlistentry> </variablelist> @@ -1562,9 +1807,9 @@ <term><varname>PacketsPerSlave=</varname></term> <listitem> <para>Specify the number of packets to transmit through a slave before - moving to the next one. When set to 0, then a slave is chosen at - random. The valid range is 0–65535. Defaults to 1. This option - only has effect when in balance-rr mode. + moving to the next one. When set to 0, then a slave is chosen at + random. The valid range is 0–65535. Defaults to 1. This option + only has effect when in balance-rr mode. </para> </listitem> </varlistentry> @@ -1573,13 +1818,13 @@ <term><varname>GratuitousARP=</varname></term> <listitem> <para>Specify the number of peer notifications (gratuitous ARPs and - unsolicited IPv6 Neighbor Advertisements) to be issued after a - failover event. As soon as the link is up on the new slave, - a peer notification is sent on the bonding device and each - VLAN sub-device. This is repeated at each link monitor interval - (ARPIntervalSec or MIIMonitorSec, whichever is active) if the number is - greater than 1. The valid range is 0–255. The default value is 1. - These options affect only the active-backup mode. + unsolicited IPv6 Neighbor Advertisements) to be issued after a + failover event. As soon as the link is up on the new slave, + a peer notification is sent on the bonding device and each + VLAN sub-device. This is repeated at each link monitor interval + (ARPIntervalSec or MIIMonitorSec, whichever is active) if the number is + greater than 1. The valid range is 0–255. The default value is 1. + These options affect only the active-backup mode. </para> </listitem> </varlistentry> @@ -1619,7 +1864,52 @@ <para>For more detail information see <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt"> Linux Ethernet Bonding Driver HOWTO</ulink></para> + </refsect1> + <refsect1> + <title>[Xfrm] Section Options</title> + + <para>The <literal>[Xfrm]</literal> section accepts the following + keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>InterfaceId=</varname></term> + <listitem> + <para>Sets the ID/key of the xfrm interface which needs to be associated with a SA/policy. + Can be decimal or hexadecimal, valid range is 0-0xffffffff, defaults to 0.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Independent=</varname></term> + <listitem> + <para>Takes a boolean. If set to <literal>no</literal>, the xfrm interface should have an + underlying device which can be used for hardware offloading. Defaults to <literal>no</literal>. + See <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for how to configure the underlying device.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>For more detail information see + <ulink url="https://lwn.net/Articles/757391"> + Virtual xfrm interfaces</ulink></para> + </refsect1> + + <refsect1> + <title>[VRF] Section Options</title> + <para>The <literal>[VRF]</literal> section only applies for + netdevs of kind <literal>vrf</literal> and accepts the + following key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Table=</varname></term> + <listitem> + <para>The numeric routing table identifier. This option is compulsory.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> <refsect1> @@ -1806,7 +2096,18 @@ PublicKey=RDf+LSpeEre7YEIKaxg+wbpsNV7du+ktR99uBEtIiCA= AllowedIPs=fd31:bf08:57cb::/48,192.168.26.0/24 Endpoint=wireguard.example.com:51820</programlisting> </example> + + <example> + <title>/etc/systemd/network/27-xfrm.netdev</title> + <programlisting>[Xfrm] +Name=xfrm0 +Kind=xfrm + +[Xfrm] +Independent=yes</programlisting> + </example> </refsect1> + <refsect1> <title>See Also</title> <para> diff --git a/man/systemd.network.xml b/man/systemd.network.xml index 4127084703..155c0868b2 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -57,7 +57,7 @@ <filename>/run/systemd/network</filename> directories. Drop-in files in <filename>/etc</filename> take precedence over those in <filename>/run</filename> which in turn take precedence over those in <filename>/usr/lib</filename>. Drop-in files under any of these - directories take precedence over the main netdev file wherever located.</para> + directories take precedence over the main network file wherever located.</para> <para>Note that an interface without any static IPv6 addresses configured, and neither DHCPv6 nor IPv6LL enabled, shall be considered to have no IPv6 support. IPv6 will be automatically @@ -77,16 +77,20 @@ is applied, all later files are ignored, even if they match as well.</para> - <para>A network file is said to match a device if each of the - entries in the <literal>[Match]</literal> section matches, or if - the section is empty. The following keys are accepted:</para> + <para>A network file is said to match a network interface if all matches specified by the + <literal>[Match]</literal> section are satisfied. When a network file does not contain valid + settings in <literal>[Match]</literal> section, then the file will match all interfaces and + <command>systemd-networkd</command> warns about that. Hint: to avoid the warning and to make it + clear that all interfaces shall be matched, add the following: + <programlisting>Name=*</programlisting> + The following keys are accepted:</para> <variablelist class='network-directives'> <varlistentry> <term><varname>MACAddress=</varname></term> <listitem> <para>A whitespace-separated list of hardware addresses. Use full colon-, hyphen- or dot-delimited hexadecimal. See the example below. - This option may appear more than one, in which case the lists are merged. If the empty string is assigned to this option, the list + This option may appear more than once, in which case the lists are merged. If the empty string is assigned to this option, the list of hardware addresses defined prior to this is reset.</para> <para>Example: @@ -109,7 +113,7 @@ <listitem> <para>A whitespace-separated list of shell-style globs matching the driver currently bound to the device, as - exposed by the udev property <literal>DRIVER</literal> + exposed by the udev property <literal>ID_NET_DRIVER</literal> of its parent device, or if that is not set the driver as exposed by <literal>ethtool -i</literal> of the device itself. If the list is prefixed with a "!", the @@ -135,6 +139,21 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>Property=</varname></term> + <listitem> + <para>A whitespace-separated list of udev property name with its value after a equal + (<literal>=</literal>). If multiple properties are specified, the test results are ANDed. + If the list is prefixed with a "!", the test is inverted. If a value contains white + spaces, then please quote whole key and value pair. If a value contains quotation, then + please escape the quotation with <literal>\</literal>.</para> + + <para>Example: if a .network file has the following: + <programlisting>Property=ID_MODEL_ID=9999 "ID_VENDOR_FROM_DATABASE=vendor name" "KEY=with \"quotation\""</programlisting> + then, the .network file matches only when an interface has all the above three properties. + </para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>Host=</varname></term> <listitem> <para>Matches against the hostname or machine ID of the host. See @@ -305,8 +324,8 @@ specified through DHCP is not used for name resolution. See option <option>UseDomains=</option> below.</para> - <para>See the <literal>[DHCP]</literal> section below for further configuration options for the DHCP client - support.</para> + <para>See the <literal>[DHCPv4]</literal> or <literal>[DHCPv6]</literal> section below for + further configuration options for the DHCP client support.</para> </listitem> </varlistentry> <varlistentry> @@ -322,9 +341,16 @@ <term><varname>LinkLocalAddressing=</varname></term> <listitem> <para>Enables link-local address autoconfiguration. Accepts <literal>yes</literal>, - <literal>no</literal>, <literal>ipv4</literal>, or <literal>ipv6</literal>. If - <varname>Bridge=</varname> is set, defaults to <literal>no</literal>, and if not, - defaults to <literal>ipv6</literal>.</para> + <literal>no</literal>, <literal>ipv4</literal>, <literal>ipv6</literal>, + <literal>fallback</literal>, or <literal>ipv4-fallback</literal>. If + <literal>fallback</literal> or <literal>ipv4-fallback</literal> is specified, then an IPv4 + link-local address is configured only when DHCPv4 fails. If <literal>fallback</literal>, + an IPv6 link-local address is always configured, and if <literal>ipv4-fallback</literal>, + the address is not configured. Note that, the fallback mechanism works only when DHCPv4 + client is enabled, that is, it requires <literal>DHCP=yes</literal> or + <literal>DHCP=ipv4</literal>. If <varname>Bridge=</varname> is set, defaults to + <literal>no</literal>, and if not, defaults to <literal>ipv6</literal>. + </para> </listitem> </varlistentry> <varlistentry> @@ -337,6 +363,15 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>DefaultRouteOnDevice=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, sets up the default route bound to the interface. + Defaults to false. This is useful when creating routes on point-to-point interfaces. + This is equivalent to e.g. the following. + <programlisting>ip route add default dev veth99</programlisting></para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>IPv6Token=</varname></term> <listitem> <para>An IPv6 address with the top 64 bits unset. When set, indicates the @@ -375,12 +410,15 @@ <varlistentry> <term><varname>DNSOverTLS=</varname></term> <listitem> - <para>Takes false or - <literal>opportunistic</literal>. When set to <literal>opportunistic</literal>, enables + <para>Takes a boolean or <literal>opportunistic</literal>. + When true, enables <ulink url="https://tools.ietf.org/html/rfc7858">DNS-over-TLS</ulink> - support on the link. This option defines a - per-interface setting for + support on the link. + When set to <literal>opportunistic</literal>, compatibility with + non-DNS-over-TLS servers is increased, by automatically + turning off DNS-over-TLS servers in this case. + This option defines a per-interface setting for <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s global <varname>DNSOverTLS=</varname> option. Defaults to false. This setting is read by @@ -616,11 +654,10 @@ </varlistentry> <varlistentry> <term><varname>IPv6AcceptRA=</varname></term> - <listitem><para>Takes a boolean. Controls IPv6 Router Advertisement (RA) reception support for the interface. - If true, RAs are accepted; if false, RAs are ignored, independently of the local forwarding state. - If unset, the kernel's default is used, and RAs are accepted only when local forwarding - is disabled for that interface. When RAs are accepted, they may trigger the start of the DHCPv6 client if - the relevant flags are set in the RA data, or if no routers are found on the link.</para> + <listitem><para>Takes a boolean. Controls IPv6 Router Advertisement (RA) reception support + for the interface. If true, RAs are accepted; if false, RAs are ignored, independently of the + local forwarding state. When RAs are accepted, they may trigger the start of the DHCPv6 + client if the relevant flags are set in the RA data, or if no routers are found on the link.</para> <para>Further settings for the IPv6 RA support may be configured in the <literal>[IPv6AcceptRA]</literal> section, see below.</para> @@ -630,10 +667,11 @@ documentation regarding <literal>accept_ra</literal>, but note that systemd's setting of <constant>1</constant> (i.e. true) corresponds to kernel's setting of <constant>2</constant>.</para> - <para>Note that if this option is enabled a userspace implementation of the IPv6 RA protocol is - used, and the kernel's own implementation remains disabled, since `networkd` needs to know all - details supplied in the advertisements, and these are not available from the kernel if the kernel's - own implemenation is used.</para> + <para>Note that kernel's implementation of the IPv6 RA protocol is always disabled, + regardless of this setting. If this option is enabled, a userspace implementation of the IPv6 + RA protocol is used, and the kernel's own implementation remains disabled, since + <command>systemd-networkd</command> needs to know all details supplied in the advertisements, + and these are not available from the kernel if the kernel's own implementation is used.</para> </listitem> </varlistentry> <varlistentry> @@ -768,6 +806,14 @@ This option may be specified more than once.</para> </listitem> </varlistentry> + <varlistentry> + <term><varname>MACsec=</varname></term> + <listitem> + <para>The name of a MACsec device to create on the link. See + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + This option may be specified more than once.</para> + </listitem> + </varlistentry> <varlistentry> <term><varname>ActiveSlave=</varname></term> <listitem> @@ -810,6 +856,30 @@ </para> </listitem> </varlistentry> + <varlistentry> + <term><varname>Xfrm=</varname></term> + <listitem> + <para>The name of the xfrm to create on the link. See + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + This option may be specified more than once.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeepConfiguration=</varname></term> + <listitem> + <para>Takes a boolean or one of <literal>static</literal>, <literal>dhcp-on-stop</literal>, + <literal>dhcp</literal>. When <literal>static</literal>, <command>systemd-networkd</command> + will not drop static addresses and routes on starting up process. When set to + <literal>dhcp-on-stop</literal>, <command>systemd-networkd</command> will not drop addresses + and routes on stopping the daemon. When <literal>dhcp</literal>, + the addresses and routes provided by a DHCP server will never be dropped even if the DHCP + lease expires. This is contrary to the DHCP specification, but may be the best choice if, + e.g., the root filesystem relies on this connection. The setting <literal>dhcp</literal> + implies <literal>dhcp-on-stop</literal>, and <literal>yes</literal> implies + <literal>dhcp</literal> and <literal>static</literal>. Defaults to + <literal>dhcp-on-stop</literal>.</para> + </listitem> + </varlistentry> </variablelist> @@ -946,9 +1016,9 @@ </listitem> </varlistentry> <varlistentry> - <term><varname>MACAddress=</varname></term> + <term><varname>LinkLayerAddress=</varname></term> <listitem> - <para>The hardware address of the neighbor.</para> + <para>The link layer address (MAC address or IP address) of the neighbor.</para> </listitem> </varlistentry> </variablelist> @@ -1016,8 +1086,9 @@ <varlistentry> <term><varname>Table=</varname></term> <listitem> - <para>Specifies the routing table identifier to lookup if the rule - selector matches. The table identifier for a route (a number between 1 and 4294967295).</para> + <para>Specifies the routing table identifier to lookup if the rule selector matches. Takes + one of <literal>default</literal>, <literal>main</literal>, and <literal>local</literal>, + or a number between 1 and 4294967295. Defaults to <literal>main</literal>.</para> </listitem> </varlistentry> <varlistentry> @@ -1065,7 +1136,17 @@ <varlistentry> <term><varname>InvertRule=</varname></term> <listitem> - <para>A boolean. Specifies wheather the rule to be inverted. Defaults to false.</para> + <para>A boolean. Specifies whether the rule to be inverted. Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Family=</varname></term> + <listitem> + <para>Takes a special value <literal>ipv4</literal>, <literal>ipv6</literal>, or + <literal>both</literal>. By default, the address family is determined by the address + specified in <varname>To=</varname> or <varname>From=</varname>. If neither + <varname>To=</varname> nor <varname>From=</varname> are specified, then defaults to + <literal>ipv4</literal>.</para> </listitem> </varlistentry> </variablelist> @@ -1154,15 +1235,19 @@ <term><varname>Protocol=</varname></term> <listitem> <para>The protocol identifier for the route. Takes a number between 0 and 255 or the special values - <literal>kernel</literal>, <literal>boot</literal> and <literal>static</literal>. Defaults to - <literal>static</literal>. + <literal>kernel</literal>, <literal>boot</literal>, <literal>static</literal>, + <literal>ra</literal> and <literal>dhcp</literal>. Defaults to <literal>static</literal>. </para> </listitem> </varlistentry> <varlistentry> <term><varname>Type=</varname></term> <listitem> - <para>Specifies the type for the route. If <literal>unicast</literal>, a regular route is defined, i.e. a + <para>Specifies the type for the route. Takes one of <literal>unicast</literal>, + <literal>local</literal>, <literal>broadcast</literal>, <literal>anycast</literal>, + <literal>multicast</literal>, <literal>blackhole</literal>, <literal>unreachable</literal>, + <literal>prohibit</literal>, <literal>throw</literal>, <literal>nat</literal>, and + <literal>xresolve</literal>. If <literal>unicast</literal>, a regular route is defined, i.e. a route indicating the path to take to a destination network address. If <literal>blackhole</literal>, packets to the defined route are discarded silently. If <literal>unreachable</literal>, packets to the defined route are discarded and the ICMP message "Host Unreachable" is generated. If <literal>prohibit</literal>, packets @@ -1185,7 +1270,7 @@ <varlistentry> <term><varname>InitialAdvertisedReceiveWindow=</varname></term> <listitem> - <para>The TCP initial advertised receive window is the amount of receive data (in bytes) that can initally be buffered at one time + <para>The TCP initial advertised receive window is the amount of receive data (in bytes) that can initially be buffered at one time on a connection. The sending host can send only that amount of data before waiting for an acknowledgment and window update from the receiving host. Takes a size in bytes between 1 and 4294967295 (2^32 - 1). The usual suffixes K, M, G are supported and are understood to the base of 1024. When unset, the kernel's default will be used. @@ -1200,6 +1285,22 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>FastOpenNoCookie=</varname></term> + <listitem> + <para>Takes a boolean. When true enables TCP fastopen without a cookie on a per-route basis. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TTLPropagate=</varname></term> + <listitem> + <para>Takes a boolean. When true enables TTL propagation at Label Switched Path (LSP) egress. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>MTUBytes=</varname></term> <listitem> <para>The maximum transmission unit in bytes to set for the @@ -1213,9 +1314,9 @@ </refsect1> <refsect1> - <title>[DHCP] Section Options</title> - <para>The <literal>[DHCP]</literal> section configures the - DHCPv4 and DHCP6 client, if it is enabled with the + <title>[DHCPv4] Section Options</title> + <para>The <literal>[DHCPv4]</literal> section configures the + DHCPv4 client, if it is enabled with the <varname>DHCP=</varname> setting described above:</para> <variablelist class='network-directives'> @@ -1232,6 +1333,14 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>RoutesToDNS=</varname></term> + <listitem> + <para>When true, the routes to the DNS servers received from the DHCP server will be + configured. When <varname>UseDNS=</varname> is disabled, this setting is ignored. + Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>UseNTP=</varname></term> <listitem> <para>When true (the default), the NTP servers received @@ -1338,17 +1447,6 @@ </varlistentry> <varlistentry> - <term><varname>CriticalConnection=</varname></term> - <listitem> - <para>When true, the connection will never be torn down - even if the DHCP lease expires. This is contrary to the - DHCP specification, but may be the best choice if, say, - the root filesystem relies on this connection. Defaults to - false.</para> - </listitem> - </varlistentry> - - <varlistentry> <term><varname>ClientIdentifier=</varname></term> <listitem> <para>The DHCPv4 client identifier to use. Takes one of <literal>mac</literal>, <literal>duid</literal> or <literal>duid-only</literal>. @@ -1378,6 +1476,16 @@ </varlistentry> <varlistentry> + <term><varname>MaxAttempts=</varname></term> + <listitem> + <para>Specifies how many times the DHCPv4 client configuration should be attempted. Takes a + number or <literal>infinity</literal>. Defaults to <literal>infinity</literal>. + Note that the time between retries is increased exponentially, so the network will not be + overloaded even if this number is high.</para> + </listitem> + </varlistentry> + + <varlistentry> <term><varname>DUIDType=</varname></term> <listitem> <para>Override the global <varname>DUIDType</varname> setting for this network. See @@ -1442,6 +1550,38 @@ </varlistentry> <varlistentry> + <term><varname>SendRelease=</varname></term> + <listitem> + <para>When true, the DHCPv4 client sends a DHCP release packet when it stops. + Defaults to false.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BlackList=</varname></term> + <listitem> + <para>A whitespace-separated list of IPv4 addresses. DHCP offers from servers in the list are rejected.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCPv6] Section Options</title> + <para>The <literal>[DHCPv6]</literal> section configures the DHCPv6 client, if it is enabled with the + <varname>DHCP=</varname> setting described above, or invoked by the IPv6 Router Advertisement:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>UseDNS=</varname></term> + <term><varname>UseNTP=</varname></term> + <listitem> + <para>As in the <literal>[DHCPv4]</literal> section.</para> + </listitem> + </varlistentry> + + <varlistentry> <term><varname>RapidCommit=</varname></term> <listitem> <para>Takes a boolean. The DHCPv6 client can obtain configuration parameters from a DHCPv6 server through @@ -1471,7 +1611,7 @@ </varlistentry> </variablelist> - </refsect1> + </refsect1> <refsect1> <title>[IPv6AcceptRA] Section Options</title> @@ -1537,6 +1677,13 @@ </listitem> </varlistentry> + <varlistentry> + <term><varname>BlackList=</varname></term> + <listitem> + <para>A whitespace-separated list of IPv6 prefixes. IPv6 prefixes supplied via router advertisements in the list are ignored.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> @@ -1865,6 +2012,32 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>ProxyARP=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether proxy ARP to be enabled on this port. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ProxyARPWiFi=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether proxy ARP to be enabled on this port + which meets extended requirements by IEEE 802.11 and Hotspot 2.0 specifications. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastRouter=</varname></term> + <listitem> + <para>Configures this port for having multicast routers attached. A port with a multicast + router will receive all multicast traffic. Takes one of <literal>no</literal> + to disable multicast routers on this port, <literal>query</literal> to let the system detect + the presence of routers, <literal>permanent</literal> to permanently enable multicast traffic + forwarding on this port, or <literal>temporary</literal> to enable multicast routers temporarily + on this port, not depending on incoming queries. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>Cost=</varname></term> <listitem> <para>Sets the "cost" of sending packets of this interface. @@ -1902,6 +2075,12 @@ </listitem> </varlistentry> <varlistentry> + <term><varname>Destination=</varname></term> + <listitem> + <para>Takes an IP address of the destination VXLAN tunnel endpoint.</para> + </listitem> + </varlistentry> + <varlistentry> <term><varname>VLANId=</varname></term> <listitem> <para>The VLAN ID for the new static MAC table entry. If @@ -1909,6 +2088,27 @@ table entry.</para> </listitem> </varlistentry> + <varlistentry> + <term><varname>VNI=</varname></term> + <listitem> + <para>The VXLAN Network Identifier (or VXLAN Segment ID) to use to connect to + the remote VXLAN tunnel endpoint. Takes a number in the range 1-16777215. + Defaults to unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AssociatedWith=</varname></term> + <listitem> + <para>Specifies where the address is associated with. Takes one of <literal>use</literal>, + <literal>self</literal>, <literal>master</literal> or <literal>router</literal>. + <literal>use</literal> means the address is in use. User space can use this option to + indicate to the kernel that the fdb entry is in use. <literal>self</literal> means + the address is associated with the port drivers fdb. Usually hardware. <literal>master</literal> + means the address is associated with master devices fdb. <literal>router</literal> means + the destination address is associated with a router. Note that it's valid if the referenced + device is a VXLAN type device and has route shortcircuit enabled. Defaults to <literal>self</literal>.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> @@ -2017,6 +2217,27 @@ DHCP=yes</programlisting> </example> <example> + <title>IPv6 Prefix Delegation</title> + + <programlisting># /etc/systemd/network/55-ipv6-pd-upstream.network +[Match] +Name=enp1s0 + +[Network] +DHCP=ipv6</programlisting> + + <programlisting># /etc/systemd/network/56-ipv6-pd-downstream.network +[Match] +Name=enp2s0 + +[Network] +IPv6PrefixDelegation=dhcpv6</programlisting> + + <para>This will enable IPv6 PD on the interface enp1s0 as an upstream interface where the + DHCPv6 client is running and enp2s0 as a downstream interface where the prefix is delegated to.</para> + </example> + + <example> <title>A bridge with two enslaved links</title> <programlisting># /etc/systemd/network/25-bridge-static.network @@ -2186,6 +2407,29 @@ Name=enp0s25 MACVTAP=macvtap-test </programlisting> </example> + + <example> + <title>A Xfrm interface with physical underlying device.</title> + + <programlisting># /etc/systemd/network/27-xfrm.netdev +[NetDev] +Name=xfrm0 + +[Xfrm] +InterfaceId=7</programlisting> + + <programlisting># /etc/systemd/network/27-eth0.network +[Match] +Name=eth0 + +[Network] +Xfrm=xfrm0</programlisting> + + <para>This creates a <literal>xfrm0</literal> interface and binds it to the <literal>eth0</literal> device. + This allows hardware based ipsec offloading to the <literal>eth0</literal> nic. + If offloading is not needed, xfrm interfaces can be assigned to the <literal>lo</literal> device. + </para> + </example> </refsect1> <refsect1> diff --git a/man/systemd.nspawn.xml b/man/systemd.nspawn.xml index 1485a26f02..787d5fd699 100644 --- a/man/systemd.nspawn.xml +++ b/man/systemd.nspawn.xml @@ -119,8 +119,8 @@ specified parameters using <varname>Parameters=</varname> are passed as additional arguments to the <filename>init</filename> process. This setting corresponds to the <option>--boot</option> switch on the <command>systemd-nspawn</command> command line. This option may not be combined with - <varname>ProcessTwo=yes</varname>. This option is the default if the - <filename>systemd-nspawn@.service</filename> template unit file is used.</para></listitem> + <varname>ProcessTwo=yes</varname>. This option is specified by default in the + <filename>systemd-nspawn@.service</filename> template unit.</para></listitem> </varlistentry> <varlistentry> @@ -145,13 +145,15 @@ <varlistentry> <term><varname>Parameters=</varname></term> - <listitem><para>Takes a space-separated list of - arguments. This is either a command line, beginning with the - binary name to execute, or – if <varname>Boot=</varname> is - enabled – the list of arguments to pass to the init - process. This setting corresponds to the command line - parameters passed on the <command>systemd-nspawn</command> - command line.</para></listitem> + <listitem><para>Takes a whitespace-separated list of arguments. Single (<literal>'</literal>) and + double (<literal>"</literal>) quotes may be used around arguments with whitespace. This is either a + command line, beginning with the binary name to execute, or – if <varname>Boot=</varname> is enabled + – the list of arguments to pass to the init process. This setting corresponds to the command line + parameters passed on the <command>systemd-nspawn</command> command line.</para> + + <para>Note: <option>Boot=no</option>, <option>Parameters=a b "c c"</option> is the same as + <command>systemd-nspawn a b "c c"</command>, and <option>Boot=yes</option>, <option>Parameters=b 'c c'</option> + is the same as <command>systemd-nspawn --boot b 'c c'</command>.</para></listitem> </varlistentry> <varlistentry> @@ -429,7 +431,7 @@ <term><varname>Inaccessible=</varname></term> <listitem><para>Masks the specified file or directly in the container, by over-mounting it with an empty file - node of the same type with the most restrictive access mode. Takes a file system path as arugment. This option + node of the same type with the most restrictive access mode. Takes a file system path as argument. This option may be used multiple times to mask multiple files or directories. This option is equivalent to the command line switch <option>--inaccessible=</option>, see <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details diff --git a/man/systemd.offline-updates.xml b/man/systemd.offline-updates.xml index cd9c1b5865..06390669de 100644 --- a/man/systemd.offline-updates.xml +++ b/man/systemd.offline-updates.xml @@ -133,7 +133,7 @@ <listitem> <para>The update service should declare <varname>DefaultDependencies=no</varname>, <varname>Requires=sysinit.target</varname>, <varname>After=sysinit.target</varname>, - <varname>After=system-update-pre.target</varname> + <varname>After=system-update-pre.target</varname>, <varname>Before=system-update.target</varname> and explicitly pull in any other services it requires.</para> </listitem> diff --git a/man/systemd.path.xml b/man/systemd.path.xml index de284d877e..39cca8cf51 100644 --- a/man/systemd.path.xml +++ b/man/systemd.path.xml @@ -34,9 +34,9 @@ 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 [Unit] and - [Install] sections. The path specific configuration options are - configured in the [Path] section.</para> + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. The path specific configuration options are + configured in the <literal>[Path]</literal> section.</para> <para>For each path file, a matching unit file must exist, describing the unit to activate when the path changes. By default, diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml index 4a8c57f45a..d8fa24727a 100644 --- a/man/systemd.resource-control.xml +++ b/man/systemd.resource-control.xml @@ -245,6 +245,10 @@ <para>This setting is supported only if the unified control group hierarchy is used and disables <varname>MemoryLimit=</varname>.</para> + + <para>Units may have their children use a default <literal>memory.min</literal> value by specifying + <varname>DefaultMemoryMin=</varname>, which has the same semantics as <varname>MemoryMin=</varname>. This setting + does not affect <literal>memory.min</literal> in the unit itself.</para> </listitem> </varlistentry> @@ -265,6 +269,10 @@ <para>This setting is supported only if the unified control group hierarchy is used and disables <varname>MemoryLimit=</varname>.</para> + + <para>Units may have their children use a default <literal>memory.low</literal> value by specifying + <varname>DefaultMemoryLow=</varname>, which has the same semantics as <varname>MemoryLow=</varname>. This setting + does not affect <literal>memory.low</literal> in the unit itself.</para> </listitem> </varlistentry> @@ -611,40 +619,80 @@ </varlistentry> <varlistentry> + <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAMM_PATH</replaceable></varname></term> + <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAMM_PATH</replaceable></varname></term> + + <listitem> + <para>Add custom network traffic filters implemented as BPF programs, applying to all IP packets + sent and received over <constant>AF_INET</constant> and <constant>AF_INET6</constant> sockets. + Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (<filename>/sys/fs/bpf/</filename>). + </para> + + <para>The filters configured with this option are applied to all sockets created by processes + of this unit (or in the case of socket units, associated with it). The filters are loaded in addition + to filters any of the parent slice units this unit might be a member of as well as any + <varname>IPAddressAllow=</varname> and <varname>IPAddressDeny=</varname> filters in any of these units. + By default there are no filters specified.</para> + + <para>If these settings are used multiple times in the same unit all the specified programs are attached. If an + empty string is assigned to these settings the program list is reset and all previous specified programs ignored.</para> + + <para>Note that for socket-activated services, the IP filter programs configured on the socket unit apply to + all sockets associated with it directly, but not to any sockets created by the ultimately activated services + for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into + the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both + the socket and the service unit, however it often makes sense to maintain one configuration more open and the other + one more restricted, depending on the usecase.</para> + + <para>Note that these settings might not be supported on some systems (for example if eBPF control group + support is not enabled in the underlying kernel or container manager). These settings will fail the service in + that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually + (requires <varname>Delegate=</varname><constant>yes</constant>) instead of using this setting.</para> + </listitem> + </varlistentry> + + <varlistentry> <term><varname>DeviceAllow=</varname></term> <listitem> - <para>Control access to specific device nodes by the - executed processes. Takes two space-separated strings: a - device node specifier followed by a combination of - <constant>r</constant>, <constant>w</constant>, - <constant>m</constant> to control - <emphasis>r</emphasis>eading, <emphasis>w</emphasis>riting, - or creation of the specific device node(s) by the unit - (<emphasis>m</emphasis>knod), respectively. This controls - the <literal>devices.allow</literal> and - <literal>devices.deny</literal> control group - attributes. For details about these control group - attributes, see <ulink - url="https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt">devices.txt</ulink>.</para> - - <para>The device node specifier is either a path to a device - node in the file system, starting with - <filename>/dev/</filename>, or a string starting with either - <literal>char-</literal> or <literal>block-</literal> - followed by a device group name, as listed in - <filename>/proc/devices</filename>. The latter is useful to - whitelist all current and future devices belonging to a - specific device group at once. The device group is matched - according to filename globbing rules, you may hence use the - <literal>*</literal> and <literal>?</literal> - wildcards. Examples: <filename>/dev/sda5</filename> is a - path to a device node, referring to an ATA or SCSI block - device. <literal>char-pts</literal> and - <literal>char-alsa</literal> are specifiers for all pseudo - TTYs and all ALSA sound devices, - respectively. <literal>char-cpu/*</literal> is a specifier - matching all CPU related device groups.</para> + <para>Control access to specific device nodes by the executed processes. Takes two space-separated + strings: a device node specifier followed by a combination of <constant>r</constant>, + <constant>w</constant>, <constant>m</constant> to control <emphasis>r</emphasis>eading, + <emphasis>w</emphasis>riting, or creation of the specific device node(s) by the unit + (<emphasis>m</emphasis>knod), respectively. On cgroup-v1 this controls the + <literal>devices.allow</literal> control group attribute. For details about this control group + attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt">devices.txt</ulink>. On + cgroup-v2 this functionality is implemented using eBPF filtering.</para> + + <para>The device node specifier is either a path to a device node in the file system, starting with + <filename>/dev/</filename>, or a string starting with either <literal>char-</literal> or + <literal>block-</literal> followed by a device group name, as listed in + <filename>/proc/devices</filename>. The latter is useful to whitelist all current and future + devices belonging to a specific device group at once. The device group is matched according to + filename globbing rules, you may hence use the <literal>*</literal> and <literal>?</literal> + wildcards. (Note that such globbing wildcards are not available for device node path + specifications!) In order to match device nodes by numeric major/minor, use device node paths in + the <filename>/dev/char/</filename> and <filename>/dev/block/</filename> directories. However, + matching devices by major/minor is generally not recommended as assignments are neither stable nor + portable between systems or different kernel versions.</para> + + <para>Examples: <filename>/dev/sda5</filename> is a path to a device node, referring to an ATA or + SCSI block device. <literal>char-pts</literal> and <literal>char-alsa</literal> are specifiers for + all pseudo TTYs and all ALSA sound devices, respectively. <literal>char-cpu/*</literal> is a + specifier matching all CPU related device groups.</para> + + <para>Note that whitelists defined this way should only reference device groups which are + resolvable at the time the unit is started. Any device groups not resolvable then are not added to + the device whitelist. In order to work around this limitation, consider extending service units + with an <command>ExecStartPre=/sbin/modprobe…</command> line that loads the necessary + kernel module implementing the device group if missing. Example: <programlisting>… +[Service] +ExecStartPre=-/sbin/modprobe -abq loop +DeviceAllow=block-loop +DeviceAllow=/dev/loop-control +…</programlisting></para> + </listitem> </varlistentry> diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 5b88417530..40ac052ba5 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -191,11 +191,17 @@ main process of the service. systemd will proceed with starting follow-up units as soon as the parent process exits.</para></listitem> - <listitem><para>Behavior of <option>oneshot</option> is similar to <option>simple</option>; however, the - service manager will consider the unit started after the main process exits. It will then start follow-up - units. <varname>RemainAfterExit=</varname> is particularly useful for this type of - service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither - <varname>Type=</varname> nor <varname>ExecStart=</varname> are specified.</para></listitem> + <listitem><para>Behavior of <option>oneshot</option> is similar to <option>simple</option>; + however, the service manager will consider the unit up after the main process exits. It will then + start follow-up units. <varname>RemainAfterExit=</varname> is particularly useful for this type + of service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither + <varname>Type=</varname> nor <varname>ExecStart=</varname> are specified. Note that if this + option is used without <varname>RemainAfterExit=</varname> the service will never enter + <literal>active</literal> unit state, but directly transition from <literal>activating</literal> + to <literal>deactivating</literal> or <literal>dead</literal> since no process is configured that + shall run continously. In particular this means that after a service of this type ran (and which + has <varname>RemainAfterExit=</varname> not set) it will not show up as started afterwards, but + as dead.</para></listitem> <listitem><para>Behavior of <option>dbus</option> is similar to <option>simple</option>; however, it is expected that the service acquires a name on the D-Bus bus, as configured by @@ -422,6 +428,26 @@ </varlistentry> <varlistentry> + <term><varname>ExecCondition=</varname></term> + <listitem><para>Optional commands that are executed before the command(s) in <varname>ExecStartPre=</varname>. + Syntax is the same as for <varname>ExecStart=</varname>, except that multiple command lines are allowed and the + commands are executed one after the other, serially.</para> + + <para>The behavior is like an <varname>ExecStartPre=</varname> and condition check hybrid: when an + <varname>ExecCondition=</varname> command exits with exit code 1 through 254 (inclusive), the remaining + commands are skipped and the unit is <emphasis>not</emphasis> marked as failed. However, if an + <varname>ExecCondition=</varname> command exits with 255 or abnormally (e.g. timeout, killed by a + signal, etc.), the unit will be considered failed (and remaining commands will be skipped). Exit code of 0 or + those matching <varname>SuccessExitStatus=</varname> will continue execution to the next command(s).</para> + + <para>The same recommendations about not running long-running processes in <varname>ExecStartPre=</varname> + also applies to <varname>ExecCondition=</varname>. <varname>ExecCondition=</varname> will also run the commands + in <varname>ExecStopPost=</varname>, as part of stopping the service, in the case of any non-zero or abnormal + exits, like the ones described above.</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 @@ -574,6 +600,35 @@ </varlistentry> <varlistentry> + <term><varname>TimeoutAbortSec=</varname></term> + <listitem><para>This option configures the time to wait for the service to terminate when it was aborted due to a + watchdog timeout (see <varname>WatchdogSec=</varname>). If the service has a short <varname>TimeoutStopSec=</varname> + this option can be used to give the system more time to write a core dump of the service. Upon expiration the service + will be forcibly terminated by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). The core file will + be truncated in this case. Use <varname>TimeoutAbortSec=</varname> to set a sensible timeout for the core dumping per + service that is large enough to write all expected data while also being short enough to handle the service failure + in due time. + </para> + + <para>Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass an empty value to skip + the dedicated watchdog abort timeout handling and fall back <varname>TimeoutStopSec=</varname>. Pass + <literal>infinity</literal> to disable the timeout logic. Defaults to <varname>DefaultTimeoutAbortSec=</varname> from + the manager configuration file (see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + </para> + + <para>If a service of <varname>Type=notify</varname> handles <constant>SIGABRT</constant> itself (instead of relying + on the kernel to write a core dump) it can send <literal>EXTEND_TIMEOUT_USEC=…</literal> to + extended the abort time beyond <varname>TimeoutAbortSec=</varname>. The first receipt of this message + must occur before <varname>TimeoutAbortSec=</varname> is exceeded, and once the abort time has exended beyond + <varname>TimeoutAbortSec=</varname>, the service manager will allow the service to continue to abort, provided + the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified, or terminates itself + (see <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> <term><varname>TimeoutSec=</varname></term> <listitem><para>A shorthand for configuring both <varname>TimeoutStartSec=</varname> and @@ -582,6 +637,16 @@ </varlistentry> <varlistentry> + <term><varname>TimeoutCleanSec=</varname></term> + <listitem><para>Configures a timeout on the clean-up operation requested through <command>systemctl + clean …</command>, see + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details. Takes the usual time values and defaults to <constant>infinity</constant>, i.e. by default + no time-out is applied. If a time-out is configured the clean operation will be aborted forcibly when + the time-out is reached, potentially leaving resources on disk.</para></listitem> + </varlistentry> + + <varlistentry> <term><varname>RuntimeMaxSec=</varname></term> <listitem><para>Configures a maximum time for the service to run. If this is used and the service has been @@ -787,27 +852,35 @@ <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 <constant>SIGHUP</constant>, - <constant>SIGINT</constant>, <constant>SIGTERM</constant>, and - <constant>SIGPIPE</constant>. Exit status definitions can - either be numeric exit codes or termination signal names, - separated by spaces. For example: - - <programlisting>SuccessExitStatus=1 2 8 SIGKILL</programlisting> - - ensures that exit codes 1, 2, 8 and - the termination signal <constant>SIGKILL</constant> are - considered clean service terminations. - </para> + <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 <constant>SIGHUP</constant>, <constant>SIGINT</constant>, + <constant>SIGTERM</constant>, and <constant>SIGPIPE</constant>. Exit status definitions can be + numeric exit codes, termination code names, or termination signal names, separated by spaces. See the + Process Exit Codes section in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + a list of termination codes names (for this setting only the part without the + <literal>EXIT_</literal> or <literal>EX_</literal> prefix should be used). See + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + a list of signal names.</para> <para>This option may appear more than once, in which case the list of successful exit statuses is merged. If the empty string is assigned to this option, the list is reset, all prior assignments of this option will have no - effect.</para></listitem> + effect.</para> + + <example> + <title>A service with with the the <varname>SuccessExitStatus=</varname> setting</title> + + <programlisting>SuccessExitStatus=TEMPFAIL 250 SIGUSR1</programlisting> + + <para>Exit codes 75 (<constant>TEMPFAIL</constant>), 250, and the termination signal + <constant>SIGKILL</constant> are considered clean service terminations.</para> + </example> + + <para>Note: <command>systemd-analyze exit-codes</command> may be used to list exit + codes and translate between numerical code values and names.</para></listitem> </varlistentry> <varlistentry> @@ -916,11 +989,9 @@ inverse of the <varname>Sockets=</varname> setting of the <filename>.service</filename> it refers to.</para> - <para>This option may appear more than once, in which case the - list of socket units is merged. If the empty string is - assigned to this option, the list of sockets is reset, and all - prior uses of this setting will have no - effect.</para></listitem> + <para>This option may appear more than once, in which case the list of socket units is merged. Note + that once set, clearing the list of sockets again (for example, by assigning the empty string to this + option) is not supported.</para></listitem> </varlistentry> <varlistentry> @@ -963,6 +1034,29 @@ above.</para></listitem> </varlistentry> + <varlistentry> + <term><varname>OOMPolicy=</varname></term> + + <listitem><para>Configure the Out-Of-Memory (OOM) killer policy. On Linux, when memory becomes scarce + the kernel might decide to kill a running process in order to free up memory and reduce memory + pressure. This setting takes one of <constant>continue</constant>, <constant>stop</constant> or + <constant>kill</constant>. If set to <constant>continue</constant> and a process of the service is + killed by the kernel's OOM killer this is logged but the service continues running. If set to + <constant>stop</constant> the event is logged but the service is terminated cleanly by the service + manager. If set to <constant>kill</constant> and one of the service's processes is killed by the OOM + killer the kernel is instructed to kill all remaining processes of the service, too. Defaults to the + setting <varname>DefaultOOMPolicy=</varname> in + <citerefentry><refentrytitle>system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> is + set to, except for services where <varname>Delegate=</varname> is turned on, where it defaults to + <constant>continue</constant>.</para> + + <para>Use the <varname>OOMScoreAdjust=</varname> setting to configure whether processes of the unit + shall be considered preferred or less preferred candidates for process termination by the Linux OOM + killer logic. See + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + </variablelist> <para>Check diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml index 5019bf9976..7157dfa32d 100644 --- a/man/systemd.slice.xml +++ b/man/systemd.slice.xml @@ -55,9 +55,9 @@ <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 [Unit] and [Install] sections. The + in the generic <literal>[Unit]</literal> and <literal>[Install]</literal> sections. The slice specific configuration options are configured in - the [Slice] section. Currently, only generic resource control settings + the <literal>[Slice]</literal> section. Currently, only generic resource control settings as described in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> are allowed. </para> diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index e29602b068..60ea63f742 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -35,9 +35,9 @@ 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 [Unit] and - [Install] sections. The socket specific configuration options are - configured in the [Socket] section.</para> + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. The socket specific configuration options are + configured in the <literal>[Socket]</literal> section.</para> <para>Additional options are listed in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, @@ -51,11 +51,11 @@ which configure resource control settings for the processes of the socket.</para> - <para>For each socket file, a matching service file must exist, + <para>For each socket unit, a matching service unit must exist, describing the service to start on incoming traffic on the socket (see <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> - for more information about .service files). The name of the + for more information about .service units). The name of the .service unit is by default the same as the name of the .socket unit, but can be altered with the <option>Service=</option> option described below. Depending on the setting of the @@ -66,7 +66,7 @@ socket file <filename>foo.socket</filename> needs a matching service <filename>foo.service</filename> if <option>Accept=no</option> is set. If - <option>Accept=yes</option> is set, a service template file + <option>Accept=yes</option> is set, a service template <filename>foo@.service</filename> must exist from which services are instantiated for each incoming connection.</para> diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml index 66d63503db..23547bb273 100644 --- a/man/systemd.swap.xml +++ b/man/systemd.swap.xml @@ -37,9 +37,9 @@ 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 [Unit] and - [Install] sections. The swap specific configuration options are - configured in the [Swap] section.</para> + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. The swap specific configuration options are + configured in the <literal>[Swap]</literal> section.</para> <para>Additional options are listed in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, @@ -148,7 +148,7 @@ <listitem><para>The swap structure will be initialized on the device. If the device is not "empty", i.e. it contains any signature, the operation will be skipped. It is hence expected - that this option remains set even after the device has been initalized.</para> + that this option remains set even after the device has been initialized.</para> <para>Note that this option can only be used in <filename>/etc/fstab</filename>, and will be ignored when part of the <varname>Options=</varname> setting in a unit file.</para> diff --git a/man/systemd.target.xml b/man/systemd.target.xml index a706a4588a..3052b17786 100644 --- a/man/systemd.target.xml +++ b/man/systemd.target.xml @@ -34,8 +34,8 @@ <para>This unit type has no specific options. 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 [Unit] and - [Install] sections. A separate [Target] section does not exist, + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. A separate <literal>[Target]</literal> section does not exist, since no target-specific options may be configured.</para> <para>Target units do not offer any additional functionality on diff --git a/man/systemd.time.xml b/man/systemd.time.xml index 4a6b808c02..c7d5f24b3c 100644 --- a/man/systemd.time.xml +++ b/man/systemd.time.xml @@ -173,6 +173,10 @@ tomorrow Pacific/Auckland → Thu 2012-11-23 19:00:00 <programlisting>2 months 5 days ago</programlisting> <para>Note that a relative timestamp is also accepted where a timestamp is expected (see above).</para> + + <para>Use the <command>timestamp</command> command of + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> to + validate and normalize timestamps for testing purposes.</para> </refsect1> <refsect1> diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml index 6a13e52ccf..ebf6de4eb2 100644 --- a/man/systemd.timer.xml +++ b/man/systemd.timer.xml @@ -35,9 +35,9 @@ 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 [Unit] and - [Install] sections. The timer specific configuration options are - configured in the [Timer] section.</para> + configuration items are configured in the generic <literal>[Unit]</literal> and + <literal>[Install]</literal> sections. The timer specific configuration options are + configured in the <literal>[Timer]</literal> section.</para> <para>For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. By @@ -286,35 +286,38 @@ <varlistentry> <term><varname>Persistent=</varname></term> - <listitem><para>Takes a boolean argument. If true, the time - when the service unit was last triggered is stored on disk. - When the timer is activated, the service unit is triggered - immediately if it would have been triggered at least once - during the time when the timer was inactive. This is useful to - catch up on missed runs of the service when the machine was - off. Note that this setting only has an effect on timers - configured with <varname>OnCalendar=</varname>. Defaults - to <varname>false</varname>. - </para></listitem> + <listitem><para>Takes a boolean argument. If true, the time when the service unit was last triggered + is stored on disk. When the timer is activated, the service unit is triggered immediately if it + would have been triggered at least once during the time when the timer was inactive. This is useful + to catch up on missed runs of the service when the system was powered down. Note that this setting + only has an effect on timers configured with <varname>OnCalendar=</varname>. Defaults to + <varname>false</varname>.</para> + + <para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp + file maintained by this option from disk. In particular, use this command before uninstalling a timer + unit. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> </varlistentry> <varlistentry> <term><varname>WakeSystem=</varname></term> - <listitem><para>Takes a boolean argument. If true, an elapsing - timer will cause the system to resume from suspend, should it - be suspended and if the system supports this. Note that this - option will only make sure the system resumes on the - appropriate times, it will not take care of suspending it - again after any work that is to be done is finished. Defaults - to <varname>false</varname>.</para></listitem> + <listitem><para>Takes a boolean argument. If true, an elapsing timer will cause the system to resume + from suspend, should it be suspended and if the system supports this. Note that this option will only + make sure the system resumes on the appropriate times, it will not take care of suspending it again + after any work that is to be done is finished. Defaults to + <varname>false</varname>.</para> + + <para>Note that this functionality requires privileges and is thus generally only available in the + system service manager.</para></listitem> </varlistentry> <varlistentry> <term><varname>RemainAfterElapse=</varname></term> <listitem><para>Takes a boolean argument. If true, an elapsed - timer will stay loaded, and its state remains queriable. If + timer will stay loaded, and its state remains queryable. If false, an elapsed timer unit that cannot elapse anymore is unloaded. Turning this off is particularly useful for transient timer units that shall disappear after they first diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 81a02253ed..acb09d005d 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -104,16 +104,24 @@ <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>. </para> - <para>Unit files are loaded from a set of paths determined during - compilation, described in the next section.</para> - - <para>Unit files can be parameterized by a single argument called the "instance name". The unit - is then constructed based on a "template file" which serves as the definition of multiple - services or other units. A template unit must have a single <literal>@</literal> at the end of - the name (right before the type suffix). The name of the full unit is formed by inserting the - instance name between <literal>@</literal> and the unit type suffix. In the unit file itself, - the instance parameter may be referred to using <literal>%i</literal> and other specifiers, see - below.</para> + <para>Unit files are loaded from a set of paths determined during compilation, described in the next + section.</para> + + <para>Valid unit names consist of a "name prefix" and a dot and a suffix specifying the unit type. The + "unit prefix" must consist of one or more valid characters (ASCII letters, digits, <literal>:</literal>, + <literal>-</literal>, <literal>_</literal>, <literal>.</literal>, and <literal>\</literal>). The total + length of the unit name including the suffix must not exceed 256 characters. The type suffix must be one + of <literal>.service</literal>, <literal>.socket</literal>, <literal>.device</literal>, + <literal>.mount</literal>, <literal>.automount</literal>, <literal>.swap</literal>, + <literal>.target</literal>, <literal>.path</literal>, <literal>.timer</literal>, + <literal>.slice</literal>, or <literal>.scope</literal>.</para> + + <para>Units names can be parameterized by a single argument called the "instance name". The unit is then + constructed based on a "template file" which serves as the definition of multiple services or other + units. A template unit must have a single <literal>@</literal> at the end of the name (right before the + type suffix). The name of the full unit is formed by inserting the instance name between + <literal>@</literal> and the unit type suffix. In the unit file itself, the instance parameter may be + referred to using <literal>%i</literal> and other specifiers, see below.</para> <para>Unit files may contain additional options on top of those listed here. If systemd encounters an unknown option, it will @@ -123,34 +131,40 @@ do not need the prefix. Applications may use this to include additional information in the unit files.</para> - <para>Units can be aliased (have an alternative name), by creating a symlink from the new name - to the existing name in one of the unit search paths. For example, - <filename>systemd-networkd.service</filename> has the alias - <filename>dbus-org.freedesktop.network1.service</filename>, created during installation as the - symlink <filename>/usr/lib/systemd/system/dbus-org.freedesktop.network1.service</filename>. In - addition, unit files may specify aliases through the <varname>Alias=</varname> directive in the - [Install] section; those aliases are only effective when the unit is enabled. When the unit is - enabled, symlinks will be created for those names, and removed when the unit is disabled. For - example, <filename>reboot.target</filename> specifies - <varname>Alias=ctrl-alt-del.target</varname>, so when enabled it will be invoked whenever - CTRL+ALT+DEL is pressed. Alias names may be used in commands like <command>enable</command>, - <command>disable</command>, <command>start</command>, <command>stop</command>, - <command>status</command>, …, and in unit dependency directives <varname>Wants=</varname>, - <varname>Requires=</varname>, <varname>Before=</varname>, <varname>After=</varname>, …, with the - limitation that aliases specified through <varname>Alias=</varname> are only effective when the - unit is enabled. Aliases cannot be used with the <command>preset</command> command.</para> + <para>Units can be aliased (have an alternative name), by creating a symlink from the new name to the + existing name in one of the unit search paths. For example, <filename>systemd-networkd.service</filename> + has the alias <filename>dbus-org.freedesktop.network1.service</filename>, created during installation as + a symlink, so when <command>systemd</command> is asked through D-Bus to load + <filename>dbus-org.freedesktop.network1.service</filename>, it'll load + <filename>systemd-networkd.service</filename>. Alias names may be used in commands like + <command>enable</command>, <command>disable</command>, <command>start</command>, <command>stop</command>, + <command>status</command>, and similar, and in all unit dependency directives, including + <varname>Wants=</varname>, <varname>Requires=</varname>, <varname>Before=</varname>, + <varname>After=</varname>. Aliases cannot be used with the <command>preset</command> command.</para> + + <para>Unit files may specify aliases through the <varname>Alias=</varname> directive in the [Install] + section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is + disabled. For example, <filename>reboot.target</filename> specifies + <varname>Alias=ctrl-alt-del.target</varname>, so when enabled, the symlink + <filename>/etc/systemd/systemd/ctrl-alt-del.service</filename> pointing to the + <filename>reboot.target</filename> file will be created, and when + <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> is invoked, + <command>systemd</command> will look for the <filename>ctrl-alt-del.service</filename> and execute + <filename>reboot.service</filename>. <command>systemd</command> does not look at the [Install] section at + all during normal operation, so any directives in that section only have an effect through the symlinks + created during enablement.</para> <para>Along with a unit file <filename>foo.service</filename>, the directory - <filename>foo.service.wants/</filename> may exist. All unit files symlinked from such a - directory are implicitly added as dependencies of type <varname>Wants=</varname> to the unit. - This is useful to hook units into the start-up of other units, without having to modify their - unit files. For details about the semantics of <varname>Wants=</varname>, see below. The - preferred way to create symlinks in the <filename>.wants/</filename> directory of a unit file is - with the <command>enable</command> command of the - <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> - tool which reads information from the [Install] section of unit files (see below). A similar - functionality exists for <varname>Requires=</varname> type dependencies as well, the directory - suffix is <filename>.requires/</filename> in this case.</para> + <filename>foo.service.wants/</filename> may exist. All unit files symlinked from such a directory are + implicitly added as dependencies of type <varname>Wants=</varname> to the unit. Similar functionality + exists for <varname>Requires=</varname> type dependencies as well, the directory suffix is + <filename>.requires/</filename> in this case. This functionality is useful to hook units into the + start-up of other units, without having to modify their unit files. For details about the semantics of + <varname>Wants=</varname>, see below. The preferred way to create symlinks in the + <filename>.wants/</filename> or <filename>.requires/</filename> directory of a unit file is by embedding + the dependency in [Install] section of the target unit, and creating the symlink in the file system with + the with the <command>enable</command> or <command>preset</command> commands of + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> <para>Along with a unit file <filename>foo.service</filename>, a "drop-in" directory <filename>foo.service.d/</filename> may exist. All files with the suffix <literal>.conf</literal> from this @@ -512,7 +526,7 @@ <replaceable>description</replaceable>.</literal>, <literal>Reached target <replaceable>description</replaceable>.</literal>, <literal>Failed to start <replaceable>description</replaceable>.</literal>), so it should be capitalized, and should - not be a full sentence or a phrase with a continous verb. Bad examples include + not be a full sentence or a phrase with a continuous verb. Bad examples include <literal>exiting the container</literal> or <literal>updating the database once per day.</literal>.</para> </listitem> @@ -832,7 +846,7 @@ <term><varname>DefaultDependencies=</varname></term> <listitem><para>Takes a boolean argument. If - <option>true</option>, (the default), a few default + <option>yes</option>, (the default), a few default dependencies will implicitly be created for the unit. The actual dependencies created depend on the unit type. For example, for service units, these dependencies ensure that the @@ -840,9 +854,9 @@ completed and is properly terminated on system shutdown. See the respective man pages for details. Generally, only services involved with early boot or late shutdown should set this - option to <option>false</option>. It is highly recommended to + option to <option>no</option>. It is highly recommended to leave this option enabled for the majority of common units. If - set to <option>false</option>, this option does not disable + set to <option>no</option>, this option does not disable all implicit dependencies, just non-essential ones.</para></listitem> </varlistentry> @@ -886,7 +900,7 @@ of powering down the system with similar semantics. <option>exit</option> causes the manager to exit following the normal shutdown procedure, and <option>exit-force</option> causes it terminate without shutting down services. When <option>exit</option> or <option>exit-force</option> is used by default the exit status of the - main process of the unit (if this applies) is returned from the service manager. However, this may be overriden + main process of the unit (if this applies) is returned from the service manager. However, this may be overridden with <varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see below.</para></listitem> </varlistentry> @@ -1007,9 +1021,7 @@ <term><varname>ConditionMemory=</varname></term> <term><varname>ConditionCPUs=</varname></term> - <!-- We do not document ConditionNull= - here, as it is not particularly - useful and probably just + <!-- We do not document ConditionNull= here, as it is not particularly useful and probably just confusing. --> <listitem><para>Before starting a unit, verify that the specified condition is true. If it is not true, the @@ -1020,7 +1032,21 @@ or runtime environment doesn't require their functionality. Use the various <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options for a similar mechanism that causes the job to fail (instead of being skipped) and results in logging about the failed check - (instead of being silently processed). For details about assertion conditions see below.</para> + (instead of being silently processed). For details about assertion conditions see below. Units with failed + conditions are considered to be in a clean state and will be garbage collected if they are not referenced. + This means, that when queried, the condition failure may or may not show up in the state of the unit.</para> + + <para>If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a + logical AND is applied). Condition checks can be prefixed with a pipe symbol (<literal>|</literal>) + in which case a condition becomes a triggering condition. If at least one triggering condition is + defined for a unit, then the unit will be executed if at least one of the triggering conditions apply + and all of the non-triggering conditions. If you prefix an argument with the pipe symbol and an + exclamation mark, the pipe symbol must be passed first, the exclamation second. Except for + <varname>ConditionPathIsSymbolicLink=</varname>, all path checks follow symlinks. If any of these + options is assigned the empty string, the list of conditions is reset completely, all previous + condition settings (of any kind) will have no effect. The <command>condition</command> verb of + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> + can be used to test condition and assert expressions.</para> <para><varname>ConditionArchitecture=</varname> may be used to check whether the system is running on a specific @@ -1089,6 +1115,7 @@ <literal>lxc-libvirt</literal>, <literal>systemd-nspawn</literal>, <literal>docker</literal>, + <literal>podman</literal>, <literal>rkt</literal>, <literal>wsl</literal>, <literal>acrn</literal> to test @@ -1123,10 +1150,11 @@ <para><varname>ConditionKernelVersion=</varname> may be used to check whether the kernel version (as reported by <command>uname -r</command>) matches a certain expression (or if prefixed with the - exclamation mark does not match it). The argument must be a single string. If the string starts with - one of <literal><</literal>, <literal><=</literal>, <literal>=</literal>, - <literal>!=</literal>, <literal>>=</literal>, <literal>></literal> a relative version - comparison is done, otherwise the specified string is matched with shell-style globs.</para> + exclamation mark does not match it). The argument must be a list of (potentially quoted) expressions. + For each of the expressions, if it starts with one of <literal><</literal>, + <literal><=</literal>, <literal>=</literal>, <literal>!=</literal>, <literal>>=</literal>, + <literal>></literal> a relative version comparison is done, otherwise the specified string is + matched with shell-style globs.</para> <para>Note that using the kernel version string is an unreliable way to determine which features are supported by a kernel, because of the widespread practice of backporting drivers, features, and fixes from newer upstream @@ -1273,26 +1301,10 @@ <literal><</literal>, <literal><=</literal>, <literal>=</literal>, <literal>!=</literal>, <literal>>=</literal>, <literal>></literal>. Compares the number of CPUs in the CPU affinity mask configured of the service manager itself with the specified number, adhering to the specified - comparision operator. On physical systems the number of CPUs in the affinity mask of the service + comparison operator. On physical systems the number of CPUs in the affinity mask of the service manager usually matches the number of physical CPUs, but in special and virtual environments might differ. In particular, in containers the affinity mask usually matches the number of CPUs assigned to - the container and not the physically available ones.</para> - - <para>If multiple conditions are specified, the unit will be - executed if all of them apply (i.e. a logical AND is applied). - Condition checks can be prefixed with a pipe symbol (|) in - which case a condition becomes a triggering condition. If at - least one triggering condition is defined for a unit, then the - unit will be executed if at least one of the triggering - conditions apply and all of the non-triggering conditions. If - you prefix an argument with the pipe symbol and an exclamation - mark, the pipe symbol must be passed first, the exclamation - second. Except for - <varname>ConditionPathIsSymbolicLink=</varname>, all path - checks follow symlinks. If any of these options is assigned - the empty string, the list of conditions is reset completely, - all previous condition settings (of any kind) will have no - effect.</para></listitem> + the container and not the physically available ones.</para></listitem> </varlistentry> <varlistentry> @@ -1331,7 +1343,11 @@ <para>Note that neither assertion nor condition expressions result in unit state changes. Also note that both are checked at the time the job is to be executed, i.e. long after depending jobs and it itself were queued. Thus, neither condition nor assertion expressions are suitable for conditionalizing unit - dependencies.</para></listitem> + dependencies.</para> + + <para>The <command>condition</command> verb of + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> + can be used to test condition and assert expressions.</para></listitem> </varlistentry> <varlistentry> @@ -1362,22 +1378,23 @@ "Forward" and "reverse" unit properties </title> - <tgroup cols='2'> + <tgroup cols='4'> <colspec colname='forward' /> <colspec colname='reverse' /> - <colspec colname='notes' /> + <colspec colname='fuse' /> + <colspec colname='ruse' /> <thead> <row> <entry>"Forward" property</entry> <entry>"Reverse" property</entry> - <entry>Where used</entry> + <entry namest='fuse' nameend='ruse' valign='middle'>Where used</entry> </row> </thead> <tbody> <row> <entry><varname>Before=</varname></entry> <entry><varname>After=</varname></entry> - <entry morerows='1' valign='middle'>Both are unit file options</entry> + <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry> </row> <row> <entry><varname>After=</varname></entry> @@ -1386,42 +1403,48 @@ <row> <entry><varname>Requires=</varname></entry> <entry><varname>RequiredBy=</varname></entry> - <entry>A unit file option; an option in the [Install] section</entry> + <entry>[Unit] section</entry> + <entry>[Install] section</entry> </row> <row> <entry><varname>Wants=</varname></entry> <entry><varname>WantedBy=</varname></entry> - <entry>A unit file option; an option in the [Install] section</entry> + <entry>[Unit] section</entry> + <entry>[Install] section</entry> </row> <row> <entry><varname>PartOf=</varname></entry> <entry><varname>ConsistsOf=</varname></entry> - <entry>A unit file option; an automatic property</entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> </row> <row> <entry><varname>BindsTo=</varname></entry> <entry><varname>BoundBy=</varname></entry> - <entry>A unit file option; an automatic property</entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> </row> <row> <entry><varname>Requisite=</varname></entry> <entry><varname>RequisiteOf=</varname></entry> - <entry>A unit file option; an automatic property</entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> </row> <row> <entry><varname>Triggers=</varname></entry> <entry><varname>TriggeredBy=</varname></entry> - <entry>Automatic properties, see notes below</entry> + <entry namest='fuse' nameend='ruse' valign='middle'>Automatic properties, see notes below</entry> </row> <row> <entry><varname>Conflicts=</varname></entry> <entry><varname>ConflictedBy=</varname></entry> - <entry>A unit file option; an automatic property</entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> </row> <row> <entry><varname>PropagatesReloadTo=</varname></entry> <entry><varname>ReloadPropagatedFrom=</varname></entry> - <entry morerows='1' valign='middle'>Both are unit file options</entry> + <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry> </row> <row> <entry><varname>ReloadPropagatedFrom=</varname></entry> @@ -1597,7 +1620,9 @@ <row> <entry><literal>%h</literal></entry> <entry>User home directory</entry> - <entry>This is the home directory of the user running the service manager instance. In case of the system manager this resolves to <literal>/root</literal>.</entry> + <entry>This is the home directory of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>/root</literal>. + +Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry> </row> <row> <entry><literal>%H</literal></entry> @@ -1687,12 +1712,16 @@ <row> <entry><literal>%u</literal></entry> <entry>User name</entry> - <entry>This is the name of the user running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry> + <entry>This is the name of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>root</literal>. + +Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry> </row> <row> <entry><literal>%U</literal></entry> <entry>User UID</entry> - <entry>This is the numeric UID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry> + <entry>This is the numeric UID of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>0</literal>. + +Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry> </row> <row> <entry><literal>%v</literal></entry> diff --git a/man/systemd.xml b/man/systemd.xml index c51f0bf4d1..c01cf46e81 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -70,8 +70,14 @@ <varlistentry> <term><option>--test</option></term> - <listitem><para>Determine startup sequence, dump it and exit. - This is an option useful for debugging only.</para></listitem> + <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at + start-up), dump it and exit — without actually executing any of the determined jobs. This option is + useful for debugging only. Note that during regular service manager start-up additional units not + shown by this operation may be started, because hardware, socket, bus or other kinds of activation + might add additional jobs as the transaction is executed. Use <option>--system</option> to request + the initial transaction of the system service manager (this is also the implied default), combine + with <option>--user</option> to request the initial transaction of the per-user service manager + instead.</para></listitem> </varlistentry> <varlistentry> <term><option>--dump-configuration-items</option></term> @@ -83,9 +89,8 @@ <varlistentry> <term><option>--dump-bus-properties</option></term> - <listitem><para>Dump exposed bus properties. This outputs - a terse but complete list of properties exposed to dbus. - </para></listitem> + <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties + exposed on D-Bus.</para></listitem> </varlistentry> <varlistentry> <term><option>--unit=</option></term> @@ -94,23 +99,20 @@ not specified, defaults to <filename>default.target</filename>.</para></listitem> </varlistentry> + <varlistentry> <term><option>--system</option></term> <term><option>--user</option></term> - <listitem><para>For <option>--system</option>, tell systemd to - run a system instance, even if the process ID is not 1, i.e. - systemd is not run as init process. <option>--user</option> - does the opposite, running a user instance even if the process - ID is 1. Normally, it should not be necessary to pass these - options, as systemd automatically detects the mode it is - started in. These options are hence of little use except for - debugging. Note that it is not supported booting and - maintaining a full system with systemd running in - <option>--system</option> mode, but PID not 1. In practice, - passing <option>--system</option> explicitly is only useful in - conjunction with <option>--test</option>.</para></listitem> + <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate + the initial transaction for the system instance or for a per-user instance. These options have no + effect when invoked without <option>--test</option>, as during regular + (i.e. non-<option>--test</option>) invocations the service manager will automatically detect whether + it shall operate in system or per-user mode, by checking whether the PID it is run as is 1 or + not. Note that it is not supported booting and maintaining a system with the service manager running + in <option>--system</option> mode but with a PID other than 1.</para></listitem> </varlistentry> + <varlistentry> <term><option>--dump-core</option></term> @@ -232,8 +234,6 @@ <option>tty</option>, <option>journal</option>, <option>journal+console</option>, - <option>syslog</option>, - <option>syslog+console</option>, <option>kmsg</option>, <option>kmsg+console</option>. If the argument is omitted @@ -582,7 +582,7 @@ <filename>exit.target</filename> unit when this signal is received. This is mostly equivalent to <command>systemctl --user start exit.target - --job-mode=replace-irreversible</command>.</para></listitem> + --job-mode=replace-irreversibly</command>.</para></listitem> </varlistentry> <varlistentry> @@ -590,7 +590,7 @@ <listitem><para>Upon receiving this signal the systemd system manager will start the <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to - <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversible</command>. If + <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly</command>. If this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note that pressing <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the @@ -682,7 +682,7 @@ <listitem><para>Halts the machine, starts the <filename>halt.target</filename> unit. This is mostly equivalent to <command>systemctl start halt.target - --job-mode=replace-irreversible</command>.</para> + --job-mode=replace-irreversibly</command>.</para> </listitem> </varlistentry> @@ -692,7 +692,7 @@ <listitem><para>Powers off the machine, starts the <filename>poweroff.target</filename> unit. This is mostly equivalent to <command>systemctl start poweroff.target - --job-mode=replace-irreversible</command>.</para> + --job-mode=replace-irreversibly</command>.</para> </listitem> </varlistentry> @@ -702,7 +702,7 @@ <listitem><para>Reboots the machine, starts the <filename>reboot.target</filename> unit. This is mostly equivalent to <command>systemctl start reboot.target - --job-mode=replace-irreversible</command>.</para> + --job-mode=replace-irreversibly</command>.</para> </listitem> </varlistentry> @@ -712,7 +712,7 @@ <listitem><para>Reboots the machine via kexec, starts the <filename>kexec.target</filename> unit. This is mostly equivalent to <command>systemctl start kexec.target - --job-mode=replace-irreversible</command>.</para> + --job-mode=replace-irreversibly</command>.</para> </listitem> </varlistentry> @@ -1028,6 +1028,16 @@ </varlistentry> <varlistentry> + <term><varname>systemd.status_unit_format=</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. If specified, + overrides the system manager configuration file option <option>StatusUnitFormat=</option>, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> <term><varname>systemd.log_target=</varname></term> <term><varname>systemd.log_level=</varname></term> <term><varname>systemd.log_location=</varname></term> diff --git a/man/sysusers.d.xml b/man/sysusers.d.xml index 4314732c67..2e93715be6 100644 --- a/man/sysusers.d.xml +++ b/man/sysusers.d.xml @@ -206,12 +206,12 @@ u root 0 "Superuser" /root /bin/zsh</pro <title>Shell</title> <para>The login shell of the user. If not specified, this will be set to - <filename>/sbin/nologin</filename>, except if the UID of the user is 0, in + <filename>/usr/sbin/nologin</filename>, except if the UID of the user is 0, in which case <filename>/bin/sh</filename> will be used.</para> <para>Only applies to lines of type <varname>u</varname> and should otherwise be left unset (or <literal>-</literal>). It is recommended to omit this, unless - a shell different <filename>/sbin/nologin</filename> must be used.</para> + a shell different <filename>/usr/sbin/nologin</filename> must be used.</para> </refsect2> </refsect1> diff --git a/man/timedatectl.xml b/man/timedatectl.xml index b4b99103de..f797e0cd67 100644 --- a/man/timedatectl.xml +++ b/man/timedatectl.xml @@ -23,22 +23,25 @@ <refsynopsisdiv> <cmdsynopsis> - <command>timedatectl <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command> + <command>timedatectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> </cmdsynopsis> </refsynopsisdiv> <refsect1> <title>Description</title> - <para><command>timedatectl</command> may be used to query and - change the system clock and its settings.</para> + <para><command>timedatectl</command> may be used to query and change the system clock and its settings, + and enable or disable time synchronization services.</para> <para>Use <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> to initialize the system time zone for mounted (but not booted) system images.</para> - <para><command>timedatectl</command> may be used to show the current status of + <para><command>timedatectl</command> may be used to show the current status of time synchronization + services, for example <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. </para> @@ -123,11 +126,8 @@ <varlistentry> <term><command>status</command></term> - <listitem><para>Show current settings of the system clock and RTC, - including whether network time synchronization through - <filename>systemd-timesyncd.service</filename> is active. Even if it is - inactive, a different service might still synchronize the clock. - If no command is specified, this is the implied default. + <listitem><para>Show current settings of the system clock and RTC, including whether network time + synchronization is active. If no command is specified, this is the implied default. </para></listitem> </varlistentry> @@ -193,11 +193,11 @@ <varlistentry> <term><command>set-ntp [BOOL]</command></term> - <listitem><para>Takes a boolean argument. Controls whether network time synchronization is active - and enabled (if available). If the argument is true, this enables and starts the first existed - service listed in the environment variable <varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname> - of <filename>systemd-timedated.service</filename>. If the argument is false, then this disables and - stops the all services listed in <varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname>.</para></listitem> + <listitem><para>Takes a boolean argument. Controls whether network time synchronization is active and + enabled (if available). If the argument is true, this enables and starts the first existing network + synchronization service. If the argument is false, then this disables and stops the known network + synchronization services. The way that the list of services is built is described below.</para> + </listitem> </varlistentry> </variablelist> @@ -227,6 +227,20 @@ <para>By default, empty properties are suppressed. Use <option>--all</option> to show those too. To select specific properties to show, use <option>--property=</option>.</para></listitem> </varlistentry> + + <varlistentry> + <term><command>ntp-servers <replaceable>INTERFACE</replaceable> <replaceable>SERVER</replaceable>…</command></term> + + <listitem><para>Set the interface specific NTP servers. This command can be used only when the + interface is managed by <command>systemd-networkd</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>revert <replaceable>INTERFACE</replaceable></command></term> + + <listitem><para>Revert the interface specific NTP servers. This command can be used only when + the interface is managed by <command>systemd-networkd</command>.</para></listitem> + </varlistentry> </variablelist> </refsect2> @@ -236,8 +250,7 @@ <refsect1> <title>Exit status</title> - <para>On success, 0 is returned, a non-zero failure - code otherwise.</para> + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> </refsect1> <xi:include href="less-variables.xml" /> diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml index 67bd1dc724..dce05c364f 100644 --- a/man/tmpfiles.d.xml +++ b/man/tmpfiles.d.xml @@ -36,6 +36,37 @@ <filename>…</filename> <filename>/usr/share/user-tmpfiles.d/*.conf</filename> </literallayout></para> + + <programlisting>#Type Path Mode User Group Age Argument +f /file/to/create mode user group - content +F /file/to/create-or-truncate mode user group - content +w /file/to/write-to - - - - content +d /directory/to/create-and-cleanup mode user group cleanup-age - +D /directory/to/create-and-remove mode user group cleanup-age - +e /directory/to/cleanup mode user group cleanup-age - +v /subvolume/to/create mode user group - - +v /subvolume-or-directory/to/create mode user group - - +Q /subvolume/to/create mode user group - - +p /fifo/to/create mode user group - - +L /symlink/to/create - - - - symlink/target/path +c /dev/char-device-to-create mode user group - - +b /dev/block-device-to-create mode user group - - +# p+, L+, c+, b+ create target unconditionally +C /target/to/create - - - - /source/to/copy +x /path-or-glob/to/ignore - - - - - +X /path-or-glob/to/ignore/recursively - - - - - +r /empty/dir/to/remove - - - - - +R /dir/to/remove/recursively - - - - - +z /path-or-glob/to/adjust/mode mode user group - MAC context +Z /path-or-glob/to/adjust/mode/recursively mode user group - MAC context +t /path-or-glob/to/set/xattrs - - - - xattrs +T /path-or-glob/to/set/xattrs/recursively - - - - xattrs +h /path-or-glob/to/set/attrs - - - - file attrs +H /path-or-glob/to/set/attrs/recursively - - - - file attrs +a /path-or-glob/to/set/acls - - - - POSIX ACLs +A /path-or-glob/to/set/acls/recursively - - - - POSIX ACLs +# a+, A+ append ACLs +</programlisting> </refsynopsisdiv> <refsect1> @@ -349,63 +380,64 @@ L /tmp/foobar - - - - /dev/null</programlisting> <varlistentry> <term><varname>t</varname></term> - <listitem><para>Set extended attributes. Lines of this type - accept shell-style globs in place of normal path names. - This can be useful for setting SMACK labels. Does not follow - symlinks.</para></listitem> + <listitem><para>Set extended attributes, see <citerefentry + project='man-pages'><refentrytitle>attr</refentrytitle> + <manvolnum>5</manvolnum></citerefentry> for details. The argument field should take one or more + assignment expressions in the form + <replaceable>namespace</replaceable>.<replaceable>attribute</replaceable>=<replaceable>value</replaceable>, + for examples see below. Lines of this type accept shell-style globs in place of normal path + names. This can be useful for setting SMACK labels. Does not follow symlinks.</para> + + <para>Please note that extended attributes settable with this line type are a different concept + from the Linux file attributes settable with <varname>h</varname>/<varname>H</varname>, see + below.</para></listitem> </varlistentry> <varlistentry> <term><varname>T</varname></term> - <listitem><para>Recursively set extended attributes. Lines - of this type accept shell-style globs in place of normal - path names. This can be useful for setting SMACK - labels. Does not follow symlinks. </para></listitem> + <listitem><para>Same as <varname>t</varname>, but operates recursively.</para></listitem> </varlistentry> <varlistentry> <term><varname>h</varname></term> - <listitem><para>Set file/directory attributes. Lines of this type - accept shell-style globs in place of normal path names.</para> + <listitem><para>Set Linux file/directory attributes. Lines of this type accept shell-style globs in + place of normal path names.</para> - <para>The format of the argument field is <varname>[+-=][aAcCdDeijPsStTu] </varname>. The prefix + <para>The format of the argument field is <varname>[+-=][aAcCdDeijPsStTu]</varname>. The prefix <varname>+</varname> (the default one) causes the attribute(s) to be added; <varname>-</varname> causes the attribute(s) to be removed; <varname>=</varname> causes the attributes to be set exactly as the following letters. The letters <literal>aAcCdDeijPsStTu</literal> select the new attributes for the files, see <citerefentry project='man-pages'><refentrytitle>chattr</refentrytitle> <manvolnum>1</manvolnum></citerefentry> for further information. </para> - <para>Passing only <varname>=</varname> as argument resets - all the file attributes listed above. It has to be pointed - out that the <varname>=</varname> prefix limits itself to - the attributes corresponding to the letters listed here. All - other attributes will be left untouched. Does not follow - symlinks.</para> - </listitem> + + <para>Passing only <varname>=</varname> as argument resets all the file attributes listed above. It + has to be pointed out that the <varname>=</varname> prefix limits itself to the attributes + corresponding to the letters listed here. All other attributes will be left untouched. Does not + follow symlinks.</para> + + <para>Please note that the Linux file attributes settable with this line type are a different + concept from the extended attributes settable with <varname>t</varname>/<varname>T</varname>, + see above.</para></listitem> </varlistentry> <varlistentry> <term><varname>H</varname></term> - <listitem><para>Recursively set file/directory attributes. Lines - of this type accept shell-style globs in place of normal - path names. Does not follow symlinks. - </para></listitem> + <listitem><para>Sames as <varname>h</varname>, but operates recursively.</para></listitem> </varlistentry> <varlistentry> <term><varname>a</varname></term> <term><varname>a+</varname></term> - <listitem><para>Set POSIX ACLs (access control lists). If - suffixed with <varname>+</varname>, the specified entries will - be added to the existing set. - <command>systemd-tmpfiles</command> will automatically add - the required base entries for user and group based on the - access mode of the file, unless base entries already exist - or are explicitly specified. The mask will be added if not - specified explicitly or already present. Lines of this type - accept shell-style globs in place of normal path names. This - can be useful for allowing additional access to certain - files. Does not follow symlinks.</para></listitem> + <listitem><para>Set POSIX ACLs (access control lists), see <citerefentry + project='man-pages'><refentrytitle>acl</refentrytitle> + <manvolnum>5</manvolnum></citerefentry>. If suffixed with <varname>+</varname>, the specified + entries will be added to the existing set. <command>systemd-tmpfiles</command> will automatically + add the required base entries for user and group based on the access mode of the file, unless base + entries already exist or are explicitly specified. The mask will be added if not specified + explicitly or already present. Lines of this type accept shell-style globs in place of normal path + names. This can be useful for allowing additional access to certain files. Does not follow + symlinks.</para></listitem> </varlistentry> <varlistentry> @@ -495,6 +527,14 @@ w- /proc/sys/vm/swappiness - - - - 10</programlisting></para> lines, when omitted or when set to <literal>-</literal>, the file ownership will not be modified. These parameters are ignored for <varname>x</varname>, <varname>r</varname>, <varname>R</varname>, <varname>L</varname>, <varname>t</varname>, and <varname>a</varname> lines.</para> + + <para>This field should generally only reference system users/groups, i.e. users/groups that are + guaranteed to be resolvable during early boot. If this field references users/groups that only become + resolveable during later boot (i.e. after NIS, LDAP or a similar networked directory service become + available), execution of the operations declared by the line will likely fail. Also see <ulink + url="https://systemd.io/UIDS-GIDS.html#notes-on-resolvability-of-user-and-group-names">Notes on + Resolvability of User and Group Names</ulink> for more information on requirements on system user/group + definitions.</para> </refsect2> <refsect2> diff --git a/man/udev.xml b/man/udev.xml index 5a78be3208..98d17bbb54 100644 --- a/man/udev.xml +++ b/man/udev.xml @@ -437,6 +437,8 @@ <para>Note that running programs that access the network or mount/unmount filesystems is not allowed inside of udev rules, due to the default sandbox that is enforced on <filename>systemd-udevd.service</filename>.</para> + <para>Please also note that <literal>:=</literal> and <literal>=</literal> are clearing + both, program and builtin commands.</para> </listitem> </varlistentry> diff --git a/man/udevadm.xml b/man/udevadm.xml index 467402ca75..c2f2bc95d2 100644 --- a/man/udevadm.xml +++ b/man/udevadm.xml @@ -175,6 +175,14 @@ <para>Cleanup the udev database.</para> </listitem> </varlistentry> + <varlistentry> + <term><option>-w<optional>SECONDS</optional></option></term> + <term><option>--wait-for-initialization<optional>=SECONDS</optional></option></term> + <listitem> + <para>Wait for device to be initialized. If argument <replaceable>SECONDS</replaceable> + is not specified, the default is to wait forever.</para> + </listitem> + </varlistentry> <xi:include href="standard-options.xml" xpointer="help" /> </variablelist> @@ -220,7 +228,9 @@ <para>Type of event to be triggered. Possible actions are <literal>add</literal>, <literal>remove</literal>, <literal>change</literal>, <literal>move</literal>, <literal>online</literal>, <literal>offline</literal>, <literal>bind</literal>, - and <literal>unbind</literal>. The default value is <literal>change</literal>.</para> + and <literal>unbind</literal>. Also, the special value <literal>help</literal> can be used + to list the possible actions. The default value is <literal>change</literal>. + </para> </listitem> </varlistentry> <varlistentry> @@ -362,6 +372,10 @@ <xi:include href="standard-options.xml" xpointer="help" /> </variablelist> + + <para>See + <citerefentry><refentrytitle>systemd-udev-settle.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for more information.</para> </refsect2> <refsect2><title>udevadm control <replaceable>option</replaceable></title> @@ -512,9 +526,13 @@ <variablelist> <varlistentry> <term><option>-a</option></term> - <term><option>--action=<replaceable>string</replaceable></option></term> + <term><option>--action=<replaceable>ACTION</replaceable></option></term> <listitem> - <para>The action string.</para> + <para>Type of event to be simulated. Possible actions are <literal>add</literal>, + <literal>remove</literal>, <literal>change</literal>, <literal>move</literal>, + <literal>online</literal>, <literal>offline</literal>, <literal>bind</literal>, + and <literal>unbind</literal>. Also, the special value <literal>help</literal> can be used + to list the possible actions. The default value is <literal>add</literal>.</para> </listitem> </varlistentry> <varlistentry> diff --git a/man/user-system-options.xml b/man/user-system-options.xml index 195c2e4163..8034735658 100644 --- a/man/user-system-options.xml +++ b/man/user-system-options.xml @@ -30,7 +30,7 @@ <para>Execute the operation remotely. Specify a hostname, or a username and hostname separated by <literal>@</literal>, to connect to. The hostname may optionally be suffixed by a - port ssh is listening on, seperated by <literal>:</literal>, and then a + port ssh is listening on, separated by <literal>:</literal>, and then a container name, separated by <literal>/</literal>, which connects directly to a specific container on the specified host. This will use SSH to talk to the remote machine manager diff --git a/man/vtable-example.c b/man/vtable-example.c new file mode 100644 index 0000000000..98c20eec52 --- /dev/null +++ b/man/vtable-example.c @@ -0,0 +1,70 @@ +#include <errno.h> +#include <stdbool.h> +#include <stddef.h> +#include <stdlib.h> +#include <stdio.h> +#include <systemd/sd-bus.h> + +#define _cleanup_(f) __attribute__((cleanup(f))) + +typedef struct object { + char *name; + uint32_t number; +} object; + +static int method(sd_bus_message *m, void *userdata, sd_bus_error *error) { + printf("Got called with userdata=%p\n", userdata); + return 1; +} + +static const sd_bus_vtable vtable[] = { + SD_BUS_VTABLE_START(0), + SD_BUS_METHOD( + "Method1", "s", "s", method, 0), + SD_BUS_METHOD_WITH_NAMES_OFFSET( + "Method2", + "so", SD_BUS_PARAM(string) SD_BUS_PARAM(path), + "s", SD_BUS_PARAM(returnstring), + method, offsetof(object, number), + SD_BUS_VTABLE_DEPRECATED), + SD_BUS_WRITABLE_PROPERTY( + "AutomaticStringProperty", "s", NULL, NULL, + offsetof(object, name), + SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE), + SD_BUS_WRITABLE_PROPERTY( + "AutomaticIntegerProperty", "u", NULL, NULL, + offsetof(object, number), + SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION), + SD_BUS_VTABLE_END +}; + +#define check(x) ({ \ + int r = x; \ + errno = r < 0 ? -r : 0; \ + printf(#x ": %m\n"); \ + if (r < 0) \ + return EXIT_FAILURE; \ + }) + +int main(int argc, char **argv) { + _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL; + + sd_bus_default(&bus); + + object object = { .number = 666 }; + check((object.name = strdup("name")) != NULL); + + check(sd_bus_add_object_vtable(bus, NULL, "/object", + "org.freedesktop.systemd.VtableExample", + vtable, + &object)); + + for (;;) { + check(sd_bus_wait(bus, UINT64_MAX)); + check(sd_bus_process(bus, NULL)); + } + + free(object.name); + + return 0; +} diff --git a/man/vtable-example.xml b/man/vtable-example.xml new file mode 100644 index 0000000000..a3cdeae704 --- /dev/null +++ b/man/vtable-example.xml @@ -0,0 +1,54 @@ +<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" +"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> +<node> + <interface name="org.freedesktop.DBus.Peer"> + <method name="Ping"/> + <method name="GetMachineId"> + <arg type="s" name="machine_uuid" direction="out"/> + </method> + </interface> + <interface name="org.freedesktop.DBus.Introspectable"> + <method name="Introspect"> + <arg name="data" type="s" direction="out"/> + </method> + </interface> + <interface name="org.freedesktop.DBus.Properties"> + <method name="Get"> + <arg name="interface" direction="in" type="s"/> + <arg name="property" direction="in" type="s"/> + <arg name="value" direction="out" type="v"/> + </method> + <method name="GetAll"> + <arg name="interface" direction="in" type="s"/> + <arg name="properties" direction="out" type="a{sv}"/> + </method> + <method name="Set"> + <arg name="interface" direction="in" type="s"/> + <arg name="property" direction="in" type="s"/> + <arg name="value" direction="in" type="v"/> + </method> + <signal name="PropertiesChanged"> + <arg type="s" name="interface"/> + <arg type="a{sv}" name="changed_properties"/> + <arg type="as" name="invalidated_properties"/> + </signal> + </interface> + <interface name="org.freedesktop.systemd.VtableExample"> + <method name="Method1"> + <arg type="s" direction="in"/> + <arg type="s" direction="out"/> + </method> + <method name="Method2"> + <arg type="s" name="string" direction="in"/> + <arg type="o" name="path" direction="in"/> + <arg type="s" name="returnstring" direction="out"/> + <annotation name="org.freedesktop.DBus.Deprecated" value="true"/> + </method> + <property name="AutomaticStringProperty" type="s" access="readwrite"> + </property> + <property name="AutomaticIntegerProperty" type="u" access="readwrite"> + <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal" value="invalidates"/> + </property> + </interface> +</node> + |