diff options
Diffstat (limited to 'man')
392 files changed, 105248 insertions, 0 deletions
diff --git a/man/.dir-locals.el b/man/.dir-locals.el new file mode 100644 index 0000000..c252bd3 --- /dev/null +++ b/man/.dir-locals.el @@ -0,0 +1,14 @@ +; special .c mode with reduced indentation for man pages +((c-mode . ((fill-column . 80) + (c-basic-offset . 2) + (eval . (c-set-offset 'substatement-open 0)) + (eval . (c-set-offset 'statement-case-open 0)) + (eval . (c-set-offset 'case-label 0)) + (eval . (c-set-offset 'arglist-intro '++)) + (eval . (c-set-offset 'arglist-close 0)))) + (nxml-mode . ((nxml-child-indent . 2) + (fill-column . 109))) + (meson-mode . ((meson-indent-basic . 8))) + (nil . ((indent-tabs-mode . nil) + (tab-width . 8) + (fill-column . 79)))) diff --git a/man/50-xdg-data-dirs.sh b/man/50-xdg-data-dirs.sh new file mode 100755 index 0000000..89e9fbb --- /dev/null +++ b/man/50-xdg-data-dirs.sh @@ -0,0 +1,12 @@ +#!/bin/bash + +# set the default value +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} +fi + +# write our output +echo XDG_DATA_DIRS=$XDG_DATA_DIRS diff --git a/man/90-rearrange-path.py b/man/90-rearrange-path.py new file mode 100755 index 0000000..7537d5e --- /dev/null +++ b/man/90-rearrange-path.py @@ -0,0 +1,40 @@ +#!/usr/bin/env python3 + +""" + +Proof-of-concept systemd environment generator that makes sure that bin dirs +are always after matching sbin dirs in the path. +(Changes /sbin:/bin:/foo/bar to /bin:/sbin:/foo/bar.) + +This generator shows how to override the configuration possibly created by +earlier generators. It would be easier to write in bash, but let's have it +in Python just to prove that we can, and to serve as a template for more +interesting generators. + +""" + +import os +import pathlib + +def rearrange_bin_sbin(path): + """Make sure any pair of …/bin, …/sbin directories is in this order + + >>> rearrange_bin_sbin('/bin:/sbin:/usr/sbin:/usr/bin') + '/bin:/sbin:/usr/bin:/usr/sbin' + """ + items = [pathlib.Path(p) for p in path.split(':')] + for i in range(len(items)): + if 'sbin' in items[i].parts: + ind = items[i].parts.index('sbin') + bin = pathlib.Path(*items[i].parts[:ind], 'bin', *items[i].parts[ind+1:]) + if bin in items[i+1:]: + j = i + 1 + items[i+1:].index(bin) + items[i], items[j] = items[j], items[i] + return ':'.join(p.as_posix() for p in items) + +if __name__ == '__main__': + path = os.environ['PATH'] # This should be always set. + # If it's not, we'll just crash, we is OK too. + new = rearrange_bin_sbin(path) + if new != path: + print('PATH={}'.format(new)) diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml new file mode 100644 index 0000000..6134b27 --- /dev/null +++ b/man/binfmt.d.xml @@ -0,0 +1,74 @@ +<?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-or-later --> +<refentry id="binfmt.d" conditional='ENABLE_BINFMT' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>binfmt.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>binfmt.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>binfmt.d</refname> + <refpurpose>Configure additional binary formats for + executables at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/binfmt.d/*.conf</filename></para> + <para><filename>/run/binfmt.d/*.conf</filename></para> + <para><filename>/usr/lib/binfmt.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>At boot, + <citerefentry><refentrytitle>systemd-binfmt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + reads configuration files from the above directories to register + in the kernel additional binary formats for executables.</para> + </refsect1> + + <refsect1> + <title>Configuration Format</title> + + <para>Each file contains a list of binfmt_misc kernel binary format rules. Consult the kernel's <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html">binfmt-misc.rst</ulink> documentation + file for more information on registration of additional binary formats and how to write rules.</para> + + <para>Empty lines and lines beginning with ; and # are ignored. + Note that this means you may not use ; and # as delimiter in + binary format rules.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="confd" /> + + <refsect1> + <title>Example</title> + <example> + <title>/etc/binfmt.d/wine.conf example:</title> + + <programlisting># Start WINE on Windows executables +:DOSWin:M::MZ::/usr/bin/wine:</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-binfmt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>wine</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/bootctl.xml b/man/bootctl.xml new file mode 100644 index 0000000..878f247 --- /dev/null +++ b/man/bootctl.xml @@ -0,0 +1,270 @@ +<?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-or-later --> + +<refentry id="bootctl" conditional='ENABLE_EFI' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>bootctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>bootctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>bootctl</refname> + <refpurpose>Control EFI firmware boot settings and manage boot loader</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>bootctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>bootctl</command> can check the EFI firmware and boot loader status, list and manage + available boot loaders and boot loader entries, and install, update, or remove the + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> boot + loader on the current system.</para> + </refsect1> + + <refsect1> + <title>Generic EFI Firmware/Boot Loader Commands</title> + + <para>These commands are available on any EFI system, regardless of the boot loader used.</para> + + <variablelist> + <varlistentry> + <term><option>status</option></term> + + <listitem><para>Shows brief information about the system firmware, the boot loader that was used to boot the + system, the boot loaders currently available in the ESP, the boot loaders listed in the firmware's list of boot + loaders and the current default boot loader entry. If no command is specified, this is the implied + default.</para></listitem> + </varlistentry> + </variablelist> + + <varlistentry> + <term><option>reboot-to-firmware</option> <optional><replaceable>BOOL</replaceable></optional></term> + + <listitem><para>Query or set the "Reboot-Into-Firmware-Setup" flag of the EFI firmware. Takes a + boolean argument which controls whether to show the firmware setup on next system reboot. If the + argument is omitted shows the current status of the flag, or whether the flag is supported. This + controls the same flag as <command>systemctl reboot --firmware-setup</command>, but is more + low-level and allows setting the flag independently from actually requesting a + reboot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>systemd-efi-options</option> <optional><replaceable>STRING</replaceable></optional></term> + + <listitem><para>When called without the optional argument, prints the current value of the + <literal>SystemdOptions</literal> EFI variable. When called with an argument, sets the + variable to that value. See + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for the meaning of that variable.</para></listitem> + </varlistentry> + </refsect1> + + <refsect1> + <title>Boot Loader Specification Commands</title> + + <para>These commands are available for all boot loaders that implement the <ulink + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> and/or the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>, such as + <command>systemd-boot</command>.</para> + + <variablelist> + + <varlistentry> + <term><option>list</option></term> + + <listitem><para>Shows all available boot loader entries implementing the <ulink + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, as well as any + other entries discovered or automatically generated by a boot loader implementing the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader + Interface</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>set-default</option> <replaceable>ID</replaceable></term> + <term><option>set-oneshot</option> <replaceable>ID</replaceable></term> + + <listitem><para>Sets the default boot loader entry. Takes a single boot loader entry ID string as + argument. The <option>set-oneshot</option> command will set the default entry only for the next boot, + the <option>set-default</option> will set it persistently for all future boots.</para></listitem> + + <listitem><para>Optionally, the boot loader entry ID may be specified as one of: <option>@default</option>, + <option>@oneshot</option> or <option>@current</option>, which correspond to the current default boot loader + entry for all future boots, the current default boot loader entry for the next boot, and the currently booted + boot loader entry. These special IDs are resolved to the current values of the EFI variables + <varname>LoaderEntryDefault</varname>, <varname>LoaderEntryOneShot</varname> and <varname>LoaderEntrySelected</varname>, + see <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> for details. + These special IDs are primarily useful as a quick way to persistently make the currently booted boot loader + entry the default choice, or to upgrade the default boot loader entry for the next boot to the default boot + loader entry for all future boots, but may be used for other operations too. + When an empty string ("") is specified as an ID, then the corresponding EFI variable will be unset. + </para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title><command>systemd-boot</command> Commands</title> + + <para>These commands manage the <command>systemd-boot</command> EFI boot loader, and do not work in + conjunction with other boot loaders.</para> + + <variablelist> + <varlistentry> + <term><option>install</option></term> + + <listitem><para>Installs <command>systemd-boot</command> into the EFI system partition. A copy of + <command>systemd-boot</command> will be stored as the EFI default/fallback loader at + <filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. The boot loader is then added + to the top of the firmware's boot loader list.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>update</option></term> + + <listitem><para>Updates all installed versions of + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, if the + available version is newer than the version installed in the EFI system partition. This also includes the EFI + default/fallback loader at <filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. The boot + loader is then added to end of the firmware's boot loader list if missing.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>remove</option></term> + + <listitem><para>Removes all installed versions of <command>systemd-boot</command> from the EFI system partition + and the firmware's boot loader list.</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>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> + + </variablelist> + </refsect1> + + <refsect1> + <title>Options</title> + <para>The following options are understood:</para> + + <variablelist> + <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> + </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> 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>. 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>. 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> + <term><option>--no-variables</option></term> + <listitem><para>Do not touch the firmware's boot loader list stored in EFI variables.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--graceful</option></term> + <listitem><para>Ignore failure when the EFI System Partition cannot be found, or when EFI variables + cannot be written. Currently only applies to random seed operations.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager"/> + <xi:include href="standard-options.xml" xpointer="help"/> + <xi:include href="standard-options.xml" xpointer="version"/> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + <para>If <varname>$SYSTEMD_RELAX_ESP_CHECKS=1</varname> is set the validation checks for the ESP are + relaxed, and the path specified with <option>--esp-path=</option> may refer to any kind of file system on + any kind of partition.</para> + + <para>Similarly, <varname>$SYSTEMD_RELAX_XBOOTLDR_CHECKS=1</varname> turns off some validation checks for + the Extended Boot Loader partition.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <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>, + <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 new file mode 100644 index 0000000..781e539 --- /dev/null +++ b/man/bootup.xml @@ -0,0 +1,356 @@ +<?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-or-later --> + +<refentry id="bootup"> + + <refentryinfo> + <title>bootup</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>bootup</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>bootup</refname> + <refpurpose>System bootup process</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>A number of different components are involved in the boot of a Linux system. Immediately after + power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot + loader (e.g. + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or + <ulink url="https://www.gnu.org/software/grub/">GRUB</ulink>) stored on a persistent storage device. This + boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types + of firmware, this firmware may also load the kernel directly.</para> + + <para>The kernel (optionally) mounts an in-memory file system, often generated by + <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed + archive which is extracted when the kernel boots up into a lightweight in-memory file system based on + tmpfs, but in the past normal file systems using an in-memory block device (ramdisk) were used, and the + name "initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads + both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file + system. <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may + be used to manage services in the initrd, similarly to the real system.</para> + + <para>After the root file system is found and mounted, the initrd hands over control to the host's system + manager (such as + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) stored in + the root file system, which is then responsible for probing all remaining hardware, mounting all + necessary file systems and spawning all configured services.</para> + + <para>On shutdown, the system manager stops all services, unmounts + all file systems (detaching the storage technologies backing + them), and then (optionally) jumps back into the initrd code which + unmounts/detaches the root file system and the storage it resides + on. As a last step, the system is powered down.</para> + + <para>Additional information about the system boot process may be + found in + <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>System Manager Bootup</title> + + <para>At boot, the system manager on the OS image is responsible + for initializing the required file systems, services and drivers + that are necessary for operation of the system. On + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + systems, this process is split up in various discrete steps which + are exposed as target units. (See + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for detailed information about target units.) The boot-up process + is highly parallelized so that the order in which specific target + units are reached is not deterministic, but still adheres to a + limited amount of ordering structure.</para> + + <para>When systemd starts up the system, it will activate all + units that are dependencies of <filename>default.target</filename> + (as well as recursively all dependencies of these dependencies). + Usually, <filename>default.target</filename> is simply an alias of + <filename>graphical.target</filename> or + <filename>multi-user.target</filename>, depending on whether the + system is configured for a graphical UI or only for a text + console. To enforce minimal ordering between the units pulled in, + a number of well-known target units are available, as listed on + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>The following chart is a structural overview of these + well-known units and their position in the boot-up logic. The + arrows describe which units are pulled in and ordered before which + other units. Units near the top are started before units nearer to + the bottom of the chart.</para> + + <!-- note: do not use unicode ellipsis here, because docbook will replace that + with three dots anyway, messing up alignment --> +<programlisting> cryptsetup-pre.target + | +(various low-level v + API VFS mounts: (various cryptsetup devices...) + mqueue, configfs, | | + debugfs, ...) v | + | cryptsetup.target | + | (various swap | | remote-fs-pre.target + | devices...) | | | | + | | | | | v + | v local-fs-pre.target | | | (network file systems) + | swap.target | | v v | + | | v | remote-cryptsetup.target | + | | (various low-level (various mounts and | | | + | | services: udevd, fsck services...) | | remote-fs.target + | | tmpfiles, random | | | / + | | seed, sysctl, ...) v | | / + | | | local-fs.target | | / + | | | | | | / + \____|______|_______________ ______|___________/ | / + \ / | / + v | / + sysinit.target | / + | | / + ______________________/|\_____________________ | / + / | | | \ | / + | | | | | | / + v v | v | | / + (various (various | (various | |/ + timers...) paths...) | sockets...) | | + | | | | | | + v v | v | | +timers.target paths.target | sockets.target | | + | | | | v | + v \_______ | _____/ rescue.service | + \|/ | | + v v | + basic.target <emphasis>rescue.target</emphasis> | + | | + ________v____________________ | + / | \ | + | | | | + v v v | + display- (various system (various system | + manager.service services services) | + | required for | | + | graphical UIs) v v + | | <emphasis>multi-user.target</emphasis> +emergency.service | | | + | \_____________ | _____________/ + v \|/ +<emphasis>emergency.target</emphasis> v + <emphasis>graphical.target</emphasis></programlisting> + + <para>Target units that are commonly used as boot targets are + <emphasis>emphasized</emphasis>. These units are good choices as + goal targets, for example by passing them to the + <varname>systemd.unit=</varname> kernel command line option (see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) + or by symlinking <filename>default.target</filename> to them. + </para> + + <para><filename>timers.target</filename> is pulled-in by + <filename>basic.target</filename> asynchronously. This allows + timers units to depend on services which become only available + later in boot.</para> + </refsect1> + + <refsect1> + <title>User manager startup</title> + + <para>The system manager starts the <filename>user@<replaceable>uid</replaceable>.service</filename> unit + for each user, which launches a separate unprivileged instance of <command>systemd</command> for each + user — the user manager. Similarly to the system manager, the user manager starts units which are pulled + in by <filename>default.target</filename>. The following chart is a structural overview of the well-known + user units. For non-graphical sessions, <filename>default.target</filename> is used. Whenever the user + logs into a graphical session, the login manager will start the + <filename>graphical-session.target</filename> target that is used to pull in units required for the + graphical session. A number of targets (shown on the right side) are started when specific hardware is + available to the user.</para> + +<programlisting> + (various (various (various + timers...) paths...) sockets...) (sound devices) + | | | | + v v v v + timers.target paths.target sockets.target sound.target + | | | + \______________ _|_________________/ (bluetooth devices) + \ / | + V v + basic.target bluetooth.target + | + __________/ \_______ (smartcard devices) + / \ | + | | v + | v smartcard.target + v graphical-session-pre.target + (various user services) | (printers) + | v | + | (services for the graphical session) v + | | printer.target + v v + <emphasis>default.target</emphasis> graphical-session.target</programlisting> + + </refsect1> + + <refsect1> + <title>Bootup in the Initial RAM Disk (initrd)</title> + <para>The initial RAM disk implementation (initrd) can be set up + using systemd as well. In this case, boot up inside the initrd + follows the following structure.</para> + + <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 + approaches the special target <filename>initrd.target</filename>. + + Before any file systems are mounted, it must be determined whether + the system will resume from hibernation or proceed with normal boot. + This is accomplished by <filename>systemd-hibernate-resume@.service</filename> + which must be finished before <filename>local-fs-pre.target</filename>, + so no filesystems can be mounted before the check is complete. + + When the root device becomes available, + <filename>initrd-root-device.target</filename> is reached. + If the root device can be mounted at + <filename>/sysroot</filename>, the + <filename>sysroot.mount</filename> unit becomes active and + <filename>initrd-root-fs.target</filename> is reached. The service + <filename>initrd-parse-etc.service</filename> scans + <filename>/sysroot/etc/fstab</filename> for a possible + <filename>/usr/</filename> mount point and additional entries + marked with the <emphasis>x-initrd.mount</emphasis> option. All + entries found are mounted below <filename>/sysroot</filename>, and + <filename>initrd-fs.target</filename> is reached. The service + <filename>initrd-cleanup.service</filename> isolates to the + <filename>initrd-switch-root.target</filename>, where cleanup + services can run. As the very last step, the + <filename>initrd-switch-root.service</filename> is activated, + which will cause the system to switch its root to + <filename>/sysroot</filename>. + </para> + +<programlisting> : (beginning identical to above) + : + v + basic.target + | emergency.service + ______________________/| | + / | v + | initrd-root-device.target <emphasis>emergency.target</emphasis> + | | + | v + | sysroot.mount + | | + | v + | initrd-root-fs.target + | | + | v + v initrd-parse-etc.service + (custom initrd | + services...) v + | (sysroot-usr.mount and + | various mounts marked + | with fstab option + | x-initrd.mount...) + | | + | v + | initrd-fs.target + \______________________ | + \| + v + initrd.target + | + v + initrd-cleanup.service + isolates to + initrd-switch-root.target + | + v + ______________________/| + / v + | initrd-udevadm-cleanup-db.service + v | + (custom initrd | + services...) | + \______________________ | + \| + v + initrd-switch-root.target + | + v + initrd-switch-root.service + | + v + Transition to Host OS</programlisting> + </refsect1> + + <refsect1> + <title>System Manager Shutdown</title> + + <para>System shutdown with systemd also consists of various target + units with some minimal ordering structure applied:</para> + +<programlisting> (conflicts with (conflicts with + all system all file system + services) mounts, swaps, + | cryptsetup + | devices, ...) + | | + v v + shutdown.target umount.target + | | + \_______ ______/ + \ / + v + (various low-level + services) + | + v + final.target + | + _____________________________________/ \_________________________________ + / | | \ + | | | | + v v v v +systemd-reboot.service systemd-poweroff.service systemd-halt.service systemd-kexec.service + | | | | + v v v v + <emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting> + + <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para> + + <para>Note that + <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and + <filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second + phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> binary), which will unmount any + remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and + robust fashion, without taking any service or unit concept into account anymore. At that point, regular + applications and resources are generally terminated and released already, the second phase hence operates only as + safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based + shutdown phase described above.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/busctl.xml b/man/busctl.xml new file mode 100644 index 0000000..912f302 --- /dev/null +++ b/man/busctl.xml @@ -0,0 +1,526 @@ +<?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-or-later --> + +<refentry id="busctl" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>busctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>busctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>busctl</refname> + <refpurpose>Introspect the bus</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>busctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt">COMMAND</arg> + <arg choice="opt" rep="repeat"><replaceable>NAME</replaceable></arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>busctl</command> may be used to + introspect and monitor the D-Bus bus.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>list</command></term> + + <listitem><para>Show all peers on the bus, by their service + names. By default, shows both unique and well-known names, but + this may be changed with the <option>--unique</option> and + <option>--acquired</option> switches. This is the default + operation if no command is specified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>status</command> <arg choice="opt"><replaceable>SERVICE</replaceable></arg></term> + + <listitem><para>Show process information and credentials of a + bus service (if one is specified by its unique or well-known + name), a process (if one is specified by its numeric PID), or + the owner of the bus (if no parameter is + specified).</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>monitor</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term> + + <listitem><para>Dump messages being exchanged. If + <replaceable>SERVICE</replaceable> is specified, show messages + to or from this peer, identified by its well-known or unique + name. Otherwise, show all messages on the bus. Use + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> + to terminate the dump.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>capture</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term> + + <listitem><para>Similar to <command>monitor</command> but + writes the output in pcap format (for details, see the <ulink + url="https://wiki.wireshark.org/Development/LibpcapFileFormat">Libpcap + File Format</ulink> description). Make sure to redirect + standard output to a file. Tools like + <citerefentry project='die-net'><refentrytitle>wireshark</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be used to dissect and view the resulting + files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>tree</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term> + + <listitem><para>Shows an object tree of one or more + services. If <replaceable>SERVICE</replaceable> is specified, + show object tree of the specified services only. Otherwise, + show all object trees of all services on the bus that acquired + at least one well-known name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>introspect</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="opt"><replaceable>INTERFACE</replaceable></arg></term> + + <listitem><para>Show interfaces, methods, properties and + signals of the specified object (identified by its path) on + the specified service. If the interface argument is passed, the + output is limited to members of the specified + interface.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>call</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>METHOD</replaceable></arg> <arg choice="opt"><replaceable>SIGNATURE</replaceable> <arg choice="opt" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></arg></term> + + <listitem><para>Invoke a method and show the response. Takes a + service name, object path, interface name and method name. If + parameters shall be passed to the method call, a signature + string is required, followed by the arguments, individually + formatted as strings. For details on the formatting used, see + below. To suppress output of the returned data, use the + <option>--quiet</option> option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>emit</command> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>SIGNAL</replaceable></arg> <arg choice="opt"><replaceable>SIGNATURE</replaceable> <arg choice="opt" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></arg></term> + + <listitem><para>Emit a signal. Takes a object path, interface name and method name. If parameters + shall be passed, a signature string is required, followed by the arguments, individually formatted as + strings. For details on the formatting used, see below. To specify the destination of the signal, + use the <option>--destination=</option> option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>get-property</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain" rep="repeat"><replaceable>PROPERTY</replaceable></arg></term> + + <listitem><para>Retrieve the current value of one or more + object properties. Takes a service name, object path, + interface name and property name. Multiple properties may be + specified at once, in which case their values will be shown one + after the other, separated by newlines. The output is, by + default, in terse format. Use <option>--verbose</option> for a + more elaborate output format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-property</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>PROPERTY</replaceable></arg> <arg choice="plain"><replaceable>SIGNATURE</replaceable></arg> <arg choice="plain" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></term> + + <listitem><para>Set the current value of an object + property. Takes a service name, object path, interface name, + property name, property signature, followed by a list of + parameters formatted as strings.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>help</command></term> + + <listitem><para>Show command syntax help.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--address=<replaceable>ADDRESS</replaceable></option></term> + + <listitem><para>Connect to the bus specified by + <replaceable>ADDRESS</replaceable> instead of using suitable + defaults for either the system or user bus (see + <option>--system</option> and <option>--user</option> + options).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--show-machine</option></term> + + <listitem><para>When showing the list of peers, show a + column containing the names of containers they belong to. + See + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--unique</option></term> + + <listitem><para>When showing the list of peers, show only + "unique" names (of the form + <literal>:<replaceable>number</replaceable>.<replaceable>number</replaceable></literal>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--acquired</option></term> + + <listitem><para>The opposite of <option>--unique</option> — + only "well-known" names will be shown.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--activatable</option></term> + + <listitem><para>When showing the list of peers, show only + peers which have actually not been activated yet, but may be + started automatically if accessed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--match=<replaceable>MATCH</replaceable></option></term> + + <listitem><para>When showing messages being exchanged, show only the + subset matching <replaceable>MATCH</replaceable>. + See + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--size=</option></term> + + <listitem> + <para>When used with the <command>capture</command> command, + specifies the maximum bus message size to capture + ("snaplen"). Defaults to 4096 bytes.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--list</option></term> + + <listitem> + <para>When used with the <command>tree</command> command, shows a + flat list of object paths instead of a tree.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem> + <para>When used with the <command>call</command> command, + suppresses display of the response message payload. Note that even + if this option is specified, errors returned will still be + printed and the tool will indicate success or failure with + the process exit code.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--verbose</option></term> + + <listitem> + <para>When used with the <command>call</command> or + <command>get-property</command> command, shows output in a + more verbose format.</para> + </listitem> + </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> + <para>When used with the <command>call</command> or <command>get-property</command> command, shows output + formatted as JSON. Expects one of <literal>short</literal> (for the shortest possible output without any + redundant whitespace or line breaks) or <literal>pretty</literal> (for a pretty version of the same, with + indentation and line breaks). Note that transformation from D-Bus marshalling to JSON is done in a loss-less + way, which means type information is embedded into the JSON object tree.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-j</option></term> + + <listitem> + <para>Equivalent to <option>--json=pretty</option> when invoked interactively from a terminal. Otherwise + equivalent to <option>--json=short</option>, in particular when the output is piped to some other + program.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--expect-reply=</option><replaceable>BOOL</replaceable></term> + + <listitem> + <para>When used with the <command>call</command> command, + specifies whether <command>busctl</command> shall wait for + completion of the method call, output the returned method + response data, and return success or failure via the process + exit code. If this is set to <literal>no</literal>, the + method call will be issued but no response is expected, the + tool terminates immediately, and thus no response can be + shown, and no success or failure is returned via the exit + code. To only suppress output of the reply message payload, + use <option>--quiet</option> above. Defaults to + <literal>yes</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--auto-start=</option><replaceable>BOOL</replaceable></term> + + <listitem> + <para>When used with the <command>call</command> or <command>emit</command> command, specifies + whether the method call should implicitly activate the + called service, should it not be running yet but is + configured to be auto-started. Defaults to + <literal>yes</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--allow-interactive-authorization=</option><replaceable>BOOL</replaceable></term> + + <listitem> + <para>When used with the <command>call</command> command, + specifies whether the services may enforce interactive + authorization while executing the operation, if the security + policy is configured for this. Defaults to + <literal>yes</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--timeout=</option><replaceable>SECS</replaceable></term> + + <listitem> + <para>When used with the <command>call</command> command, + specifies the maximum time to wait for method call + completion. If no time unit is specified, assumes + seconds. The usual other units are understood, too (ms, us, + s, min, h, d, w, month, y). Note that this timeout does not + apply if <option>--expect-reply=no</option> is used, as the + tool does not wait for any reply message then. When not + specified or when set to 0, the default of + <literal>25s</literal> is assumed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--augment-creds=</option><replaceable>BOOL</replaceable></term> + + <listitem> + <para>Controls whether credential data reported by + <command>list</command> or <command>status</command> shall + be augmented with data from + <filename>/proc/</filename>. When this is turned on, the data + shown is possibly inconsistent, as the data read from + <filename>/proc/</filename> might be more recent than the rest of + the credential information. Defaults to <literal>yes</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--watch-bind=</option><replaceable>BOOL</replaceable></term> + + <listitem> + <para>Controls whether to wait for the specified <constant>AF_UNIX</constant> bus socket to appear in the + file system before connecting to it. Defaults to off. When enabled, the tool will watch the file system until + the socket is created and then connect to it.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--destination=</option><replaceable>SERVICE</replaceable></term> + + <listitem> + <para>Takes a service name. When used with the <command>emit</command> command, a signal is + emitted to the specified service.</para> + </listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="user" /> + <xi:include href="user-system-options.xml" xpointer="system" /> + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem> + <para>Do not ellipsize the output in <command>list</command> command.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Parameter Formatting</title> + + <para>The <command>call</command> and + <command>set-property</command> commands take a signature string + followed by a list of parameters formatted as string (for details + on D-Bus signature strings, see the <ulink + url="http://dbus.freedesktop.org/doc/dbus-specification.html#type-system">Type + system chapter of the D-Bus specification</ulink>). For simple + types, each parameter following the signature should simply be the + parameter's value formatted as string. Positive boolean values may + be formatted as <literal>true</literal>, <literal>yes</literal>, + <literal>on</literal>, or <literal>1</literal>; negative boolean + values may be specified as <literal>false</literal>, + <literal>no</literal>, <literal>off</literal>, or + <literal>0</literal>. For arrays, a numeric argument for the + number of entries followed by the entries shall be specified. For + variants, the signature of the contents shall be specified, + followed by the contents. For dictionaries and structs, the + contents of them shall be directly specified.</para> + + <para>For example, + <programlisting>s jawoll</programlisting> is the formatting + of a single string <literal>jawoll</literal>.</para> + + <para> + <programlisting>as 3 hello world foobar</programlisting> + is the formatting of a string array with three entries, + <literal>hello</literal>, <literal>world</literal> and + <literal>foobar</literal>.</para> + + <para> + <programlisting>a{sv} 3 One s Eins Two u 2 Yes b true</programlisting> + is the formatting of a dictionary + array that maps strings to variants, consisting of three + entries. The string <literal>One</literal> is assigned the + string <literal>Eins</literal>. The string + <literal>Two</literal> is assigned the 32-bit unsigned + integer 2. The string <literal>Yes</literal> is assigned a + positive boolean.</para> + + <para>Note that the <command>call</command>, + <command>get-property</command>, <command>introspect</command> + commands will also generate output in this format for the returned + data. Since this format is sometimes too terse to be easily + understood, the <command>call</command> and + <command>get-property</command> commands may generate a more + verbose, multi-line output when passed the + <option>--verbose</option> option.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Write and Read a Property</title> + + <para>The following two commands first write a property and then + read it back. The property is found on the + <literal>/org/freedesktop/systemd1</literal> object of the + <literal>org.freedesktop.systemd1</literal> service. The name of + the property is <literal>LogLevel</literal> on the + <literal>org.freedesktop.systemd1.Manager</literal> + interface. The property contains a single string:</para> + + <programlisting># busctl set-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel s debug +# busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel +s "debug"</programlisting> + + </example> + + <example> + <title>Terse and Verbose Output</title> + + <para>The following two commands read a property that contains + an array of strings, and first show it in terse format, followed + by verbose format:</para> + + <programlisting>$ busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment +as 2 "LANG=en_US.UTF-8" "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" +$ busctl get-property --verbose org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment +ARRAY "s" { + STRING "LANG=en_US.UTF-8"; + STRING "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"; +};</programlisting> + </example> + + <example> + <title>Invoking a Method</title> + + <para>The following command invokes the + <literal>StartUnit</literal> method on the + <literal>org.freedesktop.systemd1.Manager</literal> + interface of the + <literal>/org/freedesktop/systemd1</literal> object + of the <literal>org.freedesktop.systemd1</literal> + service, and passes it two strings + <literal>cups.service</literal> and + <literal>replace</literal>. As a result of the method + call, a single object path parameter is received and + shown:</para> + + <programlisting># busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss "cups.service" "replace" +o "/org/freedesktop/systemd1/job/42684"</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry project='dbus'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <ulink url="https://www.freedesktop.org/wiki/Software/dbus">D-Bus</ulink>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>wireshark</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml new file mode 100644 index 0000000..942a31d --- /dev/null +++ b/man/coredump.conf.xml @@ -0,0 +1,138 @@ +<?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-or-later --> + +<refentry id="coredump.conf" conditional="ENABLE_COREDUMP" + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>coredump.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>coredump.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>coredump.conf</refname> + <refname>coredump.conf.d</refname> + <refpurpose>Core dump storage configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/coredump.conf</filename></para> + <para><filename>/etc/systemd/coredump.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/coredump.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/coredump.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These files configure the behavior of + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + a handler for core dumps invoked by the kernel. Whether <command>systemd-coredump</command> is used + is determined by the kernel's + <varname>kernel.core_pattern</varname> <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + setting. See + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry> + pages for the details.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the + [Coredump] section:</para> + + <variablelist class='config-directives'> + + <varlistentry> + <term><varname>Storage=</varname></term> + + <listitem><para>Controls where to store cores. One of <literal>none</literal>, + <literal>external</literal>, and <literal>journal</literal>. When + <literal>none</literal>, the core dumps may be logged (including the backtrace if + possible), but not stored permanently. When <literal>external</literal> (the + default), cores will be stored in <filename>/var/lib/systemd/coredump/</filename>. + When <literal>journal</literal>, cores will be stored in the journal and rotated + following normal journal rotation patterns.</para> + + <para>When cores are stored in the journal, they might be + compressed following journal compression settings, see + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + When cores are stored externally, they will be compressed + by default, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Compress=</varname></term> + + <listitem><para>Controls compression for external + storage. Takes a boolean argument, which defaults to + <literal>yes</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProcessSizeMax=</varname></term> + + <listitem><para>The maximum size in bytes of a core + which will be processed. Core dumps exceeding this size + may be stored, but the backtrace will not be generated. + </para> + + <para>Setting <varname>Storage=none</varname> and <varname>ProcessSizeMax=0</varname> + disables all coredump handling except for a log entry.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExternalSizeMax=</varname></term> + <term><varname>JournalSizeMax=</varname></term> + + <listitem><para>The maximum (uncompressed) size in bytes of a + core to be saved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxUse=</varname></term> + <term><varname>KeepFree=</varname></term> + + <listitem><para>Enforce limits on the disk space taken up by + externally stored core dumps. <option>MaxUse=</option> makes + sure that old core dumps are removed as soon as the total disk + space taken up by core dumps grows beyond this limit (defaults + to 10% of the total disk size). <option>KeepFree=</option> + controls how much disk space to keep free at least (defaults + to 15% of the total disk size). Note that the disk space used + by core dumps might temporarily exceed these limits while + core dumps are processed. Note that old core dumps are also + removed based on time via + <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Set + either value to 0 to turn off size-based + clean-up.</para></listitem> + </varlistentry> + </variablelist> + + <para>The defaults for all values are listed as comments in the + template <filename>/etc/systemd/coredump.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>, + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/coredumpctl.xml b/man/coredumpctl.xml new file mode 100644 index 0000000..62dbb31 --- /dev/null +++ b/man/coredumpctl.xml @@ -0,0 +1,351 @@ +<?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-or-later --> + +<refentry id="coredumpctl" conditional='ENABLE_COREDUMP' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>coredumpctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>coredumpctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>coredumpctl</refname> + <refpurpose>Retrieve and process saved core dumps and metadata</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>coredumpctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">PID|COMM|EXE|MATCH</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>coredumpctl</command> is a tool that can be used to retrieve and process core + dumps and metadata which were saved by + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>list</command></term> + + <listitem><para>List core dumps captured in the journal + matching specified characteristics. If no command is + specified, this is the implied default.</para> + + <para>The output is designed to be human readable and contains a table with the following + columns:</para> + <variablelist> + <varlistentry> + <term>TIME</term> + <listitem><para>The timestamp of the crash, as reported by the kernel.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PID</term> + <listitem><para>The identifier of the process that crashed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>UID</term> + <term>GID</term> + <listitem><para>The user and group identifiers of the process that crashed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SIGNAL</term> + <listitem><para>The signal that caused the process to crash, when applicable. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>COREFILE</term> + <listitem><para>Information whether the coredump was stored, and whether + it is still accessible: <literal>none</literal> means the core was + not stored, <literal>-</literal> means that it was not available (for + example because the process was not terminated by a signal), + <literal>present</literal> means that the core file is accessible by the + current user, <literal>journal</literal> means that the core was stored + in the <literal>journal</literal>, <literal>truncated</literal> is the + same as one of the previous two, but the core was too large and was not + stored in its entirety, <literal>error</literal> means that the core file + cannot be accessed, most likely because of insufficient permissions, and + <literal>missing</literal> means that the core was stored in a file, but + this file has since been removed.</para></listitem> + </varlistentry> + + <varlistentry> + <term>EXE</term> + <listitem><para>The full path to the executable. For backtraces of scripts + this is the name of the interpreter.</para></listitem> + </varlistentry> + </variablelist> + + <para>It's worth noting that different restrictions apply to + data saved in the journal and core dump files saved in + <filename>/var/lib/systemd/coredump</filename>, see overview in + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Thus it may very well happen that a particular core dump is still listed + in the journal while its corresponding core dump file has already been + removed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>info</command></term> + + <listitem><para>Show detailed information about the last core dump + or core dumps matching specified characteristics + captured in the journal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>dump</command></term> + + <listitem><para>Extract the last core dump matching specified + characteristics. The core dump will be written on standard + output, unless an output file is specified with + <option>--output=</option>. </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>debug</command></term> + + <listitem><para>Invoke a debugger on the last core dump + matching specified characteristics. By default, + <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will be used. This may be changed using the <option>--debugger=</option> + option or the <varname>$SYSTEMD_DEBUGGER</varname> environment + variable.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + + <varlistentry> + <term><option>--no-legend</option></term> + + <listitem><para>Do not print column headers.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + + <varlistentry> + <term><option>-1</option></term> + + <listitem><para>Show information of a single core dump only, instead of listing + all known core dumps.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-S</option></term> + <term><option>--since</option></term> + + <listitem><para>Only print entries which are since the specified date.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-U</option></term> + <term><option>--until</option></term> + + <listitem><para>Only print entries which are until the specified date.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--reverse</option></term> + + <listitem><para>Reverse output so that the newest entries are displayed first. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-F</option> <replaceable>FIELD</replaceable></term> + <term><option>--field=</option><replaceable>FIELD</replaceable></term> + + <listitem><para>Print all possible data values the specified + field takes in matching core dump entries of the + journal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-o</option> <replaceable>FILE</replaceable></term> + <term><option>--output=</option><replaceable>FILE</replaceable></term> + + <listitem><para>Write the core to <option>FILE</option>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--debugger=</option><replaceable>DEBUGGER</replaceable></term> + + <listitem><para>Use the given debugger for the <command>debug</command> + command. If not given and <varname>$SYSTEMD_DEBUGGER</varname> is unset, then + <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will be used. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--file=<replaceable>GLOB</replaceable></option></term> + + <listitem><para>Takes a file glob as an argument. If + specified, coredumpctl will operate on the specified journal + files matching <replaceable>GLOB</replaceable> instead of the + default runtime and system journal paths. May be specified + multiple times, in which case files will be suitably + interleaved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-D</option> <replaceable>DIR</replaceable></term> + <term><option>--directory=</option><replaceable>DIR</replaceable></term> + + <listitem><para>Use the journal files in the specified <option>DIR</option>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Suppresses informational messages about lack + of access to journal files and possible in-flight coredumps. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Matching</title> + + <para>A match can be:</para> + + <variablelist> + <varlistentry> + <term><replaceable>PID</replaceable></term> + + <listitem><para>Process ID of the + process that dumped + core. An integer.</para></listitem> + </varlistentry> + + <varlistentry> + <term><replaceable>COMM</replaceable></term> + + <listitem><para>Name of the executable (matches + <option>COREDUMP_COMM=</option>). Must not contain slashes. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><replaceable>EXE</replaceable></term> + + <listitem><para>Path to the executable (matches + <option>COREDUMP_EXE=</option>). Must contain at least one + slash. </para></listitem> + </varlistentry> + + <varlistentry> + <term><replaceable>MATCH</replaceable></term> + + <listitem><para>General journalctl match filter, must contain an equals + sign (<literal>=</literal>). See + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + <para>On success, 0 is returned; otherwise, a non-zero failure + code is returned. Not finding any matching core dumps is treated as + failure. + </para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$SYSTEMD_DEBUGGER</varname></term> + <listitem><para>Use the given debugger for the <command>debug</command> + command. See the <option>--debugger=</option> option.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>List all the core dumps of a program named foo</title> + + <programlisting># coredumpctl list foo</programlisting> + </example> + + <example> + <title>Invoke gdb on the last core dump</title> + + <programlisting># coredumpctl debug</programlisting> + </example> + + <example> + <title>Show information about a process that dumped core, + matching by its PID 6654</title> + + <programlisting># coredumpctl info 6654</programlisting> + </example> + + <example> + <title>Extract the last core dump of /usr/bin/bar to a file named + <filename index="false">bar.coredump</filename></title> + + <programlisting># coredumpctl -o bar.coredump dump /usr/bin/bar</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/crypttab.xml b/man/crypttab.xml new file mode 100644 index 0000000..0519242 --- /dev/null +++ b/man/crypttab.xml @@ -0,0 +1,575 @@ +<?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-or-later + + This is based on crypttab(5) from Fedora's initscripts package, which in + turn is based on Debian's version. + + The Red Hat version has been written by Miloslav Trmac <mitr@redhat.com>. +--> +<refentry id="crypttab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>crypttab</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>crypttab</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>crypttab</refname> + <refpurpose>Configuration for encrypted block devices</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/crypttab</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/crypttab</filename> file describes + encrypted block devices that are set up during system boot.</para> + + <para>Empty lines and lines starting with the <literal>#</literal> + character are ignored. Each of the remaining lines describes one + encrypted block device. Fields are delimited by white space.</para> + + <para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>encrypted-device</replaceable> <replaceable>key-file</replaceable> <replaceable>options</replaceable></programlisting> + The first two fields are mandatory, the remaining two are + optional.</para> + + <para>Setting up encrypted block devices using this file supports + three encryption modes: LUKS, TrueCrypt and plain. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for more information about each mode. When no mode is specified in + the options field and the block device contains a LUKS signature, + it is opened as a LUKS device; otherwise, it is assumed to be in + raw dm-crypt (plain mode) format.</para> + + <para>The first field contains the name of the resulting encrypted volume; its block device is set up + below <filename>/dev/mapper/</filename>.</para> + + <para>The second field contains a path to the underlying block + device or file, or a specification of a block device via + <literal>UUID=</literal> followed by the UUID.</para> + + <para>The third field specifies an absolute path to a file with the encryption key. Optionally, + the path may be followed by <literal>:</literal> and an fstab device specification (e.g. starting with + <literal>LABEL=</literal> or similar); in which case the path is taken relative to the device file system + root. If the field is not present or is <literal>none</literal> or <literal>-</literal>, a key file + named after the volume to unlock (i.e. the first column of the line), suffixed with + <filename>.key</filename> is automatically loaded from the <filename>/etc/cryptsetup-keys.d/</filename> + and <filename>/run/cryptsetup-keys.d/</filename> directories, if present. Otherwise, the password has to + be manually entered during system boot. For swap encryption, <filename>/dev/urandom</filename> may be + used as key file.</para> + + <para>The fourth field, if present, is a comma-delimited list of + options. The following options are recognized:</para> + + <variablelist class='fstab-options'> + + <varlistentry> + <term><option>cipher=</option></term> + + <listitem><para>Specifies the cipher to use. See <citerefentry + project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this option. A cipher with unpredictable IV values, such + as <literal>aes-cbc-essiv:sha256</literal>, is recommended. Embedded commas in the cipher + specification need to be escaped by preceding them with a backslash, see example below.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>discard</option></term> + + <listitem><para>Allow discard requests to be passed through the encrypted block + device. This improves performance on SSD storage but has security implications. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>hash=</option></term> + + <listitem><para>Specifies the hash to use for password + hashing. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this + option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>header=</option></term> + + <listitem><para>Use a detached (separated) metadata device or + file where the LUKS header is stored. This option is only + relevant for LUKS devices. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this + option.</para> + + <para>Optionally, the path may be followed by <literal>:</literal> and an fstab device specification + (e.g. starting with <literal>UUID=</literal> or similar); in which case, the path is relative to the + device file system root. The device gets mounted automatically for LUKS device activation duration only. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>keyfile-offset=</option></term> + + <listitem><para>Specifies the number of bytes to skip at the + start of the key file. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this + option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>keyfile-size=</option></term> + + <listitem><para>Specifies the maximum number of bytes to read + from the key file. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this option. This + option is ignored in plain encryption mode, as the key file + size is then given by the key size.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>keyfile-erase</option></term> + + <listitem><para>If enabled, the specified key file is erased after the volume is activated or when + activation fails. This is in particular useful when the key file is only acquired transiently before + activation (e.g. via a file in <filename>/run/</filename>, generated by a service running before + activation), and shall be removed after use. Defaults to off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>key-slot=</option></term> + + <listitem><para>Specifies the key slot to compare the + passphrase or key against. If the key slot does not match the + given passphrase or key, but another would, the setup of the + device will fail regardless. This option implies + <option>luks</option>. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values. The default is to try all key slots in + sequential order.</para></listitem> + </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 + following options are ignored since they are provided by the + LUKS header on the device: <option>cipher=</option>, + <option>hash=</option>, + <option>size=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>bitlk</option></term> + + <listitem><para>Decrypt Bitlocker drive. Encryption parameters + are deduced by cryptsetup from Bitlocker header.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>_netdev</option></term> + + <listitem><para>Marks this cryptsetup device as requiring network. It will be + started after the network is available, similarly to + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + units marked with <option>_netdev</option>. The service unit to set up this device + will be ordered between <filename>remote-fs-pre.target</filename> and + <filename>remote-cryptsetup.target</filename>, instead of + <filename>cryptsetup-pre.target</filename> and + <filename>cryptsetup.target</filename>.</para> + + <para>Hint: if this device is used for a mount point that is specified in + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + the <option>_netdev</option> option should also be used for the mount + point. Otherwise, a dependency loop might be created where the mount point + will be pulled in by <filename>local-fs.target</filename>, while the + service to configure the network is usually only started <emphasis>after</emphasis> + the local file system has been mounted.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>noauto</option></term> + + <listitem><para>This device will not be added to <filename>cryptsetup.target</filename>. + This means that it will not be automatically unlocked on boot, unless something else pulls + it in. In particular, if the device is used for a mount point, it'll be unlocked + automatically during boot, unless the mount point itself is also disabled with + <option>noauto</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>nofail</option></term> + + <listitem><para>This device will not be a hard dependency of + <filename>cryptsetup.target</filename>. It'll still be pulled in and started, but the system + will not wait for the device to show up and be unlocked, and boot will not fail if this is + unsuccessful. Note that other units that depend on the unlocked device may still fail. In + particular, if the device is used for a mount point, the mount point itself also needs to + have the <option>nofail</option> option, or the boot will fail if the device is not unlocked + successfully.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>offset=</option></term> + + <listitem><para>Start offset in the backend device, in 512-byte sectors. This + option is only relevant for plain devices.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>plain</option></term> + + <listitem><para>Force plain encryption mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>read-only</option></term><term><option>readonly</option></term> + + <listitem><para>Set up the encrypted block device in read-only + mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>same-cpu-crypt</option></term> + + <listitem><para>Perform encryption using the same cpu that IO was submitted on. The default is to use + an unbound workqueue so that encryption work is automatically balanced between available CPUs.</para> + + <para>This requires kernel 4.0 or newer.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>submit-from-crypt-cpus</option></term> + + <listitem><para>Disable offloading writes to a separate thread after encryption. There are some + situations where offloading write requests from the encryption threads to a dedicated thread degrades + performance significantly. The default is to offload write requests to a dedicated thread because it + benefits the CFQ scheduler to have writes submitted using the same context.</para> + + <para>This requires kernel 4.0 or newer.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>no-read-workqueue</option></term> + + <listitem><para>Bypass dm-crypt internal workqueue and process read requests synchronously. The + default is to queue these requests and process them asynchronously.</para> + + <para>This requires kernel 5.9 or newer.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>no-write-workqueue</option></term> + + <listitem><para>Bypass dm-crypt internal workqueue and process write requests synchronously. The + default is to queue these requests and process them asynchronously.</para> + + <para>This requires kernel 5.9 or newer.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>skip=</option></term> + + <listitem><para>How many 512-byte sectors of the encrypted data to skip at the + beginning. This is different from the <option>offset=</option> option with respect + to the sector numbers used in initialization vector (IV) calculation. Using + <option>offset=</option> will shift the IV calculation by the same negative + amount. Hence, if <option>offset=<replaceable>n</replaceable></option> is given, + sector <replaceable>n</replaceable> will get a sector number of 0 for the IV + calculation. Using <option>skip=</option> causes sector + <replaceable>n</replaceable> to also be the first sector of the mapped device, but + with its number for IV generation being <replaceable>n</replaceable>.</para> + + <para>This option is only relevant for plain devices.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>size=</option></term> + + <listitem><para>Specifies the key size in bits. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this + option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>sector-size=</option></term> + + <listitem><para>Specifies the sector size in bytes. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for possible values and the default value of this + option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>swap</option></term> + + <listitem><para>The encrypted block device will be used as a + swap device, and will be formatted accordingly after setting + up the encrypted block device, with + <citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + This option implies <option>plain</option>.</para> + + <para>WARNING: Using the <option>swap</option> option will + destroy the contents of the named partition during every boot, + so make sure the underlying block device is specified + correctly.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tcrypt</option></term> + + <listitem><para>Use TrueCrypt encryption mode. When this mode + is used, the following options are ignored since they are + provided by the TrueCrypt header on the device or do not + apply: + <option>cipher=</option>, + <option>hash=</option>, + <option>keyfile-offset=</option>, + <option>keyfile-size=</option>, + <option>size=</option>.</para> + + <para>When this mode is used, the passphrase is read from the + key file given in the third field. Only the first line of this + file is read, excluding the new line character.</para> + + <para>Note that the TrueCrypt format uses both passphrase and + key files to derive a password for the volume. Therefore, the + passphrase and all key files need to be provided. Use + <option>tcrypt-keyfile=</option> to provide the absolute path + to all key files. When using an empty passphrase in + combination with one or more key files, use + <literal>/dev/null</literal> as the password file in the third + field.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tcrypt-hidden</option></term> + + <listitem><para>Use the hidden TrueCrypt volume. This option + implies <option>tcrypt</option>.</para> + + <para>This will map the hidden volume that is inside of the + volume provided in the second field. Please note that there is + no protection for the hidden volume if the outer volume is + mounted instead. See + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for more information on this limitation.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tcrypt-keyfile=</option></term> + + <listitem><para>Specifies the absolute path to a key file to + use for a TrueCrypt volume. This implies + <option>tcrypt</option> and can be used more than once to + provide several key files.</para> + + <para>See the entry for <option>tcrypt</option> on the + behavior of the passphrase and key files when using TrueCrypt + encryption mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tcrypt-system</option></term> + + <listitem><para>Use TrueCrypt in system encryption mode. This + option implies <option>tcrypt</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tcrypt-veracrypt</option></term> + + <listitem><para>Check for a VeraCrypt volume. VeraCrypt is a fork of + TrueCrypt that is mostly compatible, but uses different, stronger key + derivation algorithms that cannot be detected without this flag. + Enabling this option could substantially slow down unlocking, because + VeraCrypt's key derivation takes much longer than TrueCrypt's. This + option implies <option>tcrypt</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>timeout=</option></term> + + <listitem><para>Specifies the timeout for querying for a + password. If no unit is specified, seconds is used. Supported + units are s, ms, us, min, h, d. A timeout of 0 waits + indefinitely (which is the default).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tmp=</option></term> + + <listitem><para>The encrypted block device will be prepared for using it as + <filename>/tmp/</filename>; it will be formatted using <citerefentry + project='man-pages'><refentrytitle>mkfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes + a file system type as argument, such as <literal>ext4</literal>, <literal>xfs</literal> or + <literal>btrfs</literal>. If no argument is specified defaults to <literal>ext4</literal>. This + option implies <option>plain</option>.</para> + + <para>WARNING: Using the <option>tmp</option> option will destroy the contents of the named partition + during every boot, so make sure the underlying block device is specified correctly.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>tries=</option></term> + + <listitem><para>Specifies the maximum number of times the user + is queried for a password. The default is 3. If set to 0, the + user is queried for a password indefinitely.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>verify</option></term> + + <listitem><para>If the encryption password is read from console, it has to be entered twice to + prevent typos.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>pkcs11-uri=</option></term> + + <listitem><para>Takes a <ulink url="https://tools.ietf.org/html/rfc7512">RFC7512 PKCS#11 URI</ulink> + pointing to a private RSA key which is used to decrypt the key specified in the third column of the + line. This is useful for unlocking encrypted volumes through security tokens or smartcards. See below + for an example how to set up this mechanism for unlocking a LUKS volume with a YubiKey security + token. The specified URI can refer directly to a private RSA key stored on a token or alternatively + just to a slot or token, in which case a search for a suitable private RSA key will be performed. In + this case if multiple suitable objects are found the token is refused. The key configured in the + third column is passed as is to RSA decryption. The resulting decrypted key is then base64 encoded + before it is used to unlock the LUKS volume.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>try-empty-password=</option></term> + + <listitem><para>Takes a boolean argument. If enabled, right before asking the user for a password it + is first attempted to unlock the volume with an empty password. This is useful for systems that are + initialized with an encrypted volume with only an empty password set, which shall be replaced with a + suitable password during first boot, but after activation.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.device-timeout=</option></term> + + <listitem><para>Specifies how long systemd should wait for a device to show up + before giving up on the entry. The argument is a time in seconds or explicitly + specified units of + <literal>s</literal>, + <literal>min</literal>, + <literal>h</literal>, + <literal>ms</literal>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-initrd.attach</option></term> + + <listitem><para>Setup this encrypted block device in the initramfs, similarly to + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + units marked with <option>x-initrd.mount</option>.</para> + + <para>Although it's not necessary to mark the mount entry for the root file system with + <option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with + the encrypted block device containing the root file system as otherwise systemd will + attempt to detach the device during the regular system shutdown while it's still in + use. With this option the device will still be detached but later after the root file + system is unmounted.</para> + + <para>All other encrypted block devices that contain file systems mounted in the initramfs + should use this option.</para> + </listitem> + </varlistentry> + + </variablelist> + + <para>At early boot and when the system manager configuration is + reloaded, this file is translated into native systemd units by + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>/etc/crypttab example</title> + <para>Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as + a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two + options <literal>cipher=xchacha12,aes-adiantum-plain64</literal>, + <literal>keyfile-timeout=10s</literal>.</para> + + <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 +external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64 +</programlisting> + </example> + + <example> + <title>Yubikey-based Volume Unlocking Example</title> + + <para>The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA + decryption keys. Here's an example how to set up a Yubikey security token for this purpose, using + <citerefentry project='debian'><refentrytitle>ykmap</refentrytitle><manvolnum>1</manvolnum></citerefentry> + from the yubikey-manager project:</para> + +<programlisting><xi:include href="yubikey-crypttab.sh" parse="text" /></programlisting> + +<para>A few notes on the above:</para> + +<itemizedlist> + <listitem><para>We use RSA (and not ECC), since Yubikeys support PKCS#11 Decrypt() only for RSA keys</para></listitem> + <listitem><para>We use RSA2048, which is the longest key size current Yubikeys support</para></listitem> + <listitem><para>LUKS key size must be shorter than 2048bit due to RSA padding, hence we use 128 bytes</para></listitem> + <listitem><para>We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes, + <ulink url="https://developers.yubico.com/PIV/Introduction/Certificate_slots.html">see + documentation</ulink>.</para></listitem> +</itemizedlist> + + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mke2fs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/custom-entities.ent.in b/man/custom-entities.ent.in new file mode 100644 index 0000000..9963322 --- /dev/null +++ b/man/custom-entities.ent.in @@ -0,0 +1,15 @@ +<?xml version="1.0" encoding="utf-8" ?> +<!ENTITY MOUNT_PATH @MOUNT_PATH@> +<!ENTITY UMOUNT_PATH @UMOUNT_PATH@> +<!ENTITY systemgeneratordir @SYSTEM_GENERATOR_DIR@> +<!ENTITY usergeneratordir @USER_GENERATOR_DIR@> +<!ENTITY systemenvgeneratordir @SYSTEM_ENV_GENERATOR_DIR@> +<!ENTITY userenvgeneratordir @USER_ENV_GENERATOR_DIR@> +<!ENTITY CERTIFICATE_ROOT @CERTIFICATE_ROOT@> +<!ENTITY FALLBACK_HOSTNAME @FALLBACK_HOSTNAME@> +<!ENTITY MEMORY_ACCOUNTING_DEFAULT @MEMORY_ACCOUNTING_DEFAULT_YES_NO@> +<!ENTITY KILL_USER_PROCESSES @KILL_USER_PROCESSES_YES_NO@> +<!ENTITY DEBUGTTY @DEBUGTTY@> +<!ENTITY RC_LOCAL_PATH @RC_LOCAL_PATH@> +<!ENTITY fedora_latest_version "33"> +<!ENTITY fedora_cloud_release "1.2"> diff --git a/man/custom-html.xsl b/man/custom-html.xsl new file mode 100644 index 0000000..6e4dc27 --- /dev/null +++ b/man/custom-html.xsl @@ -0,0 +1,318 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> + +<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/> +<!-- + - The docbook stylesheet injects empty anchor tags into generated HTML, identified by an auto-generated ID. + - Ask the docbook stylesheet to generate reproducible output when generating (these) ID values. + - This makes the output of this stylesheet reproducible across identical invocations on the same input, + - which is an easy and significant win for achieving reproducible builds. + - + - It may be even better to strip the empty anchors from the document output in addition to turning on consistent IDs, + - for this stylesheet contains its own custom ID logic (for generating permalinks) already. + --> +<xsl:param name="generate.consistent.ids" select="1"/> + +<!-- translate man page references to links to html pages --> +<xsl:template match="citerefentry[not(@project)]"> + <a> + <xsl:attribute name="href"> + <xsl:value-of select="refentrytitle"/> + <xsl:text>.html#</xsl:text> + <xsl:value-of select="refentrytitle/@target"/> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='man-pages'] | citerefentry[manvolnum='2'] | citerefentry[manvolnum='4']"> + <a> + <xsl:attribute name="href"> + <xsl:text>http://man7.org/linux/man-pages/man</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>.</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>.html</xsl:text> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='die-net']"> + <a> + <xsl:attribute name="href"> + <xsl:text>http://linux.die.net/man/</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>/</xsl:text> + <xsl:value-of select="refentrytitle"/> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='wireguard']"> + <a> + <xsl:attribute name="href"> + <xsl:text>https://git.zx2c4.com/WireGuard/about/src/tools/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>.</xsl:text> + <xsl:value-of select="manvolnum"/> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='mankier']"> + <a> + <xsl:attribute name="href"> + <xsl:text>https://www.mankier.com/</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>/</xsl:text> + <xsl:value-of select="refentrytitle"/> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='archlinux']"> + <a> + <xsl:attribute name="href"> + <xsl:text>https://www.archlinux.org/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>.</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>.html</xsl:text> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='debian']"> + <a> + <xsl:attribute name="href"> + <xsl:text>https://manpages.debian.org/unstable/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>.</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>.en.html</xsl:text> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='freebsd']"> + <a> + <xsl:attribute name="href"> + <xsl:text>https://www.freebsd.org/cgi/man.cgi?</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>(</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>)</xsl:text> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='dbus']"> + <a> + <xsl:attribute name="href"> + <xsl:text>http://dbus.freedesktop.org/doc/</xsl:text> + <xsl:value-of select="refentrytitle"/> + <xsl:text>.</xsl:text> + <xsl:value-of select="manvolnum"/> + <xsl:text>.html</xsl:text> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<xsl:template match="citerefentry[@project='url']"> + <a> + <xsl:attribute name="href"> + <xsl:value-of select="refentrytitle/@url"/> + </xsl:attribute> + <xsl:call-template name="inline.charseq"/> + </a> +</xsl:template> + +<!-- + - helper template to do conflict resolution between various headings with the same inferred ID attribute/tag from the headerlink template + - this conflict resolution is necessary to prevent malformed HTML output (multiple ID attributes with the same value) + - and it fixes xsltproc warnings during compilation of HTML man pages + - + - A simple top-to-bottom numbering scheme is implemented for nodes with the same ID value to derive unique ID values for HTML output. + - It uses two parameters: + templateID the proposed ID string to use which must be checked for conflicts + keyNode the context node which 'produced' the given templateID. + - + - Conflicts are detected solely based on keyNode, templateID is not taken into account for that purpose. + --> +<xsl:template name="generateID"> + <!-- node which generatedID needs to assume as the 'source' of the ID --> + <xsl:param name="keyNode"/> + <!-- suggested value for generatedID output, a contextually meaningful ID string --> + <xsl:param name="templateID"/> + <xsl:variable name="conflictSource" select="preceding::refsect1/title|preceding::refsect1/info/title| + preceding::refsect2/title|preceding::refsect2/info/title| + preceding::varlistentry/term[1]"/> + <xsl:variable name="conflictCount" select="count($conflictSource[. = $keyNode])"/> + <xsl:choose> + <!-- special case conflictCount = 0 to preserve compatibility with URLs generated by previous versions of this XSL stylesheet where possible --> + <xsl:when test="$conflictCount = 0"> + <xsl:value-of select="$templateID"/> + </xsl:when> + <xsl:otherwise> + <xsl:value-of select="concat($templateID, $conflictCount)"/> + </xsl:otherwise> + </xsl:choose> +</xsl:template> + +<!-- + - a helper template to abstract over the structure of generated subheading + permalink HTML output + - It helps reduce tedious repetition and groups all actual markup output (as opposed to URL/ID logic) in a single location. + --> +<xsl:template name="permalink"> + <xsl:param name="nodeType"/> <!-- local name of the element node to generate, e.g. 'h2' for <h2></h2> --> + <xsl:param name="nodeContent"/> <!-- nodeset to apply further templates to obtain the content of the subheading/term --> + <xsl:param name="linkTitle"/> <!-- value for title attribute of generated permalink, e.g. 'this is a permalink' --> + + <!-- parameters passed to generateID template, otherwise unused. --> + <xsl:param name="keyNode"/> + <xsl:param name="templateID"/> + + <!-- + - If stable URLs with fragment markers (references to the ID) turn out not to be important: + - generatedID could simply take the value of generate-id(), and various other helper templates may be dropped entirely. + - Alternatively, if xsltproc is patched to generate reproducible generate-id() output, the same simplifications can be + - applied at the cost of breaking compatibility with URLs generated from output of previous versions of this stylesheet. + --> + <xsl:variable name="generatedID"> + <xsl:call-template name="generateID"> + <xsl:with-param name="keyNode" select="$keyNode"/> + <xsl:with-param name="templateID" select="$templateID"/> + </xsl:call-template> + </xsl:variable> + + <xsl:element name="{$nodeType}"> + <xsl:attribute name="id"> + <xsl:value-of select="$generatedID"/> + </xsl:attribute> + <xsl:apply-templates select="$nodeContent"/> + <a class="headerlink" title="{$linkTitle}" href="#{$generatedID}">¶</a> + </xsl:element> +</xsl:template> + +<!-- simple wrapper around permalink to avoid repeating common info for each level of subheading covered by the permalink logic (h2, h3) --> +<xsl:template name="headerlink"> + <xsl:param name="nodeType"/> + <xsl:call-template name="permalink"> + <xsl:with-param name="nodeType" select="$nodeType"/> + <xsl:with-param name="linkTitle" select="'Permalink to this headline'"/> + <xsl:with-param name="nodeContent" select="node()"/> + <xsl:with-param name="keyNode" select="."/> + <!-- + - To retain compatibility with IDs generated by previous versions of the template, inline.charseq must be called. + - The purpose of that template is to generate markup (according to docbook documentation its purpose is to mark/format something as plain text). + - The only reason to call this template is to get the auto-generated text such as brackets ([]) before flattening it. + --> + <xsl:with-param name="templateID"> + <xsl:call-template name="inline.charseq"/> + </xsl:with-param> + </xsl:call-template> +</xsl:template> + +<xsl:template match="refsect1/title|refsect1/info/title"> + <!-- the ID is output in the block.object call for refsect1 --> + <xsl:call-template name="headerlink"> + <xsl:with-param name="nodeType" select="'h2'"/> + </xsl:call-template> +</xsl:template> + +<xsl:template match="refsect2/title|refsect2/info/title"> + <xsl:call-template name="headerlink"> + <xsl:with-param name="nodeType" select="'h3'"/> + </xsl:call-template> +</xsl:template> + +<xsl:template match="varlistentry"> + <xsl:call-template name="permalink"> + <xsl:with-param name="nodeType" select="'dt'"/> + <xsl:with-param name="linkTitle" select="'Permalink to this term'"/> + <xsl:with-param name="nodeContent" select="term"/> + <xsl:with-param name="keyNode" select="term[1]"/> + <!-- + - To retain compatibility with IDs generated by previous versions of the template, inline.charseq must be called. + - The purpose of that template is to generate markup (according to docbook documentation its purpose is to mark/format something as plain text). + - The only reason to call this template is to get the auto-generated text such as brackets ([]) before flattening it. + --> + <xsl:with-param name="templateID"> + <xsl:call-template name="inline.charseq"> + <xsl:with-param name="content" select="term[1]"/> + </xsl:call-template> + </xsl:with-param> + </xsl:call-template> + <dd> + <xsl:apply-templates select="listitem"/> + </dd> +</xsl:template> + + +<!-- add Index link at top of page --> +<xsl:template name="user.header.content"> + <style> + a.headerlink { + color: #c60f0f; + font-size: 0.8em; + padding: 0 4px 0 4px; + text-decoration: none; + visibility: hidden; + } + + a.headerlink:hover { + background-color: #c60f0f; + color: white; + } + + h1:hover > a.headerlink, h2:hover > a.headerlink, h3:hover > a.headerlink, dt:hover > a.headerlink { + visibility: visible; + } + </style> + + <a> + <xsl:attribute name="href"> + <xsl:text>index.html</xsl:text> + </xsl:attribute> + <xsl:text>Index </xsl:text> + </a>· + <a> + <xsl:attribute name="href"> + <xsl:text>systemd.directives.html</xsl:text> + </xsl:attribute> + <xsl:text>Directives </xsl:text> + </a> + + <span style="float:right"> + <xsl:text>systemd </xsl:text> + <xsl:value-of select="$systemd.version"/> + </span> + <hr/> +</xsl:template> + +<xsl:template match="literal"> + <xsl:text>"</xsl:text> + <xsl:call-template name="inline.monoseq"/> + <xsl:text>"</xsl:text> +</xsl:template> + +<!-- Switch things to UTF-8, ISO-8859-1 is soo yesteryear --> +<xsl:output method="html" encoding="UTF-8" indent="no"/> + +</xsl:stylesheet> diff --git a/man/custom-man.xsl b/man/custom-man.xsl new file mode 100644 index 0000000..2ed361f --- /dev/null +++ b/man/custom-man.xsl @@ -0,0 +1,49 @@ +<?xml version='1.0'?> <!--*-nxml-*--> + +<!-- + SPDX-License-Identifier: LGPL-2.1-or-later +--> + +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + xmlns:exsl="http://exslt.org/common" + extension-element-prefixes="exsl" + version="1.0"> + +<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/> + +<xsl:template name="top.comment" /> + +<xsl:template name="TH.title.line"> + <xsl:param name="title"/> + <xsl:param name="section"/> + <xsl:param name="extra1"/> + <xsl:param name="extra2"/> + <xsl:param name="extra3"/> + + <xsl:call-template name="mark.subheading"/> + <xsl:text>.TH "</xsl:text> + <xsl:call-template name="string.upper"> + <xsl:with-param name="string"> + <xsl:value-of select="normalize-space($title)"/> + </xsl:with-param> + </xsl:call-template> + <xsl:text>" "</xsl:text> + <xsl:value-of select="normalize-space($section)"/> + <xsl:text>" "" "systemd </xsl:text> + <xsl:value-of select="$systemd.version"/> + <xsl:text>" "</xsl:text> + <xsl:value-of select="normalize-space($extra3)"/> + <xsl:text>" </xsl:text> + <xsl:call-template name="mark.subheading"/> +</xsl:template> + +<xsl:template match="literal"> + <xsl:if test="$man.hyphenate.computer.inlines = 0"> + <xsl:call-template name="suppress.hyphenation"/> + </xsl:if> + <xsl:text>"</xsl:text> + <xsl:call-template name="inline.monoseq"/> + <xsl:text>"</xsl:text> +</xsl:template> + +</xsl:stylesheet> diff --git a/man/daemon.xml b/man/daemon.xml new file mode 100644 index 0000000..db95d2f --- /dev/null +++ b/man/daemon.xml @@ -0,0 +1,731 @@ +<?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-or-later --> + +<refentry id="daemon"> + + <refentryinfo> + <title>daemon</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>daemon</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>daemon</refname> + <refpurpose>Writing and packaging system daemons</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>A daemon is a service process that runs in the background + and supervises the system or provides functionality to other + processes. Traditionally, daemons are implemented following a + scheme originating in SysV Unix. Modern daemons should follow a + simpler yet more powerful scheme (here called "new-style" + daemons), as implemented by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + This manual page covers both schemes, and in particular includes + recommendations for daemons that shall be included in the systemd + init system.</para> + + <refsect2> + <title>SysV Daemons</title> + + <para>When a traditional SysV daemon starts, it should execute + the following steps as part of the initialization. Note that + these steps are unnecessary for new-style daemons (see below), + and should only be implemented if compatibility with SysV is + essential.</para> + + <orderedlist> + <listitem><para>Close all open file descriptors except + standard input, output, and error (i.e. the first three file + descriptors 0, 1, 2). This ensures that no accidentally passed + file descriptor stays around in the daemon process. On Linux, + this is best implemented by iterating through + <filename>/proc/self/fd</filename>, with a fallback of + iterating from file descriptor 3 to the value returned by + <function>getrlimit()</function> for + <constant>RLIMIT_NOFILE</constant>. </para></listitem> + + <listitem><para>Reset all signal handlers to their default. + This is best done by iterating through the available signals + up to the limit of <constant>_NSIG</constant> and resetting + them to <constant>SIG_DFL</constant>.</para></listitem> + + <listitem><para>Reset the signal mask + using + <function>sigprocmask()</function>.</para></listitem> + + <listitem><para>Sanitize the environment block, removing or + resetting environment variables that might negatively impact + daemon runtime.</para></listitem> + + <listitem><para>Call <function>fork()</function>, to create a + background process.</para></listitem> + + <listitem><para>In the child, call + <function>setsid()</function> to detach from any terminal and + create an independent session.</para></listitem> + + <listitem><para>In the child, call <function>fork()</function> again, to ensure that the daemon can + never re-acquire a terminal again. (This relevant if the program — and all its dependencies — does + not carefully specify `O_NOCTTY` on each and every single `open()` call that might potentially open a + TTY device node.)</para></listitem> + + <listitem><para>Call <function>exit()</function> in the first + child, so that only the second child (the actual daemon + process) stays around. This ensures that the daemon process is + re-parented to init/PID 1, as all daemons should + be.</para></listitem> + + <listitem><para>In the daemon process, connect + <filename>/dev/null</filename> to standard input, output, and + error.</para></listitem> + + <listitem><para>In the daemon process, reset the umask to 0, + so that the file modes passed to <function>open()</function>, + <function>mkdir()</function> and suchlike directly control the + access mode of the created files and + directories.</para></listitem> + + <listitem><para>In the daemon process, change the current + directory to the root directory (/), in order to avoid that + the daemon involuntarily blocks mount points from being + unmounted.</para></listitem> + + <listitem><para>In the daemon process, write the daemon PID + (as returned by <function>getpid()</function>) to a PID file, + for example <filename index='false'>/run/foobar.pid</filename> (for a + hypothetical daemon "foobar") to ensure that the daemon cannot + be started more than once. This must be implemented in + race-free fashion so that the PID file is only updated when it + is verified at the same time that the PID previously stored in + the PID file no longer exists or belongs to a foreign + process.</para></listitem> + + <listitem><para>In the daemon process, drop privileges, if + possible and applicable.</para></listitem> + + <listitem><para>From the daemon process, notify the original + process started that initialization is complete. This can be + implemented via an unnamed pipe or similar communication + channel that is created before the first + <function>fork()</function> and hence available in both the + original and the daemon process.</para></listitem> + + <listitem><para>Call <function>exit()</function> in the + original process. The process that invoked the daemon must be + able to rely on that this <function>exit()</function> happens + after initialization is complete and all external + communication channels are established and + accessible.</para></listitem> + </orderedlist> + + <para>The BSD <function>daemon()</function> function should not + be used, as it implements only a subset of these steps.</para> + + <para>A daemon that needs to provide compatibility with SysV + systems should implement the scheme pointed out above. However, + it is recommended to make this behavior optional and + configurable via a command line argument to ease debugging as + well as to simplify integration into systems using + systemd.</para> + </refsect2> + + <refsect2> + <title>New-Style Daemons</title> + + <para>Modern services for Linux should be implemented as + new-style daemons. This makes it easier to supervise and control + them at runtime and simplifies their implementation.</para> + + <para>For developing a new-style daemon, none of the + initialization steps recommended for SysV daemons need to be + implemented. New-style init systems such as systemd make all of + them redundant. Moreover, since some of these steps interfere + with process monitoring, file descriptor passing and other + functionality of the init system, it is recommended not to + execute them when run as new-style service.</para> + + <para>Note that new-style init systems guarantee execution of daemon processes in a clean process context: it is + guaranteed that the environment block is sanitized, that the signal handlers and mask is reset and that no + left-over file descriptors are passed. Daemons will be executed in their own session, with standard input + connected to <filename>/dev/null</filename> and standard output/error connected to the + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + logging service, unless otherwise configured. The umask is reset. + </para> + + <para>It is recommended for new-style daemons to implement the + following:</para> + + <orderedlist> + <listitem><para>If <constant>SIGTERM</constant> is received, + shut down the daemon and exit cleanly.</para></listitem> + + <listitem><para>If <constant>SIGHUP</constant> is received, + reload the configuration files, if this + applies.</para></listitem> + + <listitem><para>Provide a correct exit code from the main + daemon process, as this is used by the init system to detect + service errors and problems. It is recommended to follow the + exit code scheme as defined in the <ulink + url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB + recommendations for SysV init + scripts</ulink>.</para></listitem> + + <listitem><para>If possible and applicable, expose the + daemon's control interface via the D-Bus IPC system and grab a + bus name as last step of initialization.</para></listitem> + + <listitem><para>For integration in systemd, provide a + <filename>.service</filename> unit file that carries + information about starting, stopping and otherwise maintaining + the daemon. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> + + <listitem><para>As much as possible, rely on the init system's + functionality to limit the access of the daemon to files, + services and other resources, i.e. in the case of systemd, + rely on systemd's resource limit control instead of + implementing your own, rely on systemd's privilege dropping + code instead of implementing it in the daemon, and similar. + See + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the available controls.</para></listitem> + + <listitem><para>If D-Bus is used, make your daemon + bus-activatable by supplying a D-Bus service activation + configuration file. This has multiple advantages: your daemon + may be started lazily on-demand; it may be started in parallel + to other daemons requiring it — which maximizes + parallelization and boot-up speed; your daemon can be + restarted on failure without losing any bus requests, as the + bus queues requests for activatable services. See below for + details.</para></listitem> + + <listitem><para>If your daemon provides services to other + local processes or remote clients via a socket, it should be + made socket-activatable following the scheme pointed out + below. Like D-Bus activation, this enables on-demand starting + of services as well as it allows improved parallelization of + service start-up. Also, for state-less protocols (such as + syslog, DNS), a daemon implementing socket-based activation + can be restarted without losing a single request. See below + for details.</para></listitem> + + <listitem><para>If applicable, a daemon should notify the init + system about startup completion or status updates via the + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> + interface.</para></listitem> + + <listitem><para>Instead of using the + <function>syslog()</function> call to log directly to the + system syslog service, a new-style daemon may choose to simply + log to standard error via <function>fprintf()</function>, + which is then forwarded to syslog by the init system. If log + levels are necessary, these can be encoded by prefixing + individual log lines with strings like + <literal><4></literal> (for log level 4 "WARNING" in the + syslog priority scheme), following a similar style as the + Linux kernel's <function>printk()</function> level system. For + details, see + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>As new-style daemons are invoked without a controlling TTY (but as their own session + leaders) care should be taken to always specify `O_NOCTTY` on `open()` calls that possibly reference + a TTY device node, so that no controlling TTY is accidentally acquired.</para></listitem> + + </orderedlist> + + <para>These recommendations are similar but not identical to the + <ulink + url="https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html">Apple + MacOS X Daemon Requirements</ulink>.</para> + </refsect2> + + </refsect1> + <refsect1> + <title>Activation</title> + + <para>New-style init systems provide multiple additional + mechanisms to activate services, as detailed below. It is common + that services are configured to be activated via more than one + mechanism at the same time. An example for systemd: + <filename>bluetoothd.service</filename> might get activated either + when Bluetooth hardware is plugged in, or when an application + accesses its programming interfaces via D-Bus. Or, a print server + daemon might get activated when traffic arrives at an IPP port, or + when a printer is plugged in, or when a file is queued in the + printer spool directory. Even for services that are intended to be + started on system bootup unconditionally, it is a good idea to + implement some of the various activation schemes outlined below, + in order to maximize parallelization. If a daemon implements a + D-Bus service or listening socket, implementing the full bus and + socket activation scheme allows starting of the daemon with its + clients in parallel (which speeds up boot-up), since all its + communication channels are established already, and no request is + lost because client requests will be queued by the bus system (in + case of D-Bus) or the kernel (in case of sockets) until the + activation is completed.</para> + + <refsect2> + <title>Activation on Boot</title> + + <para>Old-style daemons are usually activated exclusively on + boot (and manually by the administrator) via SysV init scripts, + as detailed in the <ulink + url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB + Linux Standard Base Core Specification</ulink>. This method of + activation is supported ubiquitously on Linux init systems, both + old-style and new-style systems. Among other issues, SysV init + scripts have the disadvantage of involving shell scripts in the + boot process. New-style init systems generally employ updated + versions of activation, both during boot-up and during runtime + and using more minimal service description files.</para> + + <para>In systemd, if the developer or administrator wants to + make sure that a service or other unit is activated + automatically on boot, it is recommended to place a symlink to + the unit file in the <filename>.wants/</filename> directory of + either <filename>multi-user.target</filename> or + <filename>graphical.target</filename>, which are normally used + as boot targets at system startup. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details about the <filename>.wants/</filename> directories, + and + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about the two boot targets.</para> + + </refsect2> + + <refsect2> + <title>Socket-Based Activation</title> + + <para>In order to maximize the possible parallelization and + robustness and simplify configuration and development, it is + recommended for all new-style daemons that communicate via + listening sockets to employ socket-based activation. In a + socket-based activation scheme, the creation and binding of the + listening socket as primary communication channel of daemons to + local (and sometimes remote) clients is moved out of the daemon + code and into the init system. Based on per-daemon + configuration, the init system installs the sockets and then + hands them off to the spawned process as soon as the respective + daemon is to be started. Optionally, activation of the service + can be delayed until the first inbound traffic arrives at the + socket to implement on-demand activation of daemons. However, + the primary advantage of this scheme is that all providers and + all consumers of the sockets can be started in parallel as soon + as all sockets are established. In addition to that, daemons can + be restarted with losing only a minimal number of client + transactions, or even any client request at all (the latter is + particularly true for state-less protocols, such as DNS or + syslog), because the socket stays bound and accessible during + the restart, and all requests are queued while the daemon cannot + process them.</para> + + <para>New-style daemons which support socket activation must be + able to receive their sockets from the init system instead of + creating and binding them themselves. For details about the + programming interfaces for this scheme provided by systemd, see + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + For details about porting existing daemons to socket-based + activation, see below. With minimal effort, it is possible to + implement socket-based activation in addition to traditional + internal socket creation in the same codebase in order to + support both new-style and old-style init systems from the same + daemon binary.</para> + + <para>systemd implements socket-based activation via + <filename>.socket</filename> units, which are described in + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + When configuring socket units for socket-based activation, it is + essential that all listening sockets are pulled in by the + special target unit <filename>sockets.target</filename>. It is + recommended to place a + <varname>WantedBy=sockets.target</varname> directive in the + [Install] section to automatically add such a + dependency on installation of a socket unit. Unless + <varname>DefaultDependencies=no</varname> is set, the necessary + ordering dependencies are implicitly created for all socket + units. For more information about + <filename>sockets.target</filename>, see + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + It is not necessary or recommended to place any additional + dependencies on socket units (for example from + <filename>multi-user.target</filename> or suchlike) when one is + installed in <filename>sockets.target</filename>.</para> + </refsect2> + + <refsect2> + <title>Bus-Based Activation</title> + + <para>When the D-Bus IPC system is used for communication with + clients, new-style daemons should employ bus activation so that + they are automatically activated when a client application + accesses their IPC interfaces. This is configured in D-Bus + service files (not to be confused with systemd service unit + files!). To ensure that D-Bus uses systemd to start-up and + maintain the daemon, use the <varname>SystemdService=</varname> + directive in these service files to configure the matching + systemd service for a D-Bus service. e.g.: For a D-Bus service + whose D-Bus activation file is named + <filename>org.freedesktop.RealtimeKit.service</filename>, make + sure to set + <varname>SystemdService=rtkit-daemon.service</varname> in that + file to bind it to the systemd service + <filename>rtkit-daemon.service</filename>. This is needed to + make sure that the daemon is started in a race-free fashion when + activated via multiple mechanisms simultaneously.</para> + </refsect2> + + <refsect2> + <title>Device-Based Activation</title> + + <para>Often, daemons that manage a particular type of hardware + should be activated only when the hardware of the respective + kind is plugged in or otherwise becomes available. In a + new-style init system, it is possible to bind activation to + hardware plug/unplug events. In systemd, kernel devices + appearing in the sysfs/udev device tree can be exposed as units + if they are tagged with the string <literal>systemd</literal>. + Like any other kind of unit, they may then pull in other units + when activated (i.e. plugged in) and thus implement device-based + activation. systemd dependencies may be encoded in the udev + database via the <varname>SYSTEMD_WANTS=</varname> property. See + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. Often, it is nicer to pull in services from devices + only indirectly via dedicated targets. Example: Instead of + pulling in <filename>bluetoothd.service</filename> from all the + various bluetooth dongles and other hardware available, pull in + bluetooth.target from them and + <filename>bluetoothd.service</filename> from that target. This + provides for nicer abstraction and gives administrators the + option to enable <filename>bluetoothd.service</filename> via + controlling a <filename>bluetooth.target.wants/</filename> + symlink uniformly with a command like <command>enable</command> + of + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + instead of manipulating the udev ruleset.</para> + </refsect2> + + <refsect2> + <title>Path-Based Activation</title> + + <para>Often, runtime of daemons processing spool files or + directories (such as a printing system) can be delayed until + these file system objects change state, or become non-empty. + New-style init systems provide a way to bind service activation + to file system changes. systemd implements this scheme via + path-based activation configured in <filename>.path</filename> + units, as outlined in + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect2> + + <refsect2> + <title>Timer-Based Activation</title> + + <para>Some daemons that implement clean-up jobs that are + intended to be executed in regular intervals benefit from + timer-based activation. In systemd, this is implemented via + <filename>.timer</filename> units, as described in + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect2> + + <refsect2> + <title>Other Forms of Activation</title> + + <para>Other forms of activation have been suggested and implemented in some systems. However, there are + often simpler or better alternatives, or they can be put together of combinations of the schemes + above. Example: Sometimes, it appears useful to start daemons or <filename>.socket</filename> units + when a specific IP address is configured on a network interface, because network sockets shall be bound + to the address. However, an alternative to implement this is by utilizing the Linux + <constant>IP_FREEBIND</constant>/<constant>IPV6_FREEBIND</constant> socket option, as accessible via + <varname>FreeBind=yes</varname> in systemd socket files (see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details). This option, when enabled, allows sockets to be bound to a non-local, not configured IP + address, and hence allows bindings to a particular IP address before it actually becomes available, + making such an explicit dependency to the configured address redundant. Another often suggested trigger + for service activation is low system load. However, here too, a more convincing approach might be to + make proper use of features of the operating system, in particular, the CPU or I/O scheduler of + Linux. Instead of scheduling jobs from userspace based on monitoring the OS scheduler, it is advisable + to leave the scheduling of processes to the OS scheduler itself. systemd provides fine-grained access + to the CPU and I/O schedulers. If a process executed by the init system shall not negatively impact the + amount of CPU or I/O bandwidth available to other processes, it should be configured with + <varname>CPUSchedulingPolicy=idle</varname> and/or + <varname>IOSchedulingClass=idle</varname>. Optionally, this may be combined with timer-based activation + to schedule background jobs during runtime and with minimal impact on the system, and remove it from + the boot phase itself.</para> + </refsect2> + + </refsect1> + <refsect1> + <title>Integration with systemd</title> + + <refsect2> + <title>Writing systemd Unit Files</title> + + <para>When writing systemd unit files, it is recommended to + consider the following suggestions:</para> + + <orderedlist> + <listitem><para>If possible, do not use the + <varname>Type=forking</varname> setting in service files. But + if you do, make sure to set the PID file path using + <varname>PIDFile=</varname>. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> + + <listitem><para>If your daemon registers a D-Bus name on the + bus, make sure to use <varname>Type=dbus</varname> in the + service file if possible.</para></listitem> + + <listitem><para>Make sure to set a good human-readable + description string with + <varname>Description=</varname>.</para></listitem> + + <listitem><para>Do not disable + <varname>DefaultDependencies=</varname>, unless you really + know what you do and your unit is involved in early boot or + late system shutdown.</para></listitem> + + <listitem><para>Normally, little if any dependencies should + need to be defined explicitly. However, if you do configure + explicit dependencies, only refer to unit names listed on + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + or names introduced by your own package to keep the unit file + operating system-independent.</para></listitem> + + <listitem><para>Make sure to include an + [Install] section including installation + information for the unit file. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. To activate your service on boot, make sure to + add a <varname>WantedBy=multi-user.target</varname> or + <varname>WantedBy=graphical.target</varname> directive. To + activate your socket on boot, make sure to add + <varname>WantedBy=sockets.target</varname>. Usually, you also + want to make sure that when your service is installed, your + socket is installed too, hence add + <varname>Also=foo.socket</varname> in your service file + <filename>foo.service</filename>, for a hypothetical program + <filename>foo</filename>.</para></listitem> + + </orderedlist> + </refsect2> + + <refsect2> + <title>Installing systemd Service Files</title> + + <para>At the build installation time (e.g. <command>make + install</command> during package build), packages are + recommended to install their systemd unit files in the directory + returned by <command>pkg-config systemd + --variable=systemdsystemunitdir</command> (for system services) + or <command>pkg-config systemd + --variable=systemduserunitdir</command> (for user services). + This will make the services available in the system on explicit + request but not activate them automatically during boot. + Optionally, during package installation (e.g. <command>rpm + -i</command> by the administrator), symlinks should be created + in the systemd configuration directories via the + <command>enable</command> command of the + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool to activate them automatically on boot.</para> + + <para>Packages using + <citerefentry project='die-net'><refentrytitle>autoconf</refentrytitle><manvolnum>1</manvolnum></citerefentry> + are recommended to use a configure script + excerpt like the following to determine the + unit installation path during source + configuration:</para> + + <programlisting>PKG_PROG_PKG_CONFIG +AC_ARG_WITH([systemdsystemunitdir], + [AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],, + [with_systemdsystemunitdir=auto]) +AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [ + def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd) + + AS_IF([test "x$def_systemdsystemunitdir" = "x"], + [AS_IF([test "x$with_systemdsystemunitdir" = "xyes"], + [AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])]) + with_systemdsystemunitdir=no], + [with_systemdsystemunitdir="$def_systemdsystemunitdir"])]) +AS_IF([test "x$with_systemdsystemunitdir" != "xno"], + [AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])]) +AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])</programlisting> + + <para>This snippet allows automatic + installation of the unit files on systemd + machines, and optionally allows their + installation even on machines lacking + systemd. (Modification of this snippet for the + user unit directory is left as an exercise for the + reader.)</para> + + <para>Additionally, to ensure that + <command>make distcheck</command> continues to + work, it is recommended to add the following + to the top-level <filename>Makefile.am</filename> + file in + <citerefentry project='die-net'><refentrytitle>automake</refentrytitle><manvolnum>1</manvolnum></citerefentry>-based + projects:</para> + + <programlisting>AM_DISTCHECK_CONFIGURE_FLAGS = \ + --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)</programlisting> + + <para>Finally, unit files should be installed in the system with an automake excerpt like the following:</para> + + <programlisting>if HAVE_SYSTEMD +systemdsystemunit_DATA = \ + foobar.socket \ + foobar.service +endif</programlisting> + + <para>In the + <citerefentry project='die-net'><refentrytitle>rpm</refentrytitle><manvolnum>8</manvolnum></citerefentry> + <filename>.spec</filename> file, use snippets like the following + to enable/disable the service during + installation/deinstallation. This makes use of the RPM macros + shipped along systemd. Consult the packaging guidelines of your + distribution for details and the equivalent for other package + managers.</para> + + <para>At the top of the file:</para> + + <programlisting>BuildRequires: systemd +%{?systemd_requires}</programlisting> + + <para>And as scriptlets, further down:</para> + + <programlisting>%post +%systemd_post foobar.service foobar.socket + +%preun +%systemd_preun foobar.service foobar.socket + +%postun +%systemd_postun</programlisting> + + <para>If the service shall be restarted during upgrades, replace + the <literal>%postun</literal> scriptlet above with the + following:</para> + + <programlisting>%postun +%systemd_postun_with_restart foobar.service</programlisting> + + <para>Note that <literal>%systemd_post</literal> and + <literal>%systemd_preun</literal> expect the names of all units + that are installed/removed as arguments, separated by spaces. + <literal>%systemd_postun</literal> expects no arguments. + <literal>%systemd_postun_with_restart</literal> expects the + units to restart as arguments.</para> + + <para>To facilitate upgrades from a package version that shipped + only SysV init scripts to a package version that ships both a + SysV init script and a native systemd service file, use a + fragment like the following:</para> + + <programlisting>%triggerun -- foobar < 0.47.11-1 +if /sbin/chkconfig --level 5 foobar ; then + /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || : +fi</programlisting> + + <para>Where 0.47.11-1 is the first package version that includes + the native unit file. This fragment will ensure that the first + time the unit file is installed, it will be enabled if and only + if the SysV init script is enabled, thus making sure that the + enable status is not changed. Note that + <command>chkconfig</command> is a command specific to Fedora + which can be used to check whether a SysV init script is + enabled. Other operating systems will have to use different + commands here.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Porting Existing Daemons</title> + + <para>Since new-style init systems such as systemd are compatible + with traditional SysV init systems, it is not strictly necessary + to port existing daemons to the new style. However, doing so + offers additional functionality to the daemons as well as + simplifying integration into new-style init systems.</para> + + <para>To port an existing SysV compatible daemon, the following + steps are recommended:</para> + + <orderedlist> + <listitem><para>If not already implemented, add an optional + command line switch to the daemon to disable daemonization. This + is useful not only for using the daemon in new-style init + systems, but also to ease debugging.</para></listitem> + + <listitem><para>If the daemon offers interfaces to other + software running on the local system via local + <constant>AF_UNIX</constant> sockets, consider implementing + socket-based activation (see above). Usually, a minimal patch is + sufficient to implement this: Extend the socket creation in the + daemon code so that + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + is checked for already passed sockets first. If sockets are + passed (i.e. when <function>sd_listen_fds()</function> returns a + positive value), skip the socket creation step and use the + passed sockets. Secondly, ensure that the file system socket + nodes for local <constant>AF_UNIX</constant> sockets used in the + socket-based activation are not removed when the daemon shuts + down, if sockets have been passed. Third, if the daemon normally + closes all remaining open file descriptors as part of its + initialization, the sockets passed from the init system must be + spared. Since new-style init systems guarantee that no left-over + file descriptors are passed to executed processes, it might be a + good choice to simply skip the closing of all remaining open + file descriptors if sockets are passed.</para></listitem> + + <listitem><para>Write and install a systemd unit file for the + service (and the sockets if socket-based activation is used, as + well as a path unit file, if the daemon processes a spool + directory), see above for details.</para></listitem> + + <listitem><para>If the daemon exposes interfaces via D-Bus, + write and install a D-Bus activation file for the service, see + above for details.</para></listitem> + </orderedlist> + </refsect1> + + <refsect1> + <title>Placing Daemon Data</title> + + <para>It is recommended to follow the general guidelines for + placing package files, as discussed in + <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/directives-template.xml b/man/directives-template.xml new file mode 100644 index 0000000..addb0ef --- /dev/null +++ b/man/directives-template.xml @@ -0,0 +1,199 @@ +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.directives"> + <refentryinfo> + <title>systemd.directives</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.directives</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.directives</refname> + <refpurpose>Index of configuration directives</refpurpose> + </refnamediv> + + <refsect1> + <title>Unit directives</title> + + <para>Directives for configuring units, used in unit files.</para> + + <variablelist id='unit-directives' /> + </refsect1> + + <refsect1> + <title>Options on the kernel command line</title> + + <para>Kernel boot options for configuring the behaviour of the systemd process.</para> + + <variablelist id='kernel-commandline-options' /> + </refsect1> + + <refsect1> + <title>Environment variables</title> + + <para>Environment variables understood by the systemd manager and other programs and environment + variable-compatible settings.</para> + + <variablelist id='environment-variables' /> + </refsect1> + + <refsect1> + <title>EFI variables</title> + + <para>EFI variables understood by + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> + and other programs.</para> + + <variablelist id='efi-variables' /> + </refsect1> + + <refsect1> + <title>Home Area/User Account directives</title> + + <para>Directives for configuring home areas and user accounts via + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <variablelist id='home-directives' /> + </refsect1> + + <refsect1> + <title>UDEV directives</title> + + <para>Directives for configuring systemd units through the udev database.</para> + + <variablelist id='udev-directives' /> + </refsect1> + + <refsect1> + <title>Network directives</title> + + <para>Directives for configuring network links through the net-setup-link udev builtin and networks + through systemd-networkd.</para> + + <variablelist id='network-directives' /> + </refsect1> + + <refsect1> + <title>Journal fields</title> + + <para>Fields in the journal events with a well known meaning.</para> + + <variablelist id='journal-directives' /> + </refsect1> + + <refsect1> + <title>PAM configuration directives</title> + + <para>Directives for configuring PAM behaviour.</para> + + <variablelist id='pam-directives' /> + </refsect1> + + <refsect1> + <title><filename>/etc/crypttab</filename> and + <filename>/etc/fstab</filename> options</title> + + <para>Options which influence mounted filesystems and encrypted volumes.</para> + + <variablelist id='fstab-options' /> + </refsect1> + + <refsect1> + <title><citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry> + directives</title> + + <para>Directives for configuring systemd-nspawn containers.</para> + + <variablelist id='nspawn-directives' /> + </refsect1> + + <refsect1> + <title>Program configuration options</title> + + <para>Directives for configuring the behaviour of the systemd process and other tools through + configuration files.</para> + + <variablelist id='config-directives' /> + </refsect1> + + <refsect1> + <title>Command line options</title> + + <para>Command-line options accepted by programs in the systemd suite.</para> + + <variablelist id='options' /> + </refsect1> + + <refsect1> + <title>Constants</title> + + <para>Various constant used and/or defined by systemd.</para> + + <variablelist id='constants' /> + </refsect1> + + <refsect1> + <title>Miscellaneous options and directives</title> + + <para>Other configuration elements which don't fit in any of the above groups.</para> + + <variablelist id='miscellaneous' /> + </refsect1> + + <refsect1> + <title>Specifiers</title> + + <para>Short strings which are substituted in configuration directives.</para> + + <variablelist id='specifiers' /> + </refsect1> + + <refsect1> + <title>Files and directories</title> + + <para>Paths and file names referred to in the documentation.</para> + + <variablelist id='filenames' /> + </refsect1> + + <refsect1> + <title>D-Bus interfaces</title> + + <para>Interfaces exposed over D-Bus.</para> + + <variablelist id='dbus-interface' /> + </refsect1> + + <refsect1> + <title>D-Bus methods</title> + + <para>Methods exposed in the D-Bus interface.</para> + + <variablelist id='dbus-method' /> + </refsect1> + + <refsect1> + <title>D-Bus properties</title> + + <para>Properties exposed in the D-Bus interface.</para> + + <variablelist id='dbus-property' /> + </refsect1> + + <refsect1> + <title>D-Bus signals</title> + + <para>Signals emitted in the D-Bus interface.</para> + + <variablelist id='dbus-signal' /> + </refsect1> + + <refsect1> + <title>Colophon</title> + <para id='colophon' /> + </refsect1> +</refentry> diff --git a/man/dnssec-trust-anchors.d.xml b/man/dnssec-trust-anchors.d.xml new file mode 100644 index 0000000..25c6ce2 --- /dev/null +++ b/man/dnssec-trust-anchors.d.xml @@ -0,0 +1,181 @@ +<?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-or-later --> + +<refentry id="dnssec-trust-anchors.d" conditional='ENABLE_RESOLVE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>dnssec-trust-anchors.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>dnssec-trust-anchors.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>dnssec-trust-anchors.d</refname> + <refname>systemd.positive</refname> + <refname>systemd.negative</refname> + <refpurpose>DNSSEC trust anchor configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/dnssec-trust-anchors.d/*.positive</filename></para> + <para><filename>/run/dnssec-trust-anchors.d/*.positive</filename></para> + <para><filename>/usr/lib/dnssec-trust-anchors.d/*.positive</filename></para> + <para><filename>/etc/dnssec-trust-anchors.d/*.negative</filename></para> + <para><filename>/run/dnssec-trust-anchors.d/*.negative</filename></para> + <para><filename>/usr/lib/dnssec-trust-anchors.d/*.negative</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The DNSSEC trust anchor configuration files define positive + and negative trust anchors + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + bases DNSSEC integrity proofs on.</para> + </refsect1> + + <refsect1> + <title>Positive Trust Anchors</title> + + <para>Positive trust anchor configuration files contain DNSKEY and + DS resource record definitions to use as base for DNSSEC integrity + proofs. See <ulink + url="https://tools.ietf.org/html/rfc4035#section-4.4">RFC 4035, + Section 4.4</ulink> for more information about DNSSEC trust + anchors.</para> + + <para>Positive trust anchors are read from files with the suffix + <filename>.positive</filename> located in + <filename>/etc/dnssec-trust-anchors.d/</filename>, + <filename>/run/dnssec-trust-anchors.d/</filename> and + <filename>/usr/lib/dnssec-trust-anchors.d/</filename>. These + directories are searched in the specified order, and a trust + anchor file of the same name in an earlier path overrides a trust + anchor files in a later path. To disable a trust anchor file + shipped in <filename>/usr/lib/dnssec-trust-anchors.d/</filename> + it is sufficient to provide an identically-named file in + <filename>/etc/dnssec-trust-anchors.d/</filename> or + <filename>/run/dnssec-trust-anchors.d/</filename> that is either + empty or a symlink to <filename>/dev/null</filename> ("masked").</para> + + <para>Positive trust anchor files are simple text files resembling + DNS zone files, as documented in <ulink + url="https://tools.ietf.org/html/rfc1035#section-5">RFC 1035, Section + 5</ulink>. One DS or DNSKEY resource record may be listed per + line. Empty lines and lines starting with a semicolon + (<literal>;</literal>) are ignored and considered comments. A DS + resource record is specified like in the following example:</para> + + <programlisting>. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5</programlisting> + + <para>The first word specifies the domain, use + <literal>.</literal> for the root domain. The domain may be + specified with or without trailing dot, which is considered + equivalent. The second word must be <literal>IN</literal> the + third word <literal>DS</literal>. The following words specify the + key tag, signature algorithm, digest algorithm, followed by the + hex-encoded key fingerprint. See <ulink + url="https://tools.ietf.org/html/rfc4034#section-5">RFC 4034, + Section 5</ulink> for details about the precise syntax and meaning + of these fields.</para> + + <para>Alternatively, DNSKEY resource records may be used to define + trust anchors, like in the following example:</para> + + <programlisting>. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=</programlisting> + + <para>The first word specifies the domain again, the second word + must be <literal>IN</literal>, followed by + <literal>DNSKEY</literal>. The subsequent words encode the DNSKEY + flags, protocol and algorithm fields, followed by the key data + encoded in Base64. See <ulink + url="https://tools.ietf.org/html/rfc4034#section-2">RFC 4034, + Section 2</ulink> for details about the precise syntax and meaning + of these fields.</para> + + <para>If multiple DS or DNSKEY records are defined for the same + domain (possibly even in different trust anchor files), all keys + are used and are considered equivalent as base for DNSSEC + proofs.</para> + + <para>Note that <filename>systemd-resolved</filename> will + automatically use a built-in trust anchor key for the Internet + root domain if no positive trust anchors are defined for the root + domain. In most cases it is hence unnecessary to define an + explicit key with trust anchor files. The built-in key is disabled + as soon as at least one trust anchor key for the root domain is + defined in trust anchor files.</para> + + <para>It is generally recommended to encode trust anchors in DS + resource records, rather than DNSKEY resource records.</para> + + <para>If a trust anchor specified via a DS record is found revoked + it is automatically removed from the trust anchor database for the + runtime. See <ulink url="https://tools.ietf.org/html/rfc5011">RFC + 5011</ulink> for details about revoked trust anchors. Note that + <filename>systemd-resolved</filename> will not update its trust + anchor database from DNS servers automatically. Instead, it is + recommended to update the resolver software or update the new + trust anchor via adding in new trust anchor files.</para> + + <para>The current DNSSEC trust anchor for the Internet's root + domain is available at the <ulink + url="https://data.iana.org/root-anchors/root-anchors.xml">IANA + Trust Anchor and Keys</ulink> page.</para> + </refsect1> + + <refsect1> + <title>Negative Trust Anchors</title> + + <para>Negative trust anchors define domains where DNSSEC validation shall be turned + off. Negative trust anchor files are found at the same location as positive trust anchor files, + and follow the same overriding rules. They are text files with the + <filename>.negative</filename> suffix. Empty lines and lines whose first character is + <literal>;</literal> are ignored. Each line specifies one domain name which is the root of a DNS + subtree where validation shall be disabled. For example:</para> + + <programlisting># Reverse IPv4 mappings +10.in-addr.arpa +16.172.in-addr.arpa +168.192.in-addr.arpa +... +# Some custom domains +prod +stag +</programlisting> + + <para>Negative trust anchors are useful to support private DNS + subtrees that are not referenced from the Internet DNS hierarchy, + and not signed.</para> + + <para><ulink url="https://tools.ietf.org/html/rfc7646">RFC + 7646</ulink> for details on negative trust anchors.</para> + + <para>If no negative trust anchor files are configured a built-in + set of well-known private DNS zone domains is used as negative + trust anchors.</para> + + <para>It is also possibly to define per-interface negative trust + anchors using the <varname>DNSSECNegativeTrustAnchors=</varname> + setting in + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + files.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/environment.d.xml b/man/environment.d.xml new file mode 100644 index 0000000..272211c --- /dev/null +++ b/man/environment.d.xml @@ -0,0 +1,127 @@ +<?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-or-later + + Copyright © 2016 Red Hat, Inc. +--> +<refentry id="environment.d" conditional='ENABLE_ENVIRONMENT_D' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>environment.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>environment.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>environment.d</refname> + <refpurpose>Definition of user service environment</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>~/.config/environment.d/*.conf</filename></para> + <para><filename>/etc/environment.d/*.conf</filename></para> + <para><filename>/run/environment.d/*.conf</filename></para> + <para><filename>/usr/lib/environment.d/*.conf</filename></para> + <para><filename>/etc/environment</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Configuration files in the <filename>environment.d/</filename> directories contain lists of + environment variable assignments for services started by the systemd user instance. + <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + parses them and updates the environment exported by the systemd user instance. See below for an + discussion of which processes inherit those variables.</para> + + <para>It is recommended to use numerical prefixes for file names to simplify ordering.</para> + + <para>For backwards compatibility, a symlink to <filename>/etc/environment</filename> is + installed, so this file is also parsed.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="confd" /> + + <refsect1> + <title>Configuration Format</title> + + <para>The configuration files contain a list of + <literal><replaceable>KEY</replaceable>=<replaceable>VALUE</replaceable></literal> environment + variable assignments, separated by newlines. The right hand side of these assignments may + reference previously defined environment variables, using the <literal>${OTHER_KEY}</literal> + and <literal>$OTHER_KEY</literal> format. It is also possible to use + <literal>${<replaceable>FOO</replaceable>:-<replaceable>DEFAULT_VALUE</replaceable>}</literal> + to expand in the same way as <literal>${<replaceable>FOO</replaceable>}</literal> unless the + expansion would be empty, in which case it expands to <replaceable>DEFAULT_VALUE</replaceable>, + and use + <literal>${<replaceable>FOO</replaceable>:+<replaceable>ALTERNATE_VALUE</replaceable>}</literal> + to expand to <replaceable>ALTERNATE_VALUE</replaceable> as long as + <literal>${<replaceable>FOO</replaceable>}</literal> would have expanded to a non-empty value. + No other elements of shell syntax are supported.</para> + + <para>Each <replaceable>KEY</replaceable> must be a valid variable name. Empty lines + and lines beginning with the comment character <literal>#</literal> are ignored.</para> + + <refsect2> + <title>Example</title> + <example> + <title>Setup environment to allow access to a program installed in + <filename index="false">/opt/foo</filename></title> + + <para><filename index="false">/etc/environment.d/60-foo.conf</filename>: + </para> + <programlisting> + FOO_DEBUG=force-software-gl,log-verbose + PATH=/opt/foo/bin:$PATH + LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} + XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/} + </programlisting> + </example> + </refsect2> + </refsect1> + + <refsect1> + <title>Applicability</title> + + <para>Environment variables exported by the user manager (<command>systemd --user</command> instance + started in the <filename>user@<replaceable>uid</replaceable>.service</filename> system service) apply to + any services started by that manager. In particular, this may include services which run user shells. For + example in the GNOME environment, the graphical terminal emulator runs as the + <filename>gnome-terminal-server.service</filename> user unit, which in turn runs the user shell, so that + shell will inherit environment variables exported by the user manager. For other instances of the shell, + not launched by the user manager, the environment they inherit is defined by the program that starts + them. Hint: in general, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + units contain programs launched by systemd, and + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry> + units contain programs launched by something else.</para> + + <para>Specifically, for ssh logins, the + <citerefentry project='die-net'><refentrytitle>sshd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + service builds an environment that is a combination of variables forwarded from the remote system and + defined by <command>sshd</command>, see the discussion in + <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + A graphical display session will have an analogous mechanism to define the environment. Note that some + managers query the systemd user instance for the exported environment and inject this configuration into + programs they start, using <command>systemctl show-environment</command> or the underlying D-Bus call. + </para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/file-hierarchy.xml b/man/file-hierarchy.xml new file mode 100644 index 0000000..6c64b72 --- /dev/null +++ b/man/file-hierarchy.xml @@ -0,0 +1,806 @@ +<?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-or-later --> + +<refentry id="file-hierarchy"> + + <refentryinfo> + <title>file-hierarchy</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>file-hierarchy</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>file-hierarchy</refname> + <refpurpose>File system hierarchy overview</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>Operating systems using the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> system and service + manager are organized based on a file system hierarchy inspired by UNIX, more specifically the hierarchy described + in the <ulink url="http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html">File System Hierarchy</ulink> + specification and <citerefentry + project='man-pages'><refentrytitle>hier</refentrytitle><manvolnum>7</manvolnum></citerefentry>, with various + extensions, partially documented in the <ulink + url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG Base Directory + Specification</ulink> and <ulink url="https://www.freedesktop.org/wiki/Software/xdg-user-dirs/">XDG User + Directories</ulink>. This manual page describes a more generalized, though minimal and modernized subset of these + specifications that defines more strictly the suggestions and restrictions systemd makes on the file system + hierarchy.</para> + + <para>Many of the paths described here can be queried + with the + <citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool.</para> + </refsect1> + + <refsect1> + <title>General Structure</title> + + <variablelist> + <varlistentry> + <term><filename>/</filename></term> + <listitem><para>The file system root. Usually writable, but + this is not required. Possibly a temporary file system + (<literal>tmpfs</literal>). Not shared with other hosts + (unless read-only). </para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/boot/</filename></term> + <listitem><para>The boot partition used for bringing up the + system. On EFI systems, this is possibly the EFI System + Partition (ESP), also see + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + This directory is usually strictly local to the host, and + should be considered read-only, except when a new kernel or + boot loader is installed. This directory only exists on + systems that run on physical or emulated hardware that + requires boot loaders.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/efi/</filename></term> + <listitem><para>If the boot partition <filename>/boot/</filename> is maintained separately from the EFI System + Partition (ESP), the latter is mounted here. Tools that need to operate on the EFI system partition should look + for it at this mount point first, and fall back to <filename>/boot/</filename> — if the former doesn't qualify + (for example if it is not a mount point or does not have the correct file system type + <constant>MSDOS_SUPER_MAGIC</constant>).</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/etc/</filename></term> + <listitem><para>System-specific configuration. This directory + may or may not be read-only. Frequently, this directory is + pre-populated with vendor-supplied configuration files, but + applications should not make assumptions about this directory + being fully populated or populated at all, and should fall + back to defaults if configuration is + missing.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/home/</filename></term> + <listitem><para>The location for normal user's home + directories. Possibly shared with other systems, and never + read-only. This directory should only be used for normal + users, never for system users. This directory and possibly the + directories contained within it might only become available or + writable in late boot or even only after user authentication. + This directory might be placed on limited-functionality + network file systems, hence applications should not assume the + full set of file API is available on this directory. + Applications should generally not reference this directory + directly, but via the per-user <varname>$HOME</varname> + environment variable, or via the home directory field of the + user database.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/root/</filename></term> + <listitem><para>The home directory of the root user. The root + user's home directory is located outside of + <filename>/home/</filename> in order to make sure the root user + may log in even without <filename>/home/</filename> being + available and mounted.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/srv/</filename></term> + <listitem><para>The place to store general server payload, + managed by the administrator. No restrictions are made how + this directory is organized internally. Generally writable, + and possibly shared among systems. This directory might become + available or writable only very late during + boot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/tmp/</filename></term> + <listitem><para>The place for small temporary files. This directory is usually mounted as a + <literal>tmpfs</literal> instance, and should hence not be used for larger files. (Use + <filename>/var/tmp/</filename> for larger files.) This directory is usually flushed at boot-up. Also, + files that are not accessed within a certain time may be automatically deleted.</para> + + <para>If applications find the environment variable <varname>$TMPDIR</varname> set, they should use + the directory specified in it instead of <filename>/tmp/</filename> (see <citerefentry + project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> and + <ulink url="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">IEEE + Std 1003.1</ulink> for details).</para> + + <para>Since <filename>/tmp/</filename> is accessible to other users of the system, it is essential + that files and subdirectories under this directory are only created with <citerefentry + project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry + project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and similar calls. For more details, see <ulink url="https://systemd.io/TEMPORARY_DIRECTORIES">Using + /tmp/ and /var/tmp/ Safely</ulink>.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Runtime Data</title> + + <variablelist> + <varlistentry> + <term><filename>/run/</filename></term> + <listitem><para>A <literal>tmpfs</literal> file system for + system packages to place runtime data in. This directory is + flushed on boot, and generally writable for privileged + programs only. Always writable.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/run/log/</filename></term> + <listitem><para>Runtime system logs. System components may + place private logs in this directory. Always writable, even + when <filename>/var/log/</filename> might not be accessible + yet.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/run/user/</filename></term> + <listitem><para>Contains per-user runtime directories, each + usually individually mounted <literal>tmpfs</literal> + instances. Always writable, flushed at each reboot and when + the user logs out. User code should not reference this + directory directly, but via the + <varname>$XDG_RUNTIME_DIR</varname> environment variable, as + documented in the <ulink + url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG + Base Directory Specification</ulink>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Vendor-supplied Operating System Resources</title> + + <variablelist> + + <varlistentry> + <term><filename>/usr/</filename></term> + <listitem><para>Vendor-supplied operating system resources. + Usually read-only, but this is not required. Possibly shared + between multiple hosts. This directory should not be modified + by the administrator, except when installing or removing + vendor-supplied packages.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/bin/</filename></term> + <listitem><para>Binaries and executables for user commands + that shall appear in the <varname>$PATH</varname> search path. + It is recommended not to place binaries in this directory that + are not useful for invocation from a shell (such as daemon + binaries); these should be placed in a subdirectory of + <filename>/usr/lib/</filename> instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/include/</filename></term> + <listitem><para>C and C++ API header files of system + libraries.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/lib/</filename></term> + <listitem><para>Static, private vendor data that is compatible + with all architectures (though not necessarily + architecture-independent). Note that this includes internal + executables or other binaries that are not regularly invoked + from a shell. Such binaries may be for any architecture + supported by the system. Do not place public libraries in this + directory, use <varname>$libdir</varname> (see below), + instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/lib/<replaceable>arch-id</replaceable>/</filename></term> + <listitem><para>Location for placing dynamic libraries into, also + called <varname>$libdir</varname>. The architecture identifier + to use is defined on <ulink + url="https://wiki.debian.org/Multiarch/Tuples">Multiarch + Architecture Specifiers (Tuples)</ulink> list. Legacy + locations of <varname>$libdir</varname> are + <filename>/usr/lib/</filename>, + <filename>/usr/lib64/</filename>. This directory should not be + used for package-specific data, unless this data is + architecture-dependent, too. To query + <varname>$libdir</varname> for the primary architecture of the + system, invoke: + <programlisting># systemd-path system-library-arch</programlisting></para></listitem> + + </varlistentry> + + <varlistentry> + <term><filename>/usr/share/</filename></term> + <listitem><para>Resources shared between multiple packages, + such as documentation, man pages, time zone information, fonts + and other resources. Usually, the precise location and format + of files stored below this directory is subject to + specifications that ensure interoperability.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/share/doc/</filename></term> + <listitem><para>Documentation for the operating system or + system packages.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/share/factory/etc/</filename></term> + <listitem><para>Repository for vendor-supplied default + configuration files. This directory should be populated with + pristine vendor versions of all configuration files that may + be placed in <filename>/etc/</filename>. This is useful to + compare the local configuration of a system with vendor + defaults and to populate the local configuration with + defaults.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/usr/share/factory/var/</filename></term> + + <listitem><para>Similar to + <filename>/usr/share/factory/etc/</filename>, but for vendor + versions of files in the variable, persistent data directory + <filename>/var/</filename>.</para></listitem> + + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Persistent Variable System Data</title> + + <variablelist> + <varlistentry> + <term><filename>/var/</filename></term> + <listitem><para>Persistent, variable system data. Must be + writable. This directory might be pre-populated with + vendor-supplied data, but applications should be able to + reconstruct necessary files and directories in this + subhierarchy should they be missing, as the system might start + up without this directory being populated. Persistency is + recommended, but optional, to support ephemeral systems. This + directory might become available or writable only very late + during boot. Components that are required to operate during + early boot hence shall not unconditionally rely on this + directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/cache/</filename></term> + <listitem><para>Persistent system cache data. System + components may place non-essential data in this directory. + Flushing this directory should have no effect on operation of + programs, except for increased runtimes necessary to rebuild + these caches.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/lib/</filename></term> + <listitem><para>Persistent system data. System components may + place private data in this directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/log/</filename></term> + <listitem><para>Persistent system logs. System components may + place private logs in this directory, though it is recommended + to do most logging via the + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> + calls.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/spool/</filename></term> + <listitem><para>Persistent system spool data, such as printer + or mail queues.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/tmp/</filename></term> + <listitem><para>The place for larger and persistent temporary files. In contrast to + <filename>/tmp/</filename>, this directory is usually mounted from a persistent physical file system + and can thus accept larger files. (Use <filename>/tmp/</filename> for small ephemeral files.) This + directory is generally not flushed at boot-up, but time-based cleanup of files that have not been + accessed for a certain time is applied.</para> + + <para>If applications find the environment variable <varname>$TMPDIR</varname> set, they should use + the directory specified in it instead of <filename>/var/tmp/</filename> (see <citerefentry + project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details).</para> + + <para>The same security restrictions as with <filename>/tmp/</filename> apply: <citerefentry + project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry + project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and similar calls should be used. For further details about this directory, see <ulink + url="https://systemd.io/TEMPORARY_DIRECTORIES">Using /tmp/ and /var/tmp/ Safely</ulink>.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Virtual Kernel and API File Systems</title> + + <variablelist> + <varlistentry> + <term><filename>/dev/</filename></term> + <listitem><para>The root directory for device nodes. Usually, + this directory is mounted as a <literal>devtmpfs</literal> + instance, but might be of a different type in + sandboxed/containerized setups. This directory is managed + jointly by the kernel and + <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + and should not be written to by other components. A number of + special purpose virtual file systems might be mounted below + this directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/dev/shm/</filename></term> + <listitem><para>Place for POSIX shared memory segments, as + created via + <citerefentry project='die-net'><refentrytitle>shm_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This directory is flushed on boot, and is a + <literal>tmpfs</literal> file system. Since all users have + write access to this directory, special care should be taken + to avoid name clashes and vulnerabilities. For normal users, + shared memory segments in this directory are usually deleted + when the user logs out. Usually, it is a better idea to use + memory mapped files in <filename>/run/</filename> (for system + programs) or <varname>$XDG_RUNTIME_DIR</varname> (for user + programs) instead of POSIX shared memory segments, since these + directories are not world-writable and hence not vulnerable to + security-sensitive name clashes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/proc/</filename></term> + <listitem><para>A virtual kernel file system exposing the + process list and other functionality. This file system is + mostly an API to interface with the kernel and not a place + where normal files may be stored. For details, see + <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + A number of special purpose virtual file systems might be + mounted below this directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/proc/sys/</filename></term> + <listitem><para>A hierarchy below <filename>/proc/</filename> + that exposes a number of kernel tunables. The primary way to + configure the settings in this API file tree is via + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + files. In sandboxed/containerized setups, this directory is + generally mounted read-only.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/sys/</filename></term> + <listitem><para>A virtual kernel file system exposing + discovered devices and other functionality. This file system + is mostly an API to interface with the kernel and not a place + where normal files may be stored. In sandboxed/containerized + setups, this directory is generally mounted read-only. A number + of special purpose virtual file systems might be mounted below + this directory.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Compatibility Symlinks</title> + + <variablelist> + <varlistentry> + <term><filename>/bin/</filename></term> + <term><filename>/sbin/</filename></term> + <term><filename>/usr/sbin/</filename></term> + + <listitem><para>These compatibility symlinks point to + <filename>/usr/bin/</filename>, ensuring that scripts and + binaries referencing these legacy paths correctly find their + binaries.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/lib/</filename></term> + + <listitem><para>This compatibility symlink points to + <filename>/usr/lib/</filename>, ensuring that programs + referencing this legacy path correctly find their + resources.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/lib64/</filename></term> + + <listitem><para>On some architecture ABIs, this compatibility + symlink points to <varname>$libdir</varname>, ensuring that + binaries referencing this legacy path correctly find their + dynamic loader. This symlink only exists on architectures + whose ABI places the dynamic loader in this + path.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/run/</filename></term> + + <listitem><para>This compatibility symlink points to + <filename>/run/</filename>, ensuring that programs referencing + this legacy path correctly find their runtime + data.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Home Directory</title> + + <para>User applications may want to place files and directories in + the user's home directory. They should follow the following basic + structure. Note that some of these directories are also + standardized (though more weakly) by the <ulink + url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG + Base Directory Specification</ulink>. Additional locations for + high-level user resources are defined by <ulink + url="https://www.freedesktop.org/wiki/Software/xdg-user-dirs/">xdg-user-dirs</ulink>.</para> + + <variablelist> + <varlistentry> + <term><filename>~/.cache/</filename></term> + + <listitem><para>Persistent user cache data. User programs may + place non-essential data in this directory. Flushing this + directory should have no effect on operation of programs, + except for increased runtimes necessary to rebuild these + caches. If an application finds + <varname>$XDG_CACHE_HOME</varname> set, it should use the + directory specified in it instead of this + directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>~/.config/</filename></term> + + <listitem><para>Application configuration and state. When a + new user is created, this directory will be empty or not exist + at all. Applications should fall back to defaults should their + configuration or state in this directory be missing. If an + application finds <varname>$XDG_CONFIG_HOME</varname> set, it + should use the directory specified in it instead of this + directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>~/.local/bin/</filename></term> + + <listitem><para>Executables that shall appear in the user's + <varname>$PATH</varname> search path. It is recommended not to + place executables in this directory that are not useful for + invocation from a shell; these should be placed in a + subdirectory of <filename>~/.local/lib/</filename> instead. + Care should be taken when placing architecture-dependent + binaries in this place, which might be problematic if the home + directory is shared between multiple hosts with different + architectures.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>~/.local/lib/</filename></term> + + <listitem><para>Static, private vendor data that is compatible + with all architectures.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>~/.local/lib/<replaceable>arch-id</replaceable>/</filename></term> + + <listitem><para>Location for placing public dynamic libraries. + The architecture identifier to use is defined on <ulink + url="https://wiki.debian.org/Multiarch/Tuples">Multiarch + Architecture Specifiers (Tuples)</ulink> + list.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>~/.local/share/</filename></term> + + <listitem><para>Resources shared between multiple packages, + such as fonts or artwork. Usually, the precise location and + format of files stored below this directory is subject to + specifications that ensure interoperability. If an application + finds <varname>$XDG_DATA_HOME</varname> set, it should use the + directory specified in it instead of this + directory.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Unprivileged Write Access</title> + + <para>Unprivileged processes generally lack write access to most + of the hierarchy.</para> + + <para>The exceptions for normal users are + <filename>/tmp/</filename>, + <filename>/var/tmp/</filename>, + <filename>/dev/shm/</filename>, as well as the home directory + <varname>$HOME</varname> (usually found below + <filename>/home/</filename>) and the runtime directory + <varname>$XDG_RUNTIME_DIR</varname> (found below + <filename>/run/user/</filename>) of the user, which are all + writable.</para> + + <para>For unprivileged system processes, only + <filename>/tmp/</filename>, + <filename>/var/tmp/</filename> and + <filename>/dev/shm/</filename> are writable. If an + unprivileged system process needs a private writable directory in + <filename>/var/</filename> or <filename>/run/</filename>, it is + recommended to either create it before dropping privileges in the + daemon code, to create it via + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + fragments during boot, or via the + <varname>StateDirectory=</varname> and <varname>RuntimeDirectory=</varname> + directives of service units (see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details).</para> + + <para><filename>/tmp/</filename>, <filename>/var/tmp/</filename> and <filename>/dev/shm/</filename> + should be mounted <option>nosuid</option> and <option>nodev</option>, which means that set-user-id mode + and character or block special devices are not interpreted on those file systems. In general it is not + possible to mount them <option>noexec</option>, because various programs use those directories for + dynamically generated or optimized code, and with that flag those use cases would break. Using this flag + is OK on special-purpose installations or systems where all software that may be installed is known and + doesn't require such functionality. See the discussion of + <option>nosuid</option>/<option>nodev</option>/<option>noexec</option> in <citerefentry + project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> and + <constant>PROT_EXEC</constant> in <citerefentry + project='man-pages'><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Node Types</title> + + <para>Unix file systems support different types of file nodes, + including regular files, directories, symlinks, character and + block device nodes, sockets and FIFOs.</para> + + <para>It is strongly recommended that <filename>/dev/</filename> is + the only location below which device nodes shall be placed. + Similarly, <filename>/run/</filename> shall be the only location to + place sockets and FIFOs. Regular files, directories and symlinks + may be used in all directories.</para> + </refsect1> + + <refsect1> + <title>System Packages</title> + + <para>Developers of system packages should follow strict rules when placing their files in the file + system. The following table lists recommended locations for specific types of files supplied by the + vendor.</para> + + <table> + <title>System package vendor files locations</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="directory" /> + <colspec colname="purpose" /> + <thead> + <row> + <entry>Directory</entry> + <entry>Purpose</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>/usr/bin/</filename></entry> + <entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path, compiled for any of the supported architectures compatible with the operating system. It is not recommended to place internal binaries or binaries that are not commonly invoked from the shell in this directory, such as daemon binaries. As this directory is shared with most other packages of the system, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry> + </row> + <row> + <entry><filename>/usr/lib/<replaceable>arch-id</replaceable>/</filename></entry> + <entry>Public shared libraries of the package. As above, be careful with using too generic names, and pick unique names for your libraries to place here to avoid name clashes.</entry> + </row> + <row> + <entry><filename>/usr/lib/<replaceable>package</replaceable>/</filename></entry> + <entry>Private static vendor resources of the package, including private binaries and libraries, or any other kind of read-only vendor data.</entry> + </row> + <row> + <entry><filename>/usr/lib/<replaceable>arch-id</replaceable>/<replaceable>package</replaceable>/</filename></entry> + <entry>Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures. Note that this generally does not include private executables since binaries of a specific architecture may be freely invoked from any other supported system architecture.</entry> + </row> + <row> + <entry><filename>/usr/include/<replaceable>package</replaceable>/</filename></entry> + <entry>Public C/C++ APIs of public shared libraries of the package.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Additional static vendor files may be installed in the + <filename>/usr/share/</filename> hierarchy to the locations + defined by the various relevant specifications.</para> + + <para>The following directories shall be used by the package for local configuration and files created + during runtime:</para> + + <table> + <title>System package variable files locations</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="directory" /> + <colspec colname="purpose" /> + <thead> + <row> + <entry>Directory</entry> + <entry>Purpose</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>/etc/<replaceable>package</replaceable>/</filename></entry> + <entry>System-specific configuration for the package. It is recommended to default to safe fallbacks if this configuration is missing, if this is possible. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to copy or symlink the necessary files and directories from <filename>/usr/share/factory/</filename> during boot, via the <literal>L</literal> or <literal>C</literal> directives.</entry> + </row> + <row> + <entry><filename>/run/<replaceable>package</replaceable>/</filename></entry> + <entry>Runtime data for the package. Packages must be able to create the necessary subdirectories in this tree on their own, since the directory is flushed automatically on boot. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to create the necessary directories during boot, or the <varname>RuntimeDirectory=</varname> directive of service units may be used to create them at service startup (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details).</entry> + </row> + <row> + <entry><filename>/run/log/<replaceable>package</replaceable>/</filename></entry> + <entry>Runtime log data for the package. As above, the package needs to make sure to create this directory if necessary, as it will be flushed on every boot.</entry> + </row> + <row> + <entry><filename>/var/cache/<replaceable>package</replaceable>/</filename></entry> + <entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary. To create an empty directory, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment or the <varname>CacheDirectory=</varname> directive of service units (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) may be used.</entry> + </row> + <row> + <entry><filename>/var/lib/<replaceable>package</replaceable>/</filename></entry> + <entry>Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. To create an empty directory, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment or the <varname>StateDirectory=</varname> directive of service units (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) may be used.</entry> + </row> + <row> + <entry><filename>/var/log/<replaceable>package</replaceable>/</filename></entry> + <entry>Persistent log data of the package. As above, the package should make sure to create this directory if necessary, possibly using <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> or <varname>LogsDirectory=</varname> (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>), as it might be missing.</entry> + </row> + <row> + <entry><filename>/var/spool/<replaceable>package</replaceable>/</filename></entry> + <entry>Persistent spool/queue data of the package. As above, the package should make sure to create this directory if necessary, as it might be missing.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>User Packages</title> + + <para>Programs running in user context should follow strict rules when placing their own files in the + user's home directory. The following table lists recommended locations in the home directory for specific + types of files supplied by the vendor if the application is installed in the home directory. (User + applications installed system-wide are covered by the rules outlined above for vendor files.)</para> + + <table> + <title>Vendor package file locations under the home directory of the user</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="directory" /> + <colspec colname="purpose" /> + <thead> + <row> + <entry>Directory</entry> + <entry>Purpose</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>~/.local/bin/</filename></entry> + <entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path. It is not recommended to place internal executables or executables that are not commonly invoked from the shell in this directory, such as daemon executables. As this directory is shared with most other packages of the user, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry> + </row> + <row> + <entry><filename>~/.local/lib/<replaceable>arch-id</replaceable>/</filename></entry> + <entry>Public shared libraries of the package. As above, be careful with using overly generic names, and pick unique names for your libraries to place here to avoid name clashes.</entry> + </row> + <row> + <entry><filename>~/.local/lib/<replaceable>package</replaceable>/</filename></entry> + <entry>Private, static vendor resources of the package, compatible with any architecture, or any other kind of read-only vendor data.</entry> + </row> + <row> + <entry><filename>~/.local/lib/<replaceable>arch-id</replaceable>/<replaceable>package</replaceable>/</filename></entry> + <entry>Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Additional static vendor files may be installed in the <filename>~/.local/share/</filename> + hierarchy, mirroring the subdirectories specified in the section "Vendor-supplied operating system + resources" above.</para> + + <para>The following directories shall be used by the package for per-user local configuration and files + created during runtime:</para> + + <table> + <title>User package variable file locations</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="directory" /> + <colspec colname="purpose" /> + <thead> + <row> + <entry>Directory</entry> + <entry>Purpose</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>~/.config/<replaceable>package</replaceable>/</filename></entry> + <entry>User-specific configuration and state for the package. It is required to default to safe fallbacks if this configuration is missing.</entry> + </row> + <row> + <entry><filename><varname>$XDG_RUNTIME_DIR</varname>/<replaceable>package</replaceable>/</filename></entry> + <entry>User runtime data for the package.</entry> + </row> + <row> + <entry><filename>~/.cache/<replaceable>package</replaceable>/</filename></entry> + <entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>hier</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/glib-event-glue.c b/man/glib-event-glue.c new file mode 100644 index 0000000..5201234 --- /dev/null +++ b/man/glib-event-glue.c @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: MIT */ + +#include <stdlib.h> +#include <glib.h> +#include <systemd/sd-event.h> + +typedef struct SDEventSource { + GSource source; + GPollFD pollfd; + sd_event *event; +} SDEventSource; + +static gboolean event_prepare(GSource *source, gint *timeout_) { + return sd_event_prepare(((SDEventSource *)source)->event) > 0; +} + +static gboolean event_check(GSource *source) { + return sd_event_wait(((SDEventSource *)source)->event, 0) > 0; +} + +static gboolean event_dispatch(GSource *source, GSourceFunc callback, gpointer user_data) { + return sd_event_dispatch(((SDEventSource *)source)->event) > 0; +} + +static void event_finalize(GSource *source) { + sd_event_unref(((SDEventSource *)source)->event); +} + +static GSourceFuncs event_funcs = { + .prepare = event_prepare, + .check = event_check, + .dispatch = event_dispatch, + .finalize = event_finalize, +}; + +GSource *g_sd_event_create_source(sd_event *event) { + SDEventSource *source; + + source = (SDEventSource *)g_source_new(&event_funcs, sizeof(SDEventSource)); + + source->event = sd_event_ref(event); + source->pollfd.fd = sd_event_get_fd(event); + source->pollfd.events = G_IO_IN | G_IO_HUP | G_IO_ERR; + + g_source_add_poll((GSource *)source, &source->pollfd); + + return (GSource *)source; +} diff --git a/man/halt.xml b/man/halt.xml new file mode 100644 index 0000000..4b3beb8 --- /dev/null +++ b/man/halt.xml @@ -0,0 +1,160 @@ +<?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-or-later --> + +<refentry id="halt" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>halt</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>halt</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>halt</refname> + <refname>poweroff</refname> + <refname>reboot</refname> + <refpurpose>Halt, power-off or reboot the machine</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>halt</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>poweroff</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>reboot</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>halt</command>, <command>poweroff</command>, <command>reboot</command> may be used to + halt, power-off, or reboot the machine. All three commands take the same options.</para> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--help</option></term> + + <xi:include href="standard-options.xml" xpointer="help-text" /> + </varlistentry> + + <varlistentry> + <term><option>--halt</option></term> + + <listitem><para>Halt the machine, regardless of which one of + the three commands is invoked.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--poweroff</option></term> + + <listitem><para>Power-off the machine, regardless of which one + of the three commands is invoked.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--reboot</option></term> + + <listitem><para>Reboot the machine, regardless of which one of + the three commands is invoked.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-f</option></term> + <term><option>--force</option></term> + + <listitem><para>Force immediate halt, power-off, or reboot. When + specified once, this results in an immediate but clean shutdown + by the system manager. When specified twice, this results in an + immediate shutdown without contacting the system manager. See the + description of <option>--force</option> in + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for more details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-w</option></term> + <term><option>--wtmp-only</option></term> + + <listitem><para>Only write wtmp shutdown entry, do not + actually halt, power-off, reboot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-d</option></term> + <term><option>--no-wtmp</option></term> + + <listitem><para>Do not write wtmp shutdown + entry.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--no-sync</option></term> + + <listitem><para>Don't sync hard disks/storage media before + halt, power-off, reboot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-wall</option></term> + + <listitem><para>Do not send wall message before halt, + power-off, reboot.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <para>These commands are implemented in a way that preserves basic compatibility with the original SysV + commands. <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + verbs <command>halt</command>, <command>poweroff</command>, <command>reboot</command> provide the same + functionality with some additional features.</para> + + <para>Note that on many SysV systems <command>halt</command> used to be synonymous to + <command>poweroff</command>, i.e. both commands would equally result in powering the machine off. systemd + is more accurate here, and <command>halt</command> results in halting the machine only (leaving power + on), and <command>poweroff</command> is required to actually power it off.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/homectl.xml b/man/homectl.xml new file mode 100644 index 0000000..a9cf2f8 --- /dev/null +++ b/man/homectl.xml @@ -0,0 +1,916 @@ +<?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-or-later --> + +<refentry id="homectl" conditional='ENABLE_HOMED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>homectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>homectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>homectl</refname> + <refpurpose>Create, remove, change or inspect home directories</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>homectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>homectl</command> may be used to create, remove, change or inspect a user's home + directory. It's primarily a command interfacing with + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + which manages home directories of users.</para> + + <para>Home directories managed by <filename>systemd-homed.service</filename> are self-contained, and thus + include the user's full metadata record in the home's data storage itself, making them easy to migrate + between machines. In particular, a home directory describes a matching user record, and every user record + managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home + directory. The user account and home directory become the same concept.</para> + + <para>The following backing storage mechanisms are supported:</para> + + <itemizedlist> + <listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in + <filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after + the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption + passphrase of the LUKS2 volume. Access to data without preceding user authentication is thus not + possible, even for the system administrator. This storage mechanism provides the strongest data + security and is thus recommended.</para></listitem> + + <listitem><para>Similar, but the LUKS2 encrypted file system is located on regular block device, such + as an USB storage stick. In this mode home directories and all data they include are nicely migratable + between machines, simply by plugging the USB stick into different systems at different + times.</para></listitem> + + <listitem><para>An encrypted directory using <literal>fscrypt</literal> on file systems that support it + (at the moment this is primarily <literal>ext4</literal>), located in + <filename>/home/*.homedir</filename>. This mechanism also provides encryption, but substantially + weaker than LUKS2, as most file system metadata is unprotected. Moreover + it currently does not support changing user passwords once the home directory has been + created.</para></listitem> + + <listitem><para>A <literal>btrfs</literal> subvolume for each user, also located in + <filename>/home/*.homedir</filename>. This provides no encryption, but good quota + support.</para></listitem> + + <listitem><para>A regular directory for each user, also located in + <filename>/home/*.homedir</filename>. This provides no encryption, but is a suitable fallback + available on all machines, even where LUKS2, <literal>fscrypt</literal> or <literal>btrfs</literal> + support is not available.</para></listitem> + + <listitem><para>An individual Windows file share (CIFS) for each user.</para></listitem> + </itemizedlist> + + <para>Note that <filename>systemd-homed.service</filename> and <command>homectl</command> will not manage + "classic" UNIX user accounts as created with <citerefentry + project='man-pages'><refentrytitle>useradd</refentrytitle><manvolnum>8</manvolnum></citerefentry> or + similar tools. In particular, this functionality is not suitable for managing system users (i.e. users + with a UID below 1000) but is exclusive to regular ("human") users.</para> + + <para>Note that users/home directories managed via <command>systemd-homed.service</command> do not show + up in <filename>/etc/passwd</filename> and similar files, they are synthesized via glibc NSS during + runtime. They are thus resolvable and may be enumerated via the <citerefentry + project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool.</para> + + <para>This tool interfaces directly with <filename>systemd-homed.service</filename>, and may execute + specific commands on the home directories it manages. Since every home directory managed that way also + defines a JSON user and group record these home directories may also be inspected and enumerated via + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + + <para>Home directories managed by <filename>systemd-homed.service</filename> are usually in one of two + states, or in a transition state between them: when <literal>active</literal> they are unlocked and + mounted, and thus accessible to the system and its programs; when <literal>inactive</literal> they are + not mounted and thus not accessible. Activation happens automatically at login of the user and usually + can only complete after a password (or other authentication token) has been supplied. Deactivation + happens after the user fully logged out. A home directory remains active as long as the user is logged in + at least once, i.e. has at least one login session. When the user logs in a second time simultaneously + the home directory remains active. It is deactivated only after the last of the user's sessions + ends.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following general options are understood (further options that control the various properties + of user records managed by <filename>systemd-homed.service</filename> are documented further + down):</para> + + <variablelist> + + <varlistentry> + <term><option>--identity=</option><replaceable>FILE</replaceable></term> + + <listitem><para>Read the user's JSON record from the specified file. If passed as + <literal>-</literal> read the user record from standard input. The supplied JSON object must follow + the structure documented in <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink>. + This option may be used in conjunction with the <command>create</command> and + <command>update</command> commands (see below), where it allows configuring the user record in JSON + as-is, instead of setting the individual user record properties (see below).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--json=</option><replaceable>FORMAT</replaceable></term> + <term><option>-J</option></term> + + <listitem><para>Controls whether to output the user record in JSON format, if the + <command>inspect</command> command (see below) is used. Takes one of <literal>pretty</literal>, + <literal>short</literal> or <literal>off</literal>. If <literal>pretty</literal> human-friendly + whitespace and newlines are inserted in the output to make the JSON data more readable. If + <literal>short</literal> all superfluous whitespace is suppressed. If <literal>off</literal> (the + default) the user information is not shown in JSON format but in a friendly human readable formatting + instead. The <option>-J</option> option picks <literal>pretty</literal> when run interactively and + <literal>short</literal> otherwise.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--export-format=</option><replaceable>FORMAT</replaceable></term> + <term><option>-E</option></term> + <term><option>-EE</option></term> + + <listitem><para>When used with the <command>inspect</command> verb in JSON mode (see above) may be + used to suppress certain aspects of the JSON user record on output. Specifically, if + <literal>stripped</literal> format is used the binding and runtime fields of the record are + removed. If <literal>minimal</literal> format is used the cryptographic signature is removed too. If + <literal>full</literal> format is used the full JSON record is shown (this is the default). This + option is useful for copying an existing user record to a different system in order to create a + similar user there with the same settings. Specifically: <command>homectl inspect -EE | ssh + root@othersystem homectl create -i-</command> may be used as simple command line for replicating a + user on another host. <option>-E</option> is equivalent to <option>-j --export-format=stripped</option>, + <option>-EE</option> to <option>-j --export-format=minimal</option>. Note that when replicating user + accounts user records acquired in <literal>stripped</literal> mode will retain the original + cryptographic signatures and thus may only be modified when the private key to update them is available + on the destination machine. When replicating users in <literal>minimal</literal> mode, the signature + is removed during the replication and thus the record will be implicitly signed with the key of the destination + machine and may be updated there without any private key replication.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="no-ask-password" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>User Record Properties</title> + + <para>The following options control various properties of the user records/home directories that + <filename>systemd-homed.service</filename> manages. These switches may be used in conjunction with the + <command>create</command> and <command>update</command> commands for configuring various aspects of the + home directory and the user account:</para> + + <variablelist> + + <varlistentry> + <term><option>--real-name=</option><replaceable>NAME</replaceable></term> + <term><option>-c</option> <replaceable>NAME</replaceable></term> + + <listitem><para>The real name for the user. This corresponds with the GECOS field on classic UNIX NSS + records.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--realm=</option><replaceable>REALM</replaceable></term> + + <listitem><para>The realm for the user. The realm associates a user with a specific organization or + installation, and allows distinguishing users of the same name defined in different contexts. The + realm can be any string that also qualifies as valid DNS domain name, and it is recommended to use + the organization's or installation's domain name for this purpose, but this is not enforced nor + required. On each system only a single user of the same name may exist, and if a user with the same + name and realm is seen it is assumed to refer to the same user while a user with the same name but + different realm is considered a different user. Note that this means that two users sharing the same + name but with distinct realms are not allowed on the same system. Assigning a realm to a user is + optional.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--email-address=</option><replaceable>EMAIL</replaceable></term> + + <listitem><para>Takes an electronic mail address to associate with the user. On log-in the + <varname>$EMAIL</varname> environment variable is initialized from this value.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--location=</option><replaceable>TEXT</replaceable></term> + + <listitem><para>Takes location specification for this user. This is free-form text, which might or + might not be usable by geo-location applications. Example: <option>--location="Berlin, + Germany"</option> or <option>--location="Basement, Room 3a"</option></para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--icon-name=</option><replaceable>ICON</replaceable></term> + + <listitem><para>Takes an icon name to associate with the user, following the scheme defined by the <ulink + url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">Icon Naming + Specification</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--home-dir=</option><replaceable>PATH</replaceable></term> + <term><option>-d</option><replaceable>PATH</replaceable></term> + + <listitem><para>Takes a path to use as home directory for the user. Note that this is the directory + the user's home directory is mounted to while the user is logged in. This is not where the user's + data is actually stored, see <option>--image-path=</option> for that. If not specified defaults to + <filename>/home/$USER</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--uid=</option><replaceable>UID</replaceable></term> + + <listitem><para>Takes a preferred numeric UNIX UID to assign this user. If a user is to be created + with the specified UID and it is already taken by a different user on the local system then creation + of the home directory is refused. Note though, if after creating the home directory it is used on a + different system and the configured UID is taken by another user there, then + <command>systemd-homed</command> may assign the user a different UID on that system. The specified + UID must be outside of the system user range. It is recommended to use the 60001…60513 UID range for + this purpose. If not specified, the UID is automatically picked. If the home directory is found to be + owned by a different UID when logging in, the home directory and everything underneath it will have + its ownership changed automatically before login completes.</para> + + <para>Note that users managed by <command>systemd-homed</command> always have a matching group + associated with the same name as well as a GID matching the UID of the user. Thus, configuring the + GID separately is not permitted.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--member-of=</option><replaceable>GROUP</replaceable></term> + <term><option>-G</option> <replaceable>GROUP</replaceable></term> + + <listitem><para>Takes a comma-separated list of auxiliary UNIX groups this user shall belong + to. Example: <option>--member-of=wheel</option> to provide the user with administrator + privileges. Note that <command>systemd-homed</command> does not manage any groups besides a group + matching the user in name and numeric UID/GID. Thus any groups listed here must be registered + independently, for example with <citerefentry + project='man-pages'><refentrytitle>groupadd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Any non-existent groups are ignored. This option may be used more than once, in which case all + specified group lists are combined. If the user is currently a member of a group which is not listed, + the user will be removed from the group.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--skel=</option><replaceable>PATH</replaceable></term> + + <listitem><para>Takes a file system path to a directory. Specifies the skeleton directory to + initialize the home directory with. All files and directories in the specified path are copied into + any newly create home directory. If not specified defaults to <filename>/etc/skel/</filename>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--shell=</option><replaceable>SHELL</replaceable></term> + + <listitem><para>Takes a file system path. Specifies the shell binary to execute on terminal + logins. If not specified defaults to <filename>/bin/bash</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--setenv=</option><replaceable>VARIABLE</replaceable>=<replaceable>VALUE</replaceable></term> + + <listitem><para>Takes an environment variable assignment to set for all user processes. Note that a + number of other settings also result in environment variables to be set for the user, including + <option>--email=</option>, <option>--timezone=</option> and <option>--language=</option>. May be used + multiple times to set multiple environment variables.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--timezone=</option><replaceable>TIMEZONE</replaceable></term> + + <listitem><para>Takes a time zone location name that sets the timezone for the specified user. When + the user logs in the <varname>$TZ</varname> environment variable is initialized from this + setting. Example: <option>--timezone=Europe/Amsterdam</option> will result in the environment + variable <literal>TZ=:Europe/Amsterdam</literal>. (<literal>:</literal> is used intentionally as part + of the timezone specification, see + <citerefentry project='man-pages'><refentrytitle>tzset</refentrytitle><manvolnum>3</manvolnum></citerefentry>.) + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--language=</option><replaceable>LANG</replaceable></term> + + <listitem><para>Takes a specifier indicating the preferred language of the user. The + <varname>$LANG</varname> environment variable is initialized from this value on login, and thus a + value suitable for this environment variable is accepted here, for example + <option>--language=de_DE.UTF8</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--ssh-authorized-keys=</option><replaceable>KEYS</replaceable></term> + <listitem><para>Either takes a SSH authorized key line to associate with the user record or a + <literal>@</literal> character followed by a path to a file to read one or more such lines from. SSH + keys configured this way are made available to SSH to permit access to this home directory and user + record. This option may be used more than once to configure multiple SSH keys.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--pkcs11-token-uri=</option><replaceable>URI</replaceable></term> + <listitem><para>Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV + smartcard) that shall be able to unlock the user account. The security token URI should reference a + security token with exactly one pair of X.509 certificate and private key. A random secret key is + then generated, encrypted with the public key of the X.509 certificate, and stored as part of the + user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the + account and associated resources. See below for an example how to set up authentication with a + security token.</para> + + <para>Instead of a valid PKCS#11 URI, the special strings <literal>list</literal> and + <literal>auto</literal> may be specified. If <literal>list</literal> is passed, a brief table of + suitable, currently plugged in PKCS#11 hardware tokens is shown, along with their URIs. If + <literal>auto</literal> is passed, a suitable PKCS#11 hardware token is automatically selected (this + operation will fail if there isn't exactly one suitable token discovered). The latter is a useful + shortcut for the most common case where a single PKCS#11 hardware token is plugged in.</para> + + <para>Note that many hardware security tokens implement both PKCS#11/PIV and FIDO2 with the + <literal>hmac-secret</literal> extension (for example: the YubiKey 5 series), as supported with the + <option>--fido2-device=</option> option below. Both mechanisms are similarly powerful, though FIDO2 + is the more modern technology. PKCS#11/PIV tokens have the benefit of being recognizable before + authentication and hence can be used for implying the user identity to use for logging in, which + FIDO2 does not allow. PKCS#11/PIV devices generally require initialization (i.e. storing a + private/public key pair on them, see example below) before they can be used; FIDO2 security tokens + generally do not required that, and work out of the box.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--fido2-device=</option><replaceable>PATH</replaceable></term> + + <listitem><para>Takes a path to a Linux <literal>hidraw</literal> device + (e.g. <filename>/dev/hidraw1</filename>), referring to a FIDO2 security token implementing the + <literal>hmac-secret</literal> extension that shall be able to unlock the user account. A random salt + value is generated on the host and passed to the FIDO2 device, which calculates a HMAC hash of the + salt using an internal secret key. The result is then used as the key to unlock the user account. The + random salt is included in the user record, so that whenever authentication is needed it can be + passed to the FIDO2 token again.</para> + + <para>Instead of a valid path to a FIDO2 <literal>hidraw</literal> device the special strings + <literal>list</literal> and <literal>auto</literal> may be specified. If <literal>list</literal> is + passed, a brief table of suitable discovered FIDO2 devices is shown. If <literal>auto</literal> is + passed, a suitable FIDO2 token is automatically selected, if exactly one is discovered. The latter is + a useful shortcut for the most common case where a single FIDO2 hardware token is plugged in.</para> + + <para>Note that FIDO2 devices suitable for this option must implement the + <literal>hmac-secret</literal> extension. Most current devices (such as the YubiKey 5 series) do. If + the extension is not implemented the device cannot be used for unlocking home directories.</para> + + <para>Note that many hardware security tokens implement both FIDO2 and PKCS#11/PIV (and thus may be + used with either <option>--fido2-device=</option> or <option>--pkcs11-token-uri=</option>), for a + discussion see above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--recovery-key=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Accepts a boolean argument. If enabled a recovery key is configured for the + account. A recovery key is a computer generated access key that may be used to regain access to an + account if the password has been forgotten or the authentication token lost. The key is generated and + shown on screen, and should be printed or otherwise transferred to a secure location. A recovery key + may be entered instead of a regular password to unlock the account.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--locked=</option><replaceable>BOOLEAN</replaceable></term> + + <listitem><para>Takes a boolean argument. Specifies whether this user account shall be locked. If + true logins into this account are prohibited, if false (the default) they are permitted (of course, + only if authorization otherwise succeeds).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--not-before=</option><replaceable>TIMESTAMP</replaceable></term> + <term><option>--not-after=</option><replaceable>TIMESTAMP</replaceable></term> + + <listitem><para>These options take a timestamp string, in the format documented in + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> and + configures points in time before and after logins into this account are not + permitted.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--rate-limit-interval=</option><replaceable>SECS</replaceable></term> + <term><option>--rate-limit-burst=</option><replaceable>NUMBER</replaceable></term> + + <listitem><para>Configures a rate limit on authentication attempts for this user. If the user + attempts to authenticate more often than the specified number, on a specific system, within the + specified time interval authentication is refused until the time interval passes. Defaults to 10 + times per 1min.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--password-hint=</option><replaceable>TEXT</replaceable></term> + + <listitem><para>Takes a password hint to store alongside the user record. This string is stored + accessible only to privileged users and the user itself and may not be queried by other users. + Example: <option>--password-hint="My first pet's name"</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--enforce-password-policy=</option><replaceable>BOOL</replaceable></term> + <term><option>-P</option></term> + + <listitem><para>Takes a boolean argument. Configures whether to enforce the system's password policy + for this user, regarding quality and strength of selected passwords. Defaults to + on. <option>-P</option> is short for + <option>---enforce-password-policy=no</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--password-change-now=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean argument. If true the user is asked to change their password on next + login.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--password-change-min=</option><replaceable>TIME</replaceable></term> + <term><option>--password-change-max=</option><replaceable>TIME</replaceable></term> + <term><option>--password-change-warn=</option><replaceable>TIME</replaceable></term> + <term><option>--password-change-inactive=</option><replaceable>TIME</replaceable></term> + + <listitem><para>Each of these options takes a time span specification as argument (in the syntax + documented in + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>) and + configures various aspects of the user's password expiration policy. Specifically, + <option>--password-change-min=</option> configures how much time has to pass after changing the + password of the user until the password may be changed again. If the user tries to change their + password before this time passes the attempt is refused. <option>--password-change-max=</option> + configures how soon after it has been changed the password expires and needs to be changed again. + After this time passes logging in may only proceed after the password is changed. + <option>--password-change-warn=</option> specifies how much earlier than then the time configured + with <option>--password-change-max=</option> the user is warned at login to change their password as + it will expire soon. Finally <option>--password-change-inactive=</option> configures the time which + has to pass after the password as expired until the user is not permitted to log in or change the + password anymore. Note that these options only apply to password authentication, and do not apply to + other forms of authentication, for example PKCS#11-based security token + authentication.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--disk-size=</option><replaceable>BYTES</replaceable></term> + <listitem><para>Either takes a size in bytes as argument (possibly using the usual K, M, G, … + suffixes for 1024 base values), or a percentage value and configures the disk space to assign to the + user. If a percentage value is specified (i.e. the argument suffixed with <literal>%</literal>) it is + taken relative to the available disk space of the backing file system. If the LUKS2 backend is used + this configures the size of the loopback file and file system contained therein. For the other + storage backends configures disk quota using the filesystem's native quota logic, if available. If + not specified, defaults to 85% of the available disk space for the LUKS2 backend and to no quota for + the others.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--access-mode=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Takes a UNIX file access mode written in octal. Configures the access mode of the + home directory itself. Note that this is only used when the directory is first created, and the user + may change this any time afterwards. Example: + <option>--access-mode=0700</option></para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--umask=</option><replaceable>MASK</replaceable></term> + + <listitem><para>Takes the access mode mask (in octal syntax) to apply to newly created files and + directories of the user ("umask"). If set this controls the initial umask set for all login sessions of + the user, possibly overriding the system's defaults.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--nice=</option><replaceable>NICE</replaceable></term> + + <listitem><para>Takes the numeric scheduling priority ("nice level") to apply to the processes of the user at login + time. Takes a numeric value in the range -20 (highest priority) to 19 (lowest priority).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--rlimit=</option><replaceable>LIMIT</replaceable>=<replaceable>VALUE</replaceable><optional>:<replaceable>VALUE</replaceable></optional></term> + + <listitem><para>Allows configuration of resource limits for processes of this user, see <citerefentry + project='man-pages'><refentrytitle>getrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. Takes a resource limit name (e.g. <literal>LIMIT_NOFILE</literal>) followed by an equal + sign, followed by a numeric limit. Optionally, separated by colon a second numeric limit may be + specified. If two are specified this refers to the soft and hard limits, respectively. If only one + limit is specified the setting sets both limits in one.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--tasks-max=</option><replaceable>TASKS</replaceable></term> + + <listitem><para>Takes a non-zero unsigned integer as argument. Configures the maximum numer of tasks + (i.e. threads, where each process is at least one thread) the user may have at any given time. This + limit applies to all tasks forked off the user's sessions, even if they change user identity via + <citerefentry project='man-pages'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry> + or a similar tool. Use <option>--rlimit=LIMIT_NPROC=</option> to place a limit on the tasks actually + running under the UID of the user, thus excluding any child processes that might have changed user + identity. This controls the <varname>TasksMax=</varname> setting of the per-user systemd slice unit + <filename>user-$UID.slice</filename>. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for further details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--memory-high=</option><replaceable>BYTES</replaceable></term> + <term><option>--memory-max=</option><replaceable>BYTES</replaceable></term> + + <listitem><para>Set a limit on the memory a user may take up on a system at any given time in bytes + (the usual K, M, G, … suffixes are supported, to the base of 1024). This includes all memory used by + the user itself and all processes they forked off that changed user credentials. This controls the + <varname>MemoryHigh=</varname> and <varname>MemoryMax=</varname> settings of the per-user systemd + slice unit <filename>user-$UID.slice</filename>. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for further details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cpu-weight=</option><replaceable>WEIGHT</replaceable></term> + <term><option>--io-weight=</option><replaceable>WEIGHT</replaceable></term> + + <listitem><para>Set CPU and IO scheduling weights of the processes of the user, including those of + processes forked off by the user that changed user credentials. Takes a numeric value in the range + 1…10000. This controls the <varname>CPUWeight=</varname> and <varname>IOWeight=</varname> settings of + the per-user systemd slice unit <filename>user-$UID.slice</filename>. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for further details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--storage=</option><replaceable>STORAGE</replaceable></term> + + <listitem><para>Selects the storage mechanism to use for this home directory. Takes one of + <literal>luks</literal>, <literal>fscrypt</literal>, <literal>directory</literal>, + <literal>subvolume</literal>, <literal>cifs</literal>. For details about these mechanisms, see + above. If a new home directory is created and the storage type is not specifically specified, + <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + defines which default storage to use.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--image-path=</option><replaceable>PATH</replaceable></term> + + <listitem><para>Takes a file system path. Configures where to place the user's home directory. When + LUKS2 storage is used refers to the path to the loopback file, otherwise to the path to the home + directory (which may be in <filename>/home/</filename> or any other accessible filesystem). When + unspecified defaults to <filename>/home/$USER.home</filename> when LUKS storage is used and + <filename>/home/$USER.homedir</filename> for the other storage mechanisms. Not defined for the + <literal>cifs</literal> storage mechanism. To use LUKS2 storage on a regular block device (for + example a USB stick) pass the path to the block device here. Specifying the path to a directory here + when using LUKS2 storage is not allowed. Similar, specifying the path to a regular file or device + node is not allowed if any of the other storage backends are used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--fs-type=</option><replaceable>TYPE</replaceable></term> + + <listitem><para>When LUKS2 storage is used configures the file system type to use inside the home + directory LUKS2 container. One of <literal>btrfs</literal>, <literal>ext4</literal>, + <literal>xfs</literal>. If not specified + <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + defines which default file system type to use. Note that <literal>xfs</literal> is not recommended as + its support for file system resizing is too limited.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--luks-discard=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>When LUKS2 storage is used configures whether to enable the + <literal>discard</literal> feature of the file system. If enabled the file system on top of the LUKS2 + volume will report empty block information to LUKS2 and the loopback file below, ensuring that empty + space in the home directory is returned to the backing file system below the LUKS2 volume, resulting + in a "sparse" loopback file. This option mostly defaults to off, since this permits over-committing + home directories which results in I/O errors if the underlying file system runs full while the upper + file system wants to allocate a block. Such I/O errors are generally not handled well by file systems + nor applications. When LUKS2 storage is used on top of regular block devices (instead of on top a + loopback file) the discard logic defaults to on.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--luks-offline-discard=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Similar to <option>--luks-discard=</option>, controls the trimming of the file + system. However, while <option>--luks-discard=</option> controls what happens when the home directory + is active, <option>--luks-offline-discard=</option> controls what happens when it becomes inactive, + i.e. whether to trim/allocate the storage when deactivating the home directory. This option defaults + to on, to ensure disk space is minimized while a user is not logged in.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--luks-cipher=</option><replaceable>CIPHER</replaceable></term> + <term><option>--luks-cipher-mode=</option><replaceable>MODE</replaceable></term> + <term><option>--luks-volume-key-size=</option><replaceable>BITS</replaceable></term> + <term><option>--luks-pbkdf-type=</option><replaceable>TYPE</replaceable></term> + <term><option>--luks-pbkdf-hash-algorithm=</option><replaceable>ALGORITHM</replaceable></term> + <term><option>--luks-pbkdf-time-cost=</option><replaceable>SECONDS</replaceable></term> + <term><option>--luks-pbkdf-memory-cost=</option><replaceable>BYTES</replaceable></term> + <term><option>--luks-pbkdf-parallel-threads=</option><replaceable>THREADS</replaceable></term> + + <listitem><para>Configures various cryptographic parameters for the LUKS2 storage mechanism. See + <citerefentry + project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details on the specific attributes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--nosuid=</option><replaceable>BOOL</replaceable></term> + <term><option>--nodev=</option><replaceable>BOOL</replaceable></term> + <term><option>--noexec=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Configures the <literal>nosuid</literal>, <literal>nodev</literal> and + <literal>noexec</literal> mount options for the home directories. By default <literal>nodev</literal> + and <literal>nosuid</literal> are on, while <literal>noexec</literal> is off. For details about these + mount options see <citerefentry + project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cifs-domain=</option><replaceable>DOMAIN</replaceable></term> + <term><option>--cifs-user-name=</option><replaceable>USER</replaceable></term> + <term><option>--cifs-service=</option><replaceable>SERVICE</replaceable></term> + + <listitem><para>Configures the Windows File Sharing (CIFS) domain and user to associate with the home + directory/user account, as well as the file share ("service") to mount as directory. The latter is used when + <literal>cifs</literal> storage is selected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--stop-delay=</option><replaceable>SECS</replaceable></term> + + <listitem><para>Configures the time the per-user service manager shall continue to run after the all + sessions of the user ended. The default is configured in + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> (for + home directories of LUKS2 storage located on removable media this defaults to 0 though). A longer + time makes sure quick, repetitive logins are more efficient as the user's service manager doesn't + have to be started every time.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--kill-processes=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Configures whether to kill all processes of the user on logout. The default is + configured in + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--auto-login=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean argument. Configures whether the graphical UI of the system should + automatically log this user in if possible. Defaults to off. If less or more than one user is marked + this way automatic login is disabled.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + + <varlistentry> + <term><command>list</command></term> + + <listitem><para>List all home directories (along with brief details) currently managed by + <filename>systemd-homed.service</filename>. This command is also executed if none is specified on the + command line. (Note that the list of users shown by this command does not include users managed by + other subsystems, such as system users or any traditional users listed in + <filename>/etc/passwd</filename>.)</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>activate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term> + + <listitem><para>Activate one or more home directories. The home directories of each listed user will + be activated and made available under their mount points (typically in + <filename>/home/$USER</filename>). Note that any home activated this way stays active indefinitely, + until it is explicitly deactivated again (with <command>deactivate</command>, see below), or the user + logs in and out again and it thus is deactivated due to the automatic deactivation-on-logout + logic.</para> + + <para>Activation of a home directory involves various operations that depend on the selected storage + mechanism. If the LUKS2 mechanism is used, this generally involves: inquiring the user for a + password, setting up a loopback device, validating and activating the LUKS2 volume, checking the file + system, mounting the file system, and potentially changing the ownership of all included files to the + correct UID/GID.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>deactivate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term> + + <listitem><para>Deactivate one or more home directories. This undoes the effect of + <command>activate</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>inspect</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term> + + <listitem><para>Show various details about the specified home directories. This shows various + information about the home directory and its user account, including runtime data such as current + state, disk use and similar. Combine with <option>--json=</option> to show the detailed JSON user + record instead, possibly combined with <option>--export-format=</option> to suppress certain aspects + of the output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>authenticate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term> + + <listitem><para>Validate authentication credentials of a home directory. This queries the caller for + a password (or similar) and checks that it correctly unlocks the home directory. This leaves the home + directory in the state it is in, i.e. it leaves the home directory in inactive state if it was + inactive before, and in active state if it was active before.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>create</command> <replaceable>USER</replaceable></term> + <term><command>create</command> <option>--identity=</option><replaceable>PATH</replaceable> <optional><replaceable>USER</replaceable></optional></term> + + <listitem><para>Create a new home directory/user account of the specified name. Use the various + user record property options (as documented above) to control various aspects of the home directory + and its user accounts.</para> + + <para>The specified user name should follow the strict syntax described on <ulink + url="https://systemd.io/USER_NAMES">User/Group Name Syntax</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>remove</command> <replaceable>USER</replaceable></term> + + <listitem><para>Remove a home directory/user account. This will remove both the home directory's user + record and the home directory itself, and thus delete all files and directories owned by the + user.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>update</command> <replaceable>USER</replaceable></term> + <term><command>update</command> <option>--identity=</option><replaceable>PATH</replaceable> <optional><replaceable>USER</replaceable></optional></term> + + <listitem><para>Update a home directory/user account. Use the various user record property options + (as documented above) to make changes to the account, or alternatively provide a full, updated JSON + user record via the <option>--identity=</option> option.</para> + + <para>Note that changes to user records not signed by a cryptographic private key available locally + are not permitted, unless <option>--identity=</option> is used with a user record that is already + correctly signed by a recognized private key.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>passwd</command> <replaceable>USER</replaceable></term> + + <listitem><para>Change the password of the specified home directory/user account.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>resize</command> <replaceable>USER</replaceable> <replaceable>BYTES</replaceable></term> + + <listitem><para>Change the disk space assigned to the specified home directory. If the LUKS2 storage + mechanism is used this will automatically resize the loopback file and the file system contained + within. Note that if <literal>ext4</literal> is used inside of the LUKS2 volume, it is necessary to + deactivate the home directory before shrinking it (i.e the user has to log out). Growing can be done + while the home directory is active. If <literal>xfs</literal> is used inside of the LUKS2 volume the + home directory may not be shrunk whatsoever. On all three of <literal>ext4</literal>, + <literal>xfs</literal> and <literal>btrfs</literal> the home directory may be grown while the user is + logged in, and on the latter also shrunk while the user is logged in. If the + <literal>subvolume</literal>, <literal>directory</literal>, <literal>fscrypt</literal> storage + mechanisms are used, resizing will change file system quota.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>lock</command> <replaceable>USER</replaceable></term> + + <listitem><para>Temporarily suspend access to the user's home directory and remove any associated + cryptographic keys from memory. Any attempts to access the user's home directory will stall until the + home directory is unlocked again (i.e. re-authenticated). This functionality is primarily intended to + be used during system suspend to make sure the user's data cannot be accessed until the user + re-authenticates on resume. This operation is only defined for home directories that use the LUKS2 + storage mechanism.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>unlock</command> <replaceable>USER</replaceable></term> + + <listitem><para>Resume access to the user's home directory again, undoing the effect of + <command>lock</command> above. This requires authentication of the user, as the cryptographic keys + required for access to the home directory need to be reacquired.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>lock-all</command></term> + + <listitem><para>Execute the <command>lock</command> command on all suitable home directories at + once. This operation is generally executed on system suspend (i.e. by <command>systemctl + suspend</command> and related commands), to ensure all active user's cryptographic keys for accessing + their home directories are removed from memory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>deactivate-all</command></term> + + <listitem><para>Execute the <command>deactivate</command> command on all active home directories at + once. This operation is generally executed on system shut down (i.e. by <command>systemctl + poweroff</command> and related commands), to ensure all active user's home directories are fully + deactivated before <filename>/home/</filename> and related file systems are unmounted.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>with</command> <replaceable>USER</replaceable> <replaceable>COMMAND…</replaceable></term> + + <listitem><para>Activate the specified user's home directory, run the specified command (under the + caller's identity, not the specified user's) and deactivate the home directory afterwards again + (unless the user is logged in otherwise). This command is useful for running privileged backup + scripts and such, but requires authentication with the user's credentials in order to be able to + unlock the user's home directory.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Create a user <literal>waldo</literal> in the administrator group <literal>wheel</literal>, and + assign 500 MiB disk space to them.</title> + + <programlisting>homectl create waldo --real-name="Waldo McWaldo" -G wheel --disk-size=500M</programlisting> + </example> + + <example> + <title>Create a user <literal>wally</literal> on a USB stick, and assign a maximum of 500 concurrent + tasks to them.</title> + + <programlisting>homectl create wally --real-name="Wally McWally" --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_Fit_476fff954b2b5c44-0:0 --tasks-max=500</programlisting> + </example> + + <example> + <title>Change nice level of user <literal>odlaw</literal> to +5 and make sure the environment variable + <varname>$SOME</varname> is set to the string <literal>THING</literal> for them on login.</title> + + <programlisting>homectl update odlaw --nice=5 --setenv=SOME=THING</programlisting> + </example> + + <example> + <title>Set up authentication with a YubiKey security token using PKCS#11/PIV:</title> + + <programlisting># Clear the Yubikey from any old keys (careful!) +ykman piv reset + +# Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'. +ykman piv generate-key -a RSA2048 9d pubkey.pem + +# Create a self-signed certificate from this public key, and store it on the device. +ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem + +# We don't need the public key on disk anymore +rm pubkey.pem + +# Allow the security token to unlock the account of user 'lafcadio'. +homectl update lafcadio --pkcs11-token-uri=auto</programlisting> + </example> + + <example> + <title>Set up authentication with a FIDO2 security token:</title> + + <programlisting># Allow a FIDO2 security token to unlock the account of user 'nihilbaxter'. +homectl update nihilbaxter --fido2-device=auto</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>useradd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/homed.conf.xml b/man/homed.conf.xml new file mode 100644 index 0000000..7e99aa6 --- /dev/null +++ b/man/homed.conf.xml @@ -0,0 +1,84 @@ +<?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-or-later --> + +<refentry id="homed.conf" conditional='ENABLE_HOMED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>homed.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>homed.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>homed.conf</refname> + <refname>homed.conf.d</refname> + <refpurpose>Home area/user account manager configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/homed.conf</filename></para> + <para><filename>/etc/systemd/homed.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/homed.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/homed.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These configuration files control default parameters for home areas/user accounts created and + managed by + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>The following options are available in the [Home] section:</para> + + <variablelist class='home-directives'> + + <varlistentry> + <term><varname>DefaultStorage=</varname></term> + <listitem><para>The default storage to use for home areas. Takes one of <literal>luks</literal>, + <literal>fscrypt</literal>, <literal>directory</literal>, <literal>subvolume</literal>, + <literal>cifs</literal>. For details about these options, see + <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If not + configured or assigned the empty string, the default storage is automatically determined: if not + running in a container environment and <filename>/home/</filename> is not itself encrypted, defaults + to <literal>luks</literal>. Otherwise defaults to <literal>subvolume</literal> if + <filename>/home/</filename> is on a btrfs file system, and <literal>directory</literal> + otherwise. Note that the storage selected on the <command>homectl</command> command line always takes + precedence.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultFileSystemType=</varname></term> + <listitem><para>When using <literal>luks</literal> as storage (see above), selects the default file + system to use inside the user's LUKS volume. Takes one of <literal>btrfs</literal>, + <literal>ext4</literal> or <literal>xfs</literal>. If not specified defaults to + <literal>btrfs</literal>. This setting has no effect if a different storage mechanism is used. The + file system type selected on the <command>homectl</command> command line always takes + precedence.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/hostname.xml b/man/hostname.xml new file mode 100644 index 0000000..edbeef8 --- /dev/null +++ b/man/hostname.xml @@ -0,0 +1,71 @@ +<?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-or-later --> + +<refentry id="hostname"> + <refentryinfo> + <title>hostname</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>hostname</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>hostname</refname> + <refpurpose>Local hostname configuration file</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/hostname</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/hostname</filename> file configures the + name of the local system that is set during boot using the + <citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry> + system call. It should contain a single newline-terminated + hostname string. Comments (lines starting with a `#') are ignored. + The hostname may be a free-form string up to 64 characters in length; + however, it is recommended that it consists only of 7-bit ASCII lower-case + characters and no spaces or dots, and limits itself to the format allowed + for DNS domain name labels, even though this is not a strict + requirement.</para> + + <para>You may use + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to change the value of this file during runtime from the command + line. Use + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to initialize it on mounted (but not booted) system images.</para> + </refsect1> + + <refsect1> + <title>History</title> + + <para>The simple configuration file format of + <filename>/etc/hostname</filename> originates from Debian + GNU/Linux.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml new file mode 100644 index 0000000..8c00867 --- /dev/null +++ b/man/hostnamectl.xml @@ -0,0 +1,224 @@ +<?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-or-later --> + +<refentry id="hostnamectl" conditional='ENABLE_HOSTNAMED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>hostnamectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>hostnamectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>hostnamectl</refname> + <refpurpose>Control the system hostname</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>hostnamectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>hostnamectl</command> may be used to query and + change the system hostname and related settings.</para> + + <para>This tool distinguishes three different hostnames: the + high-level "pretty" hostname which might include all kinds of + special characters (e.g. "Lennart's Laptop"), the static hostname + which is used to initialize the kernel hostname at boot (e.g. + "lennarts-laptop"), and the transient hostname which is a fallback + value received from network configuration. If a static hostname is + set, and is valid (something other than localhost), then the + transient hostname is not used.</para> + + <para>Note that the pretty hostname has little restrictions on the characters and length used, while the static and + transient hostnames are limited to the usually accepted characters of Internet domain names, and 64 characters at + maximum (the latter being a Linux limitation).</para> + + <para>The static hostname is stored in + <filename>/etc/hostname</filename>, see + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information. The pretty hostname, chassis type, and icon + name are stored in <filename>/etc/machine-info</filename>, see + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>Use + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to initialize the system hostname for mounted (but not booted) + system images.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>status</command></term> + + <listitem><para>Show current system hostname and related information. If no command is specified, + this is the implied default.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-hostname <replaceable>NAME</replaceable></command></term> + + <listitem><para>Set the system hostname to <replaceable>NAME</replaceable>. By default, this will alter the + pretty, the static, and the transient hostname alike; however, if one or more of <option>--static</option>, + <option>--transient</option>, <option>--pretty</option> are used, only the selected hostnames are changed. If + the pretty hostname is being set, and static or transient are being set as well, the specified hostname will be + simplified in regards to the character set used before the latter are updated. This is done by removing special + characters and spaces. This ensures that the pretty and the static hostname are always closely related while + still following the validity rules of the specific name. This simplification of the hostname string is not done + if only the transient and/or static hostnames are set, and the pretty hostname is left untouched.</para> + + <para>Pass the empty string <literal></literal> as the + hostname to reset the selected hostnames to their default + (usually <literal>localhost</literal>).</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-icon-name <replaceable>NAME</replaceable></command></term> + + <listitem><para>Set the system icon name to + <replaceable>NAME</replaceable>. The icon name is used by some + graphical applications to visualize this host. The icon name + should follow the <ulink + url="http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">Icon + Naming Specification</ulink>.</para> + + <para>Pass an empty string to reset the icon name to the + default value, which is determined from chassis type (see + below) and possibly other parameters.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-chassis <replaceable>TYPE</replaceable></command></term> + + <listitem><para>Set the chassis type to + <replaceable>TYPE</replaceable>. The chassis type is used by + some graphical applications to visualize the host or alter + user interaction. Currently, the following chassis types are + defined: + <literal>desktop</literal>, + <literal>laptop</literal>, + <literal>convertible</literal>, + <literal>server</literal>, + <literal>tablet</literal>, + <literal>handset</literal>, + <literal>watch</literal>, + <literal>embedded</literal>, + as well as the special chassis types + <literal>vm</literal> and + <literal>container</literal> for virtualized systems that lack + an immediate physical chassis.</para> + + <para>Pass an empty string to reset the chassis type to the + default value which is determined from the firmware and + possibly other parameters.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>set-deployment <replaceable>ENVIRONMENT</replaceable></command></term> + + <listitem><para>Set the deployment environment description. + <replaceable>ENVIRONMENT</replaceable> must be a single word + without any control characters. One of the following is + suggested: + <literal>development</literal>, + <literal>integration</literal>, + <literal>staging</literal>, + <literal>production</literal>. + </para> + + <para>Pass an empty string to reset to the default empty + value.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>set-location <replaceable>LOCATION</replaceable></command></term> + + <listitem><para>Set the location string for the system, if it + is known. <replaceable>LOCATION</replaceable> should be a + human-friendly, free-form string describing the physical + location of the system, if it is known and applicable. This + may be as generic as <literal>Berlin, Germany</literal> or as + specific as <literal>Left Rack, 2nd Shelf</literal>.</para> + + <para>Pass an empty string to reset to the default empty + value.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--no-ask-password</option></term> + + <listitem><para>Do not query the user for authentication for + privileged operations.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--static</option></term> + <term><option>--transient</option></term> + <term><option>--pretty</option></term> + + <listitem><para>If <command>status</command> is invoked (or no explicit command is given) and one of these + switches is specified, <command>hostnamectl</command> will print out just this selected hostname.</para> + + <para>If used with <command>set-hostname</command>, only the selected hostname(s) will be updated. When more + than one of these switches are specified, all the specified hostnames will be updated. </para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/html.in b/man/html.in new file mode 100755 index 0000000..c142f58 --- /dev/null +++ b/man/html.in @@ -0,0 +1,24 @@ +#!/bin/sh +set -e + +if [ -z "$1" ]; then + echo "Use: $0 page-name (with no section suffix)" + exit 1 +fi + +# make sure the rules have been regenerated (in case man/update-man-rules was just run) +ninja -C "@BUILD_ROOT@" version.h + +target="man/$1.html" +ninja -C "@BUILD_ROOT@" "$target" + +fullname="@BUILD_ROOT@/$target" +redirect="$(test -f "$fullname" && readlink "$fullname" || :)" +if [ -n "$redirect" ]; then + ninja -C "@BUILD_ROOT@" "man/$redirect" + + fullname="@BUILD_ROOT@/man/$redirect" +fi + +set -x +exec xdg-open "$fullname" diff --git a/man/hwdb-usb-device.c b/man/hwdb-usb-device.c new file mode 100644 index 0000000..8a4b86e --- /dev/null +++ b/man/hwdb-usb-device.c @@ -0,0 +1,28 @@ +#include <stdio.h> +#include <stdint.h> +#include <sd-hwdb.h> + +int print_usb_properties(uint16_t vid, uint16_t pid) { + char match[15]; + sd_hwdb *hwdb; + const char *key, *value; + int r; + + /* Match this USB vendor and product ID combination */ + snprintf(match, sizeof match, "usb:v%04Xp%04X", vid, pid); + + r = sd_hwdb_new(&hwdb); + if (r < 0) + return r; + + SD_HWDB_FOREACH_PROPERTY(hwdb, match, key, value) + printf("%s: \"%s\" → \"%s\"\n", match, key, value); + + sd_hwdb_unref(hwdb); + return 0; +} + +int main(int argc, char **argv) { + print_usb_properties(0x046D, 0xC534); + return 0; +} diff --git a/man/hwdb.xml b/man/hwdb.xml new file mode 100644 index 0000000..2c1e502 --- /dev/null +++ b/man/hwdb.xml @@ -0,0 +1,154 @@ +<?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-or-later --> + +<refentry id="hwdb" conditional="ENABLE_HWDB"> + <refentryinfo> + <title>hwdb</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>hwdb</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>hwdb</refname> + <refpurpose>Hardware Database</refpurpose> + </refnamediv> + + <refsect1><title>Description</title> + <para>The hardware database is a key-value store for associating modalias-like keys to + udev-property-like values. It is used primarily by udev to add the relevant properties + to matching devices, but it can also be queried directly.</para> + </refsect1> + + <refsect1><title>Hardware Database Files</title> + <para>The hwdb files are read from the files located in the + system hwdb directory <filename>/usr/lib/udev/hwdb.d</filename> and + the local administration directory <filename>/etc/udev/hwdb.d</filename>. + All hwdb files are collectively sorted and processed in lexical order, + regardless of the directories in which they live. However, files with + identical filenames replace each other. Files in <filename>/etc/</filename> + have the highest priority and take precedence over files with the same + name in <filename>/usr/lib/</filename>. This can be used to override a + system-supplied hwdb file with a local file if needed; + a symlink in <filename>/etc/</filename> with the same name as a hwdb file in + <filename>/usr/lib/</filename>, pointing to <filename>/dev/null</filename>, + disables that hwdb file entirely. hwdb files must have the extension + <filename>.hwdb</filename>; other extensions are ignored.</para> + + <para>Each hwdb file contains data records consisting of matches and associated + key-value pairs. Every record in the hwdb starts with one or more match strings, + specifying a shell glob to compare the lookup string against. Multiple match lines + are specified in consecutive lines. Every match line is compared individually, and + they are combined by OR. Every match line must start at the first character of the + line.</para> + + <para>Match patterns consist of literal characters, and shell-style wildcards:</para> + <itemizedlist> + <listitem><para>Asterisk <literal>*</literal> matches any number of characters + </para></listitem> + <listitem><para>Question mark <literal>?</literal> matches a single character + </para></listitem> + <listitem><para>Character list <literal>[<replaceable>chars</replaceable>]</literal> matches one of + the characters <replaceable>chars</replaceable> listed between <literal>[</literal> and + <literal>]</literal>. A range may be specified as with a dash as + <literal>[<replaceable>first</replaceable>-<replaceable>last</replaceable>]</literal>. The match may + be inverted with a caret <literal>[^…]</literal>.</para></listitem> + </itemizedlist> + + <para>The match lines are followed by one or more key-value pair lines, which are + recognized by a leading space character. The key name and value are separated by + <literal>=</literal>. An empty line signifies the end of a record. Lines beginning + with <literal>#</literal> are ignored.</para> + + <para>In case multiple records match a given lookup string, the key-value pairs + from all records are combined. If a key is specified multiple times, the value + from the record with the highest priority is used (each key can have only a single + value). The priority is higher when the record is in a file that sorts later + lexicographically, and in case of records in the same file, later records have + higher priority.</para> + + <para>The content of all hwdb files is read by + <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and compiled to a binary database located at <filename>/etc/udev/hwdb.bin</filename>, + or alternatively <filename>/usr/lib/udev/hwdb.bin</filename> if you want ship the + compiled database in an immutable image. During runtime, only the binary database + is used.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>General syntax of hwdb files</title> + + <programlisting># /usr/lib/udev/hwdb.d/example.hwdb +# Comments can be placed before any records. This is a good spot +# to describe what that file is used for, what kind of properties +# it defines, and the ordering convention. + +# A record with three matches and one property +mouse:*:name:*Trackball*:* +mouse:*:name:*trackball*:* +mouse:*:name:*TrackBall*:* + ID_INPUT_TRACKBALL=1 + +# The rule above could be also be written in a form that +# matches Tb, tb, TB, tB: +mouse:*:name:*[tT]rack[bB]all*:* + ID_INPUT_TRACKBALL=1 + +# A record with a single match and five properties +mouse:usb:v046dp4041:name:Logitech MX Master:* + MOUSE_DPI=1000@166 + MOUSE_WHEEL_CLICK_ANGLE=15 + MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26 + MOUSE_WHEEL_CLICK_COUNT=24 + MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14 +</programlisting> + </example> + + <example> + <title>Overriding of properties</title> + + <programlisting># /usr/lib/udev/hwdb.d/60-keyboard.hwdb +evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:* + KEYBOARD_KEY_a1=help + KEYBOARD_KEY_a2=setup + KEYBOARD_KEY_a3=battery + +# Match vendor name "Acer" and any product name starting with "X123" +evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer:pnX123*:* + KEYBOARD_KEY_a2=wlan + +# /etc/udev/hwdb.d/70-keyboard.hwdb +# disable wlan key on all at keyboards +evdev:atkbd:* + KEYBOARD_KEY_a2=reserved + PROPERTY_WITH_SPACES=some string</programlisting> + + <para>If the hwdb consists of those two files, a keyboard with the lookup string + <literal>evdev:atkbd:dmi:bvnAcer:bdXXXXX:bd08/05/2010:svnAcer:pnX123</literal> + will match all three records, and end up with the following properties:</para> + + <programlisting>KEYBOARD_KEY_a1=help +KEYBOARD_KEY_a2=reserved +KEYBOARD_KEY_a3=battery +PROPERTY_WITH_SPACES=some string</programlisting> + + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry> + <refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum> + </citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/id128-app-specific.c b/man/id128-app-specific.c new file mode 100644 index 0000000..b81e50f --- /dev/null +++ b/man/id128-app-specific.c @@ -0,0 +1,11 @@ +#include <stdio.h> +#include <systemd/sd-id128.h> + +#define OUR_APPLICATION_ID SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97) + +int main(int argc, char *argv[]) { + sd_id128_t id; + sd_id128_get_machine_app_specific(OUR_APPLICATION_ID, &id); + printf("Our application ID: " SD_ID128_FORMAT_STR "\n", SD_ID128_FORMAT_VAL(id)); + return 0; +} diff --git a/man/inotify-watch-tmp.c b/man/inotify-watch-tmp.c new file mode 100644 index 0000000..ca790f0 --- /dev/null +++ b/man/inotify-watch-tmp.c @@ -0,0 +1,56 @@ +#include <stdio.h> +#include <string.h> +#include <sys/inotify.h> + +#include <systemd/sd-event.h> + +#define _cleanup_(f) __attribute__((cleanup(f))) + +static int inotify_handler(sd_event_source *source, + const struct inotify_event *event, + void *userdata) { + + const char *desc = NULL; + + sd_event_source_get_description(source, &desc); + + if (event->mask & IN_Q_OVERFLOW) + printf("inotify-handler <%s>: overflow\n", desc); + else if (event->mask & IN_CREATE) + printf("inotify-handler <%s>: create on %s\n", desc, event->name); + else if (event->mask & IN_DELETE) + printf("inotify-handler <%s>: delete on %s\n", desc, event->name); + else if (event->mask & IN_MOVED_TO) + printf("inotify-handler <%s>: moved-to on %s\n", desc, event->name); + + /* Terminate the program if an "exit" file appears */ + if ((event->mask & (IN_CREATE|IN_MOVED_TO)) && + strcmp(event->name, "exit") == 0) + sd_event_exit(sd_event_source_get_event(source), 0); + + return 1; +} + +int main(int argc, char **argv) { + _cleanup_(sd_event_unrefp) sd_event *event = NULL; + _cleanup_(sd_event_source_unrefp) sd_event_source *source1 = NULL, *source2 = NULL; + + const char *path1 = argc > 1 ? argv[1] : "/tmp"; + const char *path2 = argc > 2 ? argv[2] : NULL; + + /* Note: failure handling is omitted for brevity */ + + sd_event_default(&event); + + sd_event_add_inotify(event, &source1, path1, + IN_CREATE | IN_DELETE | IN_MODIFY | IN_MOVED_TO, + inotify_handler, NULL); + if (path2) + sd_event_add_inotify(event, &source2, path2, + IN_CREATE | IN_DELETE | IN_MODIFY | IN_MOVED_TO, + inotify_handler, NULL); + + sd_event_loop(event); + + return 0; +} diff --git a/man/journal-iterate-poll.c b/man/journal-iterate-poll.c new file mode 100644 index 0000000..100d07e --- /dev/null +++ b/man/journal-iterate-poll.c @@ -0,0 +1,25 @@ +#include <poll.h> +#include <time.h> +#include <systemd/sd-journal.h> + +int wait_for_changes(sd_journal *j) { + uint64_t t; + int msec; + struct pollfd pollfd; + + sd_journal_get_timeout(j, &t); + if (t == (uint64_t) -1) + msec = -1; + else { + struct timespec ts; + uint64_t n; + clock_gettime(CLOCK_MONOTONIC, &ts); + n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000; + msec = t > n ? (int) ((t - n + 999) / 1000) : 0; + } + + pollfd.fd = sd_journal_get_fd(j); + pollfd.events = sd_journal_get_events(j); + poll(&pollfd, 1, msec); + return sd_journal_process(j); +} diff --git a/man/journal-iterate-unique.c b/man/journal-iterate-unique.c new file mode 100644 index 0000000..fcf92e7 --- /dev/null +++ b/man/journal-iterate-unique.c @@ -0,0 +1,25 @@ +#include <stdio.h> +#include <string.h> +#include <systemd/sd-journal.h> + +int main(int argc, char *argv[]) { + sd_journal *j; + const void *d; + size_t l; + int r; + + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); + return 1; + } + r = sd_journal_query_unique(j, "_SYSTEMD_UNIT"); + if (r < 0) { + fprintf(stderr, "Failed to query journal: %s\n", strerror(-r)); + return 1; + } + SD_JOURNAL_FOREACH_UNIQUE(j, d, l) + printf("%.*s\n", (int) l, (const char*) d); + sd_journal_close(j); + return 0; +} diff --git a/man/journal-iterate-wait.c b/man/journal-iterate-wait.c new file mode 100644 index 0000000..0a23569 --- /dev/null +++ b/man/journal-iterate-wait.c @@ -0,0 +1,39 @@ +#include <stdio.h> +#include <string.h> +#include <systemd/sd-journal.h> + +int main(int argc, char *argv[]) { + int r; + sd_journal *j; + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); + return 1; + } + for (;;) { + const void *d; + size_t l; + r = sd_journal_next(j); + if (r < 0) { + fprintf(stderr, "Failed to iterate to next entry: %s\n", strerror(-r)); + break; + } + if (r == 0) { + /* Reached the end, let's wait for changes, and try again */ + r = sd_journal_wait(j, (uint64_t) -1); + if (r < 0) { + fprintf(stderr, "Failed to wait for changes: %s\n", strerror(-r)); + break; + } + continue; + } + r = sd_journal_get_data(j, "MESSAGE", &d, &l); + if (r < 0) { + fprintf(stderr, "Failed to read message field: %s\n", strerror(-r)); + continue; + } + printf("%.*s\n", (int) l, (const char*) d); + } + sd_journal_close(j); + return 0; +} diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml new file mode 100644 index 0000000..3f69f30 --- /dev/null +++ b/man/journal-remote.conf.xml @@ -0,0 +1,100 @@ +<?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-or-later + + Copyright © 2015 Chris Morgan +--> + +<refentry id="journal-remote.conf" conditional='HAVE_MICROHTTPD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>journal-remote.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>journal-remote.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>journal-remote.conf</refname> + <refname>journal-remote.conf.d</refname> + <refpurpose>Configuration files for the service accepting remote journal uploads</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/journal-remote.conf</filename></para> + <para><filename>/etc/systemd/journal-remote.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/journal-remote.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/journal-remote.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These files configure various parameters of + <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the + [Remote] section:</para> + + <variablelist class='config-directives'> + <varlistentry> + <term><varname>Seal=</varname></term> + + <listitem><para>Periodically sign the data in the journal using Forward Secure Sealing. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SplitMode=</varname></term> + + <listitem><para>One of <literal>host</literal> or <literal>none</literal>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ServerKeyFile=</varname></term> + + <listitem><para>SSL key in PEM format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ServerCertificateFile=</varname></term> + + <listitem><para>SSL certificate in PEM format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TrustedCertificateFile=</varname></term> + + <listitem><para>SSL CA certificate.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/journal-upload.conf.xml b/man/journal-upload.conf.xml new file mode 100644 index 0000000..403eb57 --- /dev/null +++ b/man/journal-upload.conf.xml @@ -0,0 +1,90 @@ +<?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-or-later --> + +<refentry id="journal-upload.conf" conditional='HAVE_MICROHTTPD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>journal-upload.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>journal-upload.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>journal-upload.conf</refname> + <refname>journal-upload.conf.d</refname> + <refpurpose>Configuration files for the journal upload service</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/journal-upload.conf</filename></para> + <para><filename>/etc/systemd/journal-upload.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/journal-upload.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/journal-upload.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These files configure various parameters of + <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the [Upload] section:</para> + + <variablelist class='config-directives'> + <varlistentry> + <term><varname>URL=</varname></term> + + <listitem><para>The URL to upload the journal entries to. See the description + of <option>--url=</option> option in + <citerefentry><refentrytitle>systemd-journal-upload</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for the description of possible values. There is no default value, so either this + option or the command-line option must be always present to make an upload.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ServerKeyFile=</varname></term> + + <listitem><para>SSL key in PEM format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ServerCertificateFile=</varname></term> + + <listitem><para>SSL CA certificate in PEM format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TrustedCertificateFile=</varname></term> + + <listitem><para>SSL CA certificate.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/journalctl.xml b/man/journalctl.xml new file mode 100644 index 0000000..3793441 --- /dev/null +++ b/man/journalctl.xml @@ -0,0 +1,1071 @@ +<?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-or-later --> + + <refentry id="journalctl" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>journalctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>journalctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>journalctl</refname> + <refpurpose>Query the systemd journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>journalctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">MATCHES</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>journalctl</command> may be used to query the + contents of the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + journal as written by + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para>If called without parameters, it will show the full + contents of the journal, starting with the oldest entry + collected.</para> + + <para>If one or more match arguments are passed, the output is + filtered accordingly. A match is in the format + <literal>FIELD=VALUE</literal>, + e.g. <literal>_SYSTEMD_UNIT=httpd.service</literal>, referring + to the components of a structured journal entry. See + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a list of well-known fields. If multiple matches are + specified matching different fields, the log entries are + filtered by both, i.e. the resulting output will show only + entries matching all the specified matches of this kind. If two + matches apply to the same field, then they are automatically + matched as alternatives, i.e. the resulting output will show + entries matching any of the specified matches for the same + field. Finally, the character <literal>+</literal> may appear + as a separate word between other terms on the command line. This + causes all matches before and after to be combined in a + disjunction (i.e. logical OR).</para> + + <para>It is also possible to filter the entries by specifying an + absolute file path as an argument. The file path may be a file or + a symbolic link and the file must exist at the time of the query. If a + file path refers to an executable binary, an <literal>_EXE=</literal> + match for the canonicalized binary path is added to the query. If a + file path refers to an executable script, a <literal>_COMM=</literal> + match for the script name is added to the query. If a file path + refers to a device node, <literal>_KERNEL_DEVICE=</literal> matches for + the kernel name of the device and for each of its ancestor devices is + added to the query. Symbolic links are dereferenced, kernel names are + synthesized, and parent devices are identified from the environment at + the time of the query. In general, a device node is the best proxy for + an actual device, as log entries do not usually contain fields that + identify an actual device. For the resulting log entries to be correct + for the actual device, the relevant parts of the environment at the time + the entry was logged, in particular the actual device corresponding to + the device node, must have been the same as those at the time of the + query. Because device nodes generally change their corresponding devices + across reboots, specifying a device node path causes the resulting + entries to be restricted to those from the current boot.</para> + + <para>Additional constraints may be added using options + <option>--boot</option>, <option>--unit=</option>, etc., to + further limit what entries will be shown (logical AND).</para> + + <para>Output is interleaved from all accessible journal files, + whether they are rotated or currently being written, and + regardless of whether they belong to the system itself or are + accessible user journals.</para> + + <para>The set of journal files which will be used can be + modified using the <option>--user</option>, + <option>--system</option>, <option>--directory</option>, and + <option>--file</option> options, see below.</para> + + <para>All users are granted access to their private per-user + journals. However, by default, only root and users who are + members of a few special groups are granted access to the system + journal and the journals of other users. Members of the groups + <literal>systemd-journal</literal>, <literal>adm</literal>, and + <literal>wheel</literal> can read all journal files. Note + that the two latter groups traditionally have additional + privileges specified by the distribution. Members of the + <literal>wheel</literal> group can often perform administrative + tasks.</para> + + <para>The output is paged through <command>less</command> by + default, and long lines are "truncated" to screen width. The + hidden part can be viewed by using the left-arrow and + right-arrow keys. Paging can be disabled; see the + <option>--no-pager</option> option and the "Environment" section + below.</para> + + <para>When outputting to a tty, lines are colored according to + priority: lines of level ERROR and higher are colored red; lines + of level NOTICE and higher are highlighted; lines of level DEBUG + are colored lighter grey; other lines are displayed normally.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--no-full</option></term> + <term><option>--full</option></term> + <term><option>-l</option></term> + + <listitem><para>Ellipsize fields when they do not fit in + available columns. The default is to show full fields, + allowing them to wrap or be truncated by the pager, if one + is used.</para> + + <para>The old options + <option>-l</option>/<option>--full</option> are not useful + anymore, except to undo <option>--no-full</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-a</option></term> + <term><option>--all</option></term> + + <listitem><para>Show all fields in full, even if they include unprintable characters or are very long. By + default, fields with unprintable characters are abbreviated as "blob data". (Note that the pager may escape + unprintable characters again.)</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-f</option></term> + <term><option>--follow</option></term> + + <listitem><para>Show only the most recent journal entries, + and continuously print new entries as they are appended to + the journal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-e</option></term> + <term><option>--pager-end</option></term> + + <listitem><para>Immediately jump to the end of the journal + inside the implied pager tool. This implies + <option>-n1000</option> to guarantee that the pager will not + buffer logs of unbounded size. This may be overridden with + an explicit <option>-n</option> with some other numeric + value, while <option>-nall</option> will disable this cap. + Note that this option is only supported for the + <citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry> + pager.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--lines=</option></term> + + <listitem><para>Show the most recent journal events and + limit the number of events shown. If + <option>--follow</option> is used, this option is + implied. The argument is a positive integer or + <literal>all</literal> to disable line limiting. The default + value is 10 if no argument is given.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-tail</option></term> + + <listitem><para>Show all stored output lines, even in follow + mode. Undoes the effect of <option>--lines=</option>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--reverse</option></term> + + <listitem><para>Reverse output so that the newest entries + are displayed first.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-o</option></term> + <term><option>--output=</option></term> + + <listitem><para>Controls the formatting of the journal + entries that are shown. Takes one of the following + options:</para> + <variablelist> + <varlistentry> + <term> + <option>short</option> + </term> + <listitem> + <para>is the default and generates an output that is + mostly identical to the formatting of classic syslog + files, showing one line per journal entry.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>short-full</option> + </term> + <listitem> + <para>is very similar, but shows timestamps in the format the <option>--since=</option> and + <option>--until=</option> options accept. Unlike the timestamp information shown in + <option>short</option> output mode this mode includes weekday, year and timezone information in the + output, and is locale-independent.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>short-iso</option> + </term> + <listitem> + <para>is very similar, but shows ISO 8601 wallclock + timestamps.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>short-iso-precise</option> + </term> + <listitem> + <para>as for <option>short-iso</option> but includes full + microsecond precision.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>short-precise</option> + </term> + <listitem> + <para>is very similar, but shows classic syslog timestamps + with full microsecond precision.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>short-monotonic</option> + </term> + <listitem> + <para>is very similar, but shows monotonic timestamps + instead of wallclock timestamps.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>short-unix</option> + </term> + <listitem> + <para>is very similar, but shows seconds passed since January 1st 1970 UTC instead of wallclock + timestamps ("UNIX time"). The time is shown with microsecond accuracy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>verbose</option> + </term> + <listitem> + <para>shows the full-structured entry items with all + fields.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>export</option> + </term> + <listitem> + <para>serializes the journal into a binary (but mostly + text-based) stream suitable for backups and network + transfer (see + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal Export Format</ulink> + for more information). To import the binary stream back + into native journald format use + <citerefentry><refentrytitle>systemd-journal-remote</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>json</option> + </term> + <listitem> + <para>formats entries as JSON objects, separated by newline characters (see <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/json">Journal JSON Format</ulink> for more + information). Field values are generally encoded as JSON strings, with three exceptions: + <orderedlist> + <listitem><para>Fields larger than 4096 bytes are encoded as <constant>null</constant> values. (This + may be turned off by passing <option>--all</option>, but be aware that this may allocate overly long + JSON objects.) </para></listitem> + + <listitem><para>Journal entries permit non-unique fields within the same log entry. JSON does not allow + non-unique fields within objects. Due to this, if a non-unique field is encountered a JSON array is + used as field value, listing all field values as elements.</para></listitem> + + <listitem><para>Fields containing non-printable or non-UTF8 bytes are encoded as arrays containing + the raw bytes individually formatted as unsigned numbers.</para></listitem> + </orderedlist> + + Note that this encoding is reversible (with the exception of the size limit).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>json-pretty</option> + </term> + <listitem> + <para>formats entries as JSON data structures, but + formats them in multiple lines in order to make them + more readable by humans.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>json-sse</option> + </term> + <listitem> + <para>formats entries as JSON data structures, but wraps + them in a format suitable for + <ulink url="https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events">Server-Sent Events</ulink>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>json-seq</option> + </term> + <listitem> + <para>formats entries as JSON data structures, but prefixes them with an ASCII Record Separator + character (0x1E) and suffixes them with an ASCII Line Feed character (0x0A), in accordance with <ulink + url="https://tools.ietf.org/html/rfc7464">JavaScript Object Notation (JSON) Text Sequences </ulink> + (<literal>application/json-seq</literal>). + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>cat</option> + </term> + <listitem> + <para>generates a very terse output, only showing the actual message of each journal entry + with no metadata, not even a timestamp. If combined with the + <option>--output-fields=</option> option will output the listed fields for each log record, + instead of the message.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>with-unit</option> + </term> + <listitem> + <para>similar to short-full, but prefixes the unit and + user unit names instead of the traditional syslog + identifier. Useful when using templated instances, as it + will include the arguments in the unit names.</para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--output-fields=</option></term> + + <listitem><para>A comma separated list of the fields which should be included in the output. This has + an effect only for the output modes which would normally show all fields (<option>verbose</option>, + <option>export</option>, <option>json</option>, <option>json-pretty</option>, + <option>json-sse</option> and <option>json-seq</option>), as well as on <option>cat</option>. For the + former, the <literal>__CURSOR</literal>, <literal>__REALTIME_TIMESTAMP</literal>, + <literal>__MONOTONIC_TIMESTAMP</literal>, and <literal>_BOOT_ID</literal> fields are always + printed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--utc</option></term> + + <listitem><para>Express time in Coordinated Universal Time + (UTC).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-hostname</option></term> + + <listitem><para>Don't show the hostname field of log messages originating from the local host. This + switch has an effect only on the <option>short</option> family of output modes (see above). + </para> + + <para>Note: this option does not remove occurrences of the hostname from log entries themselves, so + it does not prevent the hostname from being visible in the logs.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-x</option></term> + <term><option>--catalog</option></term> + + <listitem><para>Augment log lines with explanation texts from + the message catalog. This will add explanatory help texts to + log messages in the output where this is available. These + short help texts will explain the context of an error or log + event, possible solutions, as well as pointers to support + forums, developer documentation, and any other relevant + manuals. Note that help texts are not available for all + messages, but only for selected ones. For more information on + the message catalog, please refer to the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/catalog">Message Catalog Developer Documentation</ulink>.</para> + + <para>Note: when attaching <command>journalctl</command> + output to bug reports, please do <emphasis>not</emphasis> use + <option>-x</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Suppresses all informational messages + (i.e. "-- Journal begins at …", "-- Reboot --"), + any warning messages regarding + inaccessible system journals when run as a normal + user.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-m</option></term> + <term><option>--merge</option></term> + + <listitem><para>Show entries interleaved from all available + journals, including remote ones.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-b <optional><optional><replaceable>ID</replaceable></optional><optional><replaceable>±offset</replaceable></optional>|<constant>all</constant></optional></option></term> + <term><option>--boot<optional>=<optional><replaceable>ID</replaceable></optional><optional><replaceable>±offset</replaceable></optional>|<constant>all</constant></optional></option></term> + + <listitem><para>Show messages from a specific boot. This will + add a match for <literal>_BOOT_ID=</literal>.</para> + + <para>The argument may be empty, in which case logs for the + current boot will be shown.</para> + + <para>If the boot ID is omitted, a positive + <replaceable>offset</replaceable> will look up the boots + starting from the beginning of the journal, and an + equal-or-less-than zero <replaceable>offset</replaceable> will + look up boots starting from the end of the journal. Thus, + <constant>1</constant> means the first boot found in the + journal in chronological order, <constant>2</constant> the + second and so on; while <constant>-0</constant> is the last + boot, <constant>-1</constant> the boot before last, and so + on. An empty <replaceable>offset</replaceable> is equivalent + to specifying <constant>-0</constant>, except when the current + boot is not the last boot (e.g. because + <option>--directory</option> was specified to look at logs + from a different machine).</para> + + <para>If the 32-character <replaceable>ID</replaceable> is + specified, it may optionally be followed by + <replaceable>offset</replaceable> which identifies the boot + relative to the one given by boot + <replaceable>ID</replaceable>. Negative values mean earlier + boots and positive values mean later boots. If + <replaceable>offset</replaceable> is not specified, a value of + zero is assumed, and the logs for the boot given by + <replaceable>ID</replaceable> are shown.</para> + + <para>The special argument <constant>all</constant> can be + used to negate the effect of an earlier use of + <option>-b</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--list-boots</option></term> + + <listitem><para>Show a tabular list of boot numbers (relative to + the current boot), their IDs, and the timestamps of the first + and last message pertaining to the boot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-k</option></term> + <term><option>--dmesg</option></term> + + <listitem><para>Show only kernel messages. This implies + <option>-b</option> and adds the match + <literal>_TRANSPORT=kernel</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-t</option></term> + <term><option>--identifier=<replaceable>SYSLOG_IDENTIFIER</replaceable></option></term> + + <listitem><para>Show messages for the specified syslog + identifier + <replaceable>SYSLOG_IDENTIFIER</replaceable>.</para> + + <para>This parameter can be specified multiple + times.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-u</option></term> + <term><option>--unit=<replaceable>UNIT</replaceable>|<replaceable>PATTERN</replaceable></option></term> + + <listitem><para>Show messages for the specified systemd unit + <replaceable>UNIT</replaceable> (such as a service unit), or + for any of the units matched by + <replaceable>PATTERN</replaceable>. If a pattern is + specified, a list of unit names found in the journal is + compared with the specified pattern and all that match are + used. For each unit name, a match is added for messages from + 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. 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 children of the slice will be shown. + </para> + + <para>This parameter can be specified multiple times.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--user-unit=</option></term> + + <listitem><para>Show messages for the specified user session + unit. This will add a match for messages from the unit + (<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. 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 children of the unit will be shown.</para> + + <para>This parameter can be specified multiple times.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--priority=</option></term> + + <listitem><para>Filter output by message priorities or + priority ranges. Takes either a single numeric or textual log + level (i.e. between 0/<literal>emerg</literal> and + 7/<literal>debug</literal>), or a range of numeric/text log + levels in the form FROM..TO. The log levels are the usual + syslog log levels as documented in + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + i.e. <literal>emerg</literal> (0), + <literal>alert</literal> (1), <literal>crit</literal> (2), + <literal>err</literal> (3), <literal>warning</literal> (4), + <literal>notice</literal> (5), <literal>info</literal> (6), + <literal>debug</literal> (7). If a single log level is + specified, all messages with this log level or a lower (hence + more important) log level are shown. If a range is specified, + all messages within the range are shown, including both the + start and the end value of the range. This will add + <literal>PRIORITY=</literal> matches for the specified + priorities.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--facility=</option></term> + + <listitem><para>Filter output by syslog facility. Takes a comma-separated list of numbers or facility + names. The names are the usual syslog facilities as documented in + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + <option>--facility=help</option> may be used to display a list of known facility names and exit. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-g</option></term> + <term><option>--grep=</option></term> + + <listitem><para>Filter output to entries where the <varname>MESSAGE=</varname> + field matches the specified regular expression. PERL-compatible regular expressions + are used, see + <citerefentry project='url'><refentrytitle url='http://pcre.org/current/doc/html/pcre2pattern.html'>pcre2pattern</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a detailed description of the syntax.</para> + + <para>If the pattern is all lowercase, matching is case insensitive. + Otherwise, matching is case sensitive. This can be overridden with the + <option>--case-sensitive</option> option, see below.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--case-sensitive<optional>=BOOLEAN</optional></option></term> + + <listitem><para>Make pattern matching case sensitive or case insensitive.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-c</option></term> + <term><option>--cursor=</option></term> + + <listitem><para>Start showing entries from the location in the + journal specified by the passed cursor.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cursor-file=<replaceable>FILE</replaceable></option></term> + + <listitem><para>If <replaceable>FILE</replaceable> exists and contains a + cursor, start showing entries <emphasis>after</emphasis> this location. + Otherwise the show entries according the other given options. At the end, + write the cursor of the last entry to <replaceable>FILE</replaceable>. Use + this option to continually read the journal by sequentially calling + <command>journalctl</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--after-cursor=</option></term> + + <listitem><para>Start showing entries from the location in the + journal <emphasis>after</emphasis> the location specified by + the passed cursor. The cursor is shown when the + <option>--show-cursor</option> option is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--show-cursor</option></term> + + <listitem><para>The cursor is shown after the last entry after + two dashes:</para> + <programlisting>-- cursor: s=0639…</programlisting> + <para>The format of the cursor is private + and subject to change.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-S</option></term> + <term><option>--since=</option></term> + <term><option>-U</option></term> + <term><option>--until=</option></term> + + <listitem><para>Start showing entries on or newer than the specified date, or on or older than the specified + date, respectively. Date specifications should be of the format <literal>2012-10-30 18:17:16</literal>. If the + time part is omitted, <literal>00:00:00</literal> is assumed. If only the seconds component is omitted, + <literal>:00</literal> is assumed. If the date component is omitted, the current day is assumed. Alternatively + the strings <literal>yesterday</literal>, <literal>today</literal>, <literal>tomorrow</literal> are understood, + which refer to 00:00:00 of the day before the current day, the current day, or the day after the current day, + respectively. <literal>now</literal> refers to the current time. Finally, relative times may be specified, + prefixed with <literal>-</literal> or <literal>+</literal>, referring to times before or after the current + time, respectively. For complete time and date specification, see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Note that + <option>--output=short-full</option> prints timestamps that follow precisely this format. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-F</option></term> + <term><option>--field=</option></term> + + <listitem><para>Print all possible data values the specified + field can take in all entries of the journal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-N</option></term> + <term><option>--fields</option></term> + + <listitem><para>Print all field names currently used in all entries of the journal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--system</option></term> + <term><option>--user</option></term> + + <listitem><para>Show messages from system services and the + kernel (with <option>--system</option>). Show messages from + service of current user (with <option>--user</option>). If + neither is specified, show all messages that the user can see. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-M</option></term> + <term><option>--machine=</option></term> + + <listitem><para>Show messages from a running, local + container. Specify a container name to connect to.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-D <replaceable>DIR</replaceable></option></term> + <term><option>--directory=<replaceable>DIR</replaceable></option></term> + + <listitem><para>Takes a directory path as argument. If + specified, journalctl will operate on the specified journal + directory <replaceable>DIR</replaceable> instead of the + default runtime and system journal paths.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--file=<replaceable>GLOB</replaceable></option></term> + + <listitem><para>Takes a file glob as an argument. If + specified, journalctl will operate on the specified journal + files matching <replaceable>GLOB</replaceable> instead of the + default runtime and system journal paths. May be specified + multiple times, in which case files will be suitably + interleaved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root=<replaceable>ROOT</replaceable></option></term> + + <listitem><para>Takes a directory path as an argument. If specified, <command>journalctl</command> + will operate on journal directories and catalog file hierarchy underneath the specified directory + instead of the root directory (e.g. <option>--update-catalog</option> will create + <filename><replaceable>ROOT</replaceable>/var/lib/systemd/catalog/database</filename>, and journal + files under <filename><replaceable>ROOT</replaceable>/run/journal/</filename> or + <filename><replaceable>ROOT</replaceable>/var/log/journal/</filename> will be displayed). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--image=<replaceable>IMAGE</replaceable></option></term> + + <listitem><para>Takes a path to a disk image file or block device node. If specified, + <command>journalctl</command> will operate on the file system in the indicated disk image. This is + similar to <option>--root=</option> but operates on file systems stored in disk images or block + devices, thus providing an easy way to extract log data from disk images. The disk image should + either contain just a file system or a set of file systems within a GPT partition table, following + the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>. For further information on supported disk images, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + switch of the same name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--namespace=<replaceable>NAMESPACE</replaceable></option></term> + + <listitem><para>Takes a journal namespace identifier string as argument. If not specified the data + collected by the default namespace is shown. If specified shows the log data of the specified + namespace instead. If the namespace is specified as <literal>*</literal> data from all namespaces is + shown, interleaved. If the namespace identifier is prefixed with <literal>+</literal> data from the + specified namespace and the default namespace is shown, interleaved, but no other. For details about + journal namespaces see + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--header</option></term> + + <listitem><para>Instead of showing journal contents, show + internal header information of the journal fields + accessed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--disk-usage</option></term> + + <listitem><para>Shows the current disk usage of all journal + files. This shows the sum of the disk usage of all archived + and active journal files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--vacuum-size=</option></term> + <term><option>--vacuum-time=</option></term> + <term><option>--vacuum-files=</option></term> + + <listitem><para>Removes the oldest archived journal files until the disk space they use falls below the + specified size (specified with the usual <literal>K</literal>, <literal>M</literal>, <literal>G</literal> and + <literal>T</literal> suffixes), or all archived journal files contain no data older than the specified timespan + (specified with the usual <literal>s</literal>, <literal>m</literal>, <literal>h</literal>, + <literal>days</literal>, <literal>months</literal>, <literal>weeks</literal> and <literal>years</literal> + suffixes), or no more than the specified number of separate journal files remain. Note that running + <option>--vacuum-size=</option> has only an indirect effect on the output shown by + <option>--disk-usage</option>, as the latter includes active journal files, while the vacuuming operation only + operates on archived journal files. Similarly, <option>--vacuum-files=</option> might not actually reduce the + number of journal files to below the specified number, as it will not remove active journal + files.</para> + + <para><option>--vacuum-size=</option>, <option>--vacuum-time=</option> and <option>--vacuum-files=</option> + may be combined in a single invocation to enforce any combination of a size, a time and a number of files limit + on the archived journal files. Specifying any of these three parameters as zero is equivalent to not enforcing + the specific limit, and is thus redundant.</para> + + <para>These three switches may also be combined with <option>--rotate</option> into one command. If so, all + active files are rotated first, and the requested vacuuming operation is executed right after. The rotation has + the effect that all currently active files are archived (and potentially new, empty journal files opened as + replacement), and hence the vacuuming operation has the greatest effect as it can take all log data written so + far into account.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--list-catalog + <optional><replaceable>128-bit-ID…</replaceable></optional> + </option></term> + + <listitem><para>List the contents of the message catalog as a + table of message IDs, plus their short description strings. + </para> + + <para>If any <replaceable>128-bit-ID</replaceable>s are + specified, only those entries are shown.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--dump-catalog + <optional><replaceable>128-bit-ID…</replaceable></optional> + </option></term> + + <listitem><para>Show the contents of the message catalog, with + entries separated by a line consisting of two dashes and the + ID (the format is the same as <filename>.catalog</filename> + files).</para> + + <para>If any <replaceable>128-bit-ID</replaceable>s are + specified, only those entries are shown.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--update-catalog</option></term> + + <listitem><para>Update the message catalog index. This command + needs to be executed each time new catalog files are + installed, removed, or updated to rebuild the binary catalog + index.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--setup-keys</option></term> + + <listitem><para>Instead of showing journal contents, generate + a new key pair for Forward Secure Sealing (FSS). This will + generate a sealing key and a verification key. The sealing key + is stored in the journal data directory and shall remain on + the host. The verification key should be stored + externally. Refer to the <option>Seal=</option> option in + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information on Forward Secure Sealing and for a link to a + refereed scholarly paper detailing the cryptographic theory it + is based on.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--force</option></term> + + <listitem><para>When <option>--setup-keys</option> is passed + and Forward Secure Sealing (FSS) has already been configured, + recreate FSS keys.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--interval=</option></term> + + <listitem><para>Specifies the change interval for the sealing + key when generating an FSS key pair with + <option>--setup-keys</option>. Shorter intervals increase CPU + consumption but shorten the time range of undetectable journal + alterations. Defaults to 15min.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--verify</option></term> + + <listitem><para>Check the journal file for internal + consistency. If the file has been generated with FSS enabled and + the FSS verification key has been specified with + <option>--verify-key=</option>, authenticity of the journal file + is verified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--verify-key=</option></term> + + <listitem><para>Specifies the FSS verification key to use for + the <option>--verify</option> operation.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--sync</option></term> + + <listitem><para>Asks the journal daemon to write all yet + unwritten journal data to the backing file system and + synchronize all journals. This call does not return until the + synchronization operation is complete. This command guarantees + that any log messages written before its invocation are safely + stored on disk at the time it returns.</para></listitem> + </varlistentry> + + <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 (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> + <term><option>--rotate</option></term> + + <listitem><para>Asks the journal daemon to rotate journal files. This call does not return until the rotation + operation is complete. Journal file rotation has the effect that all currently active journal files are marked + as archived and renamed, so that they are never written to in future. New (empty) journal files are then + created in their place. This operation may be combined with <option>--vacuum-size=</option>, + <option>--vacuum-time=</option> and <option>--vacuum-file=</option> into a single command, see + above.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned; otherwise, a non-zero failure + code is returned.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>Examples</title> + + <para>Without arguments, all collected logs are shown + unfiltered:</para> + + <programlisting>journalctl</programlisting> + + <para>With one match specified, all entries with a field matching + the expression are shown:</para> + + <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service +journalctl _SYSTEMD_CGROUP=/user.slice/user-42.slice/session-c1.scope</programlisting> + + <para>If two different fields are matched, only entries matching + both expressions at the same time are shown:</para> + + <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097</programlisting> + + <para>If two matches refer to the same field, all entries matching + either expression are shown:</para> + + <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service</programlisting> + + <para>If the separator <literal>+</literal> is used, two + expressions may be combined in a logical OR. The following will + show all messages from the Avahi service process with the PID + 28097 plus all messages from the D-Bus service (from any of its + processes):</para> + + <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service</programlisting> + + <para>To show all fields emitted <emphasis>by</emphasis> a unit and <emphasis>about</emphasis> + the unit, option <option>-u</option>/<option>--unit=</option> should be used. + <command>journalctl -u <replaceable>name</replaceable></command> + expands to a complex filter similar to + <programlisting>_SYSTEMD_UNIT=<replaceable>name</replaceable>.service + + UNIT=<replaceable>name</replaceable>.service _PID=1 + + OBJECT_SYSTEMD_UNIT=<replaceable>name</replaceable>.service _UID=0 + + COREDUMP_UNIT=<replaceable>name</replaceable>.service _UID=0 MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 + </programlisting> + (see <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for an explanation of those patterns). + </para> + + <para>Show all logs generated by the D-Bus executable:</para> + + <programlisting>journalctl /usr/bin/dbus-daemon</programlisting> + + <para>Show all kernel logs from previous boot:</para> + + <programlisting>journalctl -k -b -1</programlisting> + + <para>Show a live log display from a system service + <filename>apache.service</filename>:</para> + + <programlisting>journalctl -f -u apache</programlisting> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/journald.conf.xml b/man/journald.conf.xml new file mode 100644 index 0000000..959815a --- /dev/null +++ b/man/journald.conf.xml @@ -0,0 +1,490 @@ +<?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-or-later --> + +<refentry id="journald.conf" + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>journald.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>journald.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>journald.conf</refname> + <refname>journald.conf.d</refname> + <refname>journald@.conf</refname> + <refpurpose>Journal service configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/journald.conf</filename></para> + <para><filename>/etc/systemd/journald.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/journald.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/journald.conf.d/*.conf</filename></para> + <para><filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These files configure various parameters of the systemd journal service, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + + <para>The <command>systemd-journald</command> instance managing the default namespace is configured by + <filename>/etc/systemd/journald.conf</filename> and associated drop-ins. Instances managing other + namespaces read <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename> with + the namespace identifier filled in. This allows each namespace to carry a distinct configuration. See + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details about journal namespaces.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the + [Journal] section:</para> + + <variablelist class='config-directives'> + + <varlistentry> + <term><varname>Storage=</varname></term> + + <listitem><para>Controls where to store journal data. One of <literal>volatile</literal>, + <literal>persistent</literal>, <literal>auto</literal> and <literal>none</literal>. If + <literal>volatile</literal>, journal log data will be stored only in memory, i.e. below the + <filename>/run/log/journal</filename> hierarchy (which is created if needed). If + <literal>persistent</literal>, data will be stored preferably on disk, i.e. below the + <filename>/var/log/journal</filename> hierarchy (which is created if needed), with a fallback to + <filename>/run/log/journal</filename> (which is created if needed), during early boot and if the disk + is not writable. <literal>auto</literal> behaves like <literal>persistent</literal> if the + <filename>/var/log/journal</filename> directory exists, and <literal>volatile</literal> otherwise + (the existence of the directory controls the storage mode). <literal>none</literal> turns off all + storage, all log data received will be dropped (but forwarding to other targets, such as the console, + the kernel log buffer, or a syslog socket will still work). Defaults to <literal>auto</literal> in + the default journal namespace, and <literal>persistent</literal> in all others.</para> + + <para>Note that when this option is changed to <literal>volatile</literal>, existing persistent data + is not removed. In the other direction, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> with + the <option>--flush</option> option may be used to move volatile data to persistent storage.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Compress=</varname></term> + + <listitem><para>Can take a boolean value. If enabled (the + default), data objects that shall be stored in the journal + and are larger than the default threshold of 512 bytes are + compressed before they are written to the file system. It + can also be set to a number of bytes to specify the + compression threshold directly. Suffixes like K, M, and G + can be used to specify larger units.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Seal=</varname></term> + + <listitem><para>Takes a boolean value. If enabled (the + default), and a sealing key is available (as created by + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <option>--setup-keys</option> command), Forward Secure Sealing + (FSS) for all persistent journal files is enabled. FSS is + based on <ulink + url="https://eprint.iacr.org/2013/397">Seekable Sequential Key + Generators</ulink> by G. A. Marson and B. Poettering + (doi:10.1007/978-3-642-40203-6_7) and may be used to protect + journal files from unnoticed alteration.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SplitMode=</varname></term> + + <listitem><para>Controls whether to split up journal files per user, either <literal>uid</literal> or + <literal>none</literal>. Split journal files are primarily useful for access control: on UNIX/Linux access + control is managed per file, and the journal daemon will assign users read access to their journal files. If + <literal>uid</literal>, all regular users (with UID outside the range of system users, dynamic service users, + and the nobody user) will each get their own journal files, and system users will log to the system journal. + See <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink> + for more details about UID ranges. + If <literal>none</literal>, journal files are not split up by user and all messages are + instead stored in the single system journal. In this mode unprivileged users generally do not have access to + their own log data. Note that splitting up journal files by user is only available for journals stored + persistently. If journals are stored on volatile storage (see <varname>Storage=</varname> above), only a single + journal file is used. Defaults to <literal>uid</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RateLimitIntervalSec=</varname></term> + <term><varname>RateLimitBurst=</varname></term> + + <listitem><para>Configures the rate limiting that is applied + to all messages generated on the system. If, in the time + interval defined by <varname>RateLimitIntervalSec=</varname>, + more messages than specified in + <varname>RateLimitBurst=</varname> are logged by a service, + all further messages within the interval are dropped until the + interval is over. A message about the number of dropped + messages is generated. This rate limiting is applied + per-service, so that two services which log do not interfere + with each other's limits. Defaults to 10000 messages in 30s. + The time specification for + <varname>RateLimitIntervalSec=</varname> may be specified in the + following units: <literal>s</literal>, <literal>min</literal>, + <literal>h</literal>, <literal>ms</literal>, + <literal>us</literal>. To turn off any kind of rate limiting, + set either value to 0.</para> + + <para>Note that the effective rate limit is multiplied by a + factor derived from the available free disk space for the journal. + Currently, this factor is calculated using the base 2 logarithm.</para> + + <table> + <title>Example <varname>RateLimitBurst=</varname> rate + modifications by the available disk space</title> + <tgroup cols='2'> + <colspec colname='freespace' /> + <colspec colname='multiplier' /> + <thead> + <row> + <entry>Available Disk Space</entry> + <entry>Burst Multiplier</entry> + </row> + </thead> + <tbody> + <row> + <entry><= 1MB</entry> + <entry>1</entry> + </row> + <row> + <entry><= 16MB</entry> + <entry>2</entry> + </row> + <row> + <entry><= 256MB</entry> + <entry>3</entry> + </row> + <row> + <entry><= 4GB</entry> + <entry>4</entry> + </row> + <row> + <entry><= 64GB</entry> + <entry>5</entry> + </row> + <row> + <entry><= 1TB</entry> + <entry>6</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>If a service provides rate limits for itself through + <varname>LogRateLimitIntervalSec=</varname> and/or <varname>LogRateLimitBurst=</varname> + in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + those values will override the settings specified here.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SystemMaxUse=</varname></term> + <term><varname>SystemKeepFree=</varname></term> + <term><varname>SystemMaxFileSize=</varname></term> + <term><varname>SystemMaxFiles=</varname></term> + <term><varname>RuntimeMaxUse=</varname></term> + <term><varname>RuntimeKeepFree=</varname></term> + <term><varname>RuntimeMaxFileSize=</varname></term> + <term><varname>RuntimeMaxFiles=</varname></term> + + <listitem><para>Enforce size limits on the journal files + stored. The options prefixed with <literal>System</literal> + apply to the journal files when stored on a persistent file + system, more specifically + <filename>/var/log/journal</filename>. The options prefixed + with <literal>Runtime</literal> apply to the journal files + when stored on a volatile in-memory file system, more + specifically <filename>/run/log/journal</filename>. The former + is used only when <filename>/var/</filename> is mounted, + writable, and the directory + <filename>/var/log/journal</filename> exists. Otherwise, only + the latter applies. Note that this means that during early + boot and if the administrator disabled persistent logging, + only the latter options apply, while the former apply if + persistent logging is enabled and the system is fully booted + up. <command>journalctl</command> and + <command>systemd-journald</command> ignore all files with + names not ending with <literal>.journal</literal> or + <literal>.journal~</literal>, so only such files, located in + the appropriate directories, are taken into account when + calculating current disk usage.</para> + + <para><varname>SystemMaxUse=</varname> and + <varname>RuntimeMaxUse=</varname> control how much disk space + the journal may use up at most. + <varname>SystemKeepFree=</varname> and + <varname>RuntimeKeepFree=</varname> control how much disk + space systemd-journald shall leave free for other uses. + <command>systemd-journald</command> will respect both limits + and use the smaller of the two values.</para> + + <para>The first pair defaults to 10% and the second to 15% of + the size of the respective file system, but each value is + capped to 4G. If the file system is nearly full and either + <varname>SystemKeepFree=</varname> or + <varname>RuntimeKeepFree=</varname> are violated when + systemd-journald is started, the limit will be raised to the + percentage that is actually free. This means that if there was + enough free space before and journal files were created, and + subsequently something else causes the file system to fill up, + journald will stop using more space, but it will not be + removing existing files to reduce the footprint again, + either. Also note that only archived files are deleted to reduce the + space occupied by journal files. This means that, in effect, there might + still be more space used than <varname>SystemMaxUse=</varname> or + <varname>RuntimeMaxUse=</varname> limit after a vacuuming operation is + complete.</para> + + <para><varname>SystemMaxFileSize=</varname> and + <varname>RuntimeMaxFileSize=</varname> control how large + individual journal files may grow at most. This influences + the granularity in which disk space is made available through + rotation, i.e. deletion of historic data. Defaults to one + eighth of the values configured with + <varname>SystemMaxUse=</varname> and + <varname>RuntimeMaxUse=</varname>, so that usually seven + rotated journal files are kept as history.</para> + + <para>Specify values in bytes or use K, M, G, T, P, E as + units for the specified sizes (equal to 1024, 1024², … bytes). + Note that size limits are enforced synchronously when journal + files are extended, and no explicit rotation step triggered by + time is needed.</para> + + <para><varname>SystemMaxFiles=</varname> and + <varname>RuntimeMaxFiles=</varname> control how many + individual journal files to keep at most. Note that only + archived files are deleted to reduce the number of files until + this limit is reached; active files will stay around. This + means that, in effect, there might still be more journal files + around in total than this limit after a vacuuming operation is + complete. This setting defaults to 100.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxFileSec=</varname></term> + + <listitem><para>The maximum time to store entries in a single + journal file before rotating to the next one. Normally, + time-based rotation should not be required as size-based + rotation with options such as + <varname>SystemMaxFileSize=</varname> should be sufficient to + ensure that journal files do not grow without bounds. However, + to ensure that not too much data is lost at once when old + journal files are deleted, it might make sense to change this + value from the default of one month. Set to 0 to turn off this + feature. This setting takes time values which may be suffixed + with the units <literal>year</literal>, + <literal>month</literal>, <literal>week</literal>, + <literal>day</literal>, <literal>h</literal> or + <literal>m</literal> to override the default time unit of + seconds.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxRetentionSec=</varname></term> + + <listitem><para>The maximum time to store journal entries. + This controls whether journal files containing entries older + than the specified time span are deleted. Normally, time-based + deletion of old journal files should not be required as + size-based deletion with options such as + <varname>SystemMaxUse=</varname> should be sufficient to + ensure that journal files do not grow without bounds. However, + to enforce data retention policies, it might make sense to + change this value from the default of 0 (which turns off this + feature). This setting also takes time values which may be + suffixed with the units <literal>year</literal>, + <literal>month</literal>, <literal>week</literal>, + <literal>day</literal>, <literal>h</literal> or <literal> + m</literal> to override the default time unit of + seconds.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SyncIntervalSec=</varname></term> + + <listitem><para>The timeout before synchronizing journal files + to disk. After syncing, journal files are placed in the + OFFLINE state. Note that syncing is unconditionally done + immediately after a log message of priority CRIT, ALERT or + EMERG has been logged. This setting hence applies only to + messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The + default timeout is 5 minutes. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ForwardToSyslog=</varname></term> + <term><varname>ForwardToKMsg=</varname></term> + <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>, + <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.</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, for example by adding <literal>log_buf_len=8M</literal> to the kernel command line. + <command>systemd</command> will automatically disable kernel's rate-limiting applied to userspace + processes (equivalent to setting <literal>printk.devkmsg=on</literal>).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxLevelStore=</varname></term> + <term><varname>MaxLevelSyslog=</varname></term> + <term><varname>MaxLevelKMsg=</varname></term> + <term><varname>MaxLevelConsole=</varname></term> + <term><varname>MaxLevelWall=</varname></term> + + <listitem><para>Controls the maximum log level of messages + that are stored in the journal, forwarded to syslog, kmsg, the + console or wall (if that is enabled, see above). As argument, + takes one of + <literal>emerg</literal>, + <literal>alert</literal>, + <literal>crit</literal>, + <literal>err</literal>, + <literal>warning</literal>, + <literal>notice</literal>, + <literal>info</literal>, + <literal>debug</literal>, + or integer values in the range of 0–7 (corresponding to the + same levels). Messages equal or below the log level specified + are stored/forwarded, messages above are dropped. Defaults to + <literal>debug</literal> for <varname>MaxLevelStore=</varname> + and <varname>MaxLevelSyslog=</varname>, to ensure that the all + messages are stored in the journal and forwarded to syslog. + Defaults to + <literal>notice</literal> for <varname>MaxLevelKMsg=</varname>, + <literal>info</literal> for <varname>MaxLevelConsole=</varname>, + and <literal>emerg</literal> for + <varname>MaxLevelWall=</varname>. These settings may be + overridden at boot time with the kernel command line options + <literal>systemd.journald.max_level_store=</literal>, + <literal>systemd.journald.max_level_syslog=</literal>, + <literal>systemd.journald.max_level_kmsg=</literal>, + <literal>systemd.journald.max_level_console=</literal>, + <literal>systemd.journald.max_level_wall=</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReadKMsg=</varname></term> + + <listitem><para>Takes a boolean value. If enabled <command>systemd-journal</command> processes + <filename>/dev/kmsg</filename> messages generated by the kernel. In the default journal namespace + this option is enabled by default, it is disabled in all others.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Audit=</varname></term> + + <listitem><para>Takes a boolean value. If enabled <command>systemd-journal</command> will turn on + kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor + disable it, leaving the previous state unchanged. Note that this option does not control whether + <command>systemd-journald</command> collects generated audit records, it just controls whether it + tells the kernel to generate them. This means if another tool turns on auditing even if + <command>systemd-journald</command> left it off, it will still collect the generated + messages. Defaults to on.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TTYPath=</varname></term> + + <listitem><para>Change the console TTY to use if + <varname>ForwardToConsole=yes</varname> is used. Defaults to + <filename>/dev/console</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LineMax=</varname></term> + + <listitem><para>The maximum line length to permit when converting stream logs into record logs. When a systemd + unit's standard output/error are connected to the journal via a stream socket, the data read is split into + individual log records at newline (<literal>\n</literal>, ASCII 10) and <constant>NUL</constant> characters. If no such delimiter is + read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly + long lines into multiple log records. Selecting overly large values increases the possible memory usage of the + Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified + number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large + line maximum line lengths affects compatibility with traditional log protocols as log records might not fit + anymore into a single <constant>AF_UNIX</constant> or <constant>AF_INET</constant> datagram. Takes a size in + bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes, + Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but + still small enough so that log records likely fit into network datagrams along with extra room for + metadata. Note that values below 79 are not accepted and will be bumped to 79.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>Forwarding to traditional syslog daemons</title> + + <para> + Journal events can be transferred to a different logging daemon + in two different ways. With the first method, messages are + immediately forwarded to a socket + (<filename>/run/systemd/journal/syslog</filename>), where the + traditional syslog daemon can read them. This method is + controlled by the <varname>ForwardToSyslog=</varname> option. With a + second method, a syslog daemon behaves like a normal journal + client, and reads messages from the journal files, similarly to + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + With this, messages do not have to be read immediately, + which allows a logging daemon which is only started late in boot + to access all messages since the start of the system. In + addition, full structured meta-data is available to it. This + method of course is available only if the messages are stored in + a journal file at all. So it will not work if + <varname>Storage=none</varname> is set. It should be noted that + usually the <emphasis>second</emphasis> method is used by syslog + daemons, so the <varname>Storage=</varname> option, and not the + <varname>ForwardToSyslog=</varname> option, is relevant for them. + </para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml new file mode 100644 index 0000000..7a41099 --- /dev/null +++ b/man/kernel-command-line.xml @@ -0,0 +1,538 @@ +<?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-or-later --> + +<refentry id="kernel-command-line"> + + <refentryinfo> + <title>kernel-command-line</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>kernel-command-line</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>kernel-command-line</refname> + <refpurpose>Kernel command line parameters</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/proc/cmdline</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The kernel, the initial RAM disk (initrd) and basic userspace functionality may be configured at + boot via kernel command line arguments. In addition, various systemd tools look at the EFI variable + <literal>SystemdOptions</literal> (if available). Both sources are combined, but the kernel command line + has higher priority. Please note that <emphasis>the EFI variable is only used by systemd tools, and is + ignored by the kernel and other user space tools</emphasis>, so it is not a replacement for the kernel + command line.</para> + + <para>For command line parameters understood by the kernel, please + see + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html"><filename>kernel-parameters.html</filename></ulink> + and + <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>For command line parameters understood by the initial RAM + disk, please see + <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + or the documentation of the specific initrd implementation of your + installation.</para> + </refsect1> + + <refsect1> + <title>Core OS Command Line Arguments</title> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.unit=</varname></term> + <term><varname>rd.systemd.unit=</varname></term> + <term><varname>systemd.dump_core</varname></term> + <term><varname>systemd.early_core_pattern=</varname></term> + <term><varname>systemd.crash_chvt</varname></term> + <term><varname>systemd.crash_shell</varname></term> + <term><varname>systemd.crash_reboot</varname></term> + <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> + <term><varname>systemd.log_color</varname></term> + <term><varname>systemd.default_standard_output=</varname></term> + <term><varname>systemd.default_standard_error=</varname></term> + <term><varname>systemd.setenv=</varname></term> + <term><varname>systemd.machine_id=</varname></term> + <term><varname>systemd.unified_cgroup_hierarchy</varname></term> + <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term> + <listitem> + <para>Parameters understood by the system and service + manager to control system behavior. For details, see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.mask=</varname></term> + <term><varname>systemd.wants=</varname></term> + <term><varname>systemd.debug_shell</varname></term> + <listitem> + <para>Additional parameters understood by + <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + to mask or start specific units at boot, or invoke a debug + shell on tty9.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.run=</varname></term> + <term><varname>systemd.run_success_action=</varname></term> + <term><varname>systemd.run_failure_action=</varname></term> + <listitem> + <para>Additional parameters understood by + <citerefentry><refentrytitle>systemd-run-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, to + run a command line specified on the kernel command line as system service after booting up.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.early_core_pattern=</varname></term> + <listitem> + <para>During early boot, the generation of core dump files is disabled until a core dump handler (if any) + takes over. This parameter allows specifying an absolute path where core dump files should be stored until + a handler is installed. The path should be absolute and may contain specifiers, see + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.restore_state=</varname></term> + <listitem> + <para>This parameter is understood by several system tools + to control whether or not they should restore system state + from the previous boot. For details, see + <citerefentry><refentrytitle>systemd-backlight@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd-rfkill.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.volatile=</varname></term> + <listitem> + <para>This parameter controls whether the system shall boot up in volatile mode. Takes a boolean argument, or + the special value <literal>state</literal>. If false (the default), normal boot mode is selected, the root + directory and <filename>/var/</filename> are mounted as specified on the kernel command line or + <filename>/etc/fstab</filename>, or otherwise configured. If true, full state-less boot mode is selected. In + this case the root directory is mounted as volatile memory file system (<literal>tmpfs</literal>), and only + <filename>/usr/</filename> is mounted from the file system configured as root device, in read-only mode. This + enables fully state-less boots were the vendor-supplied OS is used as shipped, with only default + configuration and no stored state in effect, as <filename>/etc/</filename> and <filename>/var/</filename> (as + well as all other resources shipped in the root file system) are reset at boot and lost on shutdown. If this + setting is set to <literal>state</literal> the root file system is mounted read-only, however + <filename>/var/</filename> is mounted as a volatile memory file system (<literal>tmpfs</literal>), so that the + system boots up with the normal configuration applied, but all state reset at boot and lost at shutdown. If + this setting is set to <literal>overlay</literal> the root file system is set up as + <literal>overlayfs</literal> mount combining the read-only root directory with a writable + <literal>tmpfs</literal>, so that no modifications are made to disk, but the file system may be modified + nonetheless with all changes being lost at reboot. For details, see + <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>quiet</varname></term> + <listitem> + <para>Parameter understood by both the kernel and the system + and service manager to control console log verbosity. For + details, see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>debug</varname></term> + <listitem> + <para>Parameter understood by both the kernel and the system + and service manager to control console log verbosity. For + details, see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>-b</varname></term> + <term><varname>rd.emergency</varname></term> + <term><varname>emergency</varname></term> + <term><varname>rd.rescue</varname></term> + <term><varname>rescue</varname></term> + <term><varname>single</varname></term> + <term><varname>s</varname></term> + <term><varname>S</varname></term> + <term><varname>1</varname></term> + <term><varname>2</varname></term> + <term><varname>3</varname></term> + <term><varname>4</varname></term> + <term><varname>5</varname></term> + <listitem> + <para>Parameters understood by the system and service + manager, as compatibility and convenience options. For details, see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>locale.LANG=</varname></term> + <term><varname>locale.LANGUAGE=</varname></term> + <term><varname>locale.LC_CTYPE=</varname></term> + <term><varname>locale.LC_NUMERIC=</varname></term> + <term><varname>locale.LC_TIME=</varname></term> + <term><varname>locale.LC_COLLATE=</varname></term> + <term><varname>locale.LC_MONETARY=</varname></term> + <term><varname>locale.LC_MESSAGES=</varname></term> + <term><varname>locale.LC_PAPER=</varname></term> + <term><varname>locale.LC_NAME=</varname></term> + <term><varname>locale.LC_ADDRESS=</varname></term> + <term><varname>locale.LC_TELEPHONE=</varname></term> + <term><varname>locale.LC_MEASUREMENT=</varname></term> + <term><varname>locale.LC_IDENTIFICATION=</varname></term> + <listitem> + <para>Parameters understood by the system and service + manager to control locale and language settings. For + details, see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>fsck.mode=</varname></term> + <term><varname>fsck.repair=</varname></term> + + <listitem> + <para>Parameters understood by the file system checker + services. For details, see + <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>quotacheck.mode=</varname></term> + + <listitem> + <para>Parameter understood by the file quota checker + service. For details, see + <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.journald.forward_to_syslog=</varname></term> + <term><varname>systemd.journald.forward_to_kmsg=</varname></term> + <term><varname>systemd.journald.forward_to_console=</varname></term> + <term><varname>systemd.journald.forward_to_wall=</varname></term> + + <listitem> + <para>Parameters understood by the journal service. For + details, see + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>vconsole.keymap=</varname></term> + <term><varname>vconsole.keymap_toggle=</varname></term> + <term><varname>vconsole.font=</varname></term> + <term><varname>vconsole.font_map=</varname></term> + <term><varname>vconsole.font_unimap=</varname></term> + + <listitem> + <para>Parameters understood by the virtual console setup logic. For details, see + <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>udev.log_level=</varname></term> + <term><varname>rd.udev.log_level=</varname></term> + <term><varname>udev.children_max=</varname></term> + <term><varname>rd.udev.children_max=</varname></term> + <term><varname>udev.exec_delay=</varname></term> + <term><varname>rd.udev.exec_delay=</varname></term> + <term><varname>udev.event_timeout=</varname></term> + <term><varname>rd.udev.event_timeout=</varname></term> + <term><varname>udev.timeout_signal=</varname></term> + <term><varname>rd.udev.timeout_signal=</varname></term> + <term><varname>udev.blockdev_read_only</varname></term> + <term><varname>rd.udev.blockdev_read_only</varname></term> + <term><varname>net.ifnames=</varname></term> + <term><varname>net.naming-scheme=</varname></term> + + <listitem> + <para>Parameters understood by the device event managing + daemon. For details, see + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>plymouth.enable=</varname></term> + + <listitem> + <para>May be used to disable the Plymouth boot splash. For + details, see + <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks=</varname></term> + <term><varname>rd.luks=</varname></term> + <term><varname>luks.crypttab=</varname></term> + <term><varname>rd.luks.crypttab=</varname></term> + <term><varname>luks.name=</varname></term> + <term><varname>rd.luks.name=</varname></term> + <term><varname>luks.uuid=</varname></term> + <term><varname>rd.luks.uuid=</varname></term> + <term><varname>luks.options=</varname></term> + <term><varname>rd.luks.options=</varname></term> + <term><varname>luks.key=</varname></term> + <term><varname>rd.luks.key=</varname></term> + + <listitem> + <para>Configures the LUKS full-disk encryption logic at + boot. For details, see + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>fstab=</varname></term> + <term><varname>rd.fstab=</varname></term> + + <listitem> + <para>Configures the <filename>/etc/fstab</filename> logic + at boot. For details, see + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>root=</varname></term> + <term><varname>rootfstype=</varname></term> + <term><varname>rootflags=</varname></term> + <term><varname>ro</varname></term> + <term><varname>rw</varname></term> + + <listitem> + <para>Configures the root file system and its file system + type and mount options, as well as whether it shall be + mounted read-only or read-write initially. For details, + see + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>mount.usr=</varname></term> + <term><varname>mount.usrfstype=</varname></term> + <term><varname>mount.usrflags=</varname></term> + + <listitem> + <para>Configures the /usr file system (if required) and + its file system type and mount options. For details, see + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>roothash=</varname></term> + <term><varname>systemd.verity=</varname></term> + <term><varname>rd.systemd.verity=</varname></term> + <term><varname>systemd.verity_root_data=</varname></term> + <term><varname>systemd.verity_root_hash=</varname></term> + <listitem> + <para>Configures the integrity protection root hash for the root file system, and other related + parameters. For details, see + <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.gpt_auto=</varname></term> + <term><varname>rd.systemd.gpt_auto=</varname></term> + + <listitem> + <para>Configures whether GPT based partition auto-discovery + shall be attempted. For details, see + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.default_timeout_start_sec=</varname></term> + + <listitem> + <para>Overwrites the default start job timeout <varname>DefaultTimeoutStartSec=</varname> at boot. For details, + see <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.watchdog_device=</varname></term> + + <listitem> + <para>Overwrites the watchdog device path <varname>WatchdogDevice=</varname>. For details, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.cpu_affinity=</varname></term> + + <listitem> + <para>Overrides the CPU affinity mask for the service manager and the default for all child + processes it forks. This takes precedence over <varname>CPUAffinity=</varname>, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>modules_load=</varname></term> + <term><varname>rd.modules_load=</varname></term> + + <listitem> + <para>Load a specific kernel module early at boot. For + details, see + <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>resume=</varname></term> + <term><varname>resumeflags=</varname></term> + + <listitem> + <para>Enables resume from hibernation using the specified + 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> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.firstboot=</varname></term> + + <listitem><para>Takes a boolean argument, defaults to on. If off, + <citerefentry><refentrytitle>systemd-firstboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + will not query the user for basic system settings, even if the system boots up for the first time and + the relevant settings are not initialized yet. Not to be confused with + <varname>systemd.condition-first-boot=</varname> (see below), which overrides the result of the + <varname>ConditionFirstBoot=</varname> unit file condition, and thus controls more than just + <filename>systemd-firstboot.service</filename> behaviour.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.condition-needs-update=</varname></term> + + <listitem><para>Takes a boolean argument. If specified, overrides the result of + <varname>ConditionNeedsUpdate=</varname> unit condition checks. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.condition-first-boot=</varname></term> + + <listitem><para>Takes a boolean argument. If specified, overrides the result of + <varname>ConditionFirstBoot=</varname> unit condition checks. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. Not to be confused with <varname>systemd.firstboot=</varname> which only controls behaviour + of the <filename>systemd-firstboot.service</filename> system service but has no effect on the + condition check (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.clock-usec=</varname></term> + + <listitem><para>Takes a decimal, numeric timestamp in µs since January 1st 1970, 00:00am, to set the + system clock to. The system time is set to the specified timestamp early during boot. It is not + propagated to the hardware clock (RTC).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.random-seed=</varname></term> + + <listitem><para>Takes a base64 encoded random seed value to credit with full entropy to the kernel's + random pool during early service manager initialization. This option is useful in testing + environments where delays due to random pool initialization in entropy starved virtual machines shall + be avoided.</para> + + <para>Note that if this option is used the seed is accessible to unprivileged programs from + <filename>/proc/cmdline</filename>. This option is hence a security risk when used outside of test + systems, since the (possibly) only seed used for initialization of the kernel's entropy pool might be + easily acquired by unprivileged programs.</para> + + <para>It is recommended to pass 512 bytes of randomized data (as that matches the Linux kernel pool + size), which may be generated with a command like the following:</para> + + <programlisting>dd if=/dev/urandom bs=512 count=1 status=none | base64 -w 0</programlisting> + + <para>Again: do not use this option outside of testing environments, it's a security risk elsewhere, + as secret key material derived from the entropy pool can possibly be reconstructed by unprivileged + programs.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.hostname=</varname></term> + + <listitem><para>Accepts a hostname to set during early boot. If specified takes precedence over what + is set in <filename>/etc/hostname</filename>. Note that this does not bar later runtime changes to + the hostname, it simply controls the initial hostname set during early boot.</para></listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-backlight@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-rfkill.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/kernel-install.xml b/man/kernel-install.xml new file mode 100644 index 0000000..37eefe2 --- /dev/null +++ b/man/kernel-install.xml @@ -0,0 +1,242 @@ +<?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-or-later --> + +<refentry id="kernel-install" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>kernel-install</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>kernel-install</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>kernel-install</refname> + <refpurpose>Add and remove kernel and initramfs images to and from /boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>kernel-install</command> + <arg choice="plain">COMMAND</arg> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain"><replaceable>KERNEL-VERSION</replaceable></arg> + <arg choice="plain"><replaceable>KERNEL-IMAGE</replaceable></arg> + <arg choice="opt" rep="repeat"><replaceable>INITRD-FILE</replaceable></arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para><command>kernel-install</command> is used to install and remove kernel and initramfs images to and + from the boot loader partition, referred to as <varname>$BOOT</varname> here. It will usually be one of + <filename>/boot/</filename>, <filename>/efi/</filename>, or <filename>/boot/efi/</filename>, see below. + </para> + + <para><command>kernel-install</command> will execute the files + located in the directory <filename>/usr/lib/kernel/install.d/</filename> + and the local administration directory <filename>/etc/kernel/install.d/</filename>. + All files are collectively sorted and executed in lexical order, regardless of the directory in + which they live. However, files with identical filenames replace each other. + Files in <filename>/etc/kernel/install.d/</filename> take precedence over files with the same name + in <filename>/usr/lib/kernel/install.d/</filename>. This can be used to override a system-supplied + executables with a local file if needed; a symbolic link in <filename>/etc/kernel/install.d/</filename> + with the same name as an executable in <filename>/usr/lib/kernel/install.d/</filename>, + pointing to <filename>/dev/null</filename>, disables the executable entirely. Executables must have the + extension <literal>.install</literal>; other extensions are ignored.</para> + + <para>An executable should return <constant>0</constant> on success. It may also + return <constant>77</constant> to cause the whole operation to terminate + (executables later in lexical order will be skipped).</para> + </refsect1> + + <refsect1> + <title>Commands</title> + <para>The following commands are understood:</para> + <variablelist> + <varlistentry> + <term><command>add <replaceable>KERNEL-VERSION</replaceable> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</command></term> + <listitem> + <para>This command expects a kernel version string and a path to a kernel image file as + arguments. <command>kernel-install</command> calls the executables from + <filename>/usr/lib/kernel/install.d/*.install</filename> and + <filename>/etc/kernel/install.d/*.install</filename> with the following arguments: + + <programlisting>add <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</programlisting> + </para> + + <para>Three default plugins execute the following operations in this case:</para> + + <itemizedlist> + <listitem><para><filename>00-entry-directory.install</filename> creates the directory + <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> + if <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/</filename> already exists. + </para></listitem> + + <listitem><para><filename>50-depmod.install</filename> runs + <citerefentry project='man-pages'><refentrytitle>depmod</refentrytitle><manvolnum>8</manvolnum></citerefentry> for the + <replaceable>KERNEL-VERSION</replaceable>.</para></listitem> + + <listitem><para><filename>90-loaderentry.install</filename> copies <replaceable>KERNEL-IMAGE</replaceable> + to + <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/linux</filename>. + If an <replaceable>INITRD-FILE</replaceable> is provided, it also copies <replaceable>INITRD-FILE</replaceable> + to + <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL_VERSION</replaceable>/<replaceable>INITRD-FILE</replaceable></filename>. + It also creates a boot loader entry according to the <ulink + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> in + <filename>$BOOT/loader/entries/<replaceable>MACHINE-ID</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>. + The title of the entry is the <replaceable>PRETTY_NAME</replaceable> parameter specified in + <filename>/etc/os-release</filename> or <filename>/usr/lib/os-release</filename> (if the former is + missing), or "Linux <replaceable>KERNEL-VERSION</replaceable>", if unset.</para> + + <para>If the entry directory + <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> + does not exist, this plugin does nothing.</para></listitem> + </itemizedlist> + </listitem> + </varlistentry> + <varlistentry> + <term><command>remove <replaceable>KERNEL-VERSION</replaceable></command></term> + <listitem> + <para>This command expects a kernel version string as single argument. This calls executables from + <filename>/usr/lib/kernel/install.d/*.install</filename> and + <filename>/etc/kernel/install.d/*.install</filename> with the following arguments: + + <programlisting>remove <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></programlisting> + </para> + + <para>Afterwards, <command>kernel-install</command> removes the directory + <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> + and its contents.</para> + + <para>Two default plugins execute the following operations in this case:</para> + + <itemizedlist> + + <listitem><para><filename>50-depmod.install</filename> removes the files generated by <command>depmod</command> for this kernel again.</para></listitem> + + <listitem><para><filename>90-loaderentry.install</filename> removes the file + <filename>$BOOT/loader/entries/<replaceable>MACHINE-ID</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.</para></listitem> + </itemizedlist> + + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>The <varname>$BOOT</varname> partition</title> + <para>The partition where the kernels and <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot + Loader Specification</ulink> snippets are located is called <varname>$BOOT</varname>. + <command>kernel-install</command> determines the location of this partition by checking + <filename>/efi/</filename>, <filename>/boot/</filename>, and <filename>/boot/efi/</filename> + in turn. The first location where <filename>$BOOT/loader/entries/</filename> or + <filename>$BOOT/$MACHINE_ID/</filename> exists is used.</para> + </refsect1> + + <refsect1> + <title>Options</title> + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-v</option></term> + <term><option>--verbose</option></term> + <listitem> + <para>Output additional information about operations being performed.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Environment variables</title> + <para>If <option>--verbose</option> is used, <varname>$KERNEL_INSTALL_VERBOSE=1</varname> will be set for + the plugins. They may output additional logs in this case.</para> + </refsect1> + + <refsect1> + <title>Exit status</title> + <para>If every executable returns 0 or 77, 0 is returned, and a non-zero failure code otherwise.</para> + </refsect1> + + <refsect1> + <title>Files</title> + <variablelist> + <varlistentry> + <term> + <filename>/usr/lib/kernel/install.d/*.install</filename> + <filename>/etc/kernel/install.d/*.install</filename> + </term> + <listitem> + <para>Drop-in files which are executed by kernel-install.</para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <filename>/etc/kernel/cmdline</filename> + <filename>/proc/cmdline</filename> + </term> + <listitem> + <para>Read by <filename>90-loaderentry.install</filename>. The content of the file + <filename>/etc/kernel/cmdline</filename> specifies the kernel command line to use. If that file does not + exist, <filename>/proc/cmdline</filename> is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <filename>/etc/kernel/tries</filename> + </term> + <listitem> + <para>Read by <filename>90-loaderentry.install</filename>. If this file exists a numeric value is read from + it and the naming of the generated entry file is slightly altered to include it as + <filename>$BOOT/loader/entries/<replaceable>MACHINE-ID</replaceable>-<replaceable>KERNEL-VERSION</replaceable>+<replaceable>TRIES</replaceable>.conf</filename>. This + is useful for boot loaders such as + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> which + implement boot attempt counting with a counter embedded in the entry file name.</para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <filename>/etc/machine-id</filename> + </term> + <listitem> + <para>The content of this file specifies the machine identification + <replaceable>MACHINE-ID</replaceable>. If it cannot read <filename>/etc/machine-id</filename>, + kernel-install will use "Linux" as the machine ID instead.</para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <filename>/etc/os-release</filename> + <filename>/usr/lib/os-release</filename> + </term> + <listitem> + <para>The content of the file specifies the operating system title <replaceable>PRETTY_NAME</replaceable>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>depmod</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/less-variables.xml b/man/less-variables.xml new file mode 100644 index 0000000..3b32673 --- /dev/null +++ b/man/less-variables.xml @@ -0,0 +1,124 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry id='pager'> + <term><varname>$SYSTEMD_PAGER</varname></term> + + <listitem><para>Pager to use when <option>--no-pager</option> is not given; overrides + <varname>$PAGER</varname>. If neither <varname>$SYSTEMD_PAGER</varname> nor <varname>$PAGER</varname> are set, a + set of well-known pager implementations are tried in turn, including + <citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry> and + <citerefentry project='man-pages'><refentrytitle>more</refentrytitle><manvolnum>1</manvolnum></citerefentry>, until one is found. If + no pager implementation is discovered no pager is invoked. Setting this environment variable to an empty string + or the value <literal>cat</literal> is equivalent to passing <option>--no-pager</option>.</para></listitem> + </varlistentry> + + <varlistentry id='less'> + <term><varname>$SYSTEMD_LESS</varname></term> + + <listitem><para>Override the options passed to <command>less</command> (by default + <literal>FRSXMK</literal>).</para> + + <para>Users might want to change two options in particular:</para> + + <variablelist> + <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'> + <term><varname>$SYSTEMD_LESSCHARSET</varname></term> + + <listitem><para>Override the charset passed to <command>less</command> (by default <literal>utf-8</literal>, if + the invoking terminal is determined to be UTF-8 compatible).</para></listitem> + </varlistentry> + + <varlistentry id='lesssecure'> + <term><varname>$SYSTEMD_PAGERSECURE</varname></term> + + <listitem><para>Takes a boolean argument. When true, the "secure" mode of the pager is enabled; if + false, disabled. If <varname>$SYSTEMD_PAGERSECURE</varname> is not set at all, secure mode is enabled + if the effective UID is not the same as the owner of the login session, see <citerefentry + project='man-pages'><refentrytitle>geteuid</refentrytitle><manvolnum>2</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_pid_get_owner_uid</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + In secure mode, <option>LESSSECURE=1</option> will be set when invoking the pager, and the pager shall + disable commands that open or create new files or start new subprocesses. When + <varname>$SYSTEMD_PAGERSECURE</varname> is not set at all, pagers which are not known to implement + secure mode will not be used. (Currently only + <citerefentry><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry> implements + secure mode.)</para> + + <para>Note: when commands are invoked with elevated privileges, for example under <citerefentry + project='man-pages'><refentrytitle>sudo</refentrytitle><manvolnum>8</manvolnum></citerefentry> or + <citerefentry + project='die-net'><refentrytitle>pkexec</refentrytitle><manvolnum>1</manvolnum></citerefentry>, care + must be taken to ensure that unintended interactive features are not enabled. "Secure" mode for the + pager may be enabled automatically as describe above. Setting <varname>SYSTEMD_PAGERSECURE=0</varname> + or not removing it from the inherited environment allows the user to invoke arbitrary commands. Note + that if the <varname>$SYSTEMD_PAGER</varname> or <varname>$PAGER</varname> variables are to be + honoured, <varname>$SYSTEMD_PAGERSECURE</varname> must be set too. It might be reasonable to completely + disable the pager using <option>--no-pager</option> instead.</para></listitem> + </varlistentry> + + <varlistentry id='colors'> + <term><varname>$SYSTEMD_COLORS</varname></term> + + <listitem><para>The value must be a boolean. Controls whether colorized output should be + generated. This can be specified to override the decision that <command>systemd</command> makes based + on <varname>$TERM</varname> and what the console is connected to.</para> + </listitem> + </varlistentry> + + <!-- This is not documented on purpose, because it is not clear if $NO_COLOR will become supported + widely enough. So let's provide support, but without advertising this. + <varlistentry id='no-color'> + <term><varname>$NO_COLOR</varname></term> + + <listitem><para>If set (to any value), and <varname>$SYSTEMD_COLORS</varname> is not set, equivalent to + <option>SYSTEMD_COLORS=0</option>. See <ulink url="https://no-color.org/">no-color.org</ulink>.</para> + </listitem> + </varlistentry> + --> + + <varlistentry id='urlify'> + <term><varname>$SYSTEMD_URLIFY</varname></term> + + <listitem><para>The value must be a boolean. Controls whether clickable links should be generated in + the output for terminal emulators supporting this. This can be specified to override the decision that + <command>systemd</command> makes based on <varname>$TERM</varname> and other conditions.</para> + </listitem> + </varlistentry> + + </variablelist> +</refsect1> diff --git a/man/libsystemd-pkgconfig.xml b/man/libsystemd-pkgconfig.xml new file mode 100644 index 0000000..e3b0634 --- /dev/null +++ b/man/libsystemd-pkgconfig.xml @@ -0,0 +1,13 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refsect1> + <title>Notes</title> + + <para id='pkgconfig-text'>These APIs are implemented as a shared + library, which can be compiled and linked to with the + <constant>libsystemd</constant> <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry> + file.</para> +</refsect1> diff --git a/man/libudev.xml b/man/libudev.xml new file mode 100644 index 0000000..4b87962 --- /dev/null +++ b/man/libudev.xml @@ -0,0 +1,96 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="libudev" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>libudev</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>libudev</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>libudev</refname> + <refpurpose>API for enumerating and introspecting local devices</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libudev</command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>libudev.h</filename> provides APIs to introspect + and enumerate devices on the local system.</para> + + <para>All functions require a libudev context to operate. This + context can be create via + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + It is used to track library state and link objects together. No + global state is used by libudev, everything is always linked to + a udev context.</para> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <para>To introspect a local device on a system, a udev device + object can be created via + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and friends. The device object allows one to query current state, + read and write attributes and lookup properties of the device in + question.</para> + + <para>To enumerate local devices on the system, an enumeration + object can be created via + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>To monitor the local system for hotplugged or unplugged + devices, a monitor can be created via + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Whenever libudev returns a list of objects, the + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry> + API should be used to iterate, access and modify those lists.</para> + + <para>Furthermore, libudev also exports legacy APIs that should + not be used by new software (and as such are not documented as + part of this manual). This includes the hardware database known + as <constant>udev_hwdb</constant> (please use the new + <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry> + API instead) and the <constant>udev_queue</constant> object to + query the udev daemon (which should not be used by new software + at all).</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-device</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/loader.conf.xml b/man/loader.conf.xml new file mode 100644 index 0000000..29315ce --- /dev/null +++ b/man/loader.conf.xml @@ -0,0 +1,203 @@ +<?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-or-later --> + +<refentry id="loader.conf" conditional='ENABLE_EFI' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>loader.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>loader.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>loader.conf</refname> + <refpurpose>Configuration file for systemd-boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>ESP</replaceable>/loader/loader.conf</filename>, + <filename><replaceable>ESP</replaceable>/loader/entries/*.conf</filename> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para> + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> + will read <filename><replaceable>ESP</replaceable>/loader/loader.conf</filename> and any files with the + <literal>.conf</literal> extension under + <filename><replaceable>ESP</replaceable>/loader/entries/</filename> on the EFI system partition (ESP). + </para> + + <para>Each configuration file must consist of an option name, followed by + whitespace, and the option value. <literal>#</literal> may be used to start + a comment line. Empty and comment lines are ignored.</para> + + <para>Boolean arguments may be written as + <literal>yes</literal>/<literal>y</literal>/<literal>true</literal>/<literal>1</literal> or + <literal>no</literal>/<literal>n</literal>/<literal>false</literal>/<literal>0</literal>. + </para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following configuration options in <filename>loader.conf</filename> are understood:</para> + + <variablelist> + <varlistentry> + <term>default</term> + + <listitem><para>A glob pattern to select the default entry. The default entry + may be changed in the boot menu itself, in which case the name of the + selected entry will be stored as an EFI variable, overriding this option. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>timeout</term> + + <listitem><para>How long the boot menu should be shown before the default + entry is booted, in seconds. This may be changed in the boot menu itself and + will be stored as an EFI variable in that case, overriding this option. + </para> + + <para>If the timeout is disabled, the default entry will be booted + immediately. The menu can be shown by pressing and holding a key before + systemd-boot is launched.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>console-mode</term> + + <listitem><para>This option configures the resolution of the console. Takes a + number or one of the special values listed below. The following values may be + used:</para> + + <variablelist> + <varlistentry> + <term>0</term> + <listitem> + <para>Standard UEFI 80x25 mode</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>1</term> + <listitem> + <para>80x50 mode, not supported by all devices</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>2</term> + <listitem> + <para>the first non-standard mode provided by the device + firmware, if any</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>auto</term> + <listitem> + <para>Pick a suitable mode automatically using heuristics</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>max</term> + <listitem> + <para>Pick the highest-numbered available mode</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>keep</term> + <listitem> + <para>Keep the mode selected by firmware (the default)</para> + </listitem> + </varlistentry> + </variablelist> + + </listitem> + </varlistentry> + + <varlistentry> + <term>editor</term> + + <listitem><para>Takes a boolean argument. Enable (the default) or disable the + editor. The editor should be disabled if the machine can be accessed by + unauthorized persons.</para></listitem> + </varlistentry> + + <varlistentry> + <term>auto-entries</term> + + <listitem><para>Takes a boolean argument. Enable (the default) or disable + entries for other boot entries found on the boot partition. In particular, + this may be useful when loader entries are created to show replacement + descriptions for those entries.</para></listitem> + </varlistentry> + + <varlistentry> + <term>auto-firmware</term> + + <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. Use <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> + + <refsect1> + <title>Example</title> + + <programlisting># /boot/efi/loader/loader.conf +timeout 0 +default 01234567890abcdef1234567890abdf0-* +editor no + </programlisting> + + <para>The menu will not be shown by default (the menu can still be shown by + pressing and holding a key during boot). One of the entries with files with a + name starting with <literal>01234567890abcdef1234567890abdf0-</literal> will be + selected by default. If more than one entry matches, the one with the highest + priority will be selected (generally the one with the highest version number). + The editor will be disabled, so it is not possible to alter the kernel command + line.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/locale.conf.xml b/man/locale.conf.xml new file mode 100644 index 0000000..b24ad9c --- /dev/null +++ b/man/locale.conf.xml @@ -0,0 +1,127 @@ +<?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-or-later --> + +<refentry id="locale.conf"> + <refentryinfo> + <title>locale.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>locale.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>locale.conf</refname> + <refpurpose>Configuration file for locale settings</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/locale.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/locale.conf</filename> file configures + system-wide locale settings. It is read at early boot by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + + <para>The basic file format of <filename>locale.conf</filename> is + a newline-separated list of environment-like shell-compatible + variable assignments. It is possible to source the configuration + from shell scripts, however, beyond mere variable assignments, no + shell features are supported, allowing applications to read the + file without implementing a shell compatible execution + engine.</para> + + <para>Note that the kernel command line options + <varname>locale.LANG=</varname>, + <varname>locale.LANGUAGE=</varname>, + <varname>locale.LC_CTYPE=</varname>, + <varname>locale.LC_NUMERIC=</varname>, + <varname>locale.LC_TIME=</varname>, + <varname>locale.LC_COLLATE=</varname>, + <varname>locale.LC_MONETARY=</varname>, + <varname>locale.LC_MESSAGES=</varname>, + <varname>locale.LC_PAPER=</varname>, + <varname>locale.LC_NAME=</varname>, + <varname>locale.LC_ADDRESS=</varname>, + <varname>locale.LC_TELEPHONE=</varname>, + <varname>locale.LC_MEASUREMENT=</varname>, + <varname>locale.LC_IDENTIFICATION=</varname> may be + used to override the locale settings at boot.</para> + + <para>The locale settings configured in + <filename>/etc/locale.conf</filename> are system-wide and are + inherited by every service or user, unless overridden or unset by + individual programs or individual users.</para> + + <para>Depending on the operating system, other configuration files + might be checked for locale configuration as well, however only as + fallback.</para> + + <para><filename>/etc/locale.conf</filename> is usually created and updated + using + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be used to alter the settings in this file during runtime from + the command line. Use + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to initialize them on mounted (but not booted) system images.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following locale settings may be set using + <filename>/etc/locale.conf</filename>: + <varname>LANG=</varname>, + <varname>LANGUAGE=</varname>, + <varname>LC_CTYPE=</varname>, + <varname>LC_NUMERIC=</varname>, + <varname>LC_TIME=</varname>, + <varname>LC_COLLATE=</varname>, + <varname>LC_MONETARY=</varname>, + <varname>LC_MESSAGES=</varname>, + <varname>LC_PAPER=</varname>, + <varname>LC_NAME=</varname>, + <varname>LC_ADDRESS=</varname>, + <varname>LC_TELEPHONE=</varname>, + <varname>LC_MEASUREMENT=</varname>, + <varname>LC_IDENTIFICATION=</varname>. + Note that <varname>LC_ALL</varname> may not be configured in this + file. For details about the meaning and semantics of these + settings, refer to + <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <example> + <title>German locale with English messages</title> + + <para><filename>/etc/locale.conf</filename>:</para> + + <programlisting>LANG=de_DE.UTF-8 +LC_MESSAGES=en_US.UTF-8</programlisting> + </example> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/localectl.xml b/man/localectl.xml new file mode 100644 index 0000000..7f7e577 --- /dev/null +++ b/man/localectl.xml @@ -0,0 +1,209 @@ +<?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-or-later --> + +<refentry id="localectl" conditional='ENABLE_LOCALED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>localectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>localectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>localectl</refname> + <refpurpose>Control the system locale and keyboard layout settings</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>localectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>localectl</command> may be used to query and change + the system locale and keyboard layout settings. It communicates with + <citerefentry><refentrytitle>systemd-localed</refentrytitle><manvolnum>8</manvolnum></citerefentry> + to modify files such as <filename>/etc/locale.conf</filename> and + <filename>/etc/vconsole.conf</filename>.</para> + + <para>The system locale controls the language settings of system + services and of the UI before the user logs in, such as the + display manager, as well as the default for users after + login.</para> + + <para>The keyboard settings control the keyboard layout used on + the text console and of the graphical UI before the user logs in, + such as the display manager, as well as the default for users + after login.</para> + + <para>Note that the changes performed using this tool might require + the initramfs to be rebuilt to take effect during early system boot. + The initramfs is not rebuilt automatically by <filename>localectl</filename>. + </para> + + <para>Note that + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be used to initialize the system locale for mounted (but not booted) + system images.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>status</command></term> + + <listitem><para>Show current settings of the system locale and keyboard mapping. + If no command is specified, this is the implied default.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-locale LOCALE</command></term> + <term><command>set-locale VARIABLE=LOCALE…</command></term> + + <listitem><para>Set the system locale. This takes one locale such as <literal>en_US.UTF-8</literal>, or takes one or more + locale assignments such as <literal>LANG=de_DE.utf8</literal>, <literal>LC_MESSAGES=en_GB.utf8</literal>, and so on. If + one locale without variable name is provided, then <literal>LANG=</literal> locale variable will be set. See + <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details on the available settings and their meanings. Use + <command>list-locales</command> for a list of available + locales (see below). </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>list-locales</command></term> + + <listitem><para>List available locales useful for + configuration with + <command>set-locale</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-keymap MAP [TOGGLEMAP]</command></term> + + <listitem><para>Set the system keyboard mapping for the + console and X11. This takes a mapping name (such as "de" or + "us"), and possibly a second one to define a toggle keyboard + mapping. Unless <option>--no-convert</option> is passed, the + selected setting is also applied as the default system + keyboard mapping of X11, after converting it to the closest + matching X11 keyboard mapping. Use + <command>list-keymaps</command> for a list of available + keyboard mappings (see below).</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>list-keymaps</command></term> + + <listitem><para>List available keyboard mappings for the + console, useful for configuration with + <command>set-keymap</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]]</command></term> + + <listitem><para>Set the system default keyboard mapping for + X11 and the virtual console. This takes a keyboard mapping + name (such as <literal>de</literal> or <literal>us</literal>), + and possibly a model, variant, and options, see + <citerefentry><refentrytitle>kbd</refentrytitle><manvolnum>4</manvolnum></citerefentry> + for details. Unless <option>--no-convert</option> is passed, + the selected setting is also applied as the system console + keyboard mapping, after converting it to the closest matching + console keyboard mapping.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>list-x11-keymap-models</command></term> + <term><command>list-x11-keymap-layouts</command></term> + <term><command>list-x11-keymap-variants [LAYOUT]</command></term> + <term><command>list-x11-keymap-options</command></term> + + <listitem><para>List available X11 keymap models, layouts, + variants and options, useful for configuration with + <command>set-keymap</command>. The command + <command>list-x11-keymap-variants</command> optionally takes a + layout parameter to limit the output to the variants suitable + for the specific layout.</para></listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--no-ask-password</option></term> + + <listitem><para>Do not query the user for authentication for + privileged operations.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-convert</option></term> + + <listitem><para>If <command>set-keymap</command> or + <command>set-x11-keymap</command> is invoked and this option + is passed, then the keymap will not be converted from the + console to X11, or X11 to console, + respectively.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kbd</refentrytitle><manvolnum>4</manvolnum></citerefentry>, + <ulink url="http://www.x.org/releases/current/doc/xorg-docs/input/XKB-Config.html"> + The XKB Configuration Guide + </ulink>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>mkinitrd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/localtime.xml b/man/localtime.xml new file mode 100644 index 0000000..e486474 --- /dev/null +++ b/man/localtime.xml @@ -0,0 +1,72 @@ +<?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-or-later --> + +<refentry id="localtime"> + <refentryinfo> + <title>localtime</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>localtime</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>localtime</refname> + <refpurpose>Local timezone configuration file</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/localtime</filename> -> <filename>../usr/share/zoneinfo/…</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/localtime</filename> file configures the + system-wide timezone of the local system that is used by + applications for presentation to the user. It should be an + absolute or relative symbolic link pointing to + <filename>/usr/share/zoneinfo/</filename>, followed by a timezone + identifier such as <literal>Europe/Berlin</literal> or + <literal>Etc/UTC</literal>. The resulting link should lead to the + corresponding binary + <citerefentry project='man-pages'><refentrytitle>tzfile</refentrytitle><manvolnum>5</manvolnum></citerefentry> + timezone data for the configured timezone.</para> + + <para>Because the timezone identifier is extracted from the + symlink target name of <filename>/etc/localtime</filename>, this + file may not be a normal file or hardlink.</para> + + <para>If <filename>/etc/localtime</filename> is missing, the + default <literal>UTC</literal> timezone is used.</para> + + <para>The timezone may be overridden for individual programs by + using the <varname>$TZ</varname> environment variable. See + <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>You may use + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to change the settings of this file from the command line during + runtime. Use + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to initialize the time zone on mounted (but not booted) system + images.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>tzset</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/loginctl.xml b/man/loginctl.xml new file mode 100644 index 0000000..d3745ce --- /dev/null +++ b/man/loginctl.xml @@ -0,0 +1,429 @@ +<?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-or-later --> + +<refentry id="loginctl" conditional='ENABLE_LOGIND' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>loginctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>loginctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>loginctl</refname> + <refpurpose>Control the systemd login manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>loginctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>loginctl</command> may be used to introspect and + control the state of the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + login manager + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <refsect2><title>Session Commands</title><variablelist> + + <varlistentry> + <term><command>list-sessions</command></term> + + <listitem><para>List current sessions.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>session-status</command> <optional><replaceable>ID</replaceable>…</optional></term> + + <listitem><para>Show terse runtime status information about + one or more sessions, followed by the most recent log data + from the journal. Takes one or more session identifiers as + parameters. If no session identifiers are passed, the status of + the caller's session is shown. This function is intended to + generate human-readable output. If you are looking for + computer-parsable output, use <command>show-session</command> + instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>show-session</command> <optional><replaceable>ID</replaceable>…</optional></term> + + <listitem><para>Show properties of one or more sessions or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a session ID is specified, + properties of the session are shown. By default, empty + properties are suppressed. Use <option>--all</option> to show + those too. To select specific properties to show, use + <option>--property=</option>. This command is intended to be + used whenever computer-parsable output is required. Use + <command>session-status</command> if you are looking for + formatted human-readable output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>activate</command> <optional><replaceable>ID</replaceable></optional></term> + + <listitem><para>Activate a session. This brings a session into + the foreground if another session is currently in the + foreground on the respective seat. Takes a session identifier + as argument. If no argument is specified, the session of the + caller is put into foreground.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>lock-session</command> <optional><replaceable>ID</replaceable>…</optional></term> + <term><command>unlock-session</command> <optional><replaceable>ID</replaceable>…</optional></term> + + <listitem><para>Activates/deactivates the screen lock on one + or more sessions, if the session supports it. Takes one or + more session identifiers as arguments. If no argument is + specified, the session of the caller is locked/unlocked. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>lock-sessions</command></term> + <term><command>unlock-sessions</command></term> + + <listitem><para>Activates/deactivates the screen lock on all + current sessions supporting it. </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>terminate-session</command> <replaceable>ID</replaceable>…</term> + + <listitem><para>Terminates a session. This kills all processes + of the session and deallocates all resources attached to the + session. </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>kill-session</command> <replaceable>ID</replaceable>…</term> + + <listitem><para>Send a signal to one or more processes of the + session. Use <option>--kill-who=</option> to select which + process to kill. Use <option>--signal=</option> to select the + signal to send.</para></listitem> + </varlistentry> + </variablelist></refsect2> + + <refsect2><title>User Commands</title><variablelist> + <varlistentry> + <term><command>list-users</command></term> + + <listitem><para>List currently logged in users. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>user-status</command> <optional><replaceable>USER</replaceable>…</optional></term> + + <listitem><para>Show terse runtime status information about + one or more logged in users, followed by the most recent log + data from the journal. Takes one or more user names or numeric + user IDs as parameters. If no parameters are passed, the status + is shown for the user of the session of the caller. This + function is intended to generate human-readable output. If you + are looking for computer-parsable output, use + <command>show-user</command> instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>show-user</command> <optional><replaceable>USER</replaceable>…</optional></term> + + <listitem><para>Show properties of one or more users or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a user is specified, properties of + the user are shown. By default, empty properties are + suppressed. Use <option>--all</option> to show those too. To + select specific properties to show, use + <option>--property=</option>. This command is intended to be + used whenever computer-parsable output is required. Use + <command>user-status</command> if you are looking for + formatted human-readable output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>enable-linger</command> <optional><replaceable>USER</replaceable>…</optional></term> + <term><command>disable-linger</command> <optional><replaceable>USER</replaceable>…</optional></term> + + <listitem><para>Enable/disable user lingering for one or more + users. If enabled for a specific user, a user manager is + spawned for the user at boot and kept around after logouts. + This allows users who are not logged in to run long-running + services. Takes one or more user names or numeric UIDs as + argument. If no argument is specified, enables/disables + lingering for the user of the session of the caller.</para> + + <para>See also <varname>KillUserProcesses=</varname> setting in + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>terminate-user</command> <replaceable>USER</replaceable>…</term> + + <listitem><para>Terminates all sessions of a user. This kills + all processes of all sessions of the user and deallocates all + runtime resources attached to the user.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>kill-user</command> <replaceable>USER</replaceable>…</term> + + <listitem><para>Send a signal to all processes of a user. Use + <option>--signal=</option> to select the signal to send. + </para></listitem> + </varlistentry> + </variablelist></refsect2> + + <refsect2><title>Seat Commands</title><variablelist> + <varlistentry> + <term><command>list-seats</command></term> + + <listitem><para>List currently available seats on the local + system.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>seat-status</command> <optional><replaceable>NAME</replaceable>…</optional></term> + + <listitem><para>Show terse runtime status information about + one or more seats. Takes one or more seat names as parameters. + If no seat names are passed the status of the caller's + session's seat is shown. This function is intended to generate + human-readable output. If you are looking for + computer-parsable output, use <command>show-seat</command> + instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>show-seat</command> <optional><replaceable>NAME</replaceable>…</optional></term> + + <listitem><para>Show properties of one or more seats or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a seat is specified, properties of + the seat are shown. By default, empty properties are + suppressed. Use <option>--all</option> to show those too. To + select specific properties to show, use + <option>--property=</option>. This command is intended to be + used whenever computer-parsable output is required. Use + <command>seat-status</command> if you are looking for + formatted human-readable output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>attach</command> <replaceable>NAME</replaceable> <replaceable>DEVICE</replaceable>…</term> + + <listitem><para>Persistently attach one or more devices to a + seat. The devices should be specified via device paths in the + <filename>/sys/</filename> file system. To create a new seat, + attach at least one graphics card to a previously unused seat + name. Seat names may consist only of a–z, A–Z, 0–9, + <literal>-</literal> and <literal>_</literal> and must be + prefixed with <literal>seat</literal>. To drop assignment of a + device to a specific seat, just reassign it to a different + seat, or use <command>flush-devices</command>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>flush-devices</command></term> + + <listitem><para>Removes all device assignments previously + created with <command>attach</command>. After this call, only + automatically generated seats will remain, and all seat + hardware is assigned to them.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>terminate-seat</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Terminates all sessions on a seat. This kills + all processes of all sessions on the seat and deallocates all + runtime resources attached to them.</para></listitem> + </varlistentry> + </variablelist></refsect2> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--no-ask-password</option></term> + + <listitem><para>Do not query the user for authentication for + privileged operations.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--property=</option></term> + + <listitem><para>When showing session/user/seat properties, + limit display to certain properties as specified as argument. + If not specified, all set properties are shown. The argument + should be a property name, such as + <literal>Sessions</literal>. If specified more than once, all + properties with the specified names are + shown.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--value</option></term> + + <listitem><para>When showing session/user/seat properties, + only print the value, and skip the property name and + <literal>=</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-a</option></term> + <term><option>--all</option></term> + + <listitem><para>When showing session/user/seat properties, + show all properties regardless of whether they are set or + not.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem><para>Do not ellipsize process tree entries.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--kill-who=</option></term> + + <listitem><para>When used with + <command>kill-session</command>, choose which processes to + kill. Must be one of <option>leader</option>, or + <option>all</option> to select whether to kill only the leader + process of the session or all processes of the session. If + omitted, defaults to <option>all</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-s</option></term> + <term><option>--signal=</option></term> + + <listitem><para>When used with <command>kill-session</command> + or <command>kill-user</command>, choose which signal to send + to selected processes. Must be one of the well known signal + specifiers, such as <constant>SIGTERM</constant>, + <constant>SIGINT</constant> or <constant>SIGSTOP</constant>. + If omitted, defaults to + <constant>SIGTERM</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--lines=</option></term> + + <listitem><para>When used with <command>user-status</command> + and <command>session-status</command>, controls the number of + journal lines to show, counting from the most recent ones. + Takes a positive integer argument. Defaults to 10.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-o</option></term> + <term><option>--output=</option></term> + + <listitem><para>When used with <command>user-status</command> + and <command>session-status</command>, controls the formatting + of the journal entries that are shown. For the available + choices, see + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + Defaults to <literal>short</literal>.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Querying user status</title> + + <programlisting>$ loginctl user-status +fatima (1005) + Since: Sat 2016-04-09 14:23:31 EDT; 54min ago + State: active + Sessions: 5 *3 + Unit: user-1005.slice + ├─user@1005.service + … + ├─session-3.scope + … + └─session-5.scope + ├─3473 login -- fatima + └─3515 -zsh + +Apr 09 14:40:30 laptop login[2325]: pam_unix(login:session): + session opened for user fatima by LOGIN(uid=0) +Apr 09 14:40:30 laptop login[2325]: LOGIN ON tty3 BY fatima +</programlisting> + + <para>There are two sessions, 3 and 5. Session 3 is a graphical session, + marked with a star. The tree of processing including the two corresponding + scope units and the user manager unit are shown.</para> + </example> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/logind.conf.xml b/man/logind.conf.xml new file mode 100644 index 0000000..be62b6b --- /dev/null +++ b/man/logind.conf.xml @@ -0,0 +1,365 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="logind.conf" conditional='ENABLE_LOGIND' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>logind.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>logind.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>logind.conf</refname> + <refname>logind.conf.d</refname> + <refpurpose>Login manager configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/logind.conf</filename></para> + <para><filename>/etc/systemd/logind.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/logind.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/logind.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These files configure various parameters of the systemd login manager, + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the + [Login] section:</para> + + <variablelist class='config-directives'> + + <varlistentry> + <term><varname>NAutoVTs=</varname></term> + + <listitem><para>Takes a positive integer. Configures how many + virtual terminals (VTs) to allocate by default that, when + switched to and are previously unused, + <literal>autovt</literal> services are automatically spawned + on. These services are instantiated from the template unit + <filename>autovt@.service</filename> for the respective VT TTY + name, for example, <filename>autovt@tty4.service</filename>. + By default, <filename>autovt@.service</filename> is linked to + <filename>getty@.service</filename>. In other words, login + prompts are started dynamically as the user switches to unused + virtual terminals. Hence, this parameter controls how many + login <literal>gettys</literal> are available on the VTs. If a + VT is already used by some other subsystem (for example, a + graphical login), this kind of activation will not be + attempted. Note that the VT configured in + <varname>ReserveVT=</varname> is always subject to this kind + of activation, even if it is not one of the VTs configured + with the <varname>NAutoVTs=</varname> directive. Defaults to + 6. When set to 0, automatic spawning of + <literal>autovt</literal> services is + disabled.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReserveVT=</varname></term> + + <listitem><para>Takes a positive integer. Identifies one + virtual terminal that shall unconditionally be reserved for + <filename>autovt@.service</filename> activation (see above). + The VT selected with this option will be marked busy + unconditionally, so that no other subsystem will allocate it. + This functionality is useful to ensure that, regardless of how + many VTs are allocated by other subsystems, one login + <literal>getty</literal> is always available. Defaults to 6 + (in other words, there will always be a + <literal>getty</literal> available on Alt-F6.). When set to 0, + VT reservation is disabled.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>KillUserProcesses=</varname></term> + + <listitem><para>Takes a boolean argument. Configures whether the processes of a + user should be killed when the user logs out. If true, the scope unit + corresponding to the session and all processes inside that scope will be + terminated. If false, the scope is "abandoned", see + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + and processes are not killed. Defaults to <literal>&KILL_USER_PROCESSES;</literal>, + but see the options <varname>KillOnlyUsers=</varname> and + <varname>KillExcludeUsers=</varname> below.</para> + + <para>In addition to session processes, user process may run under the user + manager unit <filename>user@.service</filename>. Depending on the linger + settings, this may allow users to run processes independent of their login + sessions. See the description of <command>enable-linger</command> in + <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + + <para>Note that setting <varname>KillUserProcesses=yes</varname> + will break tools like + <citerefentry project='die-net'><refentrytitle>screen</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and + <citerefentry project='die-net'><refentrytitle>tmux</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + unless they are moved out of the session scope. See example in + <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>KillOnlyUsers=</varname></term> + <term><varname>KillExcludeUsers=</varname></term> + + <listitem><para>These settings take space-separated lists of usernames that override the + <varname>KillUserProcesses=</varname> setting. A user name may be added to + <varname>KillExcludeUsers=</varname> to exclude the processes in the session scopes of that user from + being killed even if <varname>KillUserProcesses=yes</varname> is set. If + <varname>KillExcludeUsers=</varname> is not set, the <literal>root</literal> user is excluded by + default. <varname>KillExcludeUsers=</varname> may be set to an empty value to override this + default. If a user is not excluded, <varname>KillOnlyUsers=</varname> is checked next. If this + setting is specified, only the processes in the session scopes of those users will be + killed. Otherwise, users are subject to the <varname>KillUserProcesses=yes</varname> setting. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>IdleAction=</varname></term> + + <listitem><para>Configures the action to take when the system + is idle. Takes one of + <literal>ignore</literal>, + <literal>poweroff</literal>, + <literal>reboot</literal>, + <literal>halt</literal>, + <literal>kexec</literal>, + <literal>suspend</literal>, + <literal>hibernate</literal>, + <literal>hybrid-sleep</literal>, + <literal>suspend-then-hibernate</literal>, and + <literal>lock</literal>. + Defaults to <literal>ignore</literal>.</para> + + <para>Note that this requires that user sessions correctly + report the idle status to the system. The system will execute + the action after all sessions report that they are idle, no + idle inhibitor lock is active, and subsequently, the time + configured with <varname>IdleActionSec=</varname> (see below) + has expired.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IdleActionSec=</varname></term> + + <listitem><para>Configures the delay after which the action + configured in <varname>IdleAction=</varname> (see above) is + taken after the system is idle.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>InhibitDelayMaxSec=</varname></term> + + <listitem><para>Specifies the maximum time a system shutdown + or sleep request is delayed due to an inhibitor lock of type + <literal>delay</literal> being active before the inhibitor is + ignored and the operation executes anyway. Defaults to + 5.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>UserStopDelaySec=</varname></term> + + <listitem><para>Specifies how long to keep the user record and per-user service + <filename>user@.service</filename> around for a user after they logged out fully. If set to zero, the per-user + service is terminated immediately when the last session of the user has ended. If this option is configured to + non-zero rapid logout/login cycles are sped up, as the user's service manager is not constantly restarted. If + set to <literal>infinity</literal> the per-user service for a user is never terminated again after first login, + and continues to run until system shutdown. Defaults to 10s.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>HandlePowerKey=</varname></term> + <term><varname>HandleSuspendKey=</varname></term> + <term><varname>HandleHibernateKey=</varname></term> + <term><varname>HandleLidSwitch=</varname></term> + <term><varname>HandleLidSwitchExternalPower=</varname></term> + <term><varname>HandleLidSwitchDocked=</varname></term> + <term><varname>HandleRebootKey=</varname></term> + + <listitem><para>Controls how logind shall handle the + system power, reboot and sleep keys and the lid switch to trigger + actions such as system power-off, reboot or suspend. Can be one of + <literal>ignore</literal>, + <literal>poweroff</literal>, + <literal>reboot</literal>, + <literal>halt</literal>, + <literal>kexec</literal>, + <literal>suspend</literal>, + <literal>hibernate</literal>, + <literal>hybrid-sleep</literal>, + <literal>suspend-then-hibernate</literal>, and + <literal>lock</literal>. + If <literal>ignore</literal>, logind will never handle these + keys. If <literal>lock</literal>, all running sessions will be + screen-locked; otherwise, the specified action will be taken + in the respective event. Only input devices with the + <literal>power-switch</literal> udev tag will be watched for + key/lid switch events. <varname>HandlePowerKey=</varname> + defaults to <literal>poweroff</literal>, <varname>HandleRebootKey=</varname> + defaults to <literal>reboot</literal>. + <varname>HandleSuspendKey=</varname> and + <varname>HandleLidSwitch=</varname> default to + <literal>suspend</literal>. + <varname>HandleLidSwitchExternalPower=</varname> is completely + ignored by default (for backwards compatibility) — an explicit + value must be set before it will be used to determine + behaviour. <varname>HandleLidSwitchDocked=</varname> defaults + to <literal>ignore</literal>. + <varname>HandleHibernateKey=</varname> defaults to + <literal>hibernate</literal>. If the system is inserted in a + docking station, or if more than one display is connected, the + action specified by <varname>HandleLidSwitchDocked=</varname> + occurs; if the system is on external power the action (if any) + specified by <varname>HandleLidSwitchExternalPower=</varname> + occurs; otherwise the <varname>HandleLidSwitch=</varname> + action occurs.</para> + + <para>A different application may disable logind's handling of system power and + sleep keys and the lid switch by taking a low-level inhibitor lock + (<literal>handle-power-key</literal>, <literal>handle-suspend-key</literal>, + <literal>handle-hibernate-key</literal>, <literal>handle-lid-switch</literal>, + <literal>handle-reboot-switch</literal>). + This is most commonly used by graphical desktop environments + to take over suspend and hibernation handling, and to use their own configuration + mechanisms. If a low-level inhibitor lock is taken, logind will not take any + action when that key or switch is triggered and the <varname>Handle*=</varname> + settings are irrelevant.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PowerKeyIgnoreInhibited=</varname></term> + <term><varname>SuspendKeyIgnoreInhibited=</varname></term> + <term><varname>HibernateKeyIgnoreInhibited=</varname></term> + <term><varname>LidSwitchIgnoreInhibited=</varname></term> + <term><varname>RebootKeyIgnoreInhibited=</varname></term> + + <listitem><para>Controls whether actions that <command>systemd-logind</command> + takes when the power, reboot and sleep keys and the lid switch are triggered are subject + to high-level inhibitor locks ("shutdown", "reboot", "sleep", "idle"). Low level inhibitor + locks (<literal>handle-power-key</literal>, <literal>handle-suspend-key</literal>, + <literal>handle-hibernate-key</literal>, <literal>handle-lid-switch</literal>, + <literal>handle-reboot-key</literal>), + are always honored, irrespective of this setting.</para> + + <para>These settings take boolean arguments. If <literal>no</literal>, the + inhibitor locks taken by applications are respected. If <literal>yes</literal>, + "shutdown", "reboot" "sleep", and "idle" inhibitor locks are ignored. + <varname>PowerKeyIgnoreInhibited=</varname>, + <varname>SuspendKeyIgnoreInhibited=</varname>, + <varname>HibernateKeyIgnoreInhibited=</varname> and + <varname>RebootKeyIgnoreInhibited=</varname> default to <literal>no</literal>. + <varname>LidSwitchIgnoreInhibited=</varname> defaults to <literal>yes</literal>. + This means that when <command>systemd-logind</command> is handling events by + itself (no low level inhibitor locks are taken by another application), the lid + switch does not respect suspend blockers by default, but the power and sleep keys + do.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>HoldoffTimeoutSec=</varname></term> + + <listitem><para>Specifies a period of time after system startup or + system resume in which systemd will hold off on reacting to + lid events. This is required for the system to properly + detect any hotplugged devices so systemd can ignore lid events + if external monitors, or docks, are connected. If set to 0, + systemd will always react immediately, possibly before the + kernel fully probed all hotplugged devices. This is safe, as + long as you do not care for systemd to account for devices + that have been plugged or unplugged while the system was off. + Defaults to 30s.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RuntimeDirectorySize=</varname></term> + + <listitem><para>Sets the size limit on the + <varname>$XDG_RUNTIME_DIR</varname> runtime directory for each + user who logs in. Takes a size in bytes, optionally suffixed + with the usual K, G, M, and T suffixes, to the base 1024 + (IEC). Alternatively, a numerical percentage suffixed by + <literal>%</literal> may be specified, which sets the size + limit relative to the amount of physical RAM. Defaults to 10%. + Note that this size is a safety limit only. As each runtime + directory is a tmpfs file system, it will only consume as much + memory as is needed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RuntimeDirectoryInodesMax=</varname></term> + + <listitem><para>Sets the limit on number of inodes for the + <varname>$XDG_RUNTIME_DIR</varname> runtime directory for each + user who logs in. Takes a number, optionally suffixed with the + usual K, G, M, and T suffixes, to the base 1024 (IEC). + Defaults to <varname>RuntimeDirectorySize=</varname> divided + by 4096. Note that this size is a safety limit only. + As each runtime directory is a tmpfs file system, it will + only consume as much memory as is needed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>InhibitorsMax=</varname></term> + + <listitem><para>Controls the maximum number of concurrent inhibitors to permit. Defaults to 8192 + (8K).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SessionsMax=</varname></term> + + <listitem><para>Controls the maximum number of concurrent user sessions to manage. Defaults to 8192 + (8K). Depending on how the <filename>pam_systemd.so</filename> module is included in the PAM stack + configuration, further login sessions will either be refused, or permitted but not tracked by + <filename>systemd-logind</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemoveIPC=</varname></term> + + <listitem><para>Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the + user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the + last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as + well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users + are excluded from the effect of this setting. Defaults to <literal>yes</literal>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/machine-id.xml b/man/machine-id.xml new file mode 100644 index 0000000..f61634f --- /dev/null +++ b/man/machine-id.xml @@ -0,0 +1,198 @@ +<?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-or-later --> + +<refentry id="machine-id"> + <refentryinfo> + <title>machine-id</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>machine-id</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>machine-id</refname> + <refpurpose>Local machine ID configuration file</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/machine-id</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/machine-id</filename> file contains the unique machine ID of + the local system that is set during installation or boot. The machine ID is a single + newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from + hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all + zeros.</para> + + <para>The machine ID is usually generated from a random source during system + installation or first boot and stays constant for all subsequent boots. Optionally, + for stateless systems, it is generated during runtime during early boot if necessary. + </para> + + <para>The machine ID may be set, for example when network booting, with the + <varname>systemd.machine_id=</varname> kernel command line parameter or by passing the + option <option>--machine-id=</option> to systemd. An ID specified in this manner + has higher priority and will be used instead of the ID stored in + <filename>/etc/machine-id</filename>.</para> + + <para>The machine ID does not change based on local or network configuration or when + hardware is replaced. Due to this and its greater length, it is a more useful + replacement for the + <citerefentry project='man-pages'><refentrytitle>gethostid</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call that POSIX specifies.</para> + + <para>This machine ID adheres to the same format and logic as the + D-Bus machine ID.</para> + + <para>This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in + untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is + needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID + should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the + ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve + the original machine ID from the application-specific one. The + <citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry> + API provides an implementation of such an algorithm.</para> + </refsect1> + + <refsect1> + <title>Initialization</title> + + <para>Each machine should have a non-empty ID in normal operation. The ID of each + machine should be unique. To achieve those objectives, + <filename>/etc/machine-id</filename> can be initialized in a few different ways. + </para> + + <para>For normal operating system installations, where a custom image is created for a + specific machine, <filename>/etc/machine-id</filename> should be populated during + installation.</para> + + <para> + <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be used by installer tools to initialize the machine ID at install time, but + <filename>/etc/machine-id</filename> may also be written using any other means. + </para> + + <para>For operating system images which are created once and used on multiple + machines, for example for containers or in the cloud, + <filename>/etc/machine-id</filename> should be either missing or an empty file in the generic file + system image (the difference between the two options is described under "First Boot Semantics" below). An + ID will be generated during boot and saved to this file if possible. Having an empty file in place is + useful because it allows a temporary file to be bind-mounted over the real file, in case the image is + used read-only.</para> + + <para><citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be used to initialize <filename>/etc/machine-id</filename> on mounted (but not + booted) system images.</para> + + <para>When a machine is booted with + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + the ID of the machine will be established. If <varname>systemd.machine_id=</varname> + or <option>--machine-id=</option> options (see first section) are specified, this + value will be used. Otherwise, the value in <filename>/etc/machine-id</filename> will + 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> 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> + will attempt to save it to <filename>/etc/machine-id</filename>. If this fails, it + will attempt to bind-mount a temporary file over <filename>/etc/machine-id</filename>. + It is an error if the file system is read-only and does not contain a (possibly empty) + <filename>/etc/machine-id</filename> file.</para> + + <para><citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + will attempt to write the machine ID to the file system if + <filename>/etc/machine-id</filename> or <filename>/etc/</filename> are read-only during + early boot but become writable later on.</para> + </refsect1> + + <refsect1> + <title>First Boot Semantics</title> + + <para><filename>/etc/machine-id</filename> is used to decide whether a boot is the first one. The rules + are as follows:</para> + + <orderedlist> + <listitem><para>If <filename>/etc/machine-id</filename> does not exist, this is a first boot. During + early boot, <command>systemd</command> will write <literal>uninitialized\n</literal> to this file and overmount + a temporary file which contains the actual machine ID. Later (after <filename>first-boot-complete.target</filename> + has been reached), the real machine ID will be written to disk.</para></listitem> + + <listitem><para>If <filename>/etc/machine-id</filename> contains the string <literal>uninitialized</literal>, + a boot is also considered the first boot. The same mechanism as above applies.</para></listitem> + + <listitem><para>If <filename>/etc/machine-id</filename> exists and is empty, a boot is + <emphasis>not</emphasis> considered the first boot. <command>systemd</command> will still bind-mount a file + containing the actual machine-id over it and later try to commit it to disk (if <filename>/etc/</filename> is + writable).</para></listitem> + + <listitem><para>If <filename>/etc/machine-id</filename> already contains a valid machine-id, this is + not a first boot.</para></listitem> + </orderedlist> + + <para>If by any of the above rules, a first boot is detected, units with <varname>ConditionFirstBoot=yes</varname> + will be run.</para> + </refsect1> + + <refsect1> + <title>Relation to OSF UUIDs</title> + + <para>Note that the machine ID historically is not an OSF UUID as + defined by <ulink url="https://tools.ietf.org/html/rfc4122">RFC + 4122</ulink>, nor a Microsoft GUID; however, starting with systemd + v30, newly generated machine IDs do qualify as v4 UUIDs.</para> + + <para>In order to maintain compatibility with existing + installations, an application requiring a UUID should decode the + machine ID, and then apply the following operations to turn it + into a valid OSF v4 UUID. With <literal>id</literal> being an + unsigned character array:</para> + + <programlisting>/* Set UUID version to 4 --- truly random generation */ +id[6] = (id[6] & 0x0F) | 0x40; +/* Set the UUID variant to DCE */ +id[8] = (id[8] & 0x3F) | 0x80;</programlisting> + + <para>(This code is inspired by + <literal>generate_random_uuid()</literal> of + <filename>drivers/char/random.c</filename> from the Linux kernel + sources.)</para> + + </refsect1> + + <refsect1> + <title>History</title> + + <para>The simple configuration file format of + <filename>/etc/machine-id</filename> originates in the + <filename>/var/lib/dbus/machine-id</filename> file introduced by + D-Bus. In fact, this latter file might be a symlink to + <filename>/etc/machine-id</filename>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>gethostid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/machine-info.xml b/man/machine-info.xml new file mode 100644 index 0000000..c42f6e2 --- /dev/null +++ b/man/machine-info.xml @@ -0,0 +1,159 @@ +<?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-or-later --> + +<refentry id="machine-info"> + <refentryinfo> + <title>machine-info</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>machine-info</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>machine-info</refname> + <refpurpose>Local machine information file</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/machine-info</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/machine-info</filename> file contains + machine metadata.</para> + + <para>The basic file format of <filename>machine-info</filename> + is a newline-separated list of environment-like shell-compatible + variable assignments. It is possible to source the configuration + from shell scripts, however, beyond mere variable assignments no + shell features are supported, allowing applications to read the + file without implementing a shell compatible execution + engine.</para> + + <para><filename>/etc/machine-info</filename> contains metadata + about the machine that is set by the user or administrator.</para> + + <para>Depending on the operating system other configuration files + might be checked for machine information as well, however only as + fallback.</para> + + <para>You may use + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to change the settings of this file from the command line.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following machine metadata parameters may be set using + <filename>/etc/machine-info</filename>:</para> + + <variablelist class='environment-variables'> + + <varlistentry> + <term><varname>PRETTY_HOSTNAME=</varname></term> + + <listitem><para>A pretty human-readable UTF-8 machine + identifier string. This should contain a name like + <literal>Lennart's Laptop</literal> which is useful to present + to the user and does not suffer by the syntax limitations of + internet domain names. If possible, the internet hostname as + configured in <filename>/etc/hostname</filename> should be + kept similar to this one. Example: if this value is + <literal>Lennart's Computer</literal> an Internet hostname of + <literal>lennarts-computer</literal> might be a good choice. + If this parameter is not set, an application should fall back + to the Internet hostname for presentation + purposes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ICON_NAME=</varname></term> + + <listitem><para>An icon identifying this machine according to + the <ulink + url="http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">XDG + Icon Naming Specification</ulink>. If this parameter is not + set, an application should fall back to + <literal>computer</literal> or a similar icon + name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CHASSIS=</varname></term> + + <listitem><para>The chassis type. Currently, the following + chassis types are defined: + <literal>desktop</literal>, + <literal>laptop</literal>, + <literal>convertible</literal>, + <literal>server</literal>, + <literal>tablet</literal>, + <literal>handset</literal>, + <literal>watch</literal>, and + <literal>embedded</literal>, + as well as the special chassis types + <literal>vm</literal> and + <literal>container</literal> for + virtualized systems that lack an immediate physical chassis. + Note that many systems allow detection of the chassis type + automatically (based on firmware information or suchlike). + This setting (if set) shall take precedence over automatically + detected information and is useful to override misdetected + configuration or to manually configure the chassis type where + automatic detection is not available.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DEPLOYMENT=</varname></term> + + <listitem><para>Describes the system deployment environment. + One of the following is suggested: + <literal>development</literal>, + <literal>integration</literal>, + <literal>staging</literal>, + <literal>production</literal>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LOCATION=</varname></term> + + <listitem><para>Describes the system location if applicable + and known. Takes a human-friendly, free-form string. This may + be as generic as <literal>Berlin, Germany</literal> or as + specific as <literal>Left Rack, 2nd Shelf</literal>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Example</title> + + <programlisting>PRETTY_HOSTNAME="Lennart's Tablet" +ICON_NAME=computer-tablet +CHASSIS=tablet +DEPLOYMENT=production</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/machinectl.xml b/man/machinectl.xml new file mode 100644 index 0000000..9026849 --- /dev/null +++ b/man/machinectl.xml @@ -0,0 +1,1009 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="machinectl" conditional='ENABLE_MACHINED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>machinectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>machinectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>machinectl</refname> + <refpurpose>Control the systemd machine manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>machinectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>machinectl</command> may be used to introspect and + control the state of the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + virtual machine and container registration manager + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para><command>machinectl</command> may be used to execute + operations on machines and images. Machines in this sense are + considered running instances of:</para> + + <itemizedlist> + <listitem><para>Virtual Machines (VMs) that virtualize hardware + to run full operating system (OS) instances (including their kernels) + in a virtualized environment on top of the host OS.</para></listitem> + + <listitem><para>Containers that share the hardware and + OS kernel with the host OS, in order to run + OS userspace instances on top the host OS.</para></listitem> + + <listitem><para>The host system itself.</para></listitem> + </itemizedlist> + + <para>Machines are identified by names that follow the same rules + as UNIX and DNS hostnames. For details, see below.</para> + + <para>Machines are instantiated from disk or file system images that + frequently — but not necessarily — carry the same name as machines running + from them. Images in this sense may be:</para> + + <itemizedlist> + <listitem><para>Directory trees containing an OS, including the + top-level directories <filename>/usr/</filename>, + <filename>/etc/</filename>, and so on.</para></listitem> + + <listitem><para>btrfs subvolumes containing OS trees, similar to regular directory trees.</para></listitem> + + <listitem><para>Binary "raw" disk image files containing MBR or GPT partition tables and Linux file + systems.</para></listitem> + + <listitem><para>Similarly, block devices containing MBR or GPT partition tables and file systems.</para></listitem> + + <listitem><para>The file system tree of the host OS itself.</para></listitem> + </itemizedlist> + + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <refsect2><title>Machine Commands</title><variablelist> + + <varlistentry> + <term><command>list</command></term> + + <listitem><para>List currently running (online) virtual + machines and containers. To enumerate machine images that can + be started, use <command>list-images</command> (see + below). Note that this command hides the special + <literal>.host</literal> machine by default. Use the + <option>--all</option> switch to show it.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>status</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Show runtime status information about + one or more virtual machines and containers, followed by the + most recent log data from the journal. This function is + intended to generate human-readable output. If you are looking + for computer-parsable output, use <command>show</command> + instead. Note that the log data shown is reported by the + virtual machine or container manager, and frequently contains + console output of the machine, but not necessarily journal + contents of the machine itself.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>show</command> [<replaceable>NAME</replaceable>…]</term> + + <listitem><para>Show properties of one or more registered virtual machines or containers or the manager + itself. If no argument is specified, properties of the manager will be shown. If a NAME is specified, + properties of this virtual machine or container are shown. By default, empty properties are suppressed. Use + <option>--all</option> to show those too. To select specific properties to show, use + <option>--property=</option>. This command is intended to be used whenever computer-parsable output is + required, and does not print the control group tree or journal entries. Use <command>status</command> if you + are looking for formatted human-readable output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>start</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Start a container as a system service, using + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + This starts <filename>systemd-nspawn@.service</filename>, + instantiated for the specified machine name, similar to the + effect of <command>systemctl start</command> on the service + name. <command>systemd-nspawn</command> looks for a container + image by the specified name in + <filename>/var/lib/machines/</filename> (and other search + paths, see below) and runs it. Use + <command>list-images</command> (see below) for listing + available container images to start.</para> + + <para>Note that + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + also interfaces with a variety of other container and VM + managers, <command>systemd-nspawn</command> is just one + implementation of it. Most of the commands available in + <command>machinectl</command> may be used on containers or VMs + controlled by other managers, not just + <command>systemd-nspawn</command>. Starting VMs and container + images on those managers requires manager-specific + tools.</para> + + <para>To interactively start a container on the command line + with full access to the container's console, please invoke + <command>systemd-nspawn</command> directly. To stop a running + container use <command>machinectl poweroff</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>login</command> [<replaceable>NAME</replaceable>]</term> + + <listitem><para>Open an interactive terminal login session in + a container or on the local host. If an argument is supplied, + it refers to the container machine to connect to. If none is + specified, or the container name is specified as the empty + string, or the special machine name <literal>.host</literal> + (see below) is specified, the connection is made to the local + host instead. This will create a TTY connection to a specific + container or the local host and asks for the execution of a + getty on it. Note that this is only supported for containers + running + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + as init system.</para> + + <para>This command will open a full login prompt on the + container or the local host, which then asks for username and + password. Use <command>shell</command> (see below) or + <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> + with the <option>--machine=</option> switch to directly invoke + a single command, either interactively or in the + background.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>shell</command> [[<replaceable>NAME</replaceable>@]<replaceable>NAME</replaceable> [<replaceable>PATH</replaceable> [<replaceable>ARGUMENTS</replaceable>…]]] </term> + + <listitem><para>Open an interactive shell session in a + container or on the local host. The first argument refers to + the container machine to connect to. If none is specified, or + the machine name is specified as the empty string, or the + special machine name <literal>.host</literal> (see below) is + specified, the connection is made to the local host + instead. This works similar to <command>login</command> but + immediately invokes a user process. This command runs the + specified executable with the specified arguments, or the + default shell for the user if none is specified, or + <filename>/bin/sh</filename> if no default shell is found. By default, + <option>--uid=</option>, or by prefixing the machine name with + a username and an <literal>@</literal> character, a different + user may be selected. Use <option>--setenv=</option> to set + environment variables for the executed process.</para> + + <para>Note that <command>machinectl shell</command> does not propagate the exit code/status of the invoked + shell process. Use <command>systemd-run</command> instead if that information is required (see below).</para> + + <para>When using the <command>shell</command> command without + arguments, (thus invoking the executed shell or command on the + local host), it is in many ways similar to a <citerefentry + project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry> + session, but, unlike <command>su</command>, completely isolates + the new session from the originating session, so that it + shares no process or session properties, and is in a clean and + well-defined state. It will be tracked in a new utmp, login, + audit, security and keyring session, and will not inherit any + environment variables or resource limits, among other + properties.</para> + + <para>Note that <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> + with its <option>--machine=</option> switch may be used in place of the <command>machinectl shell</command> + command, and allows non-interactive operation, more detailed and low-level configuration of the invoked unit, + as well as access to runtime and exit code/status information of the invoked shell process. In particular, use + <command>systemd-run</command>'s <option>--wait</option> switch to propagate exit status information of the + invoked process. Use <command>systemd-run</command>'s <option>--pty</option> switch for acquiring an + interactive shell, similar to <command>machinectl shell</command>. In general, <command>systemd-run</command> + is preferable for scripting purposes. However, note that <command>systemd-run</command> might require higher + privileges than <command>machinectl shell</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>enable</command> <replaceable>NAME</replaceable>…</term> + <term><command>disable</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Enable or disable a container as a system + service to start at system boot, using + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + This enables or disables + <filename>systemd-nspawn@.service</filename>, instantiated for + the specified machine name, similar to the effect of + <command>systemctl enable</command> or <command>systemctl + disable</command> on the service name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>poweroff</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Power off one or more containers. This will + trigger a reboot by sending SIGRTMIN+4 to the container's init + process, which causes systemd-compatible init systems to shut + down cleanly. Use <command>stop</command> as alias for <command>poweroff</command>. + This operation does not work on containers that do not run a + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>-compatible + init system, such as sysvinit. Use + <command>terminate</command> (see below) to immediately + terminate a container or VM, without cleanly shutting it + down.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>reboot</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Reboot one or more containers. This will + trigger a reboot by sending SIGINT to the container's init + process, which is roughly equivalent to pressing Ctrl+Alt+Del + on a non-containerized system, and is compatible with + containers running any system manager.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>terminate</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Immediately terminates a virtual machine or + container, without cleanly shutting it down. This kills all + processes of the virtual machine or container and deallocates + all resources attached to that instance. Use + <command>poweroff</command> to issue a clean shutdown + request.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>kill</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Send a signal to one or more processes of the + virtual machine or container. This means processes as seen by + the host, not the processes inside the virtual machine or + container. Use <option>--kill-who=</option> to select which + process to kill. Use <option>--signal=</option> to select the + signal to send.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>bind</command> <replaceable>NAME</replaceable> <replaceable>PATH</replaceable> [<replaceable>PATH</replaceable>]</term> + + <listitem><para>Bind mounts a file or directory from the host into the specified container. The first path + argument is the source file or directory on the host, the second path argument is the destination file or + directory in the container. When the latter is omitted, the destination path in the container is the same as + the source path on the host. When combined with the <option>--read-only</option> switch, a ready-only bind + mount is created. When combined with the <option>--mkdir</option> switch, the destination path is first created + before the mount is applied. Note that this option is currently only supported for + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> containers, + and only if user namespacing (<option>--private-users</option>) is not used. This command supports bind + mounting directories, regular files, device nodes, <constant>AF_UNIX</constant> socket nodes, as well as + FIFOs.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>copy-to</command> <replaceable>NAME</replaceable> <replaceable>PATH</replaceable> [<replaceable>PATH</replaceable>]</term> + + <listitem><para>Copies files or directories from the host + system into a running container. Takes a container name, + followed by the source path on the host and the destination + path in the container. If the destination path is omitted, the + same as the source path is used.</para> + + <para>If host and container share the same user and group namespace, file ownership by numeric user ID and + group ID is preserved for the copy, otherwise all files and directories in the copy will be owned by the root + user and group (UID/GID 0).</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>copy-from</command> <replaceable>NAME</replaceable> <replaceable>PATH</replaceable> [<replaceable>PATH</replaceable>]</term> + + <listitem><para>Copies files or directories from a container + into the host system. Takes a container name, followed by the + source path in the container and the destination path on the host. + If the destination path is omitted, the same as the source path + is used.</para> + + <para>If host and container share the same user and group namespace, file ownership by numeric user ID and + group ID is preserved for the copy, otherwise all files and directories in the copy will be owned by the root + user and group (UID/GID 0).</para></listitem> + </varlistentry> + </variablelist></refsect2> + + <refsect2><title>Image Commands</title><variablelist> + + <varlistentry> + <term><command>list-images</command></term> + + <listitem><para>Show a list of locally installed container and + VM images. This enumerates all raw disk images and container + directories and subvolumes in + <filename>/var/lib/machines/</filename> (and other search + paths, see below). Use <command>start</command> (see above) to + run a container off one of the listed images. Note that, by + default, containers whose name begins with a dot + (<literal>.</literal>) are not shown. To show these too, + specify <option>--all</option>. Note that a special image + <literal>.host</literal> always implicitly exists and refers + to the image the host itself is booted from.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>image-status</command> [<replaceable>NAME</replaceable>…]</term> + + <listitem><para>Show terse status information about one or + more container or VM images. This function is intended to + generate human-readable output. Use + <command>show-image</command> (see below) to generate + computer-parsable output instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>show-image</command> [<replaceable>NAME</replaceable>…]</term> + + <listitem><para>Show properties of one or more registered + virtual machine or container images, or the manager itself. If + no argument is specified, properties of the manager will be + shown. If a NAME is specified, properties of this virtual + machine or container image are shown. By default, empty + properties are suppressed. Use <option>--all</option> to show + those too. To select specific properties to show, use + <option>--property=</option>. This command is intended to be + used whenever computer-parsable output is required. Use + <command>image-status</command> if you are looking for + formatted human-readable output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>clone</command> <replaceable>NAME</replaceable> <replaceable>NAME</replaceable></term> + + <listitem><para>Clones a container or VM image. The arguments specify the name of the image to clone and the + name of the newly cloned image. Note that plain directory container images are cloned into btrfs subvolume + images with this command, if the underlying file system supports this. Note that cloning a container or VM + image is optimized for file systems that support copy-on-write, and might not be efficient on others, due to + file system limitations.</para> + + <para>Note that this command leaves hostname, machine ID and + all other settings that could identify the instance + unmodified. The original image and the cloned copy will hence + share these credentials, and it might be necessary to manually + change them in the copy.</para> + + <para>If combined with the <option>--read-only</option> switch a read-only cloned image is + created.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>rename</command> <replaceable>NAME</replaceable> <replaceable>NAME</replaceable></term> + + <listitem><para>Renames a container or VM image. The + arguments specify the name of the image to rename and the new + name of the image.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>read-only</command> <replaceable>NAME</replaceable> [<replaceable>BOOL</replaceable>]</term> + + <listitem><para>Marks or (unmarks) a container or VM image + read-only. Takes a VM or container image name, followed by a + boolean as arguments. If the boolean is omitted, positive is + implied, i.e. the image is marked read-only.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>remove</command> <replaceable>NAME</replaceable>…</term> + + <listitem><para>Removes one or more container or VM images. + The special image <literal>.host</literal>, which refers to + the host's own directory tree, may not be + removed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-limit</command> [<replaceable>NAME</replaceable>] <replaceable>BYTES</replaceable></term> + + <listitem><para>Sets the maximum size in bytes that a specific + container or VM image, or all images, may grow up to on disk + (disk quota). Takes either one or two parameters. The first, + optional parameter refers to a container or VM image name. If + specified, the size limit of the specified image is changed. If + omitted, the overall size limit of the sum of all images stored + locally is changed. The final argument specifies the size + limit in bytes, possibly suffixed by the usual K, M, G, T + units. If the size limit shall be disabled, specify + <literal>-</literal> as size.</para> + + <para>Note that per-container size limits are only supported on btrfs file systems.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>clean</command></term> + + <listitem><para>Remove hidden VM or container images (or all). This command removes all hidden machine images + from <filename>/var/lib/machines/</filename>, i.e. those whose name begins with a dot. Use <command>machinectl + list-images --all</command> to see a list of all machine images, including the hidden ones.</para> + + <para>When combined with the <option>--all</option> switch removes all images, not just hidden ones. This + command effectively empties <filename>/var/lib/machines/</filename>.</para> + + <para>Note that commands such as <command>machinectl pull-tar</command> or <command>machinectl + pull-raw</command> usually create hidden, read-only, unmodified machine images from the downloaded image first, + before cloning a writable working copy of it, in order to avoid duplicate downloads in case of images that are + reused multiple times. Use <command>machinectl clean</command> to remove old, hidden images created this + way.</para></listitem> + </varlistentry> + + </variablelist></refsect2> + + <refsect2><title>Image Transfer Commands</title><variablelist> + + <varlistentry> + <term><command>pull-tar</command> <replaceable>URL</replaceable> [<replaceable>NAME</replaceable>]</term> + + <listitem><para>Downloads a <filename>.tar</filename> + container image from the specified URL, and makes it available + under the specified local machine name. The URL must be of + type <literal>http://</literal> or + <literal>https://</literal>, and must refer to a + <filename>.tar</filename>, <filename>.tar.gz</filename>, + <filename>.tar.xz</filename> or <filename>.tar.bz2</filename> + archive file. If the local machine name is omitted, it + is automatically derived from the last component of the URL, + with its suffix removed.</para> + + <para>The image is verified before it is made available, unless + <option>--verify=no</option> is specified. + Verification is done either via an inline signed file with the name + of the image and the suffix <filename>.sha256</filename> or via + separate <filename>SHA256SUMS</filename> and + <filename>SHA256SUMS.gpg</filename> files. + The signature files need to be made available on the same web + server, under the same URL as the <filename>.tar</filename> file. + With <option>--verify=checksum</option>, only the SHA256 checksum + for the file is verified, based on the <filename>.sha256</filename> + suffixed file or the <filename>SHA256SUMS</filename> file. + With <option>--verify=signature</option>, the sha checksum file is + first verified with the inline signature in the + <filename>.sha256</filename> file or the detached GPG signature file + <filename>SHA256SUMS.gpg</filename>. + The public key for this verification step needs to be available in + <filename>/usr/lib/systemd/import-pubring.gpg</filename> or + <filename>/etc/systemd/import-pubring.gpg</filename>.</para> + + <para>The container image will be downloaded and stored in a + read-only subvolume in + <filename>/var/lib/machines/</filename> that is named after + the specified URL and its HTTP etag. A writable snapshot is + then taken from this subvolume, and named after the specified + local name. This behavior ensures that creating multiple + container instances of the same URL is efficient, as multiple + downloads are not necessary. In order to create only the + read-only image, and avoid creating its writable snapshot, + specify <literal>-</literal> as local machine name.</para> + + <para>Note that the read-only subvolume is prefixed with + <filename>.tar-</filename>, and is thus not shown by + <command>list-images</command>, unless <option>--all</option> + is passed.</para> + + <para>Note that pressing C-c during execution of this command + will not abort the download. Use + <command>cancel-transfer</command>, described + below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>pull-raw</command> <replaceable>URL</replaceable> [<replaceable>NAME</replaceable>]</term> + + <listitem><para>Downloads a <filename>.raw</filename> + container or VM disk image from the specified URL, and makes + it available under the specified local machine name. The URL + must be of type <literal>http://</literal> or + <literal>https://</literal>. The container image must either + be a <filename>.qcow2</filename> or raw disk image, optionally + compressed as <filename>.gz</filename>, + <filename>.xz</filename>, or <filename>.bz2</filename>. If the + local machine name is omitted, it is automatically + derived from the last component of the URL, with its suffix + removed.</para> + + <para>Image verification is identical for raw and tar images + (see above).</para> + + <para>If the downloaded image is in + <filename>.qcow2</filename> format it is converted into a raw + image file before it is made available.</para> + + <para>Downloaded images of this type will be placed as + read-only <filename>.raw</filename> file in + <filename>/var/lib/machines/</filename>. A local, writable + (reflinked) copy is then made under the specified local + machine name. To omit creation of the local, writable copy + pass <literal>-</literal> as local machine name.</para> + + <para>Similar to the behavior of <command>pull-tar</command>, + the read-only image is prefixed with + <filename>.raw-</filename>, and thus not shown by + <command>list-images</command>, unless <option>--all</option> + is passed.</para> + + <para>Note that pressing C-c during execution of this command + will not abort the download. Use + <command>cancel-transfer</command>, described + below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>import-tar</command> <replaceable>FILE</replaceable> [<replaceable>NAME</replaceable>]</term> + <term><command>import-raw</command> <replaceable>FILE</replaceable> [<replaceable>NAME</replaceable>]</term> + <listitem><para>Imports a TAR or RAW container or VM image, + and places it under the specified name in + <filename>/var/lib/machines/</filename>. When + <command>import-tar</command> is used, the file specified as + the first argument should be a tar archive, possibly compressed + with xz, gzip or bzip2. It will then be unpacked into its own + subvolume in <filename>/var/lib/machines/</filename>. When + <command>import-raw</command> is used, the file should be a + qcow2 or raw disk image, possibly compressed with xz, gzip or + bzip2. If the second argument (the resulting image name) is + not specified, it is automatically derived from the file + name. If the filename is passed as <literal>-</literal>, the + image is read from standard input, in which case the second + argument is mandatory.</para> + + <para>Optionally, the <option>--read-only</option> switch may be used to create a read-only container or VM + image. No cryptographic validation is done when importing the images.</para> + + <para>Much like image downloads, ongoing imports may be listed + with <command>list-transfers</command> and aborted with + <command>cancel-transfer</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>import-fs</command> <replaceable>DIRECTORY</replaceable> [<replaceable>NAME</replaceable>]</term> + + <listitem><para>Imports a container image stored in a local directory into + <filename>/var/lib/machines/</filename>, operates similar to <command>import-tar</command> or + <command>import-raw</command>, but the first argument is the source directory. If supported, this command will + create btrfs snapshot or subvolume for the new image.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>export-tar</command> <replaceable>NAME</replaceable> [<replaceable>FILE</replaceable>]</term> + <term><command>export-raw</command> <replaceable>NAME</replaceable> [<replaceable>FILE</replaceable>]</term> + <listitem><para>Exports a TAR or RAW container or VM image and + stores it in the specified file. The first parameter should be + a VM or container image name. The second parameter should be a + file path the TAR or RAW image is written to. If the path ends + in <literal>.gz</literal>, the file is compressed with gzip, if + it ends in <literal>.xz</literal>, with xz, and if it ends in + <literal>.bz2</literal>, with bzip2. If the path ends in + neither, the file is left uncompressed. If the second argument + is missing, the image is written to standard output. The + compression may also be explicitly selected with the + <option>--format=</option> switch. This is in particular + useful if the second parameter is left unspecified.</para> + + <para>Much like image downloads and imports, ongoing exports + may be listed with <command>list-transfers</command> and + aborted with + <command>cancel-transfer</command>.</para> + + <para>Note that, currently, only directory and subvolume images + may be exported as TAR images, and only raw disk images as RAW + images.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>list-transfers</command></term> + + <listitem><para>Shows a list of container or VM image + downloads, imports and exports that are currently in + progress.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>cancel-transfer</command> <replaceable>ID</replaceable>…</term> + + <listitem><para>Aborts a download, import or export of the + container or VM image with the specified ID. To list ongoing + transfers and their IDs, use + <command>list-transfers</command>. </para></listitem> + </varlistentry> + + </variablelist></refsect2> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-p</option></term> + <term><option>--property=</option></term> + + <listitem><para>When showing machine or image properties, + limit the output to certain properties as specified by the + argument. If not specified, all set properties are shown. The + argument should be a property name, such as + <literal>Name</literal>. If specified more than once, all + properties with the specified names are + shown.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-a</option></term> + <term><option>--all</option></term> + + <listitem><para>When showing machine or image properties, show + all properties regardless of whether they are set or + not.</para> + + <para>When listing VM or container images, do not suppress + images beginning in a dot character + (<literal>.</literal>).</para> + + <para>When cleaning VM or container images, remove all images, not just hidden ones.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--value</option></term> + + <listitem><para>When printing properties with <command>show</command>, only print the value, + and skip the property name and <literal>=</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem><para>Do not ellipsize process tree entries or table. This implies + <option>--max-addresses=full</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--kill-who=</option></term> + + <listitem><para>When used with <command>kill</command>, choose + which processes to kill. Must be one of + <option>leader</option>, or <option>all</option> to select + whether to kill only the leader process of the machine or all + processes of the machine. If omitted, defaults to + <option>all</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-s</option></term> + <term><option>--signal=</option></term> + + <listitem><para>When used with <command>kill</command>, choose + which signal to send to selected processes. Must be one of the + well-known signal specifiers, such as + <constant>SIGTERM</constant>, <constant>SIGINT</constant> or + <constant>SIGSTOP</constant>. If omitted, defaults to + <constant>SIGTERM</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--uid=</option></term> + + <listitem><para>When used with the <command>shell</command> command, chooses the user ID to + open the interactive shell session as. If the argument to the <command>shell</command> + command also specifies a user name, this option is ignored. If the name is not specified + in either way, <literal>root</literal> will be used by default. Note that this switch is + not supported for the <command>login</command> command (see below).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-E <replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term> + <term><option>--setenv=<replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term> + + <listitem><para>When used with the <command>shell</command> command, sets an environment + variable to pass to the executed shell. Takes an environment variable name and value, + separated by <literal>=</literal>. This switch may be used multiple times to set multiple + environment variables. Note that this switch is not supported for the + <command>login</command> command (see below).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--mkdir</option></term> + + <listitem><para>When used with <command>bind</command>, creates the destination file or directory before + applying the bind mount. Note that even though the name of this option suggests that it is suitable only for + directories, this option also creates the destination file node to mount over if the object to mount is not + a directory, but a regular file, device node, socket or FIFO.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--read-only</option></term> + + <listitem><para>When used with <command>bind</command>, creates a read-only bind mount.</para> + + <para>When used with <command>clone</command>, <command>import-raw</command> or <command>import-tar</command> a + read-only container or VM image is created.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--lines=</option></term> + + <listitem><para>When used with <command>status</command>, + controls the number of journal lines to show, counting from + the most recent ones. Takes a positive integer argument. + Defaults to 10.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-o</option></term> + <term><option>--output=</option></term> + + <listitem><para>When used with <command>status</command>, + controls the formatting of the journal entries that are shown. + For the available choices, see + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + Defaults to <literal>short</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--verify=</option></term> + + <listitem><para>When downloading a container or VM image, + specify whether the image shall be verified before it is made + available. Takes one of <literal>no</literal>, + <literal>checksum</literal> and <literal>signature</literal>. + If <literal>no</literal>, no verification is done. If + <literal>checksum</literal> is specified, the download is + checked for integrity after the transfer is complete, but no + signatures are verified. If <literal>signature</literal> is + specified, the checksum is verified and the image's signature + is checked against a local keyring of trustable vendors. It is + strongly recommended to set this option to + <literal>signature</literal> if the server and protocol + support this. Defaults to + <literal>signature</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--force</option></term> + + <listitem><para>When downloading a container or VM image, and + a local copy by the specified local machine name already + exists, delete it first and replace it by the newly downloaded + image.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--format=</option></term> + + <listitem><para>When used with the <option>export-tar</option> + or <option>export-raw</option> commands, specifies the + compression format to use for the resulting file. Takes one of + <literal>uncompressed</literal>, <literal>xz</literal>, + <literal>gzip</literal>, <literal>bzip2</literal>. By default, + the format is determined automatically from the image file + name passed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--max-addresses=</option></term> + + <listitem><para>When used with the <option>list-machines</option> command, limits the number of ip + addresses output for every machine. Defaults to 1. All addresses can be requested with + <literal>all</literal> as argument to <option>--max-addresses=</option>. If the argument to + <option>--max-addresses=</option> is less than the actual number of addresses, + <literal>…</literal>follows the last address.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Suppresses additional informational output while running.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + + <varlistentry> + <term><option>-M</option></term> + <term><option>--machine=</option></term> + + <listitem><para>Connect to + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + running in a local container, to perform the specified operation within + the container.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="no-ask-password" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Machine and Image Names</title> + + <para>The <command>machinectl</command> tool operates on machines + and images whose names must be chosen following strict + rules. Machine names must be suitable for use as hostnames + following a conservative subset of DNS and UNIX/Linux + semantics. Specifically, they must consist of one or more + non-empty label strings, separated by dots. No leading or trailing + dots are allowed. No sequences of multiple dots are allowed. The + label strings may only consist of alphanumeric characters as well + as the dash and underscore. The maximum length of a machine name + is 64 characters.</para> + + <para>A special machine with the name <literal>.host</literal> + refers to the running host system itself. This is useful for execution + operations or inspecting the host system as well. Note that + <command>machinectl list</command> will not show this special + machine unless the <option>--all</option> switch is specified.</para> + + <para>Requirements on image names are less strict, however, they must be + valid UTF-8, must be suitable as file names (hence not be the + single or double dot, and not include a slash), and may not + contain control characters. Since many operations search for an + image by the name of a requested machine, it is recommended to name + images in the same strict fashion as machines.</para> + + <para>A special image with the name <literal>.host</literal> + refers to the image of the running host system. It hence + conceptually maps to the special <literal>.host</literal> machine + name described above. Note that <command>machinectl + list-images</command> will not show this special image either, unless + <option>--all</option> is specified.</para> + </refsect1> + + <refsect1> + <title>Files and Directories</title> + + <para>Machine images are preferably stored in + <filename>/var/lib/machines/</filename>, but are also searched for + in <filename>/usr/local/lib/machines/</filename> and + <filename>/usr/lib/machines/</filename>. For compatibility reasons, + the directory <filename>/var/lib/container/</filename> is + searched, too. Note that images stored below + <filename>/usr/</filename> are always considered read-only. It is + possible to symlink machines images from other directories into + <filename>/var/lib/machines/</filename> to make them available for + control with <command>machinectl</command>.</para> + + <para>Note that some image operations are only supported, efficient or atomic on btrfs file systems.</para> + + <para>Disk images are understood by + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and <command>machinectl</command> in three formats:</para> + + <itemizedlist> + <listitem><para>A simple directory tree, containing the files + and directories of the container to boot.</para></listitem> + + <listitem><para>Subvolumes (on btrfs file systems), which are + similar to the simple directories, described above. However, + they have additional benefits, such as efficient cloning and + quota reporting.</para></listitem> + + <listitem><para>"Raw" disk images, i.e. binary images of disks + with a GPT or MBR partition table. Images of this type are + regular files with the suffix + <literal>.raw</literal>.</para></listitem> + </itemizedlist> + + <para>See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for more information on image formats, in particular its + <option>--directory=</option> and <option>--image=</option> + options.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>Download an Ubuntu image and open a shell in it</title> + + <programlisting># machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz +# systemd-nspawn -M trusty-server-cloudimg-amd64-root</programlisting> + + <para>This downloads and verifies the specified + <filename>.tar</filename> image, and then uses + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to open a shell in it.</para> + </example> + + <example> + <title>Download a Fedora image, set a root password in it, start + it as a service</title> + + <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 \ + Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# passwd +# exit +# machinectl start Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# machinectl login Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64</programlisting> + + <para>This downloads the specified <filename>.raw</filename> + image with verification disabled. Then, a shell is opened in it + and a root password is set. Afterwards the shell is left, and + the machine started as system service. With the last command a + login prompt into the container is requested.</para> + </example> + + <example> + <title>Exports a container image as tar file</title> + + <programlisting># machinectl export-tar fedora myfedora.tar.xz</programlisting> + + <para>Exports the container <literal>fedora</literal> as an + xz-compressed tar file <filename>myfedora.tar.xz</filename> into the + current directory.</para> + </example> + + <example> + <title>Create a new shell session</title> + + <programlisting># machinectl shell --uid=lennart</programlisting> + + <para>This creates a new shell session on the local host for + the user ID <literal>lennart</literal>, in a <citerefentry + project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry>-like + fashion.</para> + </example> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>tar</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>xz</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>gzip</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>bzip2</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/man.in b/man/man.in new file mode 100755 index 0000000..12eb332 --- /dev/null +++ b/man/man.in @@ -0,0 +1,28 @@ +#!/bin/sh +set -e + +if [ -z "$1" ]; then + echo "Use: $0 page-name (with no section suffix)" + exit 1 +fi + +# make sure the rules have been regenerated (in case man/update-man-rules was just run) +ninja -C "@BUILD_ROOT@" version.h + +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" + +fullname="@BUILD_ROOT@/$target" +redirect="$(sed -n -r '1 s|^\.so man[0-9]/(.*)|\1|p' "$fullname")" +if [ -n "$redirect" ]; then + ninja -C "@BUILD_ROOT@" "man/$redirect" + + fullname="@BUILD_ROOT@/man/$redirect" +fi + +exec man "$fullname" diff --git a/man/meson.build b/man/meson.build new file mode 100644 index 0000000..f555d62 --- /dev/null +++ b/man/meson.build @@ -0,0 +1,241 @@ +# SPDX-License-Identifier: LGPL-2.1-or-later + +# This is lame, I know, but meson has no other include mechanism +subdir('rules') + +want_man = get_option('man') +want_html = get_option('html') +xsltproc = find_program('xsltproc', + required : want_man == 'true' or want_html == 'true') +want_man = want_man != 'false' and xsltproc.found() +want_html = want_html != 'false' and xsltproc.found() + +xsltproc_flags = [ + '--nonet', + '--xinclude', + '--maxdepth', '9000', + '--stringparam', 'man.output.quietly', '1', + '--stringparam', 'funcsynopsis.style', 'ansi', + '--stringparam', 'man.authors.section.enabled', '0', + '--stringparam', 'man.copyright.section.enabled', '0', + '--stringparam', 'systemd.version', '@0@'.format(meson.project_version()), + '--path', + '@0@:@1@'.format(meson.current_build_dir(), meson.current_source_dir())] + +custom_man_xsl = files('custom-man.xsl') +custom_html_xsl = files('custom-html.xsl') +xslt_cmd = [xsltproc, '-o', '@OUTPUT0@'] + xsltproc_flags + +custom_entities_ent = configure_file( + input : 'custom-entities.ent.in', + output : 'custom-entities.ent', + configuration : conf) + +man_pages = [] +html_pages = [] +source_xml_files = [] +dbus_docs = [] +foreach tuple : xsltproc.found() ? manpages : [] + stem = tuple[0] + section = tuple[1] + aliases = tuple[2] + condition = tuple[3] + + xml = stem + '.xml' + html = stem + '.html' + man = stem + '.' + section + + manaliases = [] + htmlaliases = [] + foreach alias : aliases + manaliases += alias + '.' + section + htmlaliases += alias + '.html' + endforeach + + mandirn = join_paths(get_option('mandir'), 'man' + section) + + if condition == '' or conf.get(condition) == 1 + p1 = custom_target( + man, + input : xml, + output : [man] + manaliases, + command : xslt_cmd + [custom_man_xsl, '@INPUT@'], + depend_files : custom_entities_ent, + install : want_man, + install_dir : mandirn) + man_pages += p1 + + p2 = [] + foreach htmlalias : htmlaliases + link = custom_target( + htmlalias, + output : htmlalias, + command : ['ln', '-fs', html, '@OUTPUT@']) + if want_html + dst = join_paths(docdir, 'html', htmlalias) + cmd = 'ln -fs @0@ $DESTDIR@1@'.format(html, dst) + meson.add_install_script('sh', '-c', cmd) + p2 += link + endif + html_pages += link + endforeach + + p3 = custom_target( + html, + input : xml, + output : html, + command : xslt_cmd + [custom_html_xsl, '@INPUT@'], + depend_files : custom_entities_ent, + depends : p2, + install : want_html, + install_dir : join_paths(docdir, 'html')) + html_pages += p3 + + file = files(tuple[0] + '.xml') + source_xml_files += file + if tuple[0].startswith('org.freedesktop.') + dbus_docs += file + endif + else + message('Skipping @0@.@1@ because @2@ is false'.format(stem, section, condition)) + endif +endforeach + +############################################################ + +have_lxml = run_command(xml_helper_py).returncode() == 0 +if not have_lxml + message('python-lxml not available, not making man page indices') +endif + +systemd_directives_xml = custom_target( + 'systemd.directives.xml', + input : ['directives-template.xml', source_xml_files], + output : 'systemd.directives.xml', + command : [make_directive_index_py, '@OUTPUT@', '@INPUT@']) + +nonindex_xml_files = source_xml_files + [systemd_directives_xml] +systemd_index_xml = custom_target( + 'systemd.index.xml', + input : nonindex_xml_files, + output : 'systemd.index.xml', + command : [make_man_index_py, '@OUTPUT@'] + nonindex_xml_files) + +foreach tuple : xsltproc.found() ? [['systemd.directives', '7', systemd_directives_xml], + ['systemd.index', '7', systemd_index_xml]] : [] + stem = tuple[0] + section = tuple[1] + xml = tuple[2] + + html = stem + '.html' + man = stem + '.' + section + + mandirn = join_paths(get_option('mandir'), 'man' + section) + + p1 = custom_target( + man, + input : xml, + output : man, + command : xslt_cmd + [custom_man_xsl, '@INPUT@'], + install : want_man and have_lxml, + install_dir : mandirn) + man_pages += p1 + + p2 = [] + if html == 'systemd.index.html' + htmlalias = 'index.html' + link = custom_target( + htmlalias, + input : p2, + output : htmlalias, + command : ['ln', '-fs', html, '@OUTPUT@']) + if want_html + dst = join_paths(docdir, 'html', htmlalias) + cmd = 'ln -fs @0@ $DESTDIR@1@'.format(html, dst) + meson.add_install_script('sh', '-c', cmd) + p2 += link + endif + html_pages += link + endif + + p3 = custom_target( + html, + input : xml, + output : html, + command : xslt_cmd + [custom_html_xsl, '@INPUT@'], + depend_files : custom_entities_ent, + depends : p2, + install : want_html and have_lxml, + install_dir : join_paths(docdir, 'html')) + html_pages += p3 +endforeach + +# Cannot use run_target because those targets are used in depends +# Also see https://github.com/mesonbuild/meson/issues/368. +man = custom_target( + 'man', + output : 'man', + depends : man_pages, + command : ['echo']) + +html = custom_target( + 'html', + output : 'html', + depends : html_pages, + command : ['echo']) + +run_target( + 'doc-sync', + depends : man_pages + html_pages, + command : ['rsync', '-rlv', + '--delete-excluded', + '--include=man', + '--include=*.html', + '--exclude=*', + '--omit-dir-times', + meson.current_build_dir(), + get_option('www-target')]) + +############################################################ + +if dbus_docs.length() > 0 + custom_target( + 'update-dbus-docs', + output : 'update-dbus-docs', + command : [update_dbus_docs_py, + '--build-dir=@0@'.format(project_build_root), + '@INPUT@'], + input : dbus_docs) + + if conf.get('BUILD_MODE') == 'BUILD_MODE_DEVELOPER' + test('dbus-docs-fresh', + update_dbus_docs_py, + args : ['--build-dir=@0@'.format(project_build_root), + '--test'] + dbus_docs) + endif +endif + +############################################################ + +if git.found() + custom_target( + 'update-man-rules', + output : 'update-man-rules', + command : ['sh', '-c', + 'cd @0@ && '.format(meson.build_root()) + + 'python3 @0@/tools/update-man-rules.py $(git ls-files ":/man/*.xml") >t && '.format(project_source_root) + + '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/modules-load.d.xml b/man/modules-load.d.xml new file mode 100644 index 0000000..cd0c006 --- /dev/null +++ b/man/modules-load.d.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-or-later --> +<refentry id="modules-load.d" conditional='HAVE_KMOD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>modules-load.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>modules-load.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>modules-load.d</refname> + <refpurpose>Configure kernel modules to load at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/modules-load.d/*.conf</filename></para> + <para><filename>/run/modules-load.d/*.conf</filename></para> + <para><filename>/usr/lib/modules-load.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + reads files from the above directories which contain kernel + modules to load during boot in a static list. Each configuration + file is named in the style of + <filename>/etc/modules-load.d/<replaceable>program</replaceable>.conf</filename>. + Note that it is usually a better idea to rely on the automatic + module loading by PCI IDs, USB IDs, DMI IDs or similar triggers + encoded in the kernel modules themselves instead of static + configuration like this. In fact, most modern kernel modules are + prepared for automatic loading already.</para> + </refsect1> + + <refsect1> + <title>Configuration Format</title> + + <para>The configuration files should simply contain a list of + kernel module names to load, separated by newlines. Empty lines + and lines whose first non-whitespace character is # or ; are + ignored.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="confd" /> + + <refsect1> + <title>Example</title> + <example> + <title>/etc/modules-load.d/virtio-net.conf example:</title> + + <programlisting># Load virtio-net.ko at boot +virtio-net</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>modprobe</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/networkctl.xml b/man/networkctl.xml new file mode 100644 index 0000000..466bba4 --- /dev/null +++ b/man/networkctl.xml @@ -0,0 +1,393 @@ +<?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-or-later --> + +<refentry id="networkctl" conditional='ENABLE_NETWORKD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>networkctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>networkctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>networkctl</refname> + <refpurpose>Query the status of network links</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>networkctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">COMMAND</arg> + <arg choice="opt" rep="repeat">LINK</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>networkctl</command> may be used to introspect the + state of the network links as seen by + <command>systemd-networkd</command>. Please refer to + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for an introduction to the basic concepts, functionality, and + configuration syntax.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term> + <command>list</command> + <optional><replaceable>PATTERN…</replaceable></optional> + </term> + + <listitem> + <para>Show a list of existing links and their status. If one ore more + <replaceable>PATTERN</replaceable>s are specified, only links matching one of them are shown. + If no further arguments are specified shows all links, + otherwise just the specified links. Produces output similar to: + + <programlisting>IDX LINK TYPE OPERATIONAL SETUP + 1 lo loopback carrier unmanaged + 2 eth0 ether routable configured + 3 virbr0 ether no-carrier unmanaged + 4 virbr0-nic ether off unmanaged + +4 links listed.</programlisting></para> + + <para>The operational status is one of the following: + <variablelist> + <varlistentry> + <term>missing</term> + <listitem> + <para>the device is missing</para> + </listitem> + </varlistentry> + <varlistentry> + <term>off</term> + <listitem> + <para>the device is powered down</para> + </listitem> + </varlistentry> + <varlistentry> + <term>no-carrier</term> + <listitem> + <para>the device is powered up, but it does not yet have a carrier</para> + </listitem> + </varlistentry> + <varlistentry> + <term>dormant</term> + <listitem> + <para>the device has a carrier, but is not yet ready for normal traffic</para> + </listitem> + </varlistentry> + <varlistentry> + <term>degraded-carrier</term> + <listitem> + <para>for bond or bridge master, one of the bonding or bridge slave network interfaces is + in off, no-carrier, or dormant state</para> + </listitem> + </varlistentry> + <varlistentry> + <term>carrier</term> + <listitem> + <para>the link has a carrier, or for bond or bridge master, all bonding or bridge slave + network interfaces are enslaved to the master.</para> + </listitem> + </varlistentry> + <varlistentry> + <term>degraded</term> + <listitem> + <para>the link has carrier and addresses valid on the local link configured</para> + </listitem> + </varlistentry> + <varlistentry> + <term>enslaved</term> + <listitem> + <para>the link has carrier and is enslaved to bond or bridge master network interface</para> + </listitem> + </varlistentry> + <varlistentry> + <term>routable</term> + <listitem> + <para>the link has carrier and routable address configured</para> + </listitem> + </varlistentry> + </variablelist> + </para> + + <para>The setup status is one of the following: + <variablelist> + <varlistentry> + <term>pending</term> + <listitem> + <para>udev is still processing the link, we don't yet know if we will manage it</para> + </listitem> + </varlistentry> + <varlistentry> + <term>failed</term> + <listitem> + <para>networkd failed to manage the link</para> + </listitem> + </varlistentry> + <varlistentry> + <term>configuring</term> + <listitem> + <para>in the process of retrieving configuration or configuring the link</para> + </listitem> + </varlistentry> + <varlistentry> + <term>configured</term> + <listitem> + <para>link configured successfully</para> + </listitem> + </varlistentry> + <varlistentry> + <term>unmanaged</term> + <listitem> + <para>networkd is not handling the link</para> + </listitem> + </varlistentry> + <varlistentry> + <term>linger</term> + <listitem> + <para>the link is gone, but has not yet been dropped by networkd</para> + </listitem> + </varlistentry> + </variablelist> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <command>status</command> + <optional><replaceable>PATTERN…</replaceable></optional> + </term> + + <listitem> + <para>Show information about the specified links: type, state, kernel module driver, hardware and + IP address, configured DNS servers, etc. If one ore more <replaceable>PATTERN</replaceable>s are + specified, only links matching one of them are shown.</para> + + <para>When no links are specified, an overall network status is shown. Also see the option + <option>--all</option>.</para> + + <para>Produces output similar to: + <programlisting> +● State: routable + Address: 10.193.76.5 on eth0 + 192.168.122.1 on virbr0 + 169.254.190.105 on eth0 + fe80::5054:aa:bbbb:cccc on eth0 + Gateway: 10.193.11.1 (CISCO SYSTEMS, INC.) on eth0 + DNS: 8.8.8.8 + 8.8.4.4</programlisting></para> + </listitem> + + </varlistentry> + + <varlistentry> + <term> + <command>lldp</command> + <optional><replaceable>PATTERN…</replaceable></optional> + </term> + + <listitem> + <para>Show discovered LLDP (Link Layer Discovery Protocol) neighbors. If one or more + <replaceable>PATTERN</replaceable>s are specified only neighbors on those interfaces are shown. + Otherwise shows discovered neighbors on all interfaces. Note that for this feature to work, + <varname>LLDP=</varname> must be turned on for the specific interface, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details.</para> + + <para>Produces output similar to: + <programlisting>LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION +enp0s25 00:e0:4c:00:00:00 GS1900 ..b........ 2 Port #2 + +Capability Flags: +o - Other; p - Repeater; b - Bridge; w - WLAN Access Point; r - Router; +t - Telephone; d - DOCSIS cable device; a - Station; c - Customer VLAN; +s - Service VLAN, m - Two-port MAC Relay (TPMR) + +1 neighbors listed.</programlisting></para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <command>label</command> + </term> + + <listitem><para>Show numerical address labels that can be used for address selection. + This is the same information that + <citerefentry project='die-net'><refentrytitle>ip-addrlabel</refentrytitle><manvolnum>8</manvolnum></citerefentry> + shows. See <ulink url="https://tools.ietf.org/html/rfc3484">RFC 3484</ulink> + for a discussion of address labels.</para> + + <para>Produces output similar to: + <programlisting>Prefix/Prefixlen Label + ::/0 1 + fc00::/7 5 + fec0::/10 11 + 2002::/16 2 + 3ffe::/16 12 + 2001:10::/28 7 + 2001::/32 6 +::ffff:0.0.0.0/96 4 + ::/96 3 + ::1/128 0</programlisting></para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <command>delete</command> + <replaceable>DEVICE…</replaceable> + </term> + <listitem><para>Deletes virtual netdevs. Takes interface name or index number.</para></listitem> + </varlistentry> + + <varlistentry> + <term> + <command>up</command> + <replaceable>DEVICE…</replaceable> + </term> + <listitem><para>Bring devices up. Takes interface name or index number.</para></listitem> + </varlistentry> + + <varlistentry> + <term> + <command>down</command> + <replaceable>DEVICE…</replaceable> + </term> + <listitem><para>Bring devices down. Takes interface name or index number.</para></listitem> + </varlistentry> + + <varlistentry> + <term> + <command>renew</command> + <replaceable>DEVICE…</replaceable> + </term> + <listitem><para>Renew dynamic configurations e.g. addresses received from DHCP server. + Takes interface name or index number.</para></listitem> + </varlistentry> + + <varlistentry> + <term> + <command>forcerenew</command> + <replaceable>DEVICE…</replaceable> + </term> + <listitem><para>Send a FORCERENEW message to all connected clients, triggering DHCP reconfiguration. + Takes interface name or index number.</para></listitem> + </varlistentry> + + <varlistentry> + <term> + <command>reconfigure</command> + <replaceable>DEVICE…</replaceable> + </term> + <listitem><para>Reconfigure network interfaces. Takes interface name or index number. Note that + this does not reload <filename>.netdev</filename> or <filename>.network</filename> + corresponding to the specified interface. So, if you edit config files, it is necessary to call + <command>networkctl reload</command> first to apply new settings.</para></listitem> + </varlistentry> + + <varlistentry> + <term> + <command>reload</command> + </term> + <listitem><para>Reload <filename>.netdev</filename> and <filename>.network</filename> files. + If a new <filename>.netdev</filename> file is found, then the corresponding netdev is created. + Note that even if an existing <filename>.netdev</filename> is modified or removed, + <command>systemd-networkd</command> does not update or remove the netdev. + If a new, modified or removed <filename>.network</filename> file is found, then all interfaces + which match the file are reconfigured.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term> + <option>-a</option> + <option>--all</option> + </term> + + <listitem> + <para>Show all links with <command>status</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-s</option> + <option>--stats</option> + </term> + + <listitem> + <para>Show link statistics with <command>status</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem> + <para>Do not ellipsize the output.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--lines=</option></term> + + <listitem> + <para>When used with <command>status</command>, controls the number of journal lines to show, + counting from the most recent ones. Takes a positive integer argument. Defaults to 10.</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" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/networkd.conf.xml b/man/networkd.conf.xml new file mode 100644 index 0000000..65aecb6 --- /dev/null +++ b/man/networkd.conf.xml @@ -0,0 +1,178 @@ +<?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-or-later + + Copyright © 2014 Vinay Kulkarni +--> + +<refentry id="networkd.conf" conditional='ENABLE_NETWORKD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>networkd.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>networkd.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>networkd.conf</refname> + <refname>networkd.conf.d</refname> + <refpurpose>Global Network configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/networkd.conf</filename></para> + <para><filename>/etc/systemd/networkd.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/networkd.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These configuration files control global network parameters. + Currently the DHCP Unique Identifier (DUID).</para> + + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>[Network] Section Options</title> + + <para>The following options are available in the [Network] section:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>SpeedMeter=</varname></term> + <listitem><para>Takes a boolean. If set to yes, then <command>systemd-networkd</command> + measures the traffic of each interface, and + <command>networkctl status <replaceable>INTERFACE</replaceable></command> shows the measured speed. + Defaults to no.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SpeedMeterIntervalSec=</varname></term> + <listitem><para>Specifies the time interval to calculate the traffic speed of each interface. + If <varname>SpeedMeter=no</varname>, the value is ignored. Defaults to 10sec.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ManageForeignRoutes=</varname></term> + <listitem><para>A boolean. When true, <command>systemd-networkd</command> will store any routes + configured by other tools in its memory. When false, <command>systemd-networkd</command> will + not manage the foreign routes, thus they are kept even if <varname>KeepConfiguration=</varname> + is false. Defaults to yes.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCP] Section Options</title> + + <para>This section configures the DHCP Unique Identifier (DUID) value used by DHCP + protocol. DHCPv6 client protocol sends the DHCP Unique Identifier and the interface + Identity Association Identifier (IAID) to a DHCP server when acquiring a dynamic IPv6 + address. DHCPv4 client protocol sends IAID and DUID to the DHCP server when acquiring + a dynamic IPv4 address if <option>ClientIdentifier=duid</option>. IAID and DUID allows + a DHCP server to uniquely identify the machine and the interface requesting a DHCP IP. + To configure IAID and ClientIdentifier, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>The following options are understood:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>DUIDType=</varname></term> + <listitem><para>Specifies how the DUID should be generated. See + <ulink url="https://tools.ietf.org/html/rfc3315#section-9">RFC 3315</ulink> + for a description of all the options.</para> + + <para>The following values are understood: + <variablelist> + <varlistentry> + <term><option>vendor</option></term> + <listitem><para>If <literal>DUIDType=vendor</literal>, then the DUID value will be generated using + <literal>43793</literal> as the vendor identifier (systemd) and hashed contents of + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + This is the default if <varname>DUIDType=</varname> is not specified. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>uuid</option></term> + <listitem><para>If <literal>DUIDType=uuid</literal>, and <varname>DUIDRawData=</varname> is not set, + then the product UUID is used as a DUID value. If a system does not have valid product UUID, then + an application-specific + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + is used as a DUID value. About the application-specific machine ID, see + <citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>link-layer-time[:<replaceable>TIME</replaceable>]</option></term> + <term><option>link-layer</option></term> + <listitem><para>If <literal>link-layer-time</literal> or <literal>link-layer</literal> is specified, + then the MAC address of the interface is used as a DUID value. The value <literal>link-layer-time</literal> + can take additional time value after a colon, e.g. <literal>link-layer-time:2018-01-23 12:34:56 UTC</literal>. + The default time value is <literal>2000-01-01 00:00:00 UTC</literal>. + </para></listitem> + </varlistentry> + </variablelist> + </para> + + <para>In all cases, <varname>DUIDRawData=</varname> can be used to override the + actual DUID value that is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DUIDRawData=</varname></term> + <listitem><para>Specifies the DHCP DUID value as a single newline-terminated, hexadecimal string, with each + byte separated by <literal>:</literal>. The DUID that is sent is composed of the DUID type specified by + <varname>DUIDType=</varname> and the value configured here.</para> + + <para>The DUID value specified here overrides the DUID that + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + generates from the machine ID. To configure DUID per-network, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The configured DHCP DUID should conform to the specification in + <ulink url="http://tools.ietf.org/html/rfc3315#section-9">RFC 3315</ulink>, + <ulink url="http://tools.ietf.org/html/rfc6355">RFC 6355</ulink>. To configure IAID, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum> + </citerefentry>.</para> + + <example> + <title>A <option>DUIDType=vendor</option> with a custom value</title> + + <programlisting>DUIDType=vendor +DUIDRawData=00:00:ab:11:f9:2a:c2:77:29:f9:5c:00</programlisting> + + <para>This specifies a 14 byte DUID, with the type DUID-EN (<literal>00:02</literal>), enterprise number + 43793 (<literal>00:00:ab:11</literal>), and identifier value <literal>f9:2a:c2:77:29:f9:5c:00</literal>. + </para> + </example> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/nss-myhostname.xml b/man/nss-myhostname.xml new file mode 100644 index 0000000..8d5b549 --- /dev/null +++ b/man/nss-myhostname.xml @@ -0,0 +1,128 @@ +<?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-or-later --> + +<refentry id="nss-myhostname" conditional='ENABLE_NSS_MYHOSTNAME'> + + <refentryinfo> + <title>nss-myhostname</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>nss-myhostname</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>nss-myhostname</refname> + <refname>libnss_myhostname.so.2</refname> + <refpurpose>Hostname resolution for the locally configured system hostname</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>libnss_myhostname.so.2</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>nss-myhostname</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of + the GNU C Library (<command>glibc</command>), primarily providing hostname resolution for the locally configured + system hostname as returned by + <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>. The precise + hostnames resolved by this module are:</para> + + <itemizedlist> + <listitem><para>The local, configured hostname is resolved to + all locally configured IP addresses ordered by their scope, or + — if none are configured — the IPv4 address 127.0.0.2 (which + is on the local loopback) and the IPv6 address ::1 (which is the + local host).</para></listitem> + + <listitem><para>The hostnames <literal>localhost</literal> and + <literal>localhost.localdomain</literal> (as well as any hostname + ending in <literal>.localhost</literal> or <literal>.localhost.localdomain</literal>) + are resolved to the IP addresses 127.0.0.1 and ::1.</para></listitem> + + <listitem><para>The hostname <literal>_gateway</literal> is + resolved to all current default routing gateway addresses, + ordered by their metric. This assigns a stable hostname to the + current gateway, useful for referencing it independently of the + current network configuration state.</para></listitem> + </itemizedlist> + + <para>Various software relies on an always-resolvable local + hostname. When using dynamic hostnames, this is traditionally + achieved by patching <filename>/etc/hosts</filename> at the same + time as changing the hostname. This is problematic since it + requires a writable <filename>/etc/</filename> file system and is + fragile because the file might be edited by the administrator at + the same time. With <command>nss-myhostname</command> enabled, + changing <filename>/etc/hosts</filename> is unnecessary, and on + many systems, the file becomes entirely optional.</para> + + <para>To activate the NSS modules, add <literal>myhostname</literal> to the line starting with + <literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>.</para> + + <para>It is recommended to place <literal>myhostname</literal> either between <literal>resolve</literal> + and "traditional" modules like <literal>dns</literal>, or after them. In the first version, well-known + names like <literal>localhost</literal> and the machine hostname are given higher priority than the + external configuration. This is recommended when the external DNS servers and network are not absolutely + trusted. In the second version, external configuration is given higher priority and + <command>nss-myhostname</command> only provides a fallback mechanism. This might be suitable in closely + controlled networks, for example on a company LAN.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables + <command>nss-myhostname</command> correctly:</para> + + <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf --> +<programlisting>passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat + +# Either (untrusted network, see above): +hosts: mymachines resolve [!UNAVAIL=return] files <command>myhostname</command> dns +# Or (only trusted networks): +hosts: mymachines resolve [!UNAVAIL=return] files dns <command>myhostname</command> +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis</programlisting> + + <para>To test, use <command>glibc</command>'s <command>getent</command> tool:</para> + + <programlisting>$ getent ahosts `hostname` +::1 STREAM omega +::1 DGRAM +::1 RAW +127.0.0.2 STREAM +127.0.0.2 DGRAM +127.0.0.2 RAW</programlisting> + + <para>In this case, the local hostname is <varname>omega</varname>.</para> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/nss-mymachines.xml b/man/nss-mymachines.xml new file mode 100644 index 0000000..b2785df --- /dev/null +++ b/man/nss-mymachines.xml @@ -0,0 +1,127 @@ +<?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-or-later --> + +<refentry id="nss-mymachines" conditional='ENABLE_NSS_MYMACHINES'> + + <refentryinfo> + <title>nss-mymachines</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>nss-mymachines</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>nss-mymachines</refname> + <refname>libnss_mymachines.so.2</refname> + <refpurpose>Hostname resolution for local container instances</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>libnss_mymachines.so.2</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>nss-mymachines</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of + the GNU C Library (<command>glibc</command>), providing hostname resolution for the names of containers running + locally that are registered with + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. The + container names are resolved to the IP addresses of the specific container, ordered by their scope. This + functionality only applies to containers using network namespacing (see the description of + <option>--private-network</option> in + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>). + Note that the name that is resolved is the one registered with <command>systemd-machined</command>, which + may be different than the hostname configured inside of the container.</para> + + <para>To activate the NSS module, add <literal>mymachines</literal> to the line starting with + <literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>.</para> + + <para>It is recommended to place <literal>mymachines</literal> before the <literal>resolve</literal> or + <literal>dns</literal> entry of the <literal>hosts:</literal> line of + <filename>/etc/nsswitch.conf</filename> in order to make sure that its mappings are preferred over other + resolvers such as DNS.</para> + </refsect1> + + <refsect1> + <title>Configuration in <filename>/etc/nsswitch.conf</filename></title> + + <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables + <command>nss-mymachines</command> correctly:</para> + + <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf --> + <programlisting>passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat + +hosts: <command>mymachines</command> resolve [!UNAVAIL=return] files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis</programlisting> + + </refsect1> + + <refsect1> + <title>Example: Mappings provided by <filename>nss-mymachines</filename></title> + + <para>The container <literal>rawhide</literal> is spawned using + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>: + </para> + + <programlisting># systemd-nspawn -M rawhide --boot --network-veth --private-users=pick +Spawning container rawhide on /var/lib/machines/rawhide. +Selected user namespace base 20119552 and range 65536. +... + +$ machinectl --max-addresses=3 +MACHINE CLASS SERVICE OS VERSION ADDRESSES +rawhide container systemd-nspawn fedora 30 169.254.40.164 fe80::94aa:3aff:fe7b:d4b9 + +$ ping -c1 rawhide +PING rawhide(fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide)) 56 data bytes +64 bytes from fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide): icmp_seq=1 ttl=64 time=0.045 ms +... +$ ping -c1 -4 rawhide +PING rawhide (169.254.40.164) 56(84) bytes of data. +64 bytes from 169.254.40.164 (169.254.40.164): icmp_seq=1 ttl=64 time=0.064 ms +... + +# machinectl shell rawhide /sbin/ip a +Connected to machine rawhide. Press ^] three times within 1s to exit session. +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + ... +2: host0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 + link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 + inet 169.254.40.164/16 brd 169.254.255.255 scope link host0 + valid_lft forever preferred_lft forever + inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link + valid_lft forever preferred_lft forever +Connection to machine rawhide terminated. +</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/nss-resolve.xml b/man/nss-resolve.xml new file mode 100644 index 0000000..78c9203 --- /dev/null +++ b/man/nss-resolve.xml @@ -0,0 +1,91 @@ +<?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-or-later --> + +<refentry id="nss-resolve" conditional='ENABLE_NSS_RESOLVE'> + + <refentryinfo> + <title>nss-resolve</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>nss-resolve</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>nss-resolve</refname> + <refname>libnss_resolve.so.2</refname> + <refpurpose>Hostname resolution via <filename>systemd-resolved.service</filename></refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>libnss_resolve.so.2</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>nss-resolve</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of the + GNU C Library (<command>glibc</command>) enabling it to resolve hostnames via the + <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry> local network + name resolution service. It replaces the <command>nss-dns</command> plug-in module that traditionally resolves + hostnames via DNS.</para> + + <para>To activate the NSS module, add <literal>resolve [!UNAVAIL=return]</literal> to the line starting + with <literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>. Specifically, it is + recommended to place <literal>resolve</literal> early in <filename>/etc/nsswitch.conf</filename>'s + <literal>hosts:</literal> line. It should be before the <literal>files</literal> entry, since + <filename>systemd-resolved</filename> supports <filename>/etc/hosts</filename> internally, but with + caching. To the contrary, it should be after <literal>mymachines</literal>, to give hostnames given to + local VMs and containers precedence over names received over DNS. Finally, we recommend placing + <literal>dns</literal> somewhere after <literal>resolve</literal>, to fall back to + <command>nss-dns</command> if <filename>systemd-resolved.service</filename> is not available.</para> + + <para>Note that <command>systemd-resolved</command> will synthesize DNS resource records in a few cases, + for example for <literal>localhost</literal> and the current local hostname, see + <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + the full list. This duplicates the functionality of + <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>, but + it is still recommended (see examples below) to keep <command>nss-myhostname</command> configured in + <filename>/etc/nsswitch.conf</filename>, to keep those names resolveable if + <command>systemd-resolved</command> is not running.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables <command>nss-resolve</command> + correctly:</para> + + <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf --> +<programlisting>passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat + +hosts: mymachines <command>resolve [!UNAVAIL=return]</command> files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/nss-systemd.xml b/man/nss-systemd.xml new file mode 100644 index 0000000..1fee8cc --- /dev/null +++ b/man/nss-systemd.xml @@ -0,0 +1,137 @@ +<?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-or-later --> + +<refentry id="nss-systemd" conditional='ENABLE_NSS_SYSTEMD'> + + <refentryinfo> + <title>nss-systemd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>nss-systemd</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>nss-systemd</refname> + <refname>libnss_systemd.so.2</refname> + <refpurpose>UNIX user and group name resolution for user/group lookup via Varlink</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>libnss_systemd.so.2</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>nss-systemd</command> is a plug-in module for the GNU Name Service Switch (NSS) + functionality of the GNU C Library (<command>glibc</command>), providing UNIX user and group name + resolution for services implementing the <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record + Lookup API via Varlink</ulink>, such as the system and service manager + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> (for its + <varname>DynamicUser=</varname> feature, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details), + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para>This module also ensures that the root and nobody users and groups (i.e. the users/groups with the UIDs/GIDs + 0 and 65534) remain resolvable at all times, even if they aren't listed in <filename>/etc/passwd</filename> or + <filename>/etc/group</filename>, or if these files are missing.</para> + + <para>This module preferably utilizes + <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for resolving users and groups, but also works without the service running.</para> + + <para>To activate the NSS module, add <literal>systemd</literal> to the lines starting with + <literal>passwd:</literal> and <literal>group:</literal> in <filename>/etc/nsswitch.conf</filename>.</para> + + <para>It is recommended to place <literal>systemd</literal> after the <literal>files</literal> or + <literal>compat</literal> entry of the <filename>/etc/nsswitch.conf</filename> lines so that + <filename>/etc/passwd</filename> and <filename>/etc/group</filename> based mappings take precedence.</para> + </refsect1> + + <refsect1> + <title>Configuration in <filename>/etc/nsswitch.conf</filename></title> + + <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables + <command>nss-systemd</command> correctly:</para> + + <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf --> + <programlisting>passwd: compat <command>systemd</command> +group: compat [SUCCESS=merge] <command>systemd</command> +shadow: compat + +hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis</programlisting> + + </refsect1> + + <refsect1> + <title>Example: Mappings provided by <filename>systemd-machined.service</filename></title> + + <para>The container <literal>rawhide</literal> is spawned using + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>: + </para> + + <programlisting># systemd-nspawn -M rawhide --boot --network-veth --private-users=pick +Spawning container rawhide on /var/lib/machines/rawhide. +Selected user namespace base 20119552 and range 65536. +... + +$ machinectl --max-addresses=3 +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:/:/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: +vg-rawhide-81:*:20119633: + +$ ps -o user:15,pid,tty,command -e|grep '^vu-rawhide' +vu-rawhide-0 692 ? /usr/lib/systemd/systemd +vu-rawhide-0 731 ? /usr/lib/systemd/systemd-journald +vu-rawhide-192 734 ? /usr/lib/systemd/systemd-networkd +vu-rawhide-193 738 ? /usr/lib/systemd/systemd-resolved +vu-rawhide-0 742 ? /usr/lib/systemd/systemd-logind +vu-rawhide-81 744 ? /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only +vu-rawhide-0 746 ? /usr/sbin/sshd -D ... +vu-rawhide-0 752 ? /usr/lib/systemd/systemd --user +vu-rawhide-0 753 ? (sd-pam) +vu-rawhide-0 1628 ? login -- zbyszek +vu-rawhide-1000 1630 ? /usr/lib/systemd/systemd --user +vu-rawhide-1000 1631 ? (sd-pam) +vu-rawhide-1000 1637 pts/8 -zsh +</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/oomctl.xml b/man/oomctl.xml new file mode 100644 index 0000000..b5e8a44 --- /dev/null +++ b/man/oomctl.xml @@ -0,0 +1,86 @@ +<?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-or-later --> + +<refentry id="oomctl" conditional='ENABLE_OOMD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>oomctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>oomctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>oomctl</refname> + <refpurpose>Analyze the state stored in <command>systemd-oomd</command></refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>oomctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>oomctl</command> may be used to get information about the various contexts read in by + the <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> userspace + out-of-memory (OOM) killer, + <citerefentry><refentrytitle>systemd-oomd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>dump</command></term> + + <listitem><para>Show the current state of the cgroup(s) and system context(s) stored by + <command>systemd-oomd</command>.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/oomd.conf.xml b/man/oomd.conf.xml new file mode 100644 index 0000000..35a0686 --- /dev/null +++ b/man/oomd.conf.xml @@ -0,0 +1,88 @@ +<?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-or-later --> + +<refentry id="oomd.conf" conditional='ENABLE_OOMD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>oomd.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>oomd.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>oomd.conf</refname> + <refname>oomd.conf.d</refname> + <refpurpose>Global <command>systemd-oomd</command> configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/oomd.conf</filename></para> + <para><filename>/etc/systemd/oomd.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/oomd.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These files configure the various parameters of the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> userspace + out-of-memory (OOM) killer, + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + See <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>[OOM] Section Options</title> + + <para>The following options are available in the [OOM] section:</para> + + <variablelist class='config-directives'> + <varlistentry> + <term><varname>SwapUsedLimitPercent=</varname></term> + + <listitem><para>Sets the limit for swap usage on the system before <command>systemd-oomd</command> will + take action. If the percentage of swap used on the system is more than what is defined here, + <command>systemd-oomd</command> will act on eligible descendant cgroups, starting from the ones with the + highest swap usage to the lowest swap usage. Which cgroups are monitored and what + action gets taken depends on what the unit has configured for <varname>ManagedOOMSwap=</varname>. + Takes a percentage value between 0% and 100%, inclusive. Defaults to 90%.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultMemoryPressureLimitPercent=</varname></term> + + <listitem><para>Sets the limit for memory pressure on the unit's cgroup before <command>systemd-oomd</command> + will take action. A unit can override this value with <varname>ManagedOOMMemoryPressureLimitPercent=</varname>. + The memory pressure for this property represents the fraction of time in a 10 second window in which all tasks + in the cgroup were delayed. For each monitored cgroup, if the memory pressure on that cgroup exceeds the + limit set for more than 30 seconds, <command>systemd-oomd</command> will act on eligible descendant cgroups, + starting from the ones with the most reclaim activity to the least reclaim activity. Which cgroups are + monitored and what action gets taken depends on what the unit has configured for + <varname>ManagedOOMMemoryPressure=</varname>. Takes a percentage value between 0% and 100%, inclusive. + Defaults to 60%.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>oomctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/org.freedesktop.LogControl1.xml b/man/org.freedesktop.LogControl1.xml new file mode 100644 index 0000000..da6dd76 --- /dev/null +++ b/man/org.freedesktop.LogControl1.xml @@ -0,0 +1,129 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.LogControl1" + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.LogControl1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.LogControl1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.LogControl1</refname> + <refpurpose>D-Bus interface to query and set logging configuration</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para><interfacename>org.freedesktop.LogControl1</interfacename> is a generic interface that is intended + to be used by any daemon which allows the log level and target to be set over D-Bus. It is implemented by + various daemons that are part of the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> suite.</para> + + <para>It is assumed that those settings are global for the whole program, so a fixed object path is + used. The interface should always be available under the path + <filename>/org/freedesktop/LogControl1</filename>.</para> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The following interface is exposed:</para> + + <programlisting executable="systemd" node="/org/freedesktop/LogControl1" interface="org.freedesktop.LogControl1"> +node /org/freedesktop/LogControl1 { + interface org.freedesktop.LogControl1 { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogLevel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogTarget = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s SyslogIdentifier = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.LogControl1"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.LogControl1"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogLevel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogTarget"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para><varname>LogLevel</varname> describes the + <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>-style + log-level, and should be one of <literal>emerg</literal>, <literal>alert</literal>, + <literal>crit</literal>, <literal>err</literal>, <literal>warning</literal>, <literal>notice</literal>, + <literal>info</literal>, <literal>debug</literal>, in order of increasing verbosity.</para> + + <para><varname>LogTarget</varname> describes the log target (mechanism). It should be one of + <literal>console</literal> (log to the console or standard output), + <literal>kmsg</literal> (log to the kernel ring buffer), + <literal>journal</literal> (log to the journal natively, see + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>), + <literal>syslog</literal> (log using the + <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> call). + </para> + + <para>Those two properties are writable, so they may be set by sufficiently privileged users.</para> + + <para><varname>SyslogIdentifier</varname> is a read-only property that shows the "syslog identifier". + It is a short string that identifies the program that is the source of log messages that is passed to + the <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> call. + </para> + </refsect2> + </refsect1> + + <refsect1> + <title>Tools</title> + + <para><command>journalctl</command> option <option>-p</option>/<option>--priority=</option> may be used + to filter log messages by log level, option <option>-t</option>/<option>--identifier=</option> may be + used to by the syslog identifier, and filters like <literal>_TRANSPORT=syslog</literal>, + <literal>_TRANSPORT=journal</literal>, and <literal>_TRANSPORT=kernel</literal> may be used to filter + messages by the mechanism through which they reached <command>systemd-journald</command>.</para> + + <para><command>systemctl log-level</command> and <command>systemctl log-target</command> verbs may be + used to query and set the <varname>LogLevel</varname> and <varname>LogTarget</varname> properties of the + service manager. <command>systemctl service-log-level</command> and <command>systemctl + service-log-target</command> may similarly be used for individual services. (Services must have the + <varname>BusName=</varname> property set and must implement the interface described here. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details about <varname>BusName=</varname>.)</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.home1.xml b/man/org.freedesktop.home1.xml new file mode 100644 index 0000000..b977e1b --- /dev/null +++ b/man/org.freedesktop.home1.xml @@ -0,0 +1,508 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.home1" conditional='ENABLE_HOMED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.home1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.home1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.home1</refname> + <refpurpose>The D-Bus interface of systemd-homed</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para><citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service which may be used to create, remove, change or inspect home areas. This page + describes the D-Bus interface. + </para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The service exposes the following interfaces on the Manager object on the bus:</para> + + <programlisting executable="systemd-homed" node="/org/freedesktop/home1" interface="org.freedesktop.home1.Manager"> +node /org/freedesktop/home1 { + interface org.freedesktop.home1.Manager { + methods: + GetHomeByName(in s user_name, + out u uid, + out s home_state, + out u gid, + out s real_name, + out s home_directory, + out s shell, + out o bus_path); + GetHomeByUID(in u uid, + out s user_name, + out s home_state, + out u gid, + out s real_name, + out s home_directory, + out s shell, + out o bus_path); + GetUserRecordByName(in s user_name, + out s user_record, + out b incomplete, + out o bus_path); + GetUserRecordByUID(in u uid, + out s user_record, + out b incomplete, + out o bus_path); + ListHomes(out a(susussso) home_areas); + ActivateHome(in s user_name, + in s secret); + DeactivateHome(in s user_name); + RegisterHome(in s user_record); + UnregisterHome(in s user_name); + CreateHome(in s user_record); + RealizeHome(in s user_name, + in s secret); + RemoveHome(in s user_name); + FixateHome(in s user_name, + in s secret); + AuthenticateHome(in s user_name, + in s secret); + UpdateHome(in s user_record); + ResizeHome(in s user_name, + in t size, + in s secret); + ChangePasswordHome(in s user_name, + in s new_secret, + in s old_secret); + LockHome(in s user_name); + UnlockHome(in s user_name, + in s secret); + AcquireHome(in s user_name, + in s secret, + in b please_suspend, + out h send_fd); + RefHome(in s user_name, + in b please_suspend, + out h send_fd); + ReleaseHome(in s user_name); + LockAllHomes(); + DeactivateAllHomes(); + properties: + readonly a(sso) AutoLogin = [...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetHomeByName()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetHomeByUID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUserRecordByName()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUserRecordByUID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListHomes()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ActivateHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="DeactivateHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RegisterHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnregisterHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CreateHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RealizeHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RemoveHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="FixateHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AuthenticateHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UpdateHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResizeHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ChangePasswordHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LockHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnlockHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AcquireHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RefHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReleaseHome()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LockAllHomes()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="DeactivateAllHomes()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AutoLogin"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>GetHomeByName()</function> returns basic user information (a minimal subset of the full + user record), provided a user name. The information supplied more or less matches what + <citerefentry project="man-pages"><refentrytitle>getpwnam</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns: + the numeric UID and GID, the real name, home directory and shell. In addition it returns a state + identifier describing the state the user's home directory is in, as well as a bus path referring to the + bus object encapsulating the user record and home directory. This object implements the + <classname>org.freedesktop.home1.Home</classname> interface documented below.</para> + + <para><function>GetHomeByUID()</function> is similar to <function>GetHomeByName()</function> but + acquires the information based on the numeric UID of the user.</para> + + <para><function>GetUserRecordByName()</function> is also similar to + <function>GetHomeByName()</function> but returns the full JSON user record data instead of the broken + down records. An additional returned boolean indicates whether the record is complete or not. A record + is considered complete when its <literal>privileged</literal> section is included, and incomplete if it + was removed (see <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink> for details + about the various sections of a user record). Generally, only privileged clients and clients running + under the identity of the user itself get access to the <literal>privileged</literal> section and will + thus see complete records.</para> + + <para><function>GetUserRecordByUID()</function> is similar to <function>GetUserRecordByName()</function> + but returns the user record matching the specified numeric UID.</para> + + <para><function>ListHomes()</function> returns an array of all locally managed users. The array + contains the same fields <function>GetHomeByName()</function> returns: user name, numeric UID, state, + numeric GID, real name, home directory, shell and bus path of the matching bus object.</para> + + <para><function>ActivateHome()</function> activates (i.e. mounts) the home directory of the specified + user. The second argument shall contain a user record consisting only of a <literal>secret</literal> + section (all other sections should be stripped, see <ulink url="https://systemd.io/USER_RECORD">JSON + User Records</ulink> for details), and should contain only the secret credentials necessary for + unlocking the home directory. Typically a client would invoke this function first with an entirely + empty record (which is possibly sufficient if single-factor authentication with a plugged-in security + token is configured), and would then retry with a record populated with more information, depending on + the returned error code, in case more credentials are necessary. This function is synchronous and + returns only after the home directory was fully activated (or the operation failed), which might take + some time. Clients must be prepared for that, and typically should extend the D-Bus method call + timeout accordingly. This method is equivalent to the <function>Activate()</function> method on the + <classname>org.freedesktop.home1.Home</classname> interface documented below, but may be called on the + manager object and takes a user name as additional argument, instead.</para> + + <para><function>DeactivateHome()</function> deactivates (i.e. unmounts) the home directory of the + specified user. It is equivalent to the <function>Deactivate()</function> method on the + <classname>org.freedesktop.home1.Home</classname> interface documented below.</para> + + <para><function>RegisterHome()</function> registers a new home directory locally. It receives the JSON + user record as only argument (which typically excludes the <literal>secret</literal> + section). Registering a home directory just makes the user record known to the system, it does not + create a home directory or such (which is expected to exist already, or created later). This operation + is useful to register home directories locally that are not located where + <filename>systemd-homed.service</filename> would find them automatically.</para> + + <para><function>UnregisterHome()</function> unregisters an existing home directory. It takes a user + name as argument and undoes what <function>RegisterHome()</function> does. It does not attempt to + remove the home directory itself, it just unregisters it with the local system. Note that if the home + directory is placed where <filename>systemd-homed.service</filename> looks for home directories anyway + this call will only undo fixation (see below), but the record will remain known to + <filename>systemd-homed.service</filename> and be listed among known records. Since the user record is + embedded into the home directory this operation generally does not discard data belonging to the user + or their record. This method is equivalent to + <function>Unregister()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>CreateHome()</function> registers and creates a new home directory. This takes a fully + specified JSON user record as argument (including the <literal>secret</literal> section). This registers + the user record locally and creates a home directory matching it, depending on the settings specified + in the record in combination with local configuration.</para> + + <para><function>RealizeHome()</function> creates a home directory whose user record is already + registered locally. This takes a user name plus a user record consisting only of the + <literal>secret</literal> section. Invoking <function>RegisterHome()</function> followed by + <function>RealizeHome()</function> is mostly equivalent to calling <function>CreateHome()</function>, + except that the latter combines the two in atomic fashion. This method is equivalent to + <function>Realize()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>RemoveHome()</function> unregisters a user record locally, and removes the home + directory belonging to it, if it is accessible. It takes a user name as argument. This method is equivalent to + <function>Remove()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>FixateHome()</function> <literal>fixates</literal> an automatically discovered home + directory. <filename>systemd-homed.service</filename> automatically discovers home directories dropped + in our plugged in and adds them to the runtime list of user records it manages. A user record + discovered that way may be <literal>fixated</literal>, in which case it is copied out of the home + directory, onto persistent storage, to fixate the UID/GID assignment of the record, and extract + additional (typically previously encrypted) user record data from the home directory. A home directory + mus be fixated before it can be logged into. This method call takes a user name and a JSON user record + consisting only of the <literal>secret</literal> section as argument. This method is equivalent to + <function>Fixate()</function> on the <classname>org.freedesktop.home1.Home</classname> interface.</para> + + <para><function>AuthenticateHome()</function> checks passwords or other authentication credentials + associated with the home directory. It takes a user name and a JSON user record consisting only of the + <literal>secret</literal> section as argument. Note that many of the other method calls authenticate + the user first, in order to execute some other operation. This method call only authenticates and + executes no further operation. Like <function>ActivateHome()</function> it is usually first invoked + with an empty JSON user record, which is then populated for subsequent tries with additional + authentication data supplied. This method is equivalent to + <function>Authenticate()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>UpdateHome()</function> updates a locally registered user record. Takes a fully + specified JSON user record as argument (including the <literal>secret</literal> section). A user with a + matching name and realm must be registered locally already, and the last change timestamp of the newly + supplied record must be newer than the previously existing user record. Note this operation updates the + user record only, it does not propagate passwords/authentication tokens from the user record to the + storage back-end, or resizes the storage back-end. Typically a home directory is first updated, and then + the password of the underlying storage updated using <function>ChangePasswordHome()</function> as well + as the storage resized using <function>ResizeHome()</function>. This method is equivalent to + <function>Update()</function> on the <classname>org.freedesktop.home1.Home</classname> interface.</para> + + <para><function>ResizeHome()</function> resizes the storage associated with a user record. Takes a user + name, a disk size in bytes and a user record consisting only of the <literal>secret</literal> section + as argument. If the size is specified as <constant>UINT64_MAX</constant> the storage is resized to the + size already specified in the user record. Typically, if the user record is updated using + <function>UpdateHome()</function> above this is used to propagate the size configured there-in down to + the underlying storage back-end. This method is equivalent to + <function>Resize()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>ChangePasswordHome()</function> changes the passwords/authentication tokens of a home + directory. Takes a user name, and two JSON user record objects, each consisting only of the + <literal>secret</literal> section, for the old and for the new passwords/authentication tokens. If the + user record with the new passwords/authentication token data is specified as empty the existing user + record's settings are propagated down to the home directory storage. This is typically used after a + user record is updated using <function>UpdateHome()</function> in order to propagate the + secrets/authentication tokens down to the storage. This method is equivalent to + <function>ChangePassword()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>LockHome()</function> temporarily suspends access to a home directory, flushing out any + cryptographic keys from memory. This is only supported on some back-ends, and usually done during system + suspend, in order to effectively secure home directories while the system is sleeping. Takes a user + name as single argument. If an application attempts to access a home directory while it is locked it + will typically freeze until the home directory is unlocked again. This method is equivalent to + <function>Lock()</function> on the <classname>org.freedesktop.home1.Home</classname> interface.</para> + + <para><function>UnlockHome()</function> undoes the effect of <function>LockHome()</function>. Takes a + user name and a user record consisting only of the <literal>secret</literal> section as arguments. This + method is equivalent to <function>Unlock()</function> on the + <classname>org.freedesktop.home1.Home</classname> interface.</para> + + <para><function>AcquireHome()</function> activates or unlocks a home directory in a reference counted + mode of operation. Takes a user name and user record consisting only of <literal>secret</literal> + section as argument. If the home directory is not active yet, it is activated. If it is currently + locked it is unlocked. After completion a reference to the activation/unlocking of the home directory + is returned via a file descriptor. When the last client which acquired such a file descriptor closes it + the home directory is automatically deactivated again. This method is typically invoked when a user + logs in, and the file descriptor is held until the user logs out again, thus ensuring the user's home + directory can be unmounted automatically again in a robust fashion, when the user logs out. The third + argument is a boolean which indicates whether the client invoking the call is able to automatically + re-authenticate when the system comes back from suspending. It should be set by all clients that + implement a secure lock screen running outside of the user's context, that is brought up when the + system comes back from suspend and can be used to re-acquire the credentials to unlock the user's home + directory. If a home directory has at least one client with an open reference to the home directory + that does not support this it is not suspended automatically at system suspend, otherwise it is. This + method is equivalent to <function>Acquire()</function> on the + <classname>org.freedesktop.home1.Home</classname> interface.</para> + + <para><function>RefHome()</function> is similar to <function>AcquireHome()</function> but takes no user + record with <literal>secret</literal> section, i.e. will take an additional reference to an already + activated/unlocked home directory without attempting to activate/unlock it itself. It will fail if the + home directory is not already activated. This method is equivalent to + <function>Ref()</function> on the <classname>org.freedesktop.home1.Home</classname> + interface.</para> + + <para><function>ReleaseHome()</function> releases a home directory again, if all file descriptors + referencing it are already closed, that where acquired through <function>AcquireHome()</function> or + <function>RefHome()</function>. Note that this call does not actually cause the deactivation of the + home directory (which happens automatically when the last referencing file descriptor is closed), but + is simply a synchronization mechanism that allows delaying of the user session's termination until any + triggered deactivation is completed. This method is equivalent to <function>Release()</function> on the + <classname>org.freedesktop.home1.Home</classname> interface.</para> + + <para><function>LockAllHomes()</function> locks all active home directories that only have references + that opted into automatic suspending during system suspend. This is usually invoked automatically + shortly before system suspend.</para> + + <para><function>DeactivateAllHomes()</function> deactivates all home areas that are currently + active. This is usually invoked automatically shortly before system shutdown.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>AutoLogin</varname> exposes an array of structures consisting of user name, seat name + and object path of an home directory object. All locally managed users that have the + <literal>autoLogin</literal> field set are listed here, with the seat name they are associated with. A + display manager may watch this property and pre-fill the login screen with the users exposed this + way.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>The Home Object</title> + + <programlisting executable="systemd-homed" node="/org/freedesktop/home1/home" interface="org.freedesktop.home1.Home"> +node /org/freedesktop/home1/home { + interface org.freedesktop.home1.Home { + methods: + Activate(in s secret); + Deactivate(); + Unregister(); + Realize(in s secret); + Remove(); + Fixate(in s secret); + Authenticate(in s secret); + Update(in s user_record); + Resize(in t size, + in s secret); + ChangePassword(in s new_secret, + in s old_secret); + Lock(); + Unlock(in s secret); + Acquire(in s secret, + in b please_suspend, + out h send_fd); + Ref(in b please_suspend, + out h send_fd); + Release(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UserName = '...'; + readonly u UID = ...; + readonly (suusss) UnixRecord = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s State = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly (sb) UserRecord = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.DBus.ObjectManager { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.DBus.ObjectManager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Home"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.DBus.ObjectManager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Home"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Activate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Deactivate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Unregister()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Realize()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Remove()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Fixate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Authenticate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Update()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Resize()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ChangePassword()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Lock()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Unlock()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Acquire()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Ref()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Release()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UserName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnixRecord"/> + + <variablelist class="dbus-property" generated="True" extra-ref="State"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UserRecord"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Activate()</function>, <function>Deactivate()</function>, + <function>Unregister()</function>, <function>Realize()</function>, <function>Remove()</function>, + <function>Fixate()</function>, <function>Authenticate()</function>, <function>Update()</function>, + <function>Resize()</function>, <function>ChangePassword()</function>, <function>Lock()</function>, + <function>Unlock()</function>, <function>Acquire()</function>, <function>Ref()</function>, + <function>Release()</function> operate like their matching counterparts on the + <classname>org.freedesktop.home1.Manager</classname> interface (see above). The main difference is that + they are methods of the home directory objects, and hence carry no additional user name + parameter. Which of the two flavors of methods to call depends on the handles to the user known on the + client side: if only the user name is known, it's preferable to use the methods on the manager object + since they operate with user names only. If however the home object path was already acquired some way + it is preferable to operate on the <classname>org.freedesktop.home1.Home</classname> objects + instead.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>UserName</varname> contains the user name of the user account/home directory.</para> + + <para><varname>UID</varname> contains the numeric UNIX UID of the user account.</para> + + <para><varname>UnixRecord</varname> contains a structure encapsulating the six fields a + <structname>struct passwd</structname> typically contains (the password field is suppressed).</para> + + <para><varname>State</varname> exposes the current state home the home directory.</para> + + <para><varname>UserRecord</varname> contains the full JSON user record string of the user account.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/org.freedesktop.hostname1.xml b/man/org.freedesktop.hostname1.xml new file mode 100644 index 0000000..f8e199c --- /dev/null +++ b/man/org.freedesktop.hostname1.xml @@ -0,0 +1,368 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="org.freedesktop.hostname1" conditional='ENABLE_HOSTNAMED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.hostname1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.hostname1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.hostname1</refname> + <refpurpose>The D-Bus interface of systemd-hostnamed</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service that can be used to control the hostname and related machine metadata from user + programs. This page describes the hostname semantics and the D-Bus interface.</para> + </refsect1> + + <refsect1> + <title>The D-Bus API</title> + + <para>The service exposes the following interfaces on the bus:</para> + + <programlisting executable="systemd-hostnamed" node="/org/freedesktop/hostname1" interface="org.freedesktop.hostname1"> +node /org/freedesktop/hostname1 { + interface org.freedesktop.hostname1 { + methods: + SetHostname(in s hostname, + in b interactive); + SetStaticHostname(in s hostname, + in b interactive); + SetPrettyHostname(in s hostname, + in b interactive); + SetIconName(in s icon, + in b interactive); + SetChassis(in s chassis, + in b interactive); + SetDeployment(in s deployment, + in b interactive); + SetLocation(in s location, + in b interactive); + GetProductUUID(in b interactive, + out ay uuid); + properties: + readonly s Hostname = '...'; + readonly s StaticHostname = '...'; + readonly s PrettyHostname = '...'; + readonly s IconName = '...'; + readonly s Chassis = '...'; + readonly s Deployment = '...'; + readonly s Location = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KernelName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KernelRelease = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KernelVersion = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OperatingSystemPrettyName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OperatingSystemCPEName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HomeURL = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.hostname1"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.hostname1"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetHostname()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetStaticHostname()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetPrettyHostname()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetIconName()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetChassis()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDeployment()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLocation()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProductUUID()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Hostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StaticHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrettyHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IconName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Chassis"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Deployment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Location"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KernelName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KernelRelease"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KernelVersion"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OperatingSystemPrettyName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OperatingSystemCPEName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HomeURL"/> + + <!--End of Autogenerated section--> + + <para>Whenever the hostname or other metadata is changed via the daemon, + <function>PropertyChanged</function> signals are sent out to subscribed clients. Changing a hostname + using this interface is authenticated via + <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink>.</para> + </refsect1> + + <refsect1> + <title>Semantics</title> + + <para>The <emphasis>static (configured) hostname</emphasis> is the one configured in + <filename>/etc/hostname</filename>. It is chosen by the local user. It is not always in sync with the + current hostname as returned by the + <citerefentry project="man-pages"><refentrytitle>gethostname</refentrytitle><manvolnum>3</manvolnum></citerefentry> + system call. If no hostname is configured this property will be the empty string. Setting this property + to the empty string will remove <filename>/etc/hostname</filename>. This property should be an + internet-style hostname, 7-bit lowercase ASCII, no special chars/spaces.</para> + + <para>The <emphasis>transient (dynamic) hostname</emphasis> is the one configured via the kernel's + <citerefentry project="man-pages"><refentrytitle>sethostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + It can be different from the static hostname if DHCP or mDNS have been configured to change the name + based on network information. <!-- FIXME: it's not DHCP that configures this... --> + This property is never empty. If no hostname is set this will default to + <literal>&FALLBACK_HOSTNAME;</literal> (configurable at compilation time). Setting this property to the + empty string will reset the dynamic hostname to the static hostname. If no static hostname is + configured the dynamic hostname will be reset to <literal>&FALLBACK_HOSTNAME;</literal>. This property + should be an internet-style hostname, 7-bit lowercase ASCII, no special chars/spaces.</para> + + <para>The <emphasis>pretty hostname</emphasis> is a free-form UTF-8 hostname for presentation to the + user. User interfaces should ensure that the pretty hostname and the static hostname stay in sync. + I.e. when the former is <literal>Lennart’s Computer</literal> the latter should be + <literal>lennarts-computer</literal>. If no pretty hostname is set this setting will be the empty + string. Applications should then find a suitable fallback, such as the dynamic hostname.</para> + + <para>The <emphasis>icon name</emphasis> is a name following the XDG icon naming spec. If not set, + information such as the chassis type (see below) is used to find a suitable fallback icon name + (i.e. <literal>computer-laptop</literal> vs. <literal>computer-desktop</literal> is picked based on the + chassis information). If no such data is available, the empty string is returned. In that case an application + should fall back to a replacement icon, for example <literal>computer</literal>. If this property is set + to the empty string, the automatic fallback name selection is enabled again.</para> + + <para>The <emphasis>chassis type</emphasis> should be one of the currently defined chassis types: + <literal>desktop</literal>, <literal>laptop</literal>, <literal>server</literal>, + <literal>tablet</literal>, <literal>handset</literal>, as well as the special chassis types + <literal>vm</literal> and <literal>container</literal> for virtualized systems. Note that in most cases + the chassis type will be determined automatically from DMI/SMBIOS/ACPI firmware information. Writing to + this setting is hence useful only to override misdetected chassis types, or to configure the chassis type if + it could not be auto-detected. Set this property to the empty string to reenable the automatic detection of + the chassis type from firmware information.</para> + + <para>Note that <filename>systemd-hostnamed</filename> starts only on request and terminates after a + short idle period. This effectively means that <function>PropertyChanged</function> messages are not sent + out for changes made directly on the files (as in: administrator edits the files with vi). This is + the intended behavior: manual configuration changes should require manual reloading.</para> + + <para>The transient (dynamic) hostname maps directly to the kernel hostname. This hostname should be + assumed to be highly dynamic, and hence should be watched directly, without depending on + <function>PropertyChanged</function> messages from <filename>systemd-hostnamed</filename>. To accomplish + this, open <filename>/proc/sys/kernel/hostname</filename> and + <citerefentry project="man-pages"><refentrytitle>poll</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for <constant>SIGHUP</constant> which is triggered by the kernel every time the hostname changes. Again: + this is special for the transient (dynamic) hostname, and does not apply to the configured (fixed) + hostname.</para> + + <para>Applications may read the hostname data directly if hostname change notifications + are not necessary. Use + <citerefentry project="man-pages"><refentrytitle>gethostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <filename>/etc/hostname</filename> (possibly with per-distribution fallbacks), and + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for that. For more information on these files and syscalls see the respective man pages.</para> + + <refsect2> + <title>Methods and Properties</title> + + <para><function>SetHostname()</function> sets the transient (dynamic) hostname which is exposed by the + <varname>Hostname</varname> property. If empty, the transient hostname is set to the static hostname. + </para> + + <para><function>SetStaticHostname()</function> sets the static hostname which is exposed by the + <varname>StaticHostname</varname> property. If empty, the built-in default of + <literal>&FALLBACK_HOSTNAME;</literal> is used.</para> + + <para><function>SetPrettyHostname()</function> sets the pretty hostname which is exposed by the + <varname>PrettyHostname</varname> property.</para> + + <para><function>SetIconName()</function>, <function>SetChassis()</function>, + <function>SetDeployment()</function>, and <function>SetLocation()</function> set the properties + <varname>IconName</varname> (the name of the icon representing for the machine), + <varname>Chassis</varname> (the machine form factor), <varname>Deployment</varname> (the system + deployment environment), and <varname>Location</varname> (physical system location), respectively. + </para> + + <para><varname>PrettyHostname</varname>, <varname>IconName</varname>, <varname>Chassis</varname>, + <varname>Deployment</varname>, and <varname>Location</varname> are stored in + <filename>/etc/machine-info</filename>. See + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + the semantics of those settings.</para> + + <para><function>GetProductUUID()</function> returns the "product uuid" as exposed by the kernel based + on DMI information in <filename>/sys/class/dmi/id/product_uuid</filename>. Reading the file directly + requires root privileges, and this method allows access to unprivileged clients through the polkit + framework.</para> + + <para><varname>KernelName</varname>, <varname>KernelRelease</varname>, and + <varname>KernelVersion</varname> expose the kernel name (e.g. <literal>Linux</literal>), release + (e.g. <literal>5.0.0-11</literal>), and version (i.e. the build number, e.g. <literal>#11</literal>) as + reported by + <citerefentry project="man-pages"><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>. + <varname>OperatingSystemPrettyName</varname>, <varname>OperatingSystemCPEName</varname>, and + <varname>HomeURL</varname> expose the <varname>PRETTY_NAME=</varname>, <varname>CPE_NAME=</varname> and + <varname>HOME_URL=</varname> fields from + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The + purpose of those properties is to allow remote clients to access this information over D-Bus. Local + clients can access the information directly.</para> + </refsect2> + + <refsect2> + <title>Security</title> + + <para>The <varname>interactive</varname> boolean parameters can be used to control whether polkit + should interactively ask the user for authentication credentials if required.</para> + + <para>The polkit action for <function>SetHostname()</function> is + <interfacename>org.freedesktop.hostname1.set-hostname</interfacename>. For + <function>SetStaticHostname()</function> and <function>SetPrettyHostname()</function> it is + <interfacename>org.freedesktop.hostname1.set-static-hostname</interfacename>. For + <function>SetIconName()</function>, <function>SetChassis()</function>, <function>SetDeployment()</function> + and <function>SetLocation()</function> it is + <interfacename>org.freedesktop.hostname1.set-machine-info</interfacename>.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Recommendations</title> + + <para>Here are three examples that show how the pretty hostname and the icon name should be used: + <itemizedlist> + <listitem><para>When registering DNS-SD services: use the pretty hostname in the service name, and pass + the icon name in the TXT data, if there is an icon name. Browsing clients can then show the server icon + on each service. This is especially useful for WebDAV applications or UPnP media sharing. + </para></listitem> + + <listitem><para>Set the bluetooth name to the pretty hostname.</para></listitem> + + <listitem><para>When your file browser has a "Computer" icon, replace the name with the pretty hostname + if set, and the icon with the icon name, if it is set.</para></listitem> + </itemizedlist></para> + + <para>To properly handle name lookups with changing local hostnames without having to edit + <filename>/etc/hosts</filename>, we recommend using <filename>systemd-hostnamed</filename> in combination + with <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>A client that wants to change the local hostname for DHCP/mDNS should invoke + <code>SetHostname("newname", false)</code> as soon as the name is available and afterwards reset it via + <code>SetHostname("")</code>.</para> + + <para>Here are some recommendations to follow when generating a static (internet) hostname from a pretty + name: + <itemizedlist> + <listitem><para>Generate a single DNS label only, not an FQDN. That means no dots allowed. Strip them, + or replace them with <literal>-</literal>.</para></listitem> + + <listitem><para>It's probably safer to not use any non-ASCII chars, even if DNS allows this in some way + these days. In fact, restrict your charset to <literal>a-zA-Z0-9</literal> and <literal>-</literal>. + Strip other chars, or try to replace them in some smart way with chars from this set, for example + <literal>ä</literal> → <literal>ae</literal>, and use <literal>-</literal> as the replacement for all + punctuation characters and whitespace.</para></listitem> + + <listitem><para>Try to avoid creating repeated <literal>-</literal>, as well as <literal>-</literal> as + the first or last char.</para></listitem> + + <listitem><para>Limit the hostname to 63 chars, which is the length of a DNS label.</para></listitem> + + <listitem><para>If after stripping special chars the empty string is the result, you can pass this + as-is to <filename>systemd-hostnamed</filename> in which case it will automatically use + <literal>&FALLBACK_HOSTNAME;</literal>.</para></listitem> + + <listitem><para>Uppercase charaacters should be replaced with their lowercase equivalents. + </para></listitem> + </itemizedlist></para> + + <para>Note that while <filename>systemd-hostnamed</filename> applies some checks to the hostname you pass + they are much looser than the recommendations above. For example, <filename>systemd-hostnamed</filename> + will also accept <literal>_</literal> in the hostname, but we recommend not using this to avoid clashes + with DNS-SD service types. Also <filename>systemd-hostnamed</filename> allows longer hostnames, but + because of the DNS label limitations, we recommend not making use of this.</para> + + <para>Here are a couple of example conversions: + <itemizedlist> + <listitem><para><literal>Lennart's PC</literal> → <literal>lennarts-pc</literal></para></listitem> + <listitem><para><literal>Müllers Computer</literal> → <literal>muellers-computer</literal></para></listitem> + <listitem><para><literal>Voran!</literal> → <literal>voran</literal></para></listitem> + <listitem><para><literal>Es war einmal ein Männlein</literal> → <literal>es-war-einmal-ein-maennlein</literal></para></listitem> + <listitem><para><literal>Jawoll. Ist doch wahr!</literal> → <literal>jawoll-ist-doch-wahr</literal></para></listitem> + <listitem><para><literal>レナート</literal> → <literal>localhost</literal></para></listitem> + <listitem><para><literal>...zack!!! zack!...</literal> → <literal>zack-zack</literal></para></listitem> + </itemizedlist></para> + + <para>Of course, an already valid internet hostname label you enter and pass through this + conversion should stay unmodified, so that users have direct control of it, if they want — by simply + ignoring the fact that the pretty hostname is pretty and just edit it as if it was the normal internet + name.</para> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.hostname1</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system \ + --dest org.freedesktop.hostname1 \ + --object-path /org/freedesktop/hostname1 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>See also</title> + + <para>David Zeuthen's original Fedora + <ulink url="https://fedoraproject.org/wiki/Features/BetterHostname">Feature page about xdg-hostname</ulink></para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.import1.xml b/man/org.freedesktop.import1.xml new file mode 100644 index 0000000..9558ee1 --- /dev/null +++ b/man/org.freedesktop.import1.xml @@ -0,0 +1,348 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.import1" conditional='ENABLE_IMPORTD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.import1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.import1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.import1</refname> + <refpurpose>The D-Bus interface of systemd-importd</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-importd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service which may be used to import, export and download additional system images. These + images can be used by tools such as + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to run local containers. The service is used as the backend for <command>machinectl pull-raw</command>, + <command>machinectl pull-tar</command> and related commands. This page describes the D-Bus interface. + </para> + + <para>Note that + <citerefentry><refentrytitle>systemd-importd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is mostly a small companion service for + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Many operations to manipulate local container and VM images are hence available via the <command>systemd-machined</command> D-Bus API, c.f. + <citerefentry><refentrytitle>org.freedesktop.machine1</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The service exposes the following interfaces on the Manager object on the bus:</para> + + <programlisting executable="systemd-importd" node="/org/freedesktop/import1" interface="org.freedesktop.import1.Manager"> +node /org/freedesktop/import1 { + interface org.freedesktop.import1.Manager { + methods: + ImportTar(in h fd, + in s local_name, + in b force, + in b read_only, + out u transfer_id, + out o transfer_path); + ImportRaw(in h fd, + in s local_name, + in b force, + in b read_only, + out u transfer_id, + out o transfer_path); + ImportFileSystem(in h fd, + in s local_name, + in b force, + in b read_only, + out u transfer_id, + out o transfer_path); + ExportTar(in s local_name, + in h fd, + in s format, + out u transfer_id, + out o transfer_path); + ExportRaw(in s local_name, + in h fd, + in s format, + out u transfer_id, + out o transfer_path); + PullTar(in s url, + in s local_name, + in s verify_mode, + in b force, + out u transfer_id, + out o transfer_path); + PullRaw(in s url, + in s local_name, + in s verify_mode, + in b force, + out u transfer_id, + out o transfer_path); + ListTransfers(out a(usssdo) transfers); + CancelTransfer(in u transfer_id); + signals: + TransferNew(u transfer_id, + o transfer_path); + TransferRemoved(u transfer_id, + o transfer_path, + s result); + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method ImportFileSystem is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ImportTar()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ImportRaw()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ImportFileSystem()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ExportTar()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ExportRaw()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PullTar()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PullRaw()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListTransfers()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CancelTransfer()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="TransferNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="TransferRemoved"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>ImportTar()</function> and <function>ImportRaw()</function> import a system image and + place it into <filename>/var/lib/machines/</filename>. The first argument should be a file descriptor + (opened for reading) referring to the tar or raw file to import. It should reference a file on disk, + a pipe or a socket. When <function>ImportTar()</function> is used the file descriptor should + refer to a tar file, optionally compressed with + <citerefentry project="die-net"><refentrytitle>gzip</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project="die-net"><refentrytitle>bzip2</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + or + <citerefentry project="die-net"><refentrytitle>xz</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + <command>systemd-importd</command> will detect the used compression scheme (if any) automatically. When + <function>ImportRaw()</function> is used the file descriptor should refer to a raw or qcow2 disk image + containing an MBR or GPT disk label, also optionally compressed with gzip, bzip2 or xz. In either case, + if the file is specified as a file descriptor on disk, progress information is generated for the import + operation (as in that case we know the total size on disk). If a socket or pipe is specified, progress information is not + available. The file descriptor argument is followed by a local name for the image. This should be a + name suitable as a hostname and will be used to name the imported image below + <filename>/var/lib/machines/</filename>. A tar import is placed as a directory tree or a + <citerefentry project="man-pages"><refentrytitle>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + subvolume below <filename>/var/lib/machines/</filename> under the specified name with no suffix + appended. A raw import is placed as a file in <filename>/var/lib/machines/</filename> with the + <filename>.raw</filename> suffix appended. If the <option>force</option> argument is true, any + pre-existing image with the same name is removed before starting the operation. Otherwise, the + operation fails if an image with the same name already exists. Finally, the + <option>read_only</option> argument controls + whether to create a writable or read-only image. Both methods return immediately after starting the import, + with the import transfer ongoing. They return a pair of transfer identifier and object path, which may + be used to retrieve progress information about the transfer or to cancel it. The transfer identifier is a + simple numeric identifier, the object path references an + <interfacename>org.freedesktop.import1.Transfer</interfacename> object, see below. Listen for a + <function>TransferRemoved</function> signal for the transfer ID in order to detect when a transfer is + complete. The returned transfer object is useful to determine the current progress or log output of the + ongoing import operation.</para> + + <para><function>ExportTar()</function> and <function>ExportRaw()</function> implement the reverse + operation, and may be used to export a system image in order to place it in a tar or raw image. They + take the machine name to export as their first parameter, followed by a file descriptor (opened for writing) + where the tar or raw file will be written. It may either reference a file on disk or a pipe/socket. The + third argument specifies in which compression format to write the image. It takes one of + <literal>uncompressed</literal>, <literal>xz</literal>, <literal>bzip2</literal> or + <literal>gzip</literal>, depending on which compression scheme is required. The image written to the + specified file descriptor will be a tar file in case of <function>ExportTar()</function> or a raw disk + image in case of <function>ExportRaw()</function>. Note that currently raw disk images may not be + exported as tar files, and vice versa. This restriction might be lifted eventually. The method + returns a transfer identifier and object path for cancelling or tracking the export operation, similar + to <function>ImportTar()</function> or <function>ImportRaw()</function> as described above.</para> + + <para><function>PullTar()</function> and <function>PullRaw()</function> may be used to download, verify + and import a system image from a URL. They take an URL argument which should point to a tar or + raw file on the <literal>http://</literal> or <literal>https://</literal> protocols, possibly + compressed with xz, bzip2 or gzip. The second argument is a local name for the image. It should be + suitable as a hostname, similar to the matching argument of the <function>ImportTar()</function> and + <function>ImportRaw()</function> methods above. The third argument indicates the verification mode for + the image. It may be one of <literal>no</literal>, <literal>checksum</literal>, + <literal>signature</literal>. <literal>no</literal> turns off any kind of verification of the image; + <literal>checksum</literal> looks for a <filename>SHA256SUM</filename> file next to the downloaded + image and verifies any SHA256 hash value in that file against the image; <literal>signature</literal> + does the same but also tries to authenticate the <filename>SHA256SUM</filename> file via + <citerefentry project="man-pages"><refentrytitle>gpg</refentrytitle><manvolnum>8</manvolnum></citerefentry> + first. The last argument indicates whether to replace a possibly pre-existing image with the same local + name (if <literal>true</literal>), or whether to fail (if <literal>false</literal>). Like the import + and export calls above, these calls return a pair of transfer identifier and object path for the ongoing + download.</para> + + <para><function>ListTransfers()</function> returns a list of ongoing import, export or download + operations as created with the six calls described above. It returns an array of structures which + consist of the numeric transfer identifier, a string indicating the operation (one of + <literal>import-tar</literal>, <literal>import-raw</literal>, <literal>export-tar</literal>, + <literal>export-raw</literal>, <literal>pull-tar</literal> or <literal>pull-raw</literal>), a string + describing the remote file (in case of download operations this is the source URL, in case of + import/export operations this is a short string describing the file descriptor passed in), a string + with the local machine image name, a progress value between 0.0 (for 0%) and 1.0 (for 100%), as well as + the transfer object path.</para> + + <para><function>CancelTransfer()</function> may be used to cancel an ongoing import, export or download + operation. Simply specify the transfer identifier to cancel the ongoing operation.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>The <function>TransferNew</function> signal is generated each time a new transfer is started with + the import, export or download calls described above. It carries the transfer ID and object path that + have just been created.</para> + + <para>The <function>TransferRemoved</function> signal is sent each time a transfer finishes, + is canceled or fails. It also carries the transfer ID and object path, followed by a string indicating + the result of the operation, which is one of <literal>done</literal> (on success), + <literal>canceled</literal> or <literal>failed</literal>.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>The Transfer Object</title> + + <programlisting executable="systemd-importd" node="/org/freedesktop/import1/transfer/_1" interface="org.freedesktop.import1.Transfer"> +node /org/freedesktop/import1/transfer/_1 { + interface org.freedesktop.import1.Transfer { + methods: + Cancel(); + signals: + LogMessage(u priority, + s line); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Id = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Local = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Remote = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Verify = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly d Progress = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--signal LogMessage is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Transfer"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Transfer"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Cancel()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="LogMessage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Id"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Local"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Remote"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Type"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Verify"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Progress"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para>The <function>Cancel()</function> method may be used to cancel the transfer. It takes no + parameters. This method is pretty much equivalent to the <function>CancelTransfer()</function> method + on the <structname>Manager</structname> interface (see above), but is exposed on the + <structname>Transfer</structname> object itself instead of taking a transfer ID.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>The <varname>Id</varname> property exposes the numeric transfer ID of the transfer object.</para> + + <para>The <varname>Local</varname>, <varname>Remote</varname> and <varname>Type</varname> properties + expose the local container name of this transfer, the remote source (in case of download: the URL, in + case of import/export: a string describing the file descriptor passed in), and the type of operation + (see the Manager's <function>ListTransfer()</function> method above for an explanation of the possible + values).</para> + + <para>The <varname>Verify</varname> property exposes the selected verification setting and is only + defined for download operations (see above).</para> + + <para>The <varname>Progress</varname> property exposes the current progress of the transfer as a value + between 0.0 and 1.0. To show a progress bar on screen we recommend to query this value in regular + intervals, for example every 500 ms or so.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.import1.Manager</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system \ + --dest org.freedesktop.import1 \ + --object-path /org/freedesktop/import1 + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.import1.Transfer</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system \ + --dest org.freedesktop.import1 \ + --object-path /org/freedesktop/import1/transfer/_1 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.locale1.xml b/man/org.freedesktop.locale1.xml new file mode 100644 index 0000000..1da386d --- /dev/null +++ b/man/org.freedesktop.locale1.xml @@ -0,0 +1,188 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.locale1" conditional='ENABLE_LOCALED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.locale1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.locale1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.locale1</refname> + <refpurpose>The D-Bus interface of systemd-localed</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service that can be used to control the system locale and keyboard mapping from user + programs. This page describes the D-Bus interface.</para> + </refsect1> + + <refsect1> + <title>The D-Bus API</title> + + <para>The service exposes the following interfaces on the bus:</para> + + <programlisting executable="systemd-localed" node="/org/freedesktop/locale1" interface="org.freedesktop.locale1"> +node /org/freedesktop/locale1 { + interface org.freedesktop.locale1 { + methods: + SetLocale(in as locale, + in b interactive); + SetVConsoleKeyboard(in s keymap, + in s keymap_toggle, + in b convert, + in b interactive); + SetX11Keyboard(in s layout, + in s model, + in s variant, + in s options, + in b convert, + in b interactive); + properties: + readonly as Locale = ['...', ...]; + readonly s X11Layout = '...'; + readonly s X11Model = '...'; + readonly s X11Variant = '...'; + readonly s X11Options = '...'; + readonly s VConsoleKeymap = '...'; + readonly s VConsoleKeymapToggle = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.locale1"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.locale1"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLocale()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetVConsoleKeyboard()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetX11Keyboard()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Locale"/> + + <variablelist class="dbus-property" generated="True" extra-ref="X11Layout"/> + + <variablelist class="dbus-property" generated="True" extra-ref="X11Model"/> + + <variablelist class="dbus-property" generated="True" extra-ref="X11Variant"/> + + <variablelist class="dbus-property" generated="True" extra-ref="X11Options"/> + + <variablelist class="dbus-property" generated="True" extra-ref="VConsoleKeymap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="VConsoleKeymapToggle"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para>If you set a new system locale all old system locale settings will be dropped and the new + settings will be saved to disk. The locale will also be passed to the system manager, and subsequently started + daemons will inherit the new system locale. Note that already running daemons will not learn about the + new value.</para> + + <para>The <function>SetVConsoleKeyboard()</function> method may be used to set the key mapping for the + virtual console. Similarly, <function>SetX11Keyboard()</function> may be used to set the default key + mapping of any X11 servers.</para> + + <para>Note that <function>SetVConsoleKeyboard()</function> instantly applies the new key mapping to the + console, while <function>SetX11Keyboard()</function> simply sets a default that may be used by later + sessions.</para> + + <para>The boolean argument <varname>convert</varname> may be set to optionally convert the console + keyboard configuration to X11 keyboard mappings and vice versa. If true and + <function>SetVConsoleKeyboard()</function> is used, the nearest X11 keyboard setting for the chosen + console setting is set. If true and <function>SetX11Keyboard()</function> is used, the nearest console + keyboard setting for the chosen X11 setting is set. Hence, it is usually sufficient to call only one of the + two functions.</para> + + <para>For graphical UIs that need to set the system keyboard mapping simply invoke + <function>SetX11Keyboard()</function>, set <varname>convert=true</varname> and ignore + <function>SetVConsoleKeyboard()</function>.</para> + + <para>Use the empty string for the keymap parameters you wish not to set.</para> + + <para>The <varname>interactive</varname> boolean parameters can be used to control whether + <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink> + should interactively ask the user for authentication credentials if required.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>Whenever the system locale or keymap is changed via the daemon, + <function>PropertyChanged</function> signals are sent out to which clients can subscribe.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>The system locale is shown in the <varname>Locale</varname> property. It is an array containing + environment-variable-assignment-like strings. The following strings are known: + <varname>LANG=</varname>, <varname>LC_CTYPE=</varname>, <varname>LC_NUMERIC=</varname>, + <varname>LC_TIME=</varname>, <varname>LC_COLLATE=</varname>, <varname>LC_MONETARY=</varname>, + <varname>LC_MESSAGES=</varname>, <varname>LC_PAPER=</varname>, <varname>LC_NAME=</varname>, + <varname>LC_ADDRESS=</varname>, <varname>LC_TELEPHONE=</varname>, <varname>LC_MEASUREMENT=</varname>, + <varname>LC_IDENTIFICATION=</varname>.</para> + + <para>The <varname>X11Layout</varname>, <varname>X11Model</varname>, <varname>X11Variant</varname>, and + <varname>X11Options</varname> properties show values configurable with + <function>SetX11Keyboard()</function> described above (or <function>SetVConsoleKeyboard()</function> + with <varname>convert=true</varname>). The <varname>VConsoleKeymap</varname> and + <varname>VConsoleKeymapToggle</varname> properties show values configurable with + <function>SetVConsoleKeyboard()</function> (or <function>SetX11Keyboard()</function> with + <varname>convert=true</varname>).</para> + </refsect2> + + <refsect2> + <title>Security</title> + + <para>Changing the system locale or keymap using this interface is authenticated via polkit. The + polkit action for <function>SetLocale()</function> is + <constant>org.freedesktop.locale1.set-locale</constant>. The polkit action for + <function>SetX11Keyboard()</function> and <function>SetVConsoleKeyboard()</function> is + <constant>org.freedesktop.locale1.set-keyboard</constant>.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.locale1</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.locale1 \ + --object-path /org/freedesktop/locale1 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.login1.xml b/man/org.freedesktop.login1.xml new file mode 100644 index 0000000..ad27b22 --- /dev/null +++ b/man/org.freedesktop.login1.xml @@ -0,0 +1,1389 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.login1" conditional='ENABLE_LOGIND' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.login1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.login1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.login1</refname> + <refpurpose>The D-Bus interface of systemd-logind</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para><citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service that keeps track of user logins and seats.</para> + + <para>The daemon provides both a C library interface as well as a D-Bus interface. The library interface + may be used to introspect and watch the state of user logins and seats. The bus interface provides the + same functionality but in addition may also be used to make changes to the system state. For more information please + consult <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The service exposes the following interfaces on the Manager object on the bus:</para> + + <programlisting executable="systemd-logind" node="/org/freedesktop/login1" interface="org.freedesktop.login1.Manager"> +node /org/freedesktop/login1 { + interface org.freedesktop.login1.Manager { + methods: + GetSession(in s session_id, + out o object_path); + GetSessionByPID(in u pid, + out o object_path); + GetUser(in u uid, + out o object_path); + GetUserByPID(in u pid, + out o object_path); + GetSeat(in s seat_id, + out o object_path); + ListSessions(out a(susso) sessions); + ListUsers(out a(uso) users); + ListSeats(out a(so) seats); + ListInhibitors(out a(ssssuu) inhibitors); + CreateSession(in u uid, + in u pid, + in s service, + in s type, + in s class, + in s desktop, + in s seat_id, + in u vtnr, + in s tty, + in s display, + in b remote, + in s remote_user, + in s remote_host, + in a(sv) properties, + out s session_id, + out o object_path, + out s runtime_path, + out h fifo_fd, + out u uid, + out s seat_id, + out u vtnr, + out b existing); + ReleaseSession(in s session_id); + ActivateSession(in s session_id); + ActivateSessionOnSeat(in s session_id, + in s seat_id); + LockSession(in s session_id); + UnlockSession(in s session_id); + LockSessions(); + UnlockSessions(); + KillSession(in s session_id, + in s who, + in i signal_number); + KillUser(in u uid, + in i signal_number); + TerminateSession(in s session_id); + TerminateUser(in u uid); + TerminateSeat(in s seat_id); + SetUserLinger(in u uid, + in b enable, + in b interactive); + AttachDevice(in s seat_id, + in s sysfs_path, + in b interactive); + FlushDevices(in b interactive); + PowerOff(in b interactive); + Reboot(in b interactive); + Halt(in b interactive); + Suspend(in b interactive); + Hibernate(in b interactive); + HybridSleep(in b interactive); + SuspendThenHibernate(in b interactive); + CanPowerOff(out s result); + CanReboot(out s result); + CanHalt(out s result); + CanSuspend(out s result); + CanHibernate(out s result); + CanHybridSleep(out s result); + CanSuspendThenHibernate(out s result); + ScheduleShutdown(in s type, + in t usec); + CancelScheduledShutdown(out b cancelled); + Inhibit(in s what, + in s who, + in s why, + in s mode, + out h pipe_fd); + CanRebootParameter(out s result); + SetRebootParameter(in s parameter); + CanRebootToFirmwareSetup(out s result); + SetRebootToFirmwareSetup(in b enable); + CanRebootToBootLoaderMenu(out s result); + SetRebootToBootLoaderMenu(in t timeout); + CanRebootToBootLoaderEntry(out s result); + SetRebootToBootLoaderEntry(in s boot_loader_entry); + SetWallMessage(in s wall_message, + in b enable); + signals: + SessionNew(s session_id, + o object_path); + SessionRemoved(s session_id, + o object_path); + UserNew(u uid, + o object_path); + UserRemoved(u uid, + o object_path); + SeatNew(s seat_id, + o object_path); + SeatRemoved(s seat_id, + o object_path); + PrepareForShutdown(b start); + PrepareForSleep(b start); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite b EnableWallMessages = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s WallMessage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u NAutoVTs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as KillOnlyUsers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as KillExcludeUsers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b KillUserProcesses = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s RebootParameter = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b RebootToFirmwareSetup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t RebootToBootLoaderMenu = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s RebootToBootLoaderEntry = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as BootLoaderEntries = ['...', ...]; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + readonly s BlockInhibited = '...'; + readonly s DelayInhibited = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InhibitDelayMaxUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UserStopDelayUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandlePowerKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleSuspendKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleHibernateKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleLidSwitch = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleLidSwitchExternalPower = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleLidSwitchDocked = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t HoldoffTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s IdleAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t IdleActionUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b PreparingForShutdown = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b PreparingForSleep = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (st) ScheduledShutdown = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Docked = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b LidClosed = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b OnExternalPower = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeDirectorySize = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeDirectoryInodesMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InhibitorsMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t NCurrentInhibitors = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SessionsMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t NCurrentSessions = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetSessionByPID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUser()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUserByPID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetSeat()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListSessions()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUsers()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListSeats()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListInhibitors()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CreateSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReleaseSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ActivateSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ActivateSessionOnSeat()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LockSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnlockSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LockSessions()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnlockSessions()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="KillSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="KillUser()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TerminateSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TerminateUser()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TerminateSeat()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetUserLinger()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachDevice()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="FlushDevices()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PowerOff()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Reboot()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Halt()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Suspend()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Hibernate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="HybridSleep()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SuspendThenHibernate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanPowerOff()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanReboot()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanHalt()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanSuspend()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanHibernate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanHybridSleep()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanSuspendThenHibernate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ScheduleShutdown()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CancelScheduledShutdown()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Inhibit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanRebootParameter()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetRebootParameter()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanRebootToFirmwareSetup()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetRebootToFirmwareSetup()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanRebootToBootLoaderMenu()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetRebootToBootLoaderMenu()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CanRebootToBootLoaderEntry()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetRebootToBootLoaderEntry()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetWallMessage()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="SessionNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="SessionRemoved"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="UserNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="UserRemoved"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="SeatNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="SeatRemoved"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="PrepareForShutdown"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="PrepareForSleep"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EnableWallMessages"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WallMessage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NAutoVTs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillOnlyUsers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillExcludeUsers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillUserProcesses"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RebootParameter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RebootToFirmwareSetup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RebootToBootLoaderMenu"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RebootToBootLoaderEntry"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BootLoaderEntries"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockInhibited"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelayInhibited"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InhibitDelayMaxUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UserStopDelayUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HandlePowerKey"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HandleSuspendKey"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HandleHibernateKey"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HandleLidSwitch"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HandleLidSwitchExternalPower"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HandleLidSwitchDocked"/> + + <variablelist class="dbus-property" generated="True" extra-ref="HoldoffTimeoutUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleAction"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleActionUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PreparingForShutdown"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PreparingForSleep"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ScheduledShutdown"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Docked"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LidClosed"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OnExternalPower"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectorySize"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryInodesMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InhibitorsMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NCurrentInhibitors"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SessionsMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NCurrentSessions"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>GetSession()</function> may be used to get the session object path for the session with + the specified ID. Similarly, <function>GetUser()</function> and <function>GetSeat()</function> get the + user and seat objects, respectively. <function>GetSessionByPID()</function> and + <function>GetUserByPID()</function> get the session/user object the specified PID belongs to if there + is any.</para> + + <para><function>ListSessions()</function> returns an array of all current sessions. The structures in + the array consist of the following fields: session id, user id, user name, seat id, session object + path. If a session does not have a seat attached, the seat id field will be an empty string.</para> + + <para><function>ListUsers()</function> returns an array of all currently logged in users. The + structures in the array consist of the following fields: user id, user name, user object path.</para> + + <para><function>ListSeats()</function> returns an array of all currently available seats. The + structure in the array consists of the following fields: seat id, seat object path.</para> + + <para><function>ListInhibitors()</function> lists all currently active inhibitors. It returns an array of + structures consisting of <varname>what</varname>, <varname>who</varname>, <varname>why</varname>, + <varname>mode</varname>, <varname>uid</varname> (user ID), and <varname>pid</varname> (process ID).</para> + + <para><function>CreateSession()</function> and <function>ReleaseSession()</function> may be used to + open or close login sessions. These calls should <emphasis>never</emphasis> be invoked directly by + clients. Creating/closing sessions is exclusively the job of PAM and its + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + module.</para> + + <para><function>ActivateSession()</function> brings the session with the specified ID into the + foreground. <function>ActivateSessionOnSeat()</function> does the same, but only if the seat id + matches.</para> + + <para><function>LockSession()</function> asks the session with the specified ID to activate the screen + lock. <function>UnlockSession()</function> asks the session with the specified ID to remove an active + screen lock, if there is any. This is implemented by sending out the Lock() and Unlock() signals from + the respective session object which session managers are supposed to listen on.</para> + + <para><function>LockSessions()</function> asks all sessions to activate their screen locks. This may be + used to lock access to the entire machine in one action. Similarly, <function>UnlockSessions()</function> + asks all sessions to deactivate their screen locks.</para> + + <para><function>KillSession()</function> may be used to send a Unix signal to one or all processes of a + session. As arguments it takes the session id, either the string <literal>leader</literal> or + <literal>all</literal> and a signal number. If <literal>leader</literal> is passed only the session + <literal>leader</literal> is killed. If <literal>all</literal> is passed all processes of the session + are killed.</para> + + <para><function>KillUser()</function> may be used to send a Unix signal to all processes of a user. As + arguments it takes the user id and a signal number.</para> + + <para><function>TerminateSession()</function>, <function>TerminateUser()</function>, + <function>TerminateSeat()</function> may be used to forcibly terminate one specific session, all + processes of a user, and all sessions attached to a specific seat, respectively. The session, user, + and seat are identified by their respective IDs.</para> + + <para><function>SetUserLinger()</function> enables or disables user lingering. If enabled, the runtime + directory of a user is kept around and they may continue to run processes while logged out. If + disabled, the runtime directory goes away as soon as they log out. <function>SetUserLinger()</function> + expects three arguments: the UID, a boolean whether to enable/disable and a boolean controlling the + <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink> + authorization interactivity (see below). Note that the user linger state is persistently + stored on disk.</para> + + <para><function>AttachDevice()</function> may be used to assign a specific device to a specific + seat. The device is identified by its <filename>/sys/</filename> path and must be eligible for seat + assignments. <function>AttachDevice()</function> takes three arguments: the seat id, the sysfs path, + and a boolean for controlling polkit interactivity (see below). Device assignments are persistently + stored on disk. To create a new seat, simply specify a previously unused seat id. For more information + about the seat assignment logic see + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para><function>FlushDevices()</function> removes all explicit seat assignments for devices, resetting + all assignments to the automatic defaults. The only argument it takes is the polkit interactivity + boolean (see below).</para> + + <para><function>PowerOff()</function>, <function>Reboot()</function>, <function>Halt()</function>, + <function>Suspend()</function>, and <function>Hibernate()</function> result in the system being powered + off, rebooted, halted (shut down without turning off power), suspended (the system state is + saved to RAM and the CPU is turned off), or hibernated (the system state is saved to disk and + the machine is powered down). <function>HybridSleep()</function> results in the system entering a + hybrid-sleep mode, i.e. the system is both hibernated and suspended. + <function>SuspendThenHibernate()</function> results in the system being suspended, then later woken + using an RTC timer and hibernated. The only argument is the polkit interactivity boolean + <varname>interactive</varname> (see below). The main purpose of these calls is that they enforce + polkit policy and hence allow powering off/rebooting/suspending/hibernating even by unprivileged + users. They also enforce inhibition locks. UIs should expose these calls as the primary mechanism to + poweroff/reboot/suspend/hibernate the machine.</para> + + <para><function>SetRebootParameter()</function> sets a parameter for a subsequent reboot operation. + See the description of <command>reboot</command> in + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and + <citerefentry project="man-pages"><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for more information.</para> + + <para><function>SetRebootToFirmwareSetup()</function>, + <function>SetRebootToBootLoaderMenu()</function>, and <function>SetRebootToBootLoaderEntry()</function> + configure the action to be taken from the boot loader after a reboot: respectively entering firmware + setup mode, the boot loader menu, or a specific boot loader entry. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for the + corresponding command line interface.</para> + + <para><function>CanPowerOff()</function>, <function>CanReboot()</function>, + <function>CanHalt()</function>, <function>CanSuspend()</function>, <function>CanHibernate()</function>, + <function>CanHybridSleep()</function>, <function>CanSuspendThenHibernate()</function>, + <function>CanRebootParameter()</function>, <function>CanRebootToFirmwareSetup()</function>, + <function>CanRebootToBootLoaderMenu()</function>, and + <function>CanRebootToBootLoaderEntry()</function> test whether the system supports the respective + operation and whether the calling user is allowed to execute it. Returns one of <literal>na</literal>, + <literal>yes</literal>, <literal>no</literal>, and <literal>challenge</literal>. If + <literal>na</literal> is returned, the operation is not available because hardware, kernel, or drivers + do not support it. If <literal>yes</literal> is returned, the operation is supported and the user may + execute the operation without further authentication. If <literal>no</literal> is returned, the + operation is available but the user is not allowed to execute the operation. If + <literal>challenge</literal> is returned, the operation is available but only after + authorization.</para> + + <para><function>ScheduleShutdown()</function> schedules a shutdown operation <varname>type</varname> at + time <varname>usec</varname> in microseconds since the UNIX epoch. <varname>type</varname> can be one + of <literal>poweroff</literal>, <literal>dry-poweroff</literal>, <literal>reboot</literal>, + <literal>dry-reboot</literal>, <literal>halt</literal>, and <literal>dry-halt</literal>. (The + <literal>dry-</literal> variants do not actually execute the shutdown action.) + <function>CancelScheduledShutdown()</function> cancels a scheduled shutdown. The output parameter + <varname>cancelled</varname> is true if a shutdown operation was scheduled.</para> + + <para><function>SetWallMessage()</function> sets the wall message (the message that will be sent out to + all terminals and stored in a + <citerefentry project="man-pages"><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry> record) for a + subsequent scheduled shutdown operation. The parameter <varname>wall_message</varname> specifies the + shutdown reason (and may be empty) which will be included in the shutdown message. The parameter + <varname>enable</varname> specifies whether to print a wall message on shutdown.</para> + + <para><function>Inhibit()</function> creates an inhibition lock. It takes four parameters: + <varname>what</varname>, <varname>who</varname>, <varname>why</varname>, and + <varname>mode</varname>. <varname>what</varname> is one or more of <literal>shutdown</literal>, + <literal>sleep</literal>, <literal>idle</literal>, <literal>handle-power-key</literal>, + <literal>handle-suspend-key</literal>, <literal>handle-hibernate-key</literal>, + <literal>handle-lid-switch</literal>, separated by colons, for inhibiting poweroff/reboot, + suspend/hibernate, the automatic idle logic, or hardware key handling. <varname>who</varname> should be + a short human readable string identifying the application taking the lock. <varname>why</varname> + should be a short human readable string identifying the reason why the lock is taken. Finally, + <varname>mode</varname> is either <literal>block</literal> or <literal>delay</literal> which encodes + whether the inhibit shall be consider mandatory or whether it should just delay the operation to a + certain maximum time. The method returns a file descriptor. The lock is released the moment this file + descriptor and all its duplicates are closed. For more information on the inhibition logic see + <ulink url="http://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor Locks</ulink>. + </para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>Whenever the inhibition state or idle hint changes, <function>PropertyChanged</function> + signals are sent out to which clients can subscribe.</para> + + <para>The <function>SessionNew</function>, <function>SessionRemoved</function>, + <function>UserNew</function>, <function>UserRemoved</function>, <function>SeatNew</function>, and + <function>SeatRemoved</function> signals are sent each time a session is created or removed, a user + logs in or out, or a seat is added or removed. They each contain the ID of the object plus the object + path.</para> + + <para>The <function>PrepareForShutdown()</function> and <function>PrepareForSleep()</function> signals + are sent right before (with the argument <literal>true</literal>) or after (with the argument + <literal>false</literal>) the system goes down for reboot/poweroff and suspend/hibernate, + respectively. This may be used by applications to save data on disk, release memory, or do other jobs + that should be done shortly before shutdown/sleep, in conjunction with delay inhibitor locks. After + completion of this work they should release their inhibition locks in order to not delay the operation + any further. For more information see + <ulink url="http://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor Locks</ulink>. + </para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>Most properties simply reflect the configuration, see + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This + includes: <varname>NAutoVTs</varname>, <varname>KillOnlyUsers</varname>, + <varname>KillExcludeUsers</varname>, <varname>KillUserProcesses</varname>, <varname>IdleAction</varname>, + <varname>InhibitDelayMaxUSec</varname>, + <varname>InhibitorsMax</varname>, + <varname>UserStopDelayUSec</varname>, + <varname>HandlePowerKey</varname>, <varname>HandleSuspendKey</varname>, + <varname>HandleHibernateKey</varname>, <varname>HandleLidSwitch</varname>, + <varname>HandleLidSwitchExternalPower</varname>, <varname>HandleLidSwitchDocked</varname>, + <varname>IdleActionUSec</varname>, <varname>HoldoffTimeoutUSec</varname>, + <varname>RemoveIPC</varname>, <varname>RuntimeDirectorySize</varname>, + <varname>RuntimeDirectoryInodesMax</varname>, <varname>InhibitorsMax</varname>, and + <varname>SessionsMax</varname>. + </para> + + <para>The <varname>IdleHint</varname> property reflects the idle hint state of the system. If the + system is idle it might get into automatic suspend or shutdown depending on the configuration.</para> + + <para><varname>IdleSinceHint</varname> and <varname>IdleSinceHintMonotonic</varname> encode the + timestamps of the last change of the idle hint boolean, in <constant>CLOCK_REALTIME</constant> and + <constant>CLOCK_MONOTONIC</constant> timestamps, respectively, in microseconds since the epoch.</para> + + <para>The <varname>BlockInhibited</varname> and <varname>DelayInhibited</varname> properties encode + the currently active locks of the respective modes. They are colon separated lists of + <literal>shutdown</literal>, <literal>sleep</literal>, and <literal>idle</literal> (see above).</para> + + <para><varname>NCurrentSessions</varname> and <varname>NCurrentInhibitors</varname> contain the number + of currently registered sessions and inhibitors.</para> + + <para>The <varname>BootLoaderEntries</varname> property contains a list of boot loader entries. + This includes boot loader entries defined in configuration and any additional loader entries + reported by the boot loader. See + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information.</para> + + <para>The <varname>PreparingForShutdown</varname> and <varname>PreparingForSleep</varname> boolean + properties are true during the interval between the two <function>PrepareForShutdown</function> and + <function>PrepareForSleep</function> signals respectively. Note that these properties do not + send out <function>PropertyChanged</function> signals.</para> + + <para>The <varname>RebootParameter</varname> property shows the value set with the + <function>SetRebootParameter()</function> method described above.</para> + + <para><varname>ScheduledShutdown</varname> shows the value pair set with the + <function>ScheduleShutdown()</function> method described above.</para> + + <para><varname>RebootToFirmwareSetup</varname>, <varname>RebootToBootLoaderMenu</varname>, and + <varname>RebootToBootLoaderEntry</varname> are true when the resprective post-reboot operation was + selected with <function>SetRebootToFirmwareSetup</function>, + <function>SetRebootToBootLoaderMenu</function>, or + <function>SetRebootToBootLoaderEntry</function>.</para> + + <para>The <varname>WallMessage</varname> and <varname>EnableWallMessages</varname> properties reflect the + shutdown reason and wall message enablement switch which can be set with the + <function>SetWallMessage()</function> method described above.</para> + + <para><varname>Docked</varname> is true if the machine is connected to a dock. + <varname>LidClosed</varname> is true when the lid (of a laptop) is closed. + <varname>OnExternalPower</varname> is true when the machine is connected to an external power supply. + </para> + </refsect2> + + <refsect2> + <title>Security</title> + + <para>A number of operations are protected via the polkit privilege + system. <function>SetUserLinger()</function> requires the + <interfacename>org.freedesktop.login1.set-user-linger</interfacename> + privilege. <function>AttachDevice()</function> requires + <interfacename>org.freedesktop.login1.attach-device</interfacename> and + <function>FlushDevices()</function> requires + <interfacename>org.freedesktop.login1.flush-devices</interfacename>. <function>PowerOff()</function>, + <function>Reboot()</function>, <function>Halt()</function>, <function>Suspend()</function>, + <function>Hibernate()</function> require + <interfacename>org.freedesktop.login1.power-off</interfacename>, + <interfacename>org.freedesktop.login1.power-off-multiple-sessions</interfacename>, + <interfacename>org.freedesktop.login1.power-off-ignore-inhibit</interfacename>, + <interfacename>org.freedesktop.login1.reboot</interfacename>, + <interfacename>org.freedesktop.login1.reboot-multiple-sessions</interfacename>, + <interfacename>org.freedesktop.login1.reboot-ignore-inhibit</interfacename>, + <interfacename>org.freedesktop.login1.halt</interfacename>, + <interfacename>org.freedesktop.login1.halt-multiple-sessions</interfacename>, + <interfacename>org.freedesktop.login1.halt-ignore-inhibit</interfacename>, + <interfacename>org.freedesktop.login1.suspend</interfacename>, + <interfacename>org.freedesktop.login1.suspend-multiple-sessions</interfacename>, + <interfacename>org.freedesktop.login1.suspend-ignore-inhibit</interfacename>, + <interfacename>org.freedesktop.login1.hibernate</interfacename>, + <interfacename>org.freedesktop.login1.hibernate-multiple-sessions</interfacename>, + <interfacename>org.freedesktop.login1.hibernate-ignore-inhibit</interfacename>, + respectively depending on whether there are other sessions around or active inhibits are present. + <function>HybridSleep()</function> and <function>SuspendThenHibernate()</function> + use the same privileges as <function>Hibernate()</function>. + <function>SetRebootParameter()</function> requires + <interfacename>org.freedesktop.login1.set-reboot-parameter</interfacename>.</para> + + <para><function>SetRebootToFirmwareSetup</function> requires + <interfacename>org.freedesktop.login1.set-reboot-to-firmware-setup</interfacename>. + <function>SetRebootToBootLoaderMenu</function> requires + <interfacename>org.freedesktop.login1.set-reboot-to-boot-loader-menu</interfacename>. + <function>SetRebootToBootLoaderEntry</function> requires + <interfacename>org.freedesktop.login1.set-reboot-to-boot-loader-entry</interfacename>. + </para> + + <para><function>ScheduleShutdown</function> and <function>CancelScheduledShutdown</function> require + the same privileges (listed above) as the immediate poweroff/reboot/halt operations.</para> + + <para><function>Inhibit()</function> is protected via one of + <interfacename>org.freedesktop.login1.inhibit-block-shutdown</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-delay-shutdown</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-block-sleep</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-delay-sleep</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-block-idle</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-handle-power-key</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-handle-suspend-key</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-handle-hibernate-key</interfacename>, + <interfacename>org.freedesktop.login1.inhibit-handle-lid-switch</interfacename> depending on the lock + type and mode taken.</para> + + <para>The <varname>interactive</varname> boolean parameters can be used to control whether polkit + should interactively ask the user for authentication credentials if required.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Seat Objects</title> + + <programlisting executable="systemd-logind" node="/org/freedesktop/login1/seat/seat0" interface="org.freedesktop.login1.Seat"> +node /org/freedesktop/login1/seat/seat0 { + interface org.freedesktop.login1.Seat { + methods: + Terminate(); + ActivateSession(in s session_id); + SwitchTo(in u vtnr); + SwitchToNext(); + SwitchToPrevious(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Id = '...'; + readonly (so) ActiveSession = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanTTY = ...; + readonly b CanGraphical = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(so) Sessions = [...]; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Seat"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Seat"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ActivateSession()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SwitchTo()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SwitchToNext()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SwitchToPrevious()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Id"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ActiveSession"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanTTY"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanGraphical"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Sessions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Terminate()</function> and <function>ActivateSession()</function> work similar to + TerminateSeat(), ActivationSessionOnSeat() on the Manager object.</para> + + <para><function>SwitchTo()</function> switches to the session on the virtual terminal + <varname>vtnr</varname>. <function>SwitchToNext()</function> and + <function>SwitchToPrevious()</function> switch to, respectively, the next and previous sessions on the + seat in the order of virtual terminals. If there is no active session, they switch to, respectively, + the first and last session on the seat.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>Whenever <function>ActiveSession</function>, <function>Sessions</function>, + <function>CanGraphical</function>, <function>CanTTY</function>, + or the idle state changes, <function>PropertyChanged</function> signals are sent out to which clients + can subscribe.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>The <varname>Id</varname> property encodes the ID of the seat.</para> + + <para><varname>ActiveSession</varname> encodes the currently active session if there is one. It is a + structure consisting of the session id and the object path.</para> + + <para><varname>CanTTY</varname> encodes whether the session is suitable for text logins, and + <varname>CanGraphical</varname> whether it is suitable for graphical sessions.</para> + + <para>The <varname>Sessions</varname> property is an array of all current sessions of this seat, each + encoded in a structure consisting of the ID and the object path.</para> + + <para>The <varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and + <varname>IdleSinceHintMonotonic</varname> properties encode the idle state, similar to the ones exposed + on the <interfacename>Manager</interfacename> object, but specific for this seat.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>User Objects</title> + + <programlisting executable="systemd-logind" node="/org/freedesktop/login1/user/_1000" interface="org.freedesktop.login1.User"> +node /org/freedesktop/login1/user/_1000 { + interface org.freedesktop.login1.User { + methods: + Terminate(); + Kill(in i signal_number); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t Timestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Service = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Slice = '...'; + readonly (so) Display = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s State = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(so) Sessions = [...]; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Linger = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.User"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.User"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Name"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Timestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Service"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Display"/> + + <variablelist class="dbus-property" generated="True" extra-ref="State"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Sessions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Linger"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Terminate()</function> and <function>Kill()</function> work similar to the + <function>TerminateUser()</function> and <function>KillUser()</function> methods on the manager + object.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>Whenever <varname>Sessions</varname> or the idle state changes, + <function>PropertyChanged</function> signals are sent out to which clients can subscribe.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>The <varname>UID</varname> and <varname>GID</varname> properties encode the Unix UID and primary + GID of the user.</para> + + <para>The <varname>Name</varname> property encodes the user name.</para> + + <para><varname>Timestamp</varname> and <varname>TimestampMonotonic</varname> encode the login time of + the user in microseconds since the epoch, in the <constant>CLOCK_REALTIME</constant> and + <constant>CLOCK_MONOTONIC</constant> clocks, respectively.</para> + + <para><varname>RuntimePath</varname> encodes the runtime path of the user, + i.e. <varname>$XDG_RUNTIME_DIR</varname>. For details see the + <ulink url="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html"> + XDG Basedir Specification + </ulink>.</para> + + <para><varname>Service</varname> contains the unit name of the user systemd service of this + user. Each logged in user is assigned a user service that runs a user systemd instance. This is + usually an instance of <filename>user@.service</filename>.</para> + + <para><varname>Slice</varname> contains the unit name of the user systemd slice of this user. Each + logged in user gets a private slice.</para> + + <para><varname>Display</varname> encodes which graphical session should be used as the primary UI display + for the user. It is a structure encoding the session ID and the object path of the session to use.</para> + + <para><varname>State</varname> encodes the user state and is one of <literal>offline</literal>, + <literal>lingering</literal>, <literal>online</literal>, <literal>active</literal>, or + <literal>closing</literal>. See + <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the states.</para> + + <para><varname>Sessions</varname> is an array of structures encoding all current sessions of the + user. Each structure consists of the ID and object path.</para> + + <para>The <varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and + <varname>IdleSinceHintMonotonic</varname> properties encode the idle hint state of the user, similar to + the <interfacename>Manager</interfacename>'s properties, but specific for this user.</para> + + <para>The <varname>Linger</varname> property shows whether lingering is enabled for this user.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Session Objects</title> + + <programlisting executable="systemd-logind" node="/org/freedesktop/login1/session/1" interface="org.freedesktop.login1.Session"> +node /org/freedesktop/login1/session/1 { + interface org.freedesktop.login1.Session { + methods: + Terminate(); + Activate(); + Lock(); + Unlock(); + SetIdleHint(in b idle); + SetLockedHint(in b locked); + Kill(in s who, + in i signal_number); + TakeControl(in b force); + ReleaseControl(); + SetType(in s type); + TakeDevice(in u major, + in u minor, + out h fd, + out b inactive); + ReleaseDevice(in u major, + in u minor); + PauseDeviceComplete(in u major, + in u minor); + SetBrightness(in s subsystem, + in s name, + in u brightness); + signals: + PauseDevice(u major, + u minor, + s type); + ResumeDevice(u major, + u minor, + h fd); + Lock(); + Unlock(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Id = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (uo) User = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t Timestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u VTNr = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (so) Seat = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTY = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Display = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Remote = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RemoteHost = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RemoteUser = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Service = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Desktop = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Scope = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Leader = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Audit = ...; + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Class = '...'; + readonly b Active = ...; + readonly s State = '...'; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + readonly b LockedHint = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Session"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Session"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Activate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Lock()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Unlock()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetIdleHint()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLockedHint()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TakeControl()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReleaseControl()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetType()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TakeDevice()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReleaseDevice()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PauseDeviceComplete()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetBrightness()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="PauseDevice"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="ResumeDevice"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="Lock"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="Unlock"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Id"/> + + <variablelist class="dbus-property" generated="True" extra-ref="User"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Name"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Timestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="VTNr"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Seat"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTY"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Display"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Remote"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoteHost"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoteUser"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Service"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Desktop"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Scope"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Leader"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Audit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Type"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Class"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Active"/> + + <variablelist class="dbus-property" generated="True" extra-ref="State"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LockedHint"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Terminate()</function>, <function>Activate()</function>, <function>Lock()</function>, + <function>Unlock()</function>, and <function>Kill()</function> work similarly to the respective calls on + the <interfacename>Manager</interfacename> object.</para> + + <para><function>SetIdleHint()</function> is called by the session object to update the idle state + of the session whenever it changes.</para> + + <para><function>TakeControl()</function> allows a process to take exclusive managed device + access-control for that session. Only one D-Bus connection can be a controller for a given session at any + time. If the <varname>force</varname> argument is set (root only), an existing controller is kicked + out and replaced. Otherwise, this method fails if there is already a controller. Note that this method is + limited to D-Bus users with the effective UID set to the user of the session or root.</para> + + <para><function>ReleaseControl()</function> drops control of a given session. Closing the D-Bus + connection implicitly releases control as well. See <function>TakeControl()</function> for more + information. This method also releases all devices for which the controller requested ownership via + <function>TakeDevice()</function>.</para> + + <para><function>SetType()</function> allows the type of the session to be changed dynamically. It can + only be called by session's current controller. If <function>TakeControl()</function> has not been + called, this method will fail. In addition, the session type will be reset to its original value once + control is released, either by calling <function>ReleaseControl()</function> or closing the D-Bus + connection. This should help prevent a session from entering an inconsistent state, for example if the + controller crashes. The only argument <varname>type</varname> is the new session type.</para> + + <para><function>TakeDevice()</function> allows a session controller to get a file descriptor for a + specific device. Pass in the major and minor numbers of the character device and + <filename>systemd-logind</filename> will return a file descriptor for the device. Only a limited set of + device-types is currently supported (but may be extended). <filename>systemd-logind</filename> + automatically mutes the file descriptor if the session is inactive and resumes it once the session is + activated again. This guarantees that a session can only access session devices if the session is + active. Note that this revoke/resume mechanism is asynchronous and may happen at any given time. This + only works on devices that are attached to the seat of the given session. A process is not required to + have direct access to the device node. <filename>systemd-logind</filename> only requires you to be the + active session controller (see <function>TakeControl()</function>). Also note that any device can only + be requested once. As long as you don't release it, further <function>TakeDevice()</function> calls + will fail.</para> + + <para><function>ReleaseDevice()</function> releases a device again (see + <function>TakeDevice()</function>). This is also implicitly done by + <function>ReleaseControl()</function> or when closing the D-Bus connection.</para> + + <para><function>PauseDeviceComplete()</function> allows a session controller to synchronously pause a + device after receiving a <function>PauseDevice(<literal>pause</literal>)</function> signal. Forced + signals (or after an internal timeout) are automatically completed by + <filename>systemd-logind</filename> asynchronously.</para> + + <para><function>SetLockedHint()</function> may be used to set the "locked hint" to + <varname>locked</varname>, i.e. information whether the session is locked. This is intended to be used + by the desktop environment to tell <command>systemd-logind</command> when the session is locked and + unlocked.</para> + + <para><function>SetBrightness()</function> may be used to set the display brightness. This is intended + to be used by the desktop environment and allows unprivileged programs to access hardware settings in + a controlled way. The <varname>subsystem</varname> parameter specifies a kernel subsystem, either + <literal>backlight</literal> or <literal>leds</literal>. The <varname>name</varname> parameter + specifies a device name under the specified subsystem. The <varname>brightness</varname> parameter + specifies the brightness. The range is defined by individual drivers, see + <filename>/sys/class/<varname>subsystem</varname>/<varname>name</varname>/max_brightness</filename>. + </para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>The active session controller exclusively gets <function>PauseDevice</function> and + <function>ResumeDevice</function> events for any device it requested via + <function>TakeDevice()</function>. They notify the controller whenever a device is paused or resumed. A + device is never resumed if its session is inactive. Also note that <function>PauseDevice</function> + signals are sent before the <function>PropertyChanged</function> signal for the + <function>Active</function> state. The inverse is true for <function>ResumeDevice</function>. A device + may remain paused for unknown reasons even though the <interfacename>Session</interfacename> is active. + </para> + + <para>A <function>PauseDevice</function> signal carries the major and minor numbers and a string describing the + type as arguments. <function>force</function> means the device was already paused by + <filename>systemd-logind</filename> and the signal is only an asynchronous + notification. <function>pause</function> means <filename>systemd-logind</filename> grants you a limited amount of time to pause the device. You must respond to this via + <function>PauseDeviceComplete()</function>. This synchronous pausing mechanism is used for + backwards-compatibility to VTs and <filename>systemd-logind</filename> is free to not make use of + it. It is also free to send a forced <function>PauseDevice</function> if you don't respond in a timely + manner (or for any other reason). <function>gone</function> means the device was unplugged from the + system and you will no longer get any notifications about it. There is no need to call + <function>ReleaseDevice()</function>. You may call <function>TakeDevice()</function> again if a new + device is assigned the major+minor combination.</para> + + <para><function>ResumeDevice</function> is sent whenever a session is active and a device is + resumed. It carries the major/minor numbers as arguments and provides a new open file descriptor. You should + switch to the new descriptor and close the old one. They are not guaranteed to have the same underlying + open file descriptor in the kernel (except for a limited set of device types).</para> + + <para>Whenever <function>Active</function> or the idle state changes, + <function>PropertyChanged</function> signals are sent out to which clients can subscribe.</para> + + <para><function>Lock</function>/<function>Unlock</function> is sent when the session is asked to be + screen-locked/unlocked. A session manager of the session should listen to this signal and act + accordingly. This signal is sent out as a result of the <function>Lock()</function> and + <function>Unlock()</function> methods, respectively.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>Id</varname> encodes the session ID.</para> + + <para><varname>User</varname> encodes the user ID of the user this session belongs to. This is a + structure consisting of the Unix UID and the object path.</para> + + <para><varname>Name</varname> encodes the user name.</para> + + <para><varname>Timestamp</varname> and <varname>TimestampMonotonic</varname> encode the microseconds + since the epoch when the session was created, in <constant>CLOCK_REALTIME</constant> or + <constant>CLOCK_MONOTONIC</constant>, respectively.</para> + + <para><varname>VTNr</varname> encodes the virtual terminal number of the session if there is any, 0 + otherwise.</para> + + <para><varname>Seat</varname> encodes the seat this session belongs to if there is any. This is a + structure consisting of the ID and the seat object path.</para> + + <para><varname>TTY</varname> encodes the kernel TTY path of the session if this is a text login. If not + this is an empty string.</para> + + <para><varname>Display</varname> encodes the X11 display name if this is a graphical login. If not, + this is an empty string.</para> + + <para><varname>Remote</varname> encodes whether the session is local or remote.</para> + + <para><varname>RemoteHost</varname> and <varname>RemoteUser</varname> encode the remote host and user + if this is a remote session, or an empty string otherwise.</para> + + <para><varname>Service</varname> encodes the PAM service name that registered the session.</para> + + <para><varname>Desktop</varname> describes the desktop environment running in the session (if + known).</para> + + <para><varname>Scope</varname> contains the systemd scope unit name of this session.</para> + + <para><varname>Leader</varname> encodes the PID of the process that registered the session.</para> + + <para><varname>Audit</varname> encodes the Kernel Audit session ID of the session if auditing is + available.</para> + + <para><varname>Type</varname> encodes the session type. It's one of <literal>unspecified</literal> (for + cron PAM sessions and suchlike), <literal>tty</literal> (for text logins) or + <literal>x11</literal>/<literal>mir</literal>/<literal>wayland</literal> (for graphical logins).</para> + + <para><varname>Class</varname> encodes the session class. It's one of <literal>user</literal> (for + normal user sessions), <literal>greeter</literal> (for display manager pseudo-sessions), or + <literal>lock-screen</literal> (for display lock screens).</para> + + <para><varname>Active</varname> is a boolean that is true if the session is active, i.e. currently in the + foreground. This field is semi-redundant due to <varname>State</varname>.</para> + + <para><varname>State</varname> encodes the session state and one of <literal>online</literal>, + <literal>active</literal>, or <literal>closing</literal>. See + <citerefentry><refentrytitle>sd_session_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the states.</para> + + <para><varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and + <varname>IdleSinceHintMonotonic</varname> encapsulate the idle hint state of this session, similarly to + how the respective properties on the manager object do it for the whole system.</para> + + <para><varname>LockedHint</varname> shows the locked hint state of this session, as set by the + <function>SetLockedHint()</function> method described above.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.login1.Manager</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1 + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.login1.Seat</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1/seat/seat0 + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.login1.User</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1/user/_1000 + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.login1.Session</interfacename> on the bus</title> + + <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1/session/45 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.machine1.xml b/man/org.freedesktop.machine1.xml new file mode 100644 index 0000000..284c3d6 --- /dev/null +++ b/man/org.freedesktop.machine1.xml @@ -0,0 +1,643 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.machine1" conditional='ENABLE_MACHINED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.machine1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.machine1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.machine1</refname> + <refpurpose>The D-Bus interface of systemd-machined</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service that keeps track of locally running virtual machines and containers. + This page describes the D-Bus interface.</para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The service exposes the following interfaces on the Manager object on the bus:</para> + + <programlisting executable="systemd-machined" node="/org/freedesktop/machine1" interface="org.freedesktop.machine1.Manager"> +node /org/freedesktop/machine1 { + interface org.freedesktop.machine1.Manager { + methods: + GetMachine(in s name, + out o machine); + GetImage(in s name, + out o image); + GetMachineByPID(in u pid, + out o machine); + ListMachines(out a(ssso) machines); + ListImages(out a(ssbttto) images); + CreateMachine(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + in a(sv) scope_properties, + out o path); + CreateMachineWithNetwork(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + in ai ifindices, + in a(sv) scope_properties, + out o path); + RegisterMachine(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + out o path); + RegisterMachineWithNetwork(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + in ai ifindices, + out o path); + UnregisterMachine(in s name); + TerminateMachine(in s id); + KillMachine(in s name, + in s who, + in i signal); + GetMachineAddresses(in s name, + out a(iay) addresses); + GetMachineOSRelease(in s name, + out a{ss} fields); + OpenMachinePTY(in s name, + out h pty, + out s pty_path); + OpenMachineLogin(in s name, + out h pty, + out s pty_path); + OpenMachineShell(in s name, + in s user, + in s path, + in as args, + in as environment, + out h pty, + out s pty_path); + BindMountMachine(in s name, + in s source, + in s destination, + in b read_only, + in b mkdir); + CopyFromMachine(in s name, + in s source, + in s destination); + CopyToMachine(in s name, + in s source, + in s destination); + OpenMachineRootDirectory(in s name, + out h fd); + GetMachineUIDShift(in s name, + out u shift); + RemoveImage(in s name); + RenameImage(in s name, + in s new_name); + CloneImage(in s name, + in s new_name, + in b read_only); + MarkImageReadOnly(in s name, + in b read_only); + GetImageHostname(in s name, + out s hostname); + GetImageMachineID(in s name, + out ay id); + GetImageMachineInfo(in s name, + out a{ss} machine_info); + GetImageOSRelease(in s name, + out a{ss} os_release); + SetPoolLimit(in t size); + SetImageLimit(in s name, + in t size); + CleanPool(in s mode, + out a(st) images); + MapFromMachineUser(in s name, + in u uid_inner, + out u uid_outer); + MapToMachineUser(in u uid_outer, + out s machine_name, + out o machine_path, + out u uid_inner); + MapFromMachineGroup(in s name, + in u gid_inner, + out u gid_outer); + MapToMachineGroup(in u gid_outer, + out s machine_name, + out o machine_path, + out u gid_inner); + signals: + MachineNew(s machine, + o path); + MachineRemoved(s machine, + o path); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s PoolPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t PoolUsage = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t PoolLimit = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method UnregisterMachine is not documented!--> + + <!--method OpenMachineRootDirectory is not documented!--> + + <!--method GetMachineUIDShift is not documented!--> + + <!--method GetImageHostname is not documented!--> + + <!--method GetImageMachineID is not documented!--> + + <!--method GetImageMachineInfo is not documented!--> + + <!--method GetImageOSRelease is not documented!--> + + <!--method CleanPool is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetImage()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetMachineByPID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListMachines()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListImages()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CreateMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CreateMachineWithNetwork()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RegisterMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RegisterMachineWithNetwork()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnregisterMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TerminateMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="KillMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetMachineAddresses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetMachineOSRelease()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenMachinePTY()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenMachineLogin()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenMachineShell()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="BindMountMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CopyFromMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CopyToMachine()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenMachineRootDirectory()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetMachineUIDShift()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RemoveImage()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RenameImage()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CloneImage()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="MarkImageReadOnly()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetImageHostname()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetImageMachineID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetImageMachineInfo()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetImageOSRelease()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetPoolLimit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetImageLimit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CleanPool()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="MapFromMachineUser()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="MapToMachineUser()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="MapFromMachineGroup()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="MapToMachineGroup()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="MachineNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="MachineRemoved"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PoolPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PoolUsage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PoolLimit"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>GetMachine()</function> may be used to get the machine object path for the machine with + the specified name. Similarly, <function>GetMachineByPID()</function> gets the machine object the + specified PID belongs to if there is any.</para> + + <para><function>GetImage()</function> may be used to get the image object path of the image with the + specified name.</para> + + <para><function>ListMachines()</function> returns an array of all currently registered machines. The + structures in the array consist of the following fields: machine name, machine class, an identifier for + the service that registered the machine and the machine object path.</para> + + <para><function>ListImages()</function> returns an array of all currently known images. The + structures in the array consist of the following fields: image name, type, read-only flag, creation + time, modification time, current disk space, and image object path.</para> + + <para><function>CreateMachine()</function> may be used to register a new virtual machine or container + with <command>systemd-machined</command>, creating a scope unit for it. It accepts the following arguments: a + machine name chosen by the registrar, an optional UUID as a 32 byte array, a string that identifies the + service that registers the machine, a class string, the PID of the leader process of the machine, an + optional root directory of the container, and an array of additional properties to use for the scope + registration. The virtual machine name must be suitable as a hostname, and hence should follow the usual + DNS hostname rules, as well as the Linux hostname restrictions. Specifically, only 7 bit ASCII is + permitted, a maximum length of 64 characters is enforced, only characters from the set + <literal>a-zA-Z0-9-_.</literal> are allowed, the name may not begin with a dot, and it may not contain + two dots immediately following each other. Container and VM managers should ideally use the hostname + used internally in the machine for this parameter. This recommendation is made in order to make the + machine name naturally resolvable using + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>. If + a container manager needs to embed characters outside of the indicated range, escaping is required, + possibly using <literal>_</literal> as the escape character. Another (somewhat natural) option would be + to utilize Internet IDNA encoding. The UUID is passed as a 32 byte array or, if no suitable UUID is + available, an empty array (zero length) or zeroed out array shall be passed. The UUID should identify + the virtual machine/container uniquely and should ideally be the same UUID that + <filename>/etc/machine-id</filename> in the VM/container is initialized from. The service string can be + free-form, but it is recommended to pass a short lowercase identifier like + <literal>systemd-nspawn</literal>, <literal>libvirt-lxc</literal> or similar. The class string should + be either <literal>container</literal> or <literal>vm</literal> indicating whether the machine to + register is of the respective class. The leader PID should be the host PID of the init process of the + container or the encapsulating process of the VM. If the root directory of the container is known and + available in the host's hierarchy, it should be passed. Otherwise, pass the empty string instead. Finally, the + scope properties are passed as array in the same way as to PID1's + <function>StartTransientUnit()</function> method. Calling this method will internally register a transient scope + unit for the calling client (utilizing the passed scope_properties) and move the leader PID into + it. The method returns an object path for the registered machine object that implements the + <interfacename>org.freedesktop.machine1.Machine</interfacename> interface (see below). Also see the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New Control Group + Interfaces</ulink> for details about scope units and how to alter resource control settings on the + created machine at runtime.</para> + + <para><function>RegisterMachine()</function> is similar to <function>CreateMachine()</function>. + However, it only registers a machine and does not create a scope unit for it. Instead, the caller's unit is + registered. We recommend to only use this method for container or VM managers that are run + multiple times, one instance for each container/VM they manage, and are invoked as system + services.</para> + + <para><function>CreateMachineWithNetwork()</function> and + <function>RegisterMachineWithNetwork()</function> are similar to <function>CreateMachine()</function> + and <function>RegisterMachine()</function> but take an extra argument: an array of network interface + indices that point towards the virtual machine or container. The interface indices should reference one + or more network interfaces on the host that can be used to communicate with the guest. Commonly, the + passed interface index refers to the host side of a "veth" link (in case of containers), a + "tun"/"tap" link (in case of VMs), or the host side of a bridge interface that bridges access to the + VM/container interfaces. Specifying this information is useful to enable support for link-local IPv6 + communication to the machines since the scope field of sockaddr_in6 can be initialized by the + specified ifindex. + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry> + makes use of this information.</para> + + <para><function>KillMachine()</function> sends a UNIX signal to the machine's processes. As its arguments, it takes a + machine name (as originally passed to <function>CreateMachine()</function> or returned by + <function>ListMachines()</function>), an identifier that specifies what precisely to send the signal to (either + <literal>leader</literal> or <literal>all</literal>), and a numeric UNIX signal integer.</para> + + <para><function>TerminateMachine()</function> terminates a virtual machine, killing its processes. It + takes a machine name as its only argument.</para> + + <para><function>GetMachineAddresses()</function> retrieves the IP addresses of a container. This method + returns an array of pairs consisting of an address family specifier (<constant>AF_INET</constant> or + <constant>AF_INET6</constant>) and a byte array containing the addresses. This is only supported for + containers that make use of network namespacing.</para> + + <para><function>GetMachineOSRelease()</function> retrieves the OS release information of a + container. This method returns an array of key value pairs read from the + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file in + the container and is useful to identify the operating system used in a container.</para> + + <para><function>OpenMachinePTY()</function> allocates a pseudo TTY in the container and returns a file + descriptor and its path. This is equivalent to transitioning into the container and invoking + <citerefentry project="man-pages"><refentrytitle>posix_openpt</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>OpenMachineLogin()</function> allocates a pseudo TTY in the container and ensures that + a getty login prompt of the container is running on the other end. It returns the file descriptor of + the PTY and the PTY path. This is useful for acquiring a pty with a login prompt from the + container.</para> + + <para><function>OpenMachineShell()</function> allocates a pseudo TTY in the container, as the specified + user, and invokes the executable at the specified path with a list of arguments (starting from + argv[0]) and an environment block. It then returns the file descriptor of the PTY and the PTY + path.</para> + + <para><function>BindMountMachine()</function> bind mounts a file or directory from the host into the + container. Its arguments consist of a machine name, the source directory on the host, the destination directory in the + container, and two booleans, one indicating whether the bind mount shall be + read-only, the other indicating whether the destination mount point shall be created first, if it is + missing.</para> + + <para><function>CopyFromMachine()</function> copies files or directories from a container into the + host. It takes a container name, a source directory in the container and a destination directory on the + host as arguments. <function>CopyToMachine()</function> does the opposite and copies files from a source + directory on the host into a destination directory in the container.</para> + + <para><function>RemoveImage()</function> removes the image with the specified name.</para> + + <para><function>RenameImage()</function> renames the specified image.</para> + + <para><function>CloneImage()</function> clones the specified image under a new name. It also takes a + boolean argument indicating whether the resulting image shall be read-only or not.</para> + + <para><function>MarkImageReadOnly()</function> toggles the read-only flag of an image.</para> + + <para><function>SetPoolLimit()</function> sets an overall quota limit on the pool of images.</para> + + <para><function>SetImageLimit()</function> sets a per-image quota limit.</para> + + <para><function>MapFromMachineUser()</function>, <function>MapToMachineUser()</function>, + <function>MapFromMachineGroup()</function>, and <function>MapToMachineGroup()</function> may be used to map + UIDs/GIDs from the host user namespace to a container user namespace or vice versa.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para><function>MachineNew</function> and <function>MachineRemoved</function> are sent whenever a new + machine is registered or removed. These signals carry the machine name and the object path to the corresponding + <interfacename>org.freedesktop.machine1.Machine</interfacename> interface (see below).</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>PoolPath</varname> specifies the file system path where images are written to.</para> + + <para><varname>PoolUsage</varname> specifies the current usage size of the image pool in bytes.</para> + + <para><varname>PoolLimit</varname> specifies the size limit of the image pool in bytes.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Machine Objects</title> + + <programlisting executable="systemd-machined" node="/org/freedesktop/machine1/machine/rawhide" interface="org.freedesktop.machine1.Machine"> +node /org/freedesktop/machine1/machine/rawhide { + interface org.freedesktop.machine1.Machine { + methods: + Terminate(); + Kill(in s who, + in i signal); + GetAddresses(out a(iay) addresses); + GetOSRelease(out a{ss} fields); + GetUIDShift(out u shift); + OpenPTY(out h pty, + out s pty_path); + OpenLogin(out h pty, + out s pty_path); + OpenShell(in s user, + in s path, + in as args, + in as environment, + out h pty, + out s pty_path); + BindMount(in s source, + in s destination, + in b read_only, + in b mkdir); + CopyFrom(in s source, + in s destination); + CopyTo(in s source, + in s destination); + OpenRootDirectory(out h fd); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay Id = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t Timestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Service = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Unit = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Leader = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Class = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ai NetworkInterfaces = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s State = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method GetUIDShift is not documented!--> + + <!--method OpenPTY is not documented!--> + + <!--method OpenLogin is not documented!--> + + <!--method OpenShell is not documented!--> + + <!--method BindMount is not documented!--> + + <!--method CopyFrom is not documented!--> + + <!--method CopyTo is not documented!--> + + <!--method OpenRootDirectory is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Machine"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Machine"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetAddresses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetOSRelease()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUIDShift()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenPTY()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenLogin()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenShell()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="BindMount()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CopyFrom()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CopyTo()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="OpenRootDirectory()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Name"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Id"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Timestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Service"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Unit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Leader"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Class"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NetworkInterfaces"/> + + <variablelist class="dbus-property" generated="True" extra-ref="State"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Terminate()</function> and <function>Kill()</function> terminate/kill the machine. These methods + take the same arguments as <function>TerminateMachine()</function> and + <function>KillMachine()</function> on the Manager interface, respectively.</para> + + <para><function>GetAddresses()</function> and <function>GetOSRelease()</function> get the IP address and OS + release information from the machine. These methods take the same arguments as + <function>GetMachineAddresses()</function> and <function>GetMachineOSRelease()</function> of the + Manager interface, respectively.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>Name</varname> is the machine name as it was passed in during registration with + <function>CreateMachine()</function> on the manager object.</para> + + <para><varname>Id</varname> is the machine UUID.</para> + + <para><varname>Timestamp</varname> and <varname>TimestampMonotonic</varname> are the realtime and + monotonic timestamps when the virtual machines where created in microseconds since the epoch.</para> + + <para><varname>Service</varname> contains a short string identifying the registering service as passed + in during registration of the machine.</para> + + <para><varname>Unit</varname> is the systemd scope or service unit name for the machine.</para> + + <para><varname>Leader</varname> is the PID of the leader process of the machine.</para> + + <para><varname>Class</varname> is the class of the machine and is either the string "vm" (for real VMs + based on virtualized hardware) or "container" (for light-weight userspace virtualization sharing the + same kernel as the host).</para> + + <para><varname>RootDirectory</varname> is the root directory of the container if it is known and + applicable or the empty string.</para> + + <para><varname>NetworkInterfaces</varname> contains an array of network interface indices that point + towards the container, the VM or the host. For details about this information see the description of + <function>CreateMachineWithNetwork()</function> above.</para> + + <para><varname>State</varname> is the state of the machine and is one of <literal>opening</literal>, + <literal>running</literal>, or <literal>closing</literal>. Note that the state machine is not considered + part of the API and states might be removed or added without this being considered API breakage. + </para> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.machine1.Manager</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.machine1 \ + --object-path /org/freedesktop/machine1 + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.machine1.Machine</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.machine1 \ + --object-path /org/freedesktop/machine1/machine/rawhide + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.oom1.xml b/man/org.freedesktop.oom1.xml new file mode 100644 index 0000000..ab0725e --- /dev/null +++ b/man/org.freedesktop.oom1.xml @@ -0,0 +1,74 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.oom1" conditional='ENABLE_OOMD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.oom1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.oom1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.oom1</refname> + <refpurpose>The D-Bus interface of systemd-oomd</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service which implements a userspace out-of-memory (OOM) killer. This page describes the + D-Bus interface.</para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The service exposes the following interfaces on the Manager object on the bus:</para> + + <programlisting executable="systemd-oomd" node="/org/freedesktop/oom1" interface="org.freedesktop.oom1.Manager"> +node /org/freedesktop/oom1 { + interface org.freedesktop.oom1.Manager { + methods: + DumpByFileDescriptor(out h fd); + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method DumpByFileDescriptor is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.oom1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.oom1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="DumpByFileDescriptor()"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para>...</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.resolve1.xml b/man/org.freedesktop.resolve1.xml new file mode 100644 index 0000000..4156236 --- /dev/null +++ b/man/org.freedesktop.resolve1.xml @@ -0,0 +1,856 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="org.freedesktop.resolve1" conditional='ENABLE_RESOLVE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.resolve1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.resolve1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.resolve1</refname> + <refpurpose>The D-Bus interface of systemd-resolved</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service that provides hostname resolution and caching using DNS, LLMNR, and mDNS. It also + does DNSSEC validation. This page describes the resolve semantics and the D-Bus interface.</para> + + <para>This page contains an API reference only. If you are looking for a longer explanation how to use + this API, please consult + <ulink url="https://wiki.freedesktop.org/www/Software/systemd/writing-network-configuration-managers"> + Writing Network Configuration Managers</ulink> and + <ulink url="https://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients">Writing Resolver + Clients</ulink>. + </para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The service exposes the following interfaces on the Manager object on the bus:</para> + + <programlisting executable="systemd-resolved" node="/org/freedesktop/resolve1" interface="org.freedesktop.resolve1.Manager"> +node /org/freedesktop/resolve1 { + interface org.freedesktop.resolve1.Manager { + methods: + ResolveHostname(in i ifindex, + in s name, + in i family, + in t flags, + out a(iiay) addresses, + out s canonical, + out t flags); + ResolveAddress(in i ifindex, + in i family, + in ay address, + in t flags, + out a(is) names, + out t flags); + ResolveRecord(in i ifindex, + in s name, + in q class, + in q type, + in t flags, + out a(iqqay) records, + out t flags); + ResolveService(in i ifindex, + in s name, + in s type, + in s domain, + in i family, + in t flags, + out a(qqqsa(iiay)s) srv_data, + out aay txt_data, + out s canonical_name, + out s canonical_type, + out s canonical_domain, + out t flags); + GetLink(in i ifindex, + out o path); + SetLinkDNS(in i ifindex, + in a(iay) addresses); + SetLinkDNSEx(in i ifindex, + in a(iayqs) addresses); + SetLinkDomains(in i ifindex, + in a(sb) domains); + SetLinkDefaultRoute(in i ifindex, + in b enable); + SetLinkLLMNR(in i ifindex, + in s mode); + SetLinkMulticastDNS(in i ifindex, + in s mode); + SetLinkDNSOverTLS(in i ifindex, + in s mode); + SetLinkDNSSEC(in i ifindex, + in s mode); + SetLinkDNSSECNegativeTrustAnchors(in i ifindex, + in as names); + RevertLink(in i ifindex); + RegisterService(in s name, + in s name_template, + in s type, + in q service_port, + in q service_priority, + in q service_weight, + in aa{say} txt_datas, + out o service_path); + UnregisterService(in o service_path); + ResetStatistics(); + FlushCaches(); + ResetServerFeatures(); + properties: + readonly s LLMNRHostname = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s LLMNR = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s MulticastDNS = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSOverTLS = '...'; + readonly a(iiay) DNS = [...]; + readonly a(iiayqs) DNSEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(iiay) FallbackDNS = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(iiayqs) FallbackDNSEx = [...]; + readonly (iiay) CurrentDNSServer = ...; + readonly (iiayqs) CurrentDNSServerEx = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(isb) Domains = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (tt) TransactionStatistics = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (ttt) CacheStatistics = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSSEC = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (tttt) DNSSECStatistics = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b DNSSECSupported = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DNSSECNegativeTrustAnchors = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSStubListener = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ResolvConfMode = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method RegisterService is not documented!--> + + <!--method UnregisterService is not documented!--> + + <!--method FlushCaches is not documented!--> + + <!--method ResetServerFeatures is not documented!--> + + <!--property DNSSECNegativeTrustAnchors is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResolveHostname()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResolveAddress()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResolveRecord()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResolveService()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetLink()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNS()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSEx()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDomains()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDefaultRoute()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkLLMNR()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkMulticastDNS()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSOverTLS()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSSEC()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSSECNegativeTrustAnchors()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RevertLink()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RegisterService()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnregisterService()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResetStatistics()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="FlushCaches()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResetServerFeatures()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LLMNRHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LLMNR"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MulticastDNS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSOverTLS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FallbackDNS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FallbackDNSEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServer"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServerEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Domains"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TransactionStatistics"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheStatistics"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSEC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSECStatistics"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSECSupported"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSECNegativeTrustAnchors"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSStubListener"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ResolvConfMode"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>ResolveHostname()</function> takes a hostname and resolves it to one or more IP + addresses. As parameters it takes the Linux network interface index to execute the query on, or 0 if + it may be done on any suitable interface. The <varname>name</varname> parameter specifies the hostname + to resolve. Note that if required, IDNA conversion is applied to this name unless it is resolved via + LLMNR or MulticastDNS. The <varname>family</varname> parameter limits the results to a specific address + family. It may be <constant>AF_INET</constant>, <constant>AF_INET6</constant> or + <constant>AF_UNSPEC</constant>. If <constant>AF_UNSPEC</constant> is specified (recommended), both + kinds are retrieved, subject to local network configuration (i.e. if no local, routable IPv6 address is + found, no IPv6 address is retrieved; and similarly for IPv4). A 64-bit <varname>flags</varname> field + may be used to alter the behaviour of the resolver operation (see below). The method returns an array + of address records. Each address record consists of the interface index the address belongs to, an + address family as well as a byte array with the actual IP address data (which either has 4 or 16 + elements, depending on the address family). The returned address family will be one of + <constant>AF_INET</constant> or <constant>AF_INET6</constant>. For IPv6, the returned address interface + index should be used to initialize the .sin6_scope_id field of a + <structname>struct sockaddr_in6</structname> instance to permit support for resolution to link-local IP + addresses. The address array is followed by the canonical name of the host, which may or may not be + identical to the resolved hostname. Finally, a 64-bit <varname>flags</varname> field is returned that + is defined similarly to the <varname>flags</varname> field that was passed in, but contains information + about the resolved data (see below). If the hostname passed in is an IPv4 or IPv6 address formatted as + string, it is parsed, and the result is returned. In this case, no network communication is + done.</para> + + <para><function>ResolveAddress()</function> executes the reverse operation: it takes an IP address and + acquires one or more hostnames for it. As parameters it takes the interface index to execute the query + on, or <constant>0</constant> if all suitable interfaces are OK. The <varname>family</varname> + parameter indicates the address family of the IP address to resolve. It may be either + <constant>AF_INET</constant> or <constant>AF_INET6</constant>. The <varname>address</varname> parameter + takes the raw IP address data (as either a 4 or 16 byte array). The <varname>flags</varname> input + parameter may be used to alter the resolver operation (see below). The method returns an array of name + records, each consisting of an interface index and a hostname. The <varname>flags</varname> output + field contains additional information about the resolver operation (see below).</para> + + <para><function>ResolveRecord()</function> takes a DNS resource record (RR) type, class and name, and + retrieves the full resource record set (RRset), including the RDATA, for it. As parameter it takes the + Linux network interface index to execute the query on, or <constant>0</constant> if it may be done on + any suitable interface. The <varname>name</varname> parameter specifies the RR domain name to look up + (no IDNA conversion is applied), followed by the 16-bit class and type fields (which may be + ANY). Finally, a <varname>flags</varname> field may be passed in to alter behaviour of the look-up (see + below). On completion, an array of RR items is returned. Each array entry consists of the network interface + index the RR was discovered on, the type and class field of the RR found, and a byte array of the raw + RR discovered. The raw RR data starts with the RR's domain name, in the original casing, followed + by the RR type, class, TTL and RDATA, in the binary format documented in + <ulink url="https://www.ietf.org/rfc/rfc1035.txt">RFC 1035</ulink>. For RRs that support name + compression in the payload (such as MX or PTR), the compression is expanded in the returned + data.</para> + + <para>Note that currently, the class field has to be specified as IN or ANY. Specifying a different + class will return an error indicating that look-ups of this kind are unsupported. Similarly, some + special types are not supported either (AXFR, OPT, …). While <filename>systemd-resolved</filename> parses and validates resource + records of many types, it is crucial that clients using this API understand that the RR data originates + from the network and should be thoroughly validated before use.</para> + + <para><function>ResolveService()</function> may be used to resolve a DNS SRV service record, as well as the + hostnames referenced in it, and possibly an accompanying DNS-SD TXT record containing additional + service metadata. The primary benefit of using this method over <function>ResolveRecord()</function> + specifying the SRV type is that it will resolve the SRV and TXT RRs as well as the hostnames referenced + in the SRV in a single operation. As parameters it takes a Linux network interface index, a service + name, a service type and a service domain. This method may be invoked in three different modes:</para> + + <orderedlist> + <listitem><para>To resolve a DNS-SD service, specify the service name (e.g. <literal>Lennart's + Files</literal>), the service type (e.g. <literal>_webdav._tcp</literal>) and the domain to search in + (e.g. <literal>local</literal>) as the three service parameters. The service name must be in UTF-8 + format, and no IDNA conversion is applied to it in this mode (as mandated by the DNS-SD + specifications). However, if necessary, IDNA conversion is applied to the domain parameter.</para> + </listitem> + + <listitem><para>To resolve a plain SRV record, set the service name parameter to the empty string + and set the service type and domain properly. (IDNA conversion is applied to the domain, if + necessary.)</para></listitem> + + <listitem><para>Alternatively, leave both the service name and type empty and specify the full + domain name of the SRV record (i.e. prefixed with the service type) in the domain parameter. (No IDNA + coversion is applied in this mode.)</para></listitem> + </orderedlist> + + <para>The <varname>family</varname> parameter of the <function>ResolveService()</function> method encodes + the desired family of the addresses to resolve (use <constant>AF_INET</constant>, + <constant>AF_INET6</constant>, or <constant>AF_UNSPEC</constant>). If this is enabled (Use the + <constant>NO_ADDRESS</constant> flag to turn address resolution off, see below). The + <varname>flags</varname> parameter takes a couple of flags that may be used to alter the resolver + operation.</para> + + <para>On completion, <function>ResolveService()</function> returns an array of SRV record structures. Each + items consisting of the priority, weight and port fields as well as the hostname to contact, as encoded in the SRV + record. Immediately following is an array of the addresses of this hostname, with each item consisting + of the interface index, the address family and the address data in a byte array. This address array is + followed by the canonicalized hostname. After this array of SRV record structures an array of byte + arrays follows that encodes the TXT RR strings, in case DNS-SD look-ups are enabled. The next parameters + are the canonical service name, type and domain. This may or may not be identical to the parameters + passed in. Finally, a <varname>flags</varname> field is returned that contains information about the + resolver operation performed.</para> + + <para>The <function>ResetStatistics()</function> method resets the various statistics counters that + <filename>systemd-resolved</filename> maintains to zero. (For details, see the statistics properties below.)</para> + + <para>The <function>GetLink()</function> method takes a network interface index and returns the object + path to the <interfacename>org.freedesktop.resolve1.Link</interfacename> object corresponding to it. + </para> + + <para>The <function>SetLinkDNS()</function> method sets the DNS servers to use on a specific + interface. This method (and the following ones) may be used by network management software to configure + per-interface DNS settings. It takes a network interface index as well as an array of DNS server IP + address records. Each array item consists of an address family (either <constant>AF_INET</constant> or + <constant>AF_INET6</constant>), followed by a 4-byte or 16-byte array with the raw address data. This + method is a one-step shortcut for retrieving the Link object for a network interface using + <function>GetLink()</function> (see above) and then invoking the <function>SetDNS()</function> method + (see below) on it.</para> + + <para><function>SetLinkDNSEx()</function> is similar to <function>SetLinkDNS()</function>, but allows + an IP port (instead of the default 53) and DNS name to be specified for each DNS server. The server + name is used for Server Name Indication (SNI), which is useful when DNS-over-TLS is + used. C.f. <varname>DNS=</varname> in + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para><function>SetLinkDefaultRoute()</function> specifies whether the link shall be used as the + default route for name queries. See the description of name routing in + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details.</para> + + <para>The <function>SetLinkDomains()</function> method sets the search and routing domains to use on a + specific network interface for DNS look-ups. It takes a network interface index and an array of domains, + each with a boolean parameter indicating whether the specified domain shall be used as a search domain + (false), or just as a routing domain (true). Search domains are used for qualifying single-label names into + FQDN when looking up hostnames, as well as for making routing decisions on which interface to send + queries ending in the domain to. Routing domains are only used for routing decisions and not used for single-label + name qualification. Pass the search domains in the order they should be used.</para> + + <para>The <function>SetLinkLLMNR()</function> method enables or disables LLMNR support on a specific + network interface. It takes a network interface index as well as a string that may either be empty or one of + <literal>yes</literal>, <literal>no</literal> or <literal>resolve</literal>. If empty, the systemd-wide + default LLMNR setting is used. If <literal>yes</literal>, LLMNR is used for resolution of single-label + names and the local hostname is registered on all local LANs for LLMNR resolution by peers. If + <literal>no</literal>, LLMNR is turned off fully on this interface. If <literal>resolve</literal>, LLMNR + is only enabled for resolving names, but the local hostname is not registered for other peers to + use.</para> + + <para>Similarly, the <function>SetLinkMulticastDNS()</function> method enables or disables MulticastDNS + support on a specific interface. It takes the same parameters as <function>SetLinkLLMNR()</function> + described above.</para> + + <para>The <function>SetLinkDNSSEC()</function> method enables or disables DNSSEC validation on a + specific network interface. It takes a network interface index as well as a string that may either be + empty or one of <literal>yes</literal>, <literal>no</literal>, or <literal>allow-downgrade</literal>. When + empty, the system-wide default DNSSEC setting is used. If <literal>yes</literal>, full DNSSEC validation + is done for all look-ups. If the selected DNS server does not support DNSSEC, look-ups will fail if this + mode is used. If <literal>no</literal>, DNSSEC validation is fully disabled. If + <literal>allow-downgrade</literal>, DNSSEC validation is enabled, but is turned off automatically if the + selected server does not support it (thus opening up behaviour to downgrade attacks). Note that DNSSEC + only applies to traditional DNS, not to LLMNR or MulticastDNS.</para> + + <para>The <function>SetLinkDNSSECNegativeTrustAnchors()</function> method may be used to configure DNSSEC + Negative Trust Anchors (NTAs) for a specific network interface. It takes a network interface index and a + list of domains as arguments.</para> + + <para>The <function>SetLinkDNSOverTLS()</function> method enables or disables DNS-over-TLS. + C.f. <varname>DNSOverTLS=</varname> in + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details.</para> + + <para>Network management software integrating with <filename>systemd-resolved</filename> should call + <function>SetLinkDNS()</function> or <function>SetLinkDNSEx()</function>, + <function>SetLinkDefaultRoute()</function>, <function>SetLinkDomains()</function> and others after the + interface appeared in the kernel (and thus after a network interface index has been assigned), but + before the network interfaces is activated (<constant>IFF_UP</constant> set) so that all settings take + effect during the full time the network interface is up. It is safe to alter settings while the + interface is up, however. Use <function>RevertLink()</function> (described below) to reset all + per-interface settings.</para> + + <para>The <function>RevertLink()</function> method may be used to revert all per-link settings + described above to the defaults.</para> + + <refsect3> + <title>The Flags Parameter</title> + + <para>The four methods above accept and return a 64-bit flags value. In most cases passing 0 is sufficient + and recommended. However, the following flags are defined to alter the look-up:</para> + + <programlisting> +#define SD_RESOLVED_DNS (UINT64_C(1) << 0) +#define SD_RESOLVED_LLMNR_IPV4 (UINT64_C(1) << 1) +#define SD_RESOLVED_LLMNR_IPV6 (UINT64_C(1) << 2) +#define SD_RESOLVED_MDNS_IPV4 (UINT64_C(1) << 3) +#define SD_RESOLVED_MDNS_IPV6 (UINT64_C(1) << 4) +#define SD_RESOLVED_NO_CNAME (UINT64_C(1) << 5) +#define SD_RESOLVED_NO_TXT (UINT64_C(1) << 6) +#define SD_RESOLVED_NO_ADDRESS (UINT64_C(1) << 7) +#define SD_RESOLVED_NO_SEARCH (UINT64_C(1) << 8) +#define SD_RESOLVED_AUTHENTICATED (UINT64_C(1) << 9) + </programlisting> + + <para>On input, the first five flags control the protocols to use for the look-up. They refer to + classic unicast DNS, LLMNR via IPv4/UDP and IPv6/UDP respectively, as well as MulticastDNS via + IPv4/UDP and IPv6/UDP. If all of these five bits are off on input (which is strongly recommended) the + look-up will be done via all suitable protocols for the specific look-up. Note that these flags + operate as filter only, but cannot force a look-up to be done via a protocol. Specifically, + <filename>systemd-resolved</filename> will only route look-ups within the .local TLD to MulticastDNS + (plus some reverse look-up address domains), and single-label names to LLMNR (plus some reverse + address lookup domains). It will route neither of these to Unicast DNS servers. Also, it will do + LLMNR and Multicast DNS only on interfaces suitable for multicast.</para> + + <para>On output, these five flags indicate which protocol was used to execute the operation, and hence + where the data was found.</para> + + <para>The primary use cases for these five flags are follow-up look-ups based on DNS data retrieved + earlier. In this case it is often a good idea to limit the follow-up look-up to the protocol that was + used to discover the first DNS result.</para> + + <para>The NO_CNAME flag controls whether CNAME/DNAME resource records shall be followed during the + look-up. This flag is only available at input, none of the functions will return it on output. If a + CNAME/DNAME RR is discovered while resolving a hostname, an error is returned instead. By default, + when the flag is off, CNAME/DNAME RRs are followed.</para> + + <para>The NO_TXT and NO_ADDRESS flags only influence operation of the + <function>ResolveService()</function> method. They are only defined for input, not output. If + NO_TXT set, the DNS-SD TXT RR look-up is not done in the same operation. If NO_ADDRESS is specified, + the hostnames discovered are not implicitly translated to their addresses.</para> + + <para>The NO_SEARCH flag turns off the search domain logic. It is only defined for input in + <function>ResolveHostname()</function>. When specified, single-label hostnames are not qualified + using defined search domains, if any are configured. Note that <function>ResolveRecord()</function> + will never qualify single-label domain names using search domains. Also note that + multi-label hostnames are never subject to search list expansion.</para> + + <para>The AUTHENTICATED bit is defined only in the output flags of the four functions. If set, the + returned data has been fully authenticated. Specifically, this bit is set for all DNSSEC-protected data + for which a full trust chain may be established to a trusted domain anchor. It is also set for locally + synthesized data, such as <literal>localhost</literal> or data from + <filename>/etc/hosts</filename>. Moreover, it is set for all LLMNR or mDNS RRs which originate from the + local host. Applications that require authenticated RR data for operation should check this flag before + trusting the data. Note that <filename>systemd-resolved</filename> will never return invalidated data, hence this flag + simply allows to discern the cases where data is known to be trustable, or where there is proof that + the data is "rightfully" unauthenticated (which includes cases where the underlying protocol or server + does not support authenticating data).</para> + </refsect3> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>The <varname>LLMNR</varname> and <varname>MulticastDNS</varname> properties report whether LLMNR + and MulticastDNS are (globally) enabled. Each may be one of <literal>yes</literal>, + <literal>no</literal>, and <literal>resolve</literal>. See <function>SetLinkLLMNR()</function> + and <function>SetLinkMulticastDNS()</function> above.</para> + + <para><varname>LLMNRHostname</varname> contains the hostname currently exposed on the network via + LLMNR. It usually follows the system hostname as may be queried via + <citerefentry project="man-pages"><refentrytitle>gethostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but may differ if a conflict is detected on the network.</para> + + <para><varname>DNS</varname> and <varname>DNSEx</varname> contain arrays of all DNS servers currently + used by <filename>systemd-resolved</filename>. <varname>DNS</varname> contains information similar to + the DNS server data in <filename>/run/systemd/resolve/resolv.conf</filename>. Each structure in the + array consists of a numeric network interface index, an address family, and a byte array containing the + DNS server address (either 4 bytes in length for IPv4 or 16 bytes in lengths for IPv6). + <varname>DNSEx</varname> is similar, but additionally contains the IP port and server name (used for + Server Name Indication, SNI). Both arrays contain DNS servers configured system-wide, including those + possibly read from a foreign <filename>/etc/resolv.conf</filename> or the <varname>DNS=</varname> + setting in <filename>/etc/systemd/resolved.conf</filename>, as well as per-interface DNS server + information either retrieved from + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + or configured by external software via <function>SetLinkDNS()</function> or + <function>SetLinkDNSEx()</function> (see above). The network interface index will be 0 for the + system-wide configured services and non-zero for the per-link servers.</para> + + <para><varname>FallbackDNS</varname> and <varname>FallbackDNSEx</varname> contain arrays of all DNS + servers configured as fallback servers, if any, using the same format as <varname>DNS</varname> and + <varname>DNSEx</varname> described above. See the description of <varname>FallbackDNS=</varname> in + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + the description of when those servers are used.</para> + + <para><varname>CurrentDNSServer</varname> and <varname>CurrentDNSServerEx</varname> specify the server + that is currently used for query resolution, in the same format as a single entry in the + <varname>DNS</varname> and <varname>DNSEx</varname> arrays described above.</para> + + <para>Similarly, the <varname>Domains</varname> property contains an array of all search and routing + domains currently used by <filename>systemd-resolved</filename>. Each entry consists of a network + interface index (again, 0 encodes system-wide entries), the actual domain name, and whether the entry + is used only for routing (true) or for both routing and searching (false).</para> + + <para>The <varname>TransactionStatistics</varname> property contains information about the number of + transactions <filename>systemd-resolved</filename> has processed. It contains a pair of unsigned 64-bit counters, the first + containing the number of currently ongoing transactions, the second the number of total transactions + <filename>systemd-resolved</filename> is processing or has processed. The latter value may be reset using the + <function>ResetStatistics()</function> method described above. Note that the number of transactions does + not directly map to the number of issued resolver bus method calls. While simple look-ups usually require a + single transaction only, more complex look-ups might result in more, for example when CNAMEs or DNSSEC + are in use.</para> + + <para>The <varname>CacheStatistics</varname> property contains information about the executed cache + operations so far. It exposes three 64-bit counters: the first being the total number of current cache + entries (both positive and negative), the second the number of cache hits, and the third the number of + cache misses. The latter counters may be reset using <function>ResetStatistics()</function> (see + above).</para> + + <para>The <varname>DNSSEC</varname> property specifies current status of DNSSEC validation. It is one + of <literal>yes</literal> (validation is enforced), <literal>no</literal> (no validation is done), + <literal>allow-downgrade</literal> (validation is done if the current DNS server supports it). See the + description of <varname>DNSSEC=</varname> in + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>The <varname>DNSSECStatistics</varname> property contains information about the DNSSEC + validations executed so far. It contains four 64-bit counters: the number of secure, insecure, bogus, + and indeterminate DNSSEC validations so far. The counters are increased for each validated RRset, and + each non-existance proof. The secure counter is increased for each operation that successfully verified + a signed reply, the insecure counter is increased for each operation that successfully verified that an + unsigned reply is rightfully unsigned. The bogus counter is increased for each operation where the + validation did not check out and the data is likely to have been tempered with. Finally the + indeterminate counter is increased for each operation which did not complete because the necessary keys + could not be acquired or the cryptographic algorithms were unknown.</para> + + <para>The <varname>DNSSECSupported</varname> boolean property reports whether DNSSEC is enabled and + the selected DNS servers support it. It combines information about system-wide and per-link DNS + settings (see below), and only reports true if DNSSEC is enabled and supported on every interface for + which DNS is configured and for the system-wide settings if there are any. Note that <filename>systemd-resolved</filename> assumes + DNSSEC is supported by DNS servers until it verifies that this is not the case. Thus, the reported + value may initially be true, until the first transactions are executed.</para> + + <para>The <varname>DNSOverTLS</varname> boolean property reports whether DNS-over-TLS is enabled. + </para> + + <para>The <varname>ResolvConfMode</varname> property exposes how <filename>/etc/resolv.conf</filename> + is managed on the host. Currently, the values <literal>uplink</literal>, <literal>stub</literal>, + <literal>static</literal> (these three correspond to the three different files + <filename>systemd-resolved.service</filename> provides), <literal>foreign</literal> (the file is + managed by admin or another service, <filename>systemd-resolved.service</filename> just consumes it), + <literal>missing</literal> (<filename>/etc/resolv.conf</filename> is missing).</para> + + <para>The <varname>DNSStubListener</varname> property reports whether the stub listener on port 53 is + enabled. Possible values are <literal>yes</literal> (enabled), <literal>no</literal> (disabled), + <literal>udp</literal> (only the UDP listener is enabled), and <literal>tcp</literal> (only the TCP + listener is enabled).</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Link Object</title> + + <programlisting executable="systemd-resolved" node="/org/freedesktop/resolve1/link/_1" interface="org.freedesktop.resolve1.Link"> +node /org/freedesktop/resolve1/link/_1 { + interface org.freedesktop.resolve1.Link { + methods: + SetDNS(in a(iay) addresses); + SetDNSEx(in a(iayqs) addresses); + SetDomains(in a(sb) domains); + SetDefaultRoute(in b enable); + SetLLMNR(in s mode); + SetMulticastDNS(in s mode); + SetDNSOverTLS(in s mode); + SetDNSSEC(in s mode); + SetDNSSECNegativeTrustAnchors(in as names); + Revert(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ScopesMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iay) DNS = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayqs) DNSEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (iay) CurrentDNSServer = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (iayqs) CurrentDNSServerEx = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(sb) Domains = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b DefaultRoute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s LLMNR = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s MulticastDNS = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSOverTLS = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSSEC = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DNSSECNegativeTrustAnchors = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b DNSSECSupported = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--property DNSSECNegativeTrustAnchors is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Link"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Link"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDNS()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDNSEx()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDomains()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDefaultRoute()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLLMNR()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetMulticastDNS()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDNSOverTLS()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDNSSEC()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDNSSECNegativeTrustAnchors()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Revert()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ScopesMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServer"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServerEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Domains"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultRoute"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LLMNR"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MulticastDNS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSOverTLS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSEC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSECNegativeTrustAnchors"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DNSSECSupported"/> + + <!--End of Autogenerated section--> + + <para>For each Linux network interface a "Link" object is created which exposes per-link DNS + configuration and state. Use <function>GetLink()</function> on the Manager interface to retrieve the + object path for a link object given the network interface index (see above).</para> + + <refsect2> + <title>Methods</title> + + <para>The various methods exposed by the Link interface are equivalent to their similarly named + counterparts on the Manager interface. e.g. <function>SetDNS()</function> on the Link object maps to + <function>SetLinkDNS()</function> on the Manager object, the main difference being that the later + expects an interface index to be specified. Invoking the methods on the Manager interface has the + benefit of reducing roundtrips, as it is not necessary to first request the Link object path via + <function>GetLink()</function> before invoking the methods. The same relationship holds for + <function>SetDNSEx()</function>, <function>SetDomains()</function>, + <function>SetDefaultRoute()</function>, <function>SetLLMNR()</function>, + <function>SetMulticastDNS()</function>, <function>SetDNSOverTLS()</function>, + <function>SetDNSSEC()</function>, <function>SetDNSSECNegativeTrustAnchors()</function>, and + <function>Revert()</function>. For further details on these methods see the + <interfacename>Manager</interfacename> documentation above.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>ScopesMask</varname> defines which resolver scopes are currently active on this + interface. This 64-bit unsigned integer field is a bit mask consisting of a subset of the bits of the + flags parameter describe above. Specifically, it may have the DNS, LLMNR and MDNS bits (the latter in + IPv4 and IPv6 flavours) set. Each individual bit is set when the protocol applies to a specific + interface and is enabled for it. It is unset otherwise. Specifically, a multicast-capable interface in + the "UP" state with an IP address is suitable for LLMNR or MulticastDNS, and any interface that is UP and + has an IP address is suitable for DNS. Note the relationship of the bits exposed here with the LLMNR + and MulticastDNS properties also exposed on the Link interface. The latter expose what is *configured* + to be used on the interface, the former expose what is actually used on the interface, taking into + account the abilities of the interface.</para> + + <para><varname>DNSSECSupported</varname> exposes a boolean field that indicates whether DNSSEC is + currently configured and in use on the interface. Note that if DNSSEC is enabled on an interface, it is + assumed available until it is detected that the configured server does not actually support it. Thus, + this property may initially report that DNSSEC is supported on an interface.</para> + + <para><varname>DefaultRoute</varname> exposes a boolean field that indicates whether the interface will + be used as default route for name queries. See <function>SetLinkDefaultRoute()</function> above.</para> + + <para>The other properties reflect the state of the various configuration settings for the link which + may be set with the various methods calls such as <function>SetDNS()</function> or + <function>SetLLMNR()</function>.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Common Errors</title> + + <para>Many bus methods <filename>systemd-resolved</filename> exposes (in particular the resolver methods such + as <function>ResolveHostname()</function> on the <interfacename>Manager</interfacename> interface) may return + some of the following errors:</para> + + <variablelist> + <varlistentry><term><constant>org.freedesktop.resolve1.NoNameServers</constant></term> + <listitem><para>No suitable DNS servers were found to resolve a request.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.InvalidReply</constant></term> + <listitem><para>A response from the selected DNS server was not understood.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.NoSuchRR</constant></term> + <listitem><para>The requested name exists, but there is no resource record of the requested type for + it. (This is the DNS NODATA case).</para></listitem></varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.CNameLoop</constant></term> + <listitem><para>The look-up failed because a CNAME or DNAME loop was detected.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.Aborted</constant></term> + <listitem><para>The look-up was aborted because the selected protocol became unavailable while the + operation was ongoing.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.NoSuchService</constant></term> + <listitem><para>A service look-up was successful, but the SRV record reported that the service is not + available.</para></listitem></varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.DnssecFailed</constant></term> + <listitem><para>The acquired response did not pass DNSSEC validation.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.NoTrustAnchor</constant></term> + <listitem><para>No chain of trust could be established for the response to a configured DNSSEC trust + anchor.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.ResourceRecordTypeUnsupported</constant></term> + <listitem><para>The requested resource record type is not supported on the selected DNS servers. This + error is generated for example when an RRSIG record is requested from a DNS server that does not + support DNSSEC.</para></listitem> + + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.NoSuchLink</constant></term> + <listitem><para>No network interface with the specified network interface index exists. + </para></listitem></varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.LinkBusy</constant></term> + <listitem><para>The requested configuration change could not be made because + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + already took possession of the interface and supplied configuration data for it.</para></listitem> + </varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.NetworkDown</constant></term> + <listitem><para>The requested look-up failed because the system is currently not connected to any + suitable network.</para></listitem></varlistentry> + + <varlistentry><term><constant>org.freedesktop.resolve1.DnsError.NXDOMAIN</constant></term> + <term><constant>org.freedesktop.resolve1.DnsError.REFUSED</constant></term> + <term>...</term> + <listitem><para>The look-up failed with a DNS return code reporting a failure. The error names used as + suffixes here are defined in by IANA in + <ulink url="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6">DNS RCODEs</ulink>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.resolve1.Manager</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.resolve1 \ + --object-path /org/freedesktop/resolve1 + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.resolve1.Link</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.resolve1 \ + --object-path /org/freedesktop/resolve1/link/_11 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.systemd1.xml b/man/org.freedesktop.systemd1.xml new file mode 100644 index 0000000..78fd0b3 --- /dev/null +++ b/man/org.freedesktop.systemd1.xml @@ -0,0 +1,9875 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.systemd1" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.systemd1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.systemd1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.systemd1</refname> + <refpurpose>The D-Bus interface of systemd</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> and its + auxiliary daemons expose a number of APIs over D-Bus. This page only describes the various APIs exposed by the + system and service manager itself. It does not cover the auxiliary daemons. + </para> + + <para>The service manager exposes a number of objects on the bus: one + <interfacename>Manager</interfacename> object as a central entry point for clients along with individual objects + for each unit and for each queued job. The unit objects each implement a generic + <interfacename>Unit</interfacename> interface as well as a type-specific interface. For example, service units + implement both <interfacename>org.freedesktop.systemd1.Unit</interfacename> and + <interfacename>org.freedesktop.system1.Service</interfacename>. The manager object can list + unit and job objects or directly convert a unit name or job id into a bus path of the corresponding + D-Bus object.</para> + + <para>Properties exposing time values are usually encoded in microseconds (usec) on the bus, even if + their corresponding settings in the unit files are in seconds.</para> + + <para>In contrast to most of the other services of the systemd suite, PID 1 does not use + <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink> + for controlling access to privileged operations, but relies exclusively on the low-level D-Bus policy + language. (This is done in order to avoid a cyclic dependency between polkit and systemd/PID 1.) This + means that sensitive operations exposed by PID 1 on the bus are generally not available to unprivileged + processes directly. However, some operations (such as shutdown/reboot/suspend) are made available through the D-Bus + API of logind, see + <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>The Manager Object</title> + + <para>The main entry point object is available on the fixed + <constant>/org/freedesktop/systemd1</constant> object path:</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager"> +node /org/freedesktop/systemd1 { + interface org.freedesktop.systemd1.Manager { + methods: + GetUnit(in s name, + out o unit); + GetUnitByPID(in u pid, + out o unit); + GetUnitByInvocationID(in ay invocation_id, + out o unit); + GetUnitByControlGroup(in s cgroup, + out o unit); + LoadUnit(in s name, + out o unit); + StartUnit(in s name, + in s mode, + out o job); + StartUnitReplace(in s old_unit, + in s new_unit, + in s mode, + out o job); + StopUnit(in s name, + in s mode, + out o job); + ReloadUnit(in s name, + in s mode, + out o job); + RestartUnit(in s name, + in s mode, + out o job); + TryRestartUnit(in s name, + in s mode, + out o job); + ReloadOrRestartUnit(in s name, + in s mode, + out o job); + ReloadOrTryRestartUnit(in s name, + in s mode, + out o job); + EnqueueUnitJob(in s name, + in s job_type, + in s job_mode, + out u job_id, + out o job_path, + out s unit_id, + out o unit_path, + out s job_type, + out a(uosos) affected_jobs); + KillUnit(in s name, + in s whom, + in i signal); + CleanUnit(in s name, + in as mask); + FreezeUnit(in s name); + ThawUnit(in s name); + ResetFailedUnit(in s name); + SetUnitProperties(in s name, + in b runtime, + in a(sv) properties); + RefUnit(in s name); + UnrefUnit(in s name); + StartTransientUnit(in s name, + in s mode, + in a(sv) properties, + in a(sa(sv)) aux, + out o job); + GetUnitProcesses(in s name, + out a(sus) processes); + AttachProcessesToUnit(in s unit_name, + in s subcgroup, + in au pids); + AbandonScope(in s name); + GetJob(in u id, + out o job); + GetJobAfter(in u id, + out a(usssoo) jobs); + GetJobBefore(in u id, + out a(usssoo) jobs); + CancelJob(in u id); + ClearJobs(); + ResetFailed(); + SetShowStatus(in s mode); + ListUnits(out a(ssssssouso) units); + ListUnitsFiltered(in as states, + out a(ssssssouso) units); + ListUnitsByPatterns(in as states, + in as patterns, + out a(ssssssouso) units); + ListUnitsByNames(in as names, + out a(ssssssouso) units); + ListJobs(out a(usssoo) jobs); + Subscribe(); + Unsubscribe(); + Dump(out s output); + DumpByFileDescriptor(out h fd); + Reload(); + Reexecute(); + Exit(); + Reboot(); + PowerOff(); + Halt(); + KExec(); + SwitchRoot(in s new_root, + in s init); + SetEnvironment(in as assignments); + UnsetEnvironment(in as names); + UnsetAndSetEnvironment(in as names, + in as assignments); + ListUnitFiles(out a(ss) unit_files); + ListUnitFilesByPatterns(in as states, + in as patterns, + out a(ss) unit_files); + GetUnitFileState(in s file, + out s state); + EnableUnitFiles(in as files, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + DisableUnitFiles(in as files, + in b runtime, + out a(sss) changes); + EnableUnitFilesWithFlags(in as files, + in t flags, + out b carries_install_info, + out a(sss) changes); + DisableUnitFilesWithFlags(in as files, + in t flags, + out a(sss) changes); + ReenableUnitFiles(in as files, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + LinkUnitFiles(in as files, + in b runtime, + in b force, + out a(sss) changes); + PresetUnitFiles(in as files, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + PresetUnitFilesWithMode(in as files, + in s mode, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + MaskUnitFiles(in as files, + in b runtime, + in b force, + out a(sss) changes); + UnmaskUnitFiles(in as files, + in b runtime, + out a(sss) changes); + RevertUnitFiles(in as files, + out a(sss) changes); + SetDefaultTarget(in s name, + in b force, + out a(sss) changes); + GetDefaultTarget(out s name); + PresetAllUnitFiles(in s mode, + in b runtime, + in b force, + out a(sss) changes); + AddDependencyUnitFiles(in as files, + in s target, + in s type, + in b runtime, + in b force, + out a(sss) changes); + GetUnitFileLinks(in s name, + in b runtime, + out as links); + SetExitCode(in y number); + LookupDynamicUserByName(in s name, + out u uid); + LookupDynamicUserByUID(in u uid, + out s name); + GetDynamicUsers(out a(us) users); + signals: + UnitNew(s id, + o unit); + UnitRemoved(s id, + o unit); + JobNew(u id, + o job, + s unit); + JobRemoved(u id, + o job, + s unit, + s result); + StartupFinished(t firmware, + t loader, + t kernel, + t initrd, + t userspace, + t total); + UnitFilesChanged(); + Reloading(b active); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Version = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Features = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Virtualization = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Architecture = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Tainted = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FirmwareTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FirmwareTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LoaderTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LoaderTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KernelTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KernelTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UserspaceTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UserspaceTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogLevel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogTarget = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NNames = ...; + readonly u NFailedUnits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NJobs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NInstalledJobs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NFailedJobs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly d Progress = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ConfirmSpawn = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b ShowStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnitPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultStandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultStandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t RuntimeWatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t RebootWatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t KExecWatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite b ServiceWatchdogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s SystemState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly y ExitCode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultTimerAccuracyUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultTimeoutStartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultTimeoutStopUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultTimeoutAbortUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultRestartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultStartLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DefaultStartLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultCPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultBlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultMemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultTasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultTasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultOOMPolicy = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method GetUnitByInvocationID is not documented!--> + + <!--method GetUnitByControlGroup is not documented!--> + + <!--method EnqueueUnitJob is not documented!--> + + <!--method CleanUnit is not documented!--> + + <!--method FreezeUnit is not documented!--> + + <!--method ThawUnit is not documented!--> + + <!--method RefUnit is not documented!--> + + <!--method UnrefUnit is not documented!--> + + <!--method GetUnitProcesses is not documented!--> + + <!--method AttachProcessesToUnit is not documented!--> + + <!--method AbandonScope is not documented!--> + + <!--method GetJobAfter is not documented!--> + + <!--method GetJobBefore is not documented!--> + + <!--method SetShowStatus is not documented!--> + + <!--method ListUnitsFiltered is not documented!--> + + <!--method ListUnitsByPatterns is not documented!--> + + <!--method ListUnitsByNames is not documented!--> + + <!--method Dump is not documented!--> + + <!--method DumpByFileDescriptor is not documented!--> + + <!--method ListUnitFilesByPatterns is not documented!--> + + <!--method PresetUnitFilesWithMode is not documented!--> + + <!--method RevertUnitFiles is not documented!--> + + <!--method PresetAllUnitFiles is not documented!--> + + <!--method AddDependencyUnitFiles is not documented!--> + + <!--method GetUnitFileLinks is not documented!--> + + <!--method SetExitCode is not documented!--> + + <!--method LookupDynamicUserByName is not documented!--> + + <!--method LookupDynamicUserByUID is not documented!--> + + <!--method GetDynamicUsers is not documented!--> + + <!--signal UnitNew is not documented!--> + + <!--signal UnitRemoved is not documented!--> + + <!--signal JobNew is not documented!--> + + <!--signal JobRemoved is not documented!--> + + <!--signal StartupFinished is not documented!--> + + <!--signal UnitFilesChanged is not documented!--> + + <!--signal Reloading is not documented!--> + + <!--property SecurityStartTimestampMonotonic is not documented!--> + + <!--property SecurityFinishTimestamp is not documented!--> + + <!--property SecurityFinishTimestampMonotonic is not documented!--> + + <!--property GeneratorsStartTimestampMonotonic is not documented!--> + + <!--property GeneratorsFinishTimestamp is not documented!--> + + <!--property GeneratorsFinishTimestampMonotonic is not documented!--> + + <!--property UnitsLoadStartTimestamp is not documented!--> + + <!--property UnitsLoadStartTimestampMonotonic is not documented!--> + + <!--property UnitsLoadFinishTimestamp is not documented!--> + + <!--property UnitsLoadFinishTimestampMonotonic is not documented!--> + + <!--property InitRDSecurityStartTimestamp is not documented!--> + + <!--property InitRDSecurityStartTimestampMonotonic is not documented!--> + + <!--property InitRDSecurityFinishTimestamp is not documented!--> + + <!--property InitRDSecurityFinishTimestampMonotonic is not documented!--> + + <!--property InitRDGeneratorsStartTimestamp is not documented!--> + + <!--property InitRDGeneratorsStartTimestampMonotonic is not documented!--> + + <!--property InitRDGeneratorsFinishTimestamp is not documented!--> + + <!--property InitRDGeneratorsFinishTimestampMonotonic is not documented!--> + + <!--property InitRDUnitsLoadStartTimestamp is not documented!--> + + <!--property InitRDUnitsLoadStartTimestampMonotonic is not documented!--> + + <!--property InitRDUnitsLoadFinishTimestamp is not documented!--> + + <!--property InitRDUnitsLoadFinishTimestampMonotonic is not documented!--> + + <!--property LogLevel is not documented!--> + + <!--property LogTarget is not documented!--> + + <!--property NFailedUnits is not documented!--> + + <!--property ConfirmSpawn is not documented!--> + + <!--property ShowStatus is not documented!--> + + <!--property DefaultStandardOutput is not documented!--> + + <!--property DefaultStandardError is not documented!--> + + <!--property RuntimeWatchdogUSec is not documented!--> + + <!--property RebootWatchdogUSec is not documented!--> + + <!--property KExecWatchdogUSec is not documented!--> + + <!--property ServiceWatchdogs is not documented!--> + + <!--property SystemState is not documented!--> + + <!--property ExitCode is not documented!--> + + <!--property DefaultTimerAccuracyUSec is not documented!--> + + <!--property DefaultTimeoutStartUSec is not documented!--> + + <!--property DefaultTimeoutStopUSec is not documented!--> + + <!--property DefaultTimeoutAbortUSec is not documented!--> + + <!--property DefaultRestartUSec is not documented!--> + + <!--property DefaultStartLimitIntervalUSec is not documented!--> + + <!--property DefaultStartLimitBurst is not documented!--> + + <!--property DefaultCPUAccounting is not documented!--> + + <!--property DefaultBlockIOAccounting is not documented!--> + + <!--property DefaultMemoryAccounting is not documented!--> + + <!--property DefaultTasksAccounting is not documented!--> + + <!--property DefaultLimitCPU is not documented!--> + + <!--property DefaultLimitCPUSoft is not documented!--> + + <!--property DefaultLimitFSIZE is not documented!--> + + <!--property DefaultLimitFSIZESoft is not documented!--> + + <!--property DefaultLimitDATA is not documented!--> + + <!--property DefaultLimitDATASoft is not documented!--> + + <!--property DefaultLimitSTACK is not documented!--> + + <!--property DefaultLimitSTACKSoft is not documented!--> + + <!--property DefaultLimitCORE is not documented!--> + + <!--property DefaultLimitCORESoft is not documented!--> + + <!--property DefaultLimitRSS is not documented!--> + + <!--property DefaultLimitRSSSoft is not documented!--> + + <!--property DefaultLimitNOFILE is not documented!--> + + <!--property DefaultLimitNOFILESoft is not documented!--> + + <!--property DefaultLimitAS is not documented!--> + + <!--property DefaultLimitASSoft is not documented!--> + + <!--property DefaultLimitNPROC is not documented!--> + + <!--property DefaultLimitNPROCSoft is not documented!--> + + <!--property DefaultLimitMEMLOCK is not documented!--> + + <!--property DefaultLimitMEMLOCKSoft is not documented!--> + + <!--property DefaultLimitLOCKS is not documented!--> + + <!--property DefaultLimitLOCKSSoft is not documented!--> + + <!--property DefaultLimitSIGPENDING is not documented!--> + + <!--property DefaultLimitSIGPENDINGSoft is not documented!--> + + <!--property DefaultLimitMSGQUEUE is not documented!--> + + <!--property DefaultLimitMSGQUEUESoft is not documented!--> + + <!--property DefaultLimitNICE is not documented!--> + + <!--property DefaultLimitNICESoft is not documented!--> + + <!--property DefaultLimitRTPRIO is not documented!--> + + <!--property DefaultLimitRTPRIOSoft is not documented!--> + + <!--property DefaultLimitRTTIME is not documented!--> + + <!--property DefaultLimitRTTIMESoft is not documented!--> + + <!--property DefaultTasksMax is not documented!--> + + <!--property TimerSlackNSec is not documented!--> + + <!--property DefaultOOMPolicy is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Manager"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Manager"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByPID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByInvocationID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByControlGroup()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LoadUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="StartUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="StartUnitReplace()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="StopUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReloadUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RestartUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TryRestartUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrRestartUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrTryRestartUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="EnqueueUnitJob()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="KillUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CleanUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="FreezeUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ThawUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResetFailedUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetUnitProperties()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RefUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnrefUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="StartTransientUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnitProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcessesToUnit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AbandonScope()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetJob()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetJobAfter()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetJobBefore()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="CancelJob()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ClearJobs()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResetFailed()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetShowStatus()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUnits()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUnitsFiltered()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUnitsByPatterns()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUnitsByNames()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListJobs()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Subscribe()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Unsubscribe()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Dump()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="DumpByFileDescriptor()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Reload()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Reexecute()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Exit()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Reboot()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PowerOff()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Halt()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="KExec()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SwitchRoot()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetEnvironment()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnsetEnvironment()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnsetAndSetEnvironment()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListUnitFilesByPatterns()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnitFileState()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="EnableUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="DisableUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="EnableUnitFilesWithFlags()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="DisableUnitFilesWithFlags()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReenableUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LinkUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PresetUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PresetUnitFilesWithMode()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="MaskUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="UnmaskUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="RevertUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetDefaultTarget()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetDefaultTarget()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="PresetAllUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AddDependencyUnitFiles()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetUnitFileLinks()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetExitCode()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LookupDynamicUserByName()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="LookupDynamicUserByUID()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetDynamicUsers()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="UnitNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="UnitRemoved"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="JobNew"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="JobRemoved"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="StartupFinished"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="UnitFilesChanged"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="Reloading"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Version"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Features"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Virtualization"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Architecture"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Tainted"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FirmwareTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FirmwareTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoaderTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoaderTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KernelTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KernelTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UserspaceTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UserspaceTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecurityStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecurityStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecurityFinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecurityFinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsFinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsFinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadFinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadFinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityFinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityFinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsFinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsFinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadFinishTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadFinishTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogLevel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogTarget"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NNames"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NFailedUnits"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NJobs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NInstalledJobs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NFailedJobs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Progress"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Environment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfirmSpawn"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ShowStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultStandardOutput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultStandardError"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeWatchdogUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RebootWatchdogUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KExecWatchdogUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ServiceWatchdogs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemState"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExitCode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimerAccuracyUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimeoutStartUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimeoutStopUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimeoutAbortUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultRestartUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultCPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultBlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultTasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCPU"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCPUSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitFSIZE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitFSIZESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitDATA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitDATASoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSTACK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSTACKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCORE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCORESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRSS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRSSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNOFILE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNOFILESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitAS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitASSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNPROC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNPROCSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMEMLOCK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMEMLOCKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitLOCKS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitLOCKSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSIGPENDING"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSIGPENDINGSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMSGQUEUE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMSGQUEUESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNICE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNICESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTPRIO"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTPRIOSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTTIME"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTTIMESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultTasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultOOMPolicy"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para>Note that many of the methods exist twice: once on the <interfacename>Manager</interfacename> + object and once on the respective unit objects. This is to optimize access times so that methods that + belong to unit objects do not have to be called with a resolved unit path, but can be called with only + the unit id, too.</para> + + <para><function>GetUnit()</function> may be used to get the unit object path for a unit name. It takes + the unit name and returns the object path. If a unit has not been loaded yet by this name this method + will fail.</para> + + <para><function>GetUnitByPID()</function> may be used to get the unit object path of the unit a process + ID belongs to. It takes a UNIX PID and returns the object path. The PID must refer to an existing system process.</para> + + <para><function>LoadUnit()</function> is similar to <function>GetUnit()</function> but will load the + unit from disk if possible.</para> + + <para><function>StartUnit()</function> enqueues a start job and possibly depending jobs. It takes the unit + to activate and a mode string as arguments. The mode needs to be one of <literal>replace</literal>, + <literal>fail</literal>, <literal>isolate</literal>, <literal>ignore-dependencies</literal>, or + <literal>ignore-requirements</literal>. If <literal>replace</literal>, the method will start the unit and + its dependencies, possibly replacing already queued jobs that conflict with it. If + <literal>fail</literal>, the method will start the unit and its dependencies, but will fail if this would + change an already queued job. If <literal>isolate</literal>, the method will start the unit in question + and terminate all units that aren't dependencies of it. If <literal>ignore-dependencies</literal>, it + will start a unit but ignore all its dependencies. If <literal>ignore-requirements</literal>, it will + start a unit but only ignore the requirement dependencies. It is not recommended to make use of the + latter two options. On completion, this method returns the newly created job object.</para> + + <para><function>StartUnitReplace()</function> is similar to <function>StartUnit()</function> but + replaces a job that is queued for one unit by a job for another unit.</para> + + <para><function>StopUnit()</function> is similar to <function>StartUnit()</function> but stops the + specified unit rather than starting it. Note that the <literal>isolate</literal> mode is invalid for this + method.</para> + + <para><function>ReloadUnit()</function>, <function>RestartUnit()</function>, + <function>TryRestartUnit()</function>, <function>ReloadOrRestartUnit()</function>, or + <function>ReloadOrTryRestartUnit()</function> may be used to restart and/or reload a unit. These methods take + similar arguments as <function>StartUnit()</function>. Reloading is done only if the unit is already + running and fails otherwise. If a service is restarted that isn't running, it will be started unless + the "Try" flavor is used in which case a service that isn't running is not affected by the restart. The + "ReloadOrRestart" flavors attempt a reload if the unit supports it and use a restart otherwise.</para> + + <para><function>KillUnit()</function> may be used to kill (i.e. send a signal to) all processes of a + unit. It takes the unit <varname>name</varname>, an enum <varname>who</varname> and a UNIX + <varname>signal</varname> number to send. The <varname>who</varname> enum is one of + <literal>main</literal>, <literal>control</literal> or <literal>all</literal>. If + <literal>main</literal>, only the main process of the unit is killed. If <literal>control</literal>, only + the control process of the unit is killed. If <literal>all</literal>, all processes are killed. A + <literal>control</literal> process is for example a process that is configured via + <varname>ExecStop=</varname> and is spawned in parallel to the main daemon process in order to shut it + down.</para> + + <para><function>GetJob()</function> returns the job object path for a specific job, identified by its + id.</para> + + <para><function>CancelJob()</function> cancels a specific job identified by its numeric ID. This + operation is also available in the <function>Cancel()</function> method of Job objects (see below) and + exists primarily to reduce the necessary round trips to execute this operation. Note that this will not + have any effect on jobs whose execution has already begun.</para> + + <para><function>ClearJobs()</function> flushes the job queue, removing all jobs that are still + queued. Note that this does not have any effect on jobs whose execution has already begun. It only + flushes jobs that are queued and have not yet begun execution.</para> + + <para><function>ResetFailedUnit()</function> resets the "failed" state of a specific unit.</para> + + <para><function>ResetFailed()</function> resets the "failed" state of all units.</para> + + <para><function>ListUnits()</function> returns an array of all currently loaded units. Note that + units may be known by multiple names at the same name, and hence there might be more unit names loaded + than actual units behind them. The array consists of structures with the following elements: + <itemizedlist> + <listitem><para>The primary unit name as string</para></listitem> + + <listitem><para>The human readable description string</para></listitem> + + <listitem><para>The load state (i.e. whether the unit file has been loaded + successfully)</para></listitem> + + <listitem><para>The active state (i.e. whether the unit is currently started or + not)</para></listitem> + + <listitem><para>The sub state (a more fine-grained version of the active state that is specific to + the unit type, which the active state is not)</para></listitem> + + <listitem><para>A unit that is being followed in its state by this unit, if there is any, otherwise + the empty string.</para></listitem> + + <listitem><para>The unit object path</para></listitem> + + <listitem><para>If there is a job queued for the job unit, the numeric job id, 0 + otherwise</para></listitem> + + <listitem><para>The job type as string</para></listitem> + + <listitem><para>The job object path</para></listitem> + </itemizedlist></para> + + <para><function>ListJobs()</function> returns an array with all currently queued jobs. Returns an array + consisting of structures with the following elements: + <itemizedlist> + <listitem><para>The numeric job id</para></listitem> + + <listitem><para>The primary unit name for this job</para></listitem> + + <listitem><para>The job type as string</para></listitem> + + <listitem><para>The job state as string</para></listitem> + + <listitem><para>The job object path</para></listitem> + + <listitem><para>The unit object path</para></listitem> + </itemizedlist></para> + + <para><function>Subscribe()</function> enables most bus signals to be sent out. Clients which are + interested in signals need to call this method. Signals are only sent out if at least one client + invoked this method. <function>Unsubscribe()</function> reverts the signal subscription that + <function>Subscribe()</function> implements. It is not necessary to invoke + <function>Unsubscribe()</function> as clients are tracked. Signals are no longer sent out as soon as + all clients which previously asked for <function>Subscribe()</function> either closed their connection + to the bus or invoked <function>Unsubscribe()</function>.</para> + + <para><function>Reload()</function> may be invoked to reload all unit files.</para> + + <para><function>Reexecute()</function> may be invoked to reexecute the main manager process. It will + serialize its state, reexecute, and deserizalize the state again. This is useful for upgrades and is a + more comprehensive version of <function>Reload()</function>.</para> + + <para><function>Exit()</function> may be invoked to ask the manager to exit. This is not available for + the system manager and is useful only for user session managers.</para> + + <para><function>Reboot()</function>, <function>PowerOff()</function>, <function>Halt()</function>, or + <function>KExec()</function> may be used to ask for immediate reboot, powering down, halt or kexec + based reboot of the system. Note that this does not shut down any services and immediately transitions + into the reboot process. These functions are normally only called as the last step of shutdown and should + not be called directly. To shut down the machine, it is generally a better idea to invoke + <function>Reboot()</function> or <function>PowerOff()</function> on the + <filename>systemd-logind</filename> manager object; see + <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information.</para> + + <para><function>SwitchRoot()</function> may be used to transition to a new root directory. This is + intended to be used by initial RAM disks. The method takes two arguments: the new root directory (which + needs to be specified) and an init binary path (which may be left empty, in which case it is + automatically searched for). The state of the system manager will be serialized before the + transition. After the transition, the manager binary on the main system is invoked and replaces the old + PID 1. All state will then be deserialized.</para> + + <para><function>SetEnvironment()</function> may be used to alter the environment block that is passed + to all spawned processes. It takes a string array of environment variable assignments. Any previously set + environment variables will be overridden.</para> + + <para><function>UnsetEnvironment()</function> may be used to unset environment variables. It takes a + string array of environment variable names. All variables specified will be unset (if they have been + set previously) and no longer be passed to all spawned processes. This method has no effect for variables + that were previously not set, but will not fail in that case.</para> + + <para><function>UnsetAndSetEnvironment()</function> is a combination of + <function>UnsetEnvironment()</function> and <function>SetEnvironment()</function>. It takes two + lists. The first list contains variables to unset, the second one contains assignments to set. If a + variable is listed in both, the variable is set after this method returns, i.e. the set list overrides the + unset list.</para> + + <para><function>ListUnitFiles()</function> returns an array of unit names and their enablement + status. Note that <function>ListUnit()</function> returns a list of units currently loaded into memory, + while <function>ListUnitFiles()</function> returns a list of unit <emphasis>files</emphasis> that were + found on disk. Note that while most units are read directly from a unit file with the same name, some + units are not backed by files and some files (templates) cannot directly be loaded as units but need + to be instantiated instead.</para> + + <para><function>GetUnitFileState()</function> returns the current enablement status of a specific unit + file.</para> + + <para><function>EnableUnitFiles()</function> may be used to enable one or more units in the system (by + creating symlinks to them in <filename>/etc/</filename> or <filename>/run/</filename>). It takes a list + of unit files to enable (either just file names or full absolute paths if the unit files are residing + outside the usual unit search paths) and two booleans: the first controls whether the unit shall be + enabled for runtime only (true, <filename>/run/</filename>), or persistently (false, + <filename>/etc/</filename>). The second one controls whether symlinks pointing to other units shall be + replaced if necessary. This method returns one boolean and an array of the changes made. The boolean + signals whether the unit files contained any enablement information (i.e. an [Install]) section. The + changes array consists of structures with three strings: the type of the change (one of + <literal>symlink</literal> or <literal>unlink</literal>), the file name of the symlink and the + destination of the symlink. Note that most of the following calls return a changes list in the same + format.</para> + + <para>Similarly, <function>DisableUnitFiles()</function> disables one or more units in the system, + i.e. removes all symlinks to them in <filename>/etc/</filename> and <filename>/run/</filename>.</para> + + <para>The <function>EnableUnitFilesWithFlags()</function> and <function>DisableUnitFilesWithFlags()</function> + take in options as flags instead of booleans to allow for extendability, defined as follows:</para> + + <programlisting> +#define SD_SYSTEMD_UNIT_RUNTIME (UINT64_C(1) << 0) +#define SD_SYSTEMD_UNIT_FORCE (UINT64_C(1) << 1) +#define SD_SYSTEMD_UNIT_PORTABLE (UINT64_C(1) << 2) + </programlisting> + + <para><varname>SD_SYSTEMD_UNIT_RUNTIME</varname> will enable or disable the unit for runtime only, + <varname>SD_SYSTEMD_UNIT_FORCE</varname> controls whether symlinks pointing to other units shall be + replaced if necessary. <varname>SD_SYSTEMD_UNIT_PORTABLE</varname> will add or remove the symlinks in + <filename>/etc/systemd/system.attached</filename> and <filename>/run/systemd/system.attached</filename>.</para> + + <para>Similarly, <function>ReenableUnitFiles()</function> applies the changes to one or more units that + would result from disabling and enabling the unit quickly one after the other in an atomic + fashion. This is useful to apply updated [Install] information contained in unit files.</para> + + <para>Similarly, <function>LinkUnitFiles()</function> links unit files (that are located outside of the + usual unit search paths) into the unit search path.</para> + + <para>Similarly, <function>PresetUnitFiles()</function> enables/disables one or more unit files + according to the preset policy. See + <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>7</manvolnum></citerefentry> for more + information.</para> + + <para>Similarly, <function>MaskUnitFiles()</function> masks unit files and + <function>UnmaskUnitFiles()</function> unmasks them again.</para> + + <para><function>SetDefaultTarget()</function> changes the <filename>default.target</filename> link. See + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for more + information.</para> + + <para><function>GetDefaultTarget()</function> retrieves the name of the unit to which + <filename>default.target</filename> is aliased.</para> + + <para><function>SetUnitProperties()</function> may be used to modify certain unit properties at + runtime. Not all properties may be changed at runtime, but many resource management settings (primarily + those listed in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>) + may. The changes are applied instantly and stored on disk for future boots, unless + <varname>runtime</varname> is true, in which case the settings only apply until the next + reboot. <varname>name</varname> is the name of the unit to modify. <varname>properties</varname> are + the settings to set, encoded as an array of property name and value pairs. Note that this is not a + dictionary! Also note that when setting array properties with this method usually results in appending to + the pre-configured array. To reset the configured arrays, set the property to an empty array first and + then append to it.</para> + + <para><function>StartTransientUnit()</function> may be used to create and start a transient unit which + will be released as soon as it is not running or referenced anymore or the system is + rebooted. <varname>name</varname> is the unit name including its suffix and must be + unique. <varname>mode</varname> is the same as in <function>StartUnit()</function>, + <varname>properties</varname> contains properties of the unit, specified like in + <function>SetUnitProperties()</function>. <varname>aux</varname> is currently unused and should be + passed as an empty array. See the + <ulink url="http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New Control Group + Interface</ulink> for more information how to make use of this functionality for resource control + purposes.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para>Note that most signals are sent out only after <function>Subscribe()</function> has been invoked + by at least one client. Make sure to invoke this method when subscribing to these signals!</para> + + <para><function>UnitNew()</function> and <function>UnitRemoved()</function> are sent out each time a + new unit is loaded or unloaded. Note that this has little to do with whether a unit is available on + disk or not, and simply reflects the units that are currently loaded into memory. The signals take two + parameters: the primary unit name and the object path.</para> + + <para><function>JobNew()</function> and <function>JobRemoved()</function> are sent out each time a new + job is queued or dequeued. Both signals take the numeric job ID, the bus path and the primary unit name + for this job as arguments. <function>JobRemoved()</function> also includes a result string which is one + of <literal>done</literal>, <literal>canceled</literal>, <literal>timeout</literal>, + <literal>failed</literal>, <literal>dependency</literal>, or + <literal>skipped</literal>. <literal>done</literal> indicates successful execution of a + job. <literal>canceled</literal> indicates that a job has been canceled (via + <function>CancelJob()</function> above) before it finished execution (this doesn't necessarily mean + though that the job operation is actually cancelled too, see above). <literal>timeout</literal> + indicates that the job timeout was reached. <literal>failed</literal> indicates that the job + failed. <literal>dependency</literal> indicates that a job this job depended on failed and the job hence + was removed as well. <literal>skipped</literal> indicates that a job was skipped because + it didn't apply to the unit's current state.</para> + + <para><function>StartupFinished()</function> is sent out when startup finishes. It carries six + microsecond timespan values, each indicating how much boot time has been spent in the firmware (if + known), in the boot loader (if known), in the kernel initialization phase, in the initrd (if known), in + userspace and in total. These values may also be calculated from the + <varname>FirmwareTimestampMonotonic</varname>, <varname>LoaderTimestampMonotonic</varname>, + <varname>InitRDTimestampMonotonic</varname>, <varname>UserspaceTimestampMonotonic</varname>, and + <varname>FinishTimestampMonotonic</varname> properties (see below).</para> + + <para><function>UnitFilesChanged()</function> is sent out each time the list of enabled or masked unit + files on disk have changed.</para> + + <para><function>Reloading()</function> is sent out immediately before a daemon reload is done (with the + boolean parameter set to True) and after a daemon reload is completed (with the boolean parameter set + to False). This may be used by UIs to optimize UI updates.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>Most properties simply reflect the respective options in + <filename>/etc/systemd/system.conf</filename> and the kernel command line.</para> + + <para>The others:</para> + + <para><varname>Version</varname> encodes the version string of the running systemd instance. Note that + the version string is purely informational. It should not be parsed and one may not assume the version to + be formatted in any particular way. We take the liberty to change the versioning scheme at any time and + it is not part of the public API.</para> + + <para><varname>Features</varname> encodes the features that have been enabled and disabled for this + build. Enabled options are prefixed with +, disabled options with -.</para> + + <para><varname>Tainted</varname> encodes a couple of taint flags as a colon-separated list. When + systemd detects it is running on a system with certain problems, it will set an appropriate taint + flag. Taints may be used to lower the chance of bogus bug reports. The following taints are currently + known: <literal>split-usr</literal>, <literal>mtab-not-symlink</literal>, + <literal>cgroups-missing</literal>, <literal>local-hwclock</literal>. <literal>split-usr</literal> is + set if <filename>/usr/</filename> is not pre-mounted when systemd is first invoked. See + <ulink url="http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken"> + Booting Without /usr is Broken</ulink> + for details why this is bad. <literal>mtab-not-symlink</literal> indicates that + <filename>/etc/mtab</filename> is not a symlink to <filename>/proc/self/mounts</filename> as + required. <literal>cgroups-missing</literal> indicates that control groups have not been enabled in the + kernel. <literal>local-hwclock</literal> indicates that the local RTC is configured to be in local time + rather than UTC.</para> + + <para><varname>FirmwareTimestamp</varname>, <varname>FirmwareTimestampMonotonic</varname>, + <varname>LoaderTimestamp</varname>, <varname>LoaderTimestampMonotonic</varname>, + <varname>KernelTimestamp</varname>, <varname>KernelTimestampMonotonic</varname>, + <varname>InitRDTimestamp</varname>, <varname>InitRDTimestampMonotonic</varname>, + <varname>UserspaceTimestamp</varname>, <varname>UserspaceTimestampMonotonic</varname>, + <varname>FinishTimestamp</varname>, and <varname>FinishTimestampMonotonic</varname> encode + <constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> microsecond timestamps + taken when the firmware first began execution, when the boot loader first began execution, when the + kernel first began execution, when the initrd first began execution, when the main systemd instance + began execution and finally, when all queued startup jobs finished execution. These values are useful + for determining boot-time performance. Note that as monotonic time begins with the kernel startup, the + <varname>KernelTimestampMonotonic</varname> timestamp will always be 0 and + <varname>FirmwareTimestampMonotonic</varname> and <varname>LoaderTimestampMonotonic</varname> are to + be read as negative values. Also, not all fields are always available, depending on the used firmware, + boot loader or initrd implementation. In these cases the respective pairs of timestamps are both 0, + indicating that no data is available.</para> + + <para>Similarly, the <varname>SecurityStartTimestamp</varname>, + <varname>GeneratorsStartTimestamp</varname> and <varname>LoadUnitTimestamp</varname> (as well as their + monotonic and stop counterparts) expose performance data for uploading the security policies to the + kernel (such as the SELinux, IMA, or SMACK policies), for running the generator tools and for loading + the unit files.</para> + + <para><varname>NNames</varname> encodes how many unit names are currently known. This only includes + names of units that are currently loaded and can be more than the amount of actually loaded units since + units may have more than one name.</para> + + <para><varname>NJobs</varname> encodes how many jobs are currently queued.</para> + + <para><varname>NInstalledJobs</varname> encodes how many jobs have ever been queued in total.</para> + + <para><varname>NFailedJobs</varname> encodes how many jobs have ever failed in total.</para> + + <para><varname>Progress</varname> encodes boot progress as a floating point value between 0.0 and + 1.0. This value begins at 0.0 at early-boot and ends at 1.0 when boot is finished and is based on the + number of executed and queued jobs. After startup, this field is always 1.0 indicating a finished + boot.</para> + + <para><varname>Environment</varname> encodes the environment block passed to all executed services. It + may be altered with bus calls such as <function>SetEnvironment()</function> (see above).</para> + + <para><varname>UnitPath</varname> encodes the currently active unit file search path. It is an array of + file system paths encoded as strings.</para> + + <para><varname>Virtualization</varname> contains a short ID string describing the virtualization + technology the system runs in. On bare-metal hardware this is the empty string. Otherwise, it contains + an identifier such as <literal>kvm</literal>, <literal>vmware</literal> and so on. For a full list of + IDs see + <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + Note that only the "innermost" virtualization technology is exported here. This detects both + full-machine virtualizations (VMs) and shared-kernel virtualization (containers).</para> + + <para><varname>Architecture</varname> contains a short ID string describing the architecture the + systemd instance is running on. This follows the same vocabulary as + <varname>ConditionArchitectures=</varname>.</para> + + <para><varname>ControlGroup</varname> contains the root control group path of this system manager. Note + that the root path is encoded as the empty string here (not as <literal>/</literal>!), so that it can be + appended to <filename>/sys/fs/cgroup/systemd</filename> easily. This value will be set to the empty + string for the host instance and some other string for container instances.</para> + </refsect2> + + <refsect2> + <title>Security</title> + + <para>Read access is generally granted to all clients. Additionally, for unprivileged clients, some + operations are allowed through the polkit privilege system. Operations which modify unit state + (<function>StartUnit()</function>, <function>StopUnit()</function>, <function>KillUnit()</function>, + <function>RestartUnit()</function> and similar, <function>SetProperty()</function>) require + <interfacename>org.freedesktop.systemd1.manage-units</interfacename>. Operations which modify unit file + enablement state (<function>EnableUnitFiles()</function>, <function>DisableUnitFiles()</function>, + <function>EnableUnitFilesWithFlags()</function>, <function>DisableUnitFilesWithFlags()</function>, + <function>ReenableUnitFiles()</function>, <function>LinkUnitFiles()</function>, + <function>PresetUnitFiles</function>, <function>MaskUnitFiles</function>, and similar) require + <interfacename>org.freedesktop.systemd1.manage-unit-files</interfacename>. Operations which modify the + exported environment (<function>SetEnvironment()</function>, <function>UnsetEnvironment()</function>, + <function>UnsetAndSetEnvironment()</function>) require + <interfacename>org.freedesktop.systemd1.set-environment</interfacename>. <function>Reload()</function> + and <function>Reexecute()</function> require + <interfacename>org.freedesktop.systemd1.reload-daemon</interfacename>. + </para> + </refsect2> + </refsect1> + + <refsect1> + <title>Unit Objects</title> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice" interface="org.freedesktop.systemd1.Unit"> +node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { + interface org.freedesktop.systemd1.Unit { + methods: + Start(in s mode, + out o job); + Stop(in s mode, + out o job); + Reload(in s mode, + out o job); + Restart(in s mode, + out o job); + TryRestart(in s mode, + out o job); + ReloadOrRestart(in s mode, + out o job); + ReloadOrTryRestart(in s mode, + out o job); + EnqueueJob(in s job_type, + in s job_mode, + out u job_id, + out o job_path, + out s unit_id, + out o unit_path, + out s job_type, + out a(uosos) affected_jobs); + Kill(in s whom, + in i signal); + ResetFailed(); + SetProperties(in b runtime, + in a(sv) properties); + Ref(); + Unref(); + Clean(in as mask); + Freeze(); + Thaw(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Id = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Names = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Following = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Requires = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Requisite = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Wants = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as BindsTo = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PartOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RequiredBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RequisiteOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as WantedBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as BoundBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConsistsOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Conflicts = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConflictedBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Before = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as After = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as OnFailure = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Triggers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as TriggeredBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PropagatesReloadTo = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReloadPropagatedFrom = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as JoinsNamespaceOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RequiresMountsFor = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Documentation = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Description = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LoadState = '...'; + readonly s ActiveState = '...'; + readonly s FreezerState = '...'; + readonly s SubState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s FragmentPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SourcePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as DropInPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s UnitFileState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s UnitFilePreset = '...'; + readonly t StateChangeTimestamp = ...; + readonly t StateChangeTimestampMonotonic = ...; + readonly t InactiveExitTimestamp = ...; + readonly t InactiveExitTimestampMonotonic = ...; + readonly t ActiveEnterTimestamp = ...; + readonly t ActiveEnterTimestampMonotonic = ...; + readonly t ActiveExitTimestamp = ...; + readonly t ActiveExitTimestampMonotonic = ...; + readonly t InactiveEnterTimestamp = ...; + readonly t InactiveEnterTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanStart = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanStop = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanReload = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanIsolate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CanClean = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanFreeze = ...; + readonly (uo) Job = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b StopWhenUnneeded = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RefuseManualStart = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RefuseManualStop = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b AllowIsolate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultDependencies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OnFailureJobMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreOnIsolate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NeedDaemonReload = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t JobTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t JobRunningTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s JobTimeoutAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s JobTimeoutRebootArgument = '...'; + readonly b ConditionResult = ...; + readonly b AssertResult = ...; + readonly t ConditionTimestamp = ...; + readonly t ConditionTimestampMonotonic = ...; + readonly t AssertTimestamp = ...; + readonly t AssertTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sbbsi) Conditions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sbbsi) Asserts = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (ss) LoadError = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Transient = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Perpetual = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t StartLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StartLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StartLimitAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s FailureAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FailureActionExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SuccessAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SuccessActionExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RebootArgument = '...'; + readonly ay InvocationID = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s CollectMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as Refs = ['...', ...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method EnqueueJob is not documented!--> + + <!--method Ref is not documented!--> + + <!--method Unref is not documented!--> + + <!--method Clean is not documented!--> + + <!--method Freeze is not documented!--> + + <!--method Thaw is not documented!--> + + <!--property PartOf is not documented!--> + + <!--property RequisiteOf is not documented!--> + + <!--property ConsistsOf is not documented!--> + + <!--property ReloadPropagatedFrom is not documented!--> + + <!--property JoinsNamespaceOf is not documented!--> + + <!--property FreezerState is not documented!--> + + <!--property DropInPaths is not documented!--> + + <!--property UnitFilePreset is not documented!--> + + <!--property StateChangeTimestamp is not documented!--> + + <!--property StateChangeTimestampMonotonic is not documented!--> + + <!--property CanClean is not documented!--> + + <!--property CanFreeze is not documented!--> + + <!--property OnFailureJobMode is not documented!--> + + <!--property JobRunningTimeoutUSec is not documented!--> + + <!--property JobTimeoutAction is not documented!--> + + <!--property JobTimeoutRebootArgument is not documented!--> + + <!--property AssertResult is not documented!--> + + <!--property AssertTimestamp is not documented!--> + + <!--property AssertTimestampMonotonic is not documented!--> + + <!--property Asserts is not documented!--> + + <!--property Perpetual is not documented!--> + + <!--property StartLimitIntervalUSec is not documented!--> + + <!--property StartLimitAction is not documented!--> + + <!--property FailureAction is not documented!--> + + <!--property FailureActionExitStatus is not documented!--> + + <!--property SuccessAction is not documented!--> + + <!--property SuccessActionExitStatus is not documented!--> + + <!--property RebootArgument is not documented!--> + + <!--property InvocationID is not documented!--> + + <!--property CollectMode is not documented!--> + + <!--property Refs is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Start()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Stop()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Reload()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Restart()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="TryRestart()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrRestart()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrTryRestart()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="EnqueueJob()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ResetFailed()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetProperties()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Ref()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Unref()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Clean()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Freeze()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Thaw()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Id"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Names"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Following"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Requires"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Requisite"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Wants"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindsTo"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PartOf"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RequiredBy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RequisiteOf"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WantedBy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BoundBy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConsistsOf"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Conflicts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConflictedBy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Before"/> + + <variablelist class="dbus-property" generated="True" extra-ref="After"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OnFailure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Triggers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TriggeredBy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PropagatesReloadTo"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReloadPropagatedFrom"/> + + <variablelist class="dbus-property" generated="True" extra-ref="JoinsNamespaceOf"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RequiresMountsFor"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Documentation"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Description"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoadState"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ActiveState"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FreezerState"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SubState"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FragmentPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SourcePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DropInPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitFileState"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnitFilePreset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateChangeTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateChangeTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InactiveExitTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InactiveExitTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ActiveEnterTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ActiveEnterTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ActiveExitTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ActiveExitTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InactiveEnterTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InactiveEnterTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanStart"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanStop"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanReload"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanIsolate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanClean"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanFreeze"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Job"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StopWhenUnneeded"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RefuseManualStart"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RefuseManualStop"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowIsolate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultDependencies"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OnFailureJobMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IgnoreOnIsolate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NeedDaemonReload"/> + + <variablelist class="dbus-property" generated="True" extra-ref="JobTimeoutUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="JobRunningTimeoutUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="JobTimeoutAction"/> + + <variablelist class="dbus-property" generated="True" extra-ref="JobTimeoutRebootArgument"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConditionResult"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AssertResult"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConditionTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConditionTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AssertTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AssertTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Conditions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Asserts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoadError"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Transient"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Perpetual"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartLimitAction"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FailureAction"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FailureActionExitStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SuccessAction"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SuccessActionExitStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RebootArgument"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InvocationID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CollectMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Refs"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Start()</function>, <function>Stop()</function>, <function>Reload()</function>, + <function>Restart()</function>, <function>TryRestart()</function>, + <function>ReloadOrRestart()</function>, <function>ReloadOrTryRestart()</function>, + <function>Kill()</function>, <function>ResetFailed()</function>, and + <function>SetProperties()</function> implement the same operation as the respective methods on the + <interfacename>Manager</interfacename> object (see above). However, these methods operate on the unit + object and hence do not take a unit name parameter. Invoking the methods directly on the Manager + object has the advantage of not requiring a <function>GetUnit()</function> call to get the unit object + for a specific unit name. Calling the methods on the Manager object is hence a round trip + optimization.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>Id</varname> contains the primary name of the unit.</para> + + <para><varname>Names</varname> contains all names of the unit, including the primary name that is also + exposed in <varname>Id</varname>.</para> + + <para><varname>Following</varname> either contains the empty string or contains the name of another + unit that this unit follows in state. This is used for some device units which reflect the unit state + machine of another unit, and which other unit this is might possibly change.</para> + + <para><varname>Requires</varname>, <varname>RequiresOverridable</varname>, + <varname>Requisite</varname>, <varname>RequisiteOverridable</varname>, <varname>Wants</varname>, + <varname>BindsTo</varname>, <varname>RequiredBy</varname>, <varname>RequiredByOverridable</varname>, + <varname>WantedBy</varname>, <varname>BoundBy</varname>, <varname>Conflicts</varname>, + <varname>ConflictedBy</varname>, <varname>Before</varname>, <varname>After</varname>, + <varname>OnFailure</varname>, <varname>Triggers</varname>, <varname>TriggeredBy</varname>, + <varname>PropagatesReloadTo</varname>, and <varname>RequiresMountsFor</varname> contain arrays which encode + the dependencies and their inverse dependencies (where this applies) as configured in the unit file or + determined automatically.</para> + + <para><varname>Description</varname> contains the human readable description string for the + unit.</para> + + <para><varname>SourcePath</varname> contains the path to a configuration file this unit is + automatically generated from in case it is not a native unit (in which case it contains the empty + string). For example, all mount units generated from <filename>/etc/fstab</filename> have this field + set to <filename>/etc/fstab</filename>.</para> + + <para><varname>Documentation</varname> contains a string array with URLs of documentation for this + unit.</para> + + <para><varname>LoadState</varname> contains a state value that reflects whether the configuration file + of this unit has been loaded. The following states are currently defined: <literal>loaded</literal>, + <literal>error</literal>, and <literal>masked</literal>. <literal>loaded</literal> indicates that the + configuration was successfully loaded. <literal>error</literal> indicates that the configuration failed + to load. The <varname>LoadError</varname> field (see below) contains information about the cause of + this failure. <literal>masked</literal> indicates that the unit is currently masked out (i.e. symlinked + to <filename>/dev/null</filename> or empty). Note that the <varname>LoadState</varname> is fully + orthogonal to the <varname>ActiveState</varname> (see below) as units without valid loaded + configuration might be active (because configuration might have been reloaded at a time where a unit + was already active).</para> + + <para><varname>ActiveState</varname> contains a state value that reflects whether the unit is currently + active or not. The following states are currently defined: <literal>active</literal>, + <literal>reloading</literal>, <literal>inactive</literal>, <literal>failed</literal>, + <literal>activating</literal>, and <literal>deactivating</literal>. <literal>active</literal> indicates + that unit is active (obviously...). <literal>reloading</literal> indicates that the unit is active and + currently reloading its configuration. <literal>inactive</literal> indicates that it is inactive and + the previous run was successful or no previous run has taken place yet. <literal>failed</literal> + indicates that it is inactive and the previous run was not successful (more information about the + reason for this is available on the unit type specific interfaces, for example for services in the + <varname>Result</varname> property, see below). <literal>activating</literal> indicates that the unit + has previously been inactive but is currently in the process of entering an active state. Conversely + <literal>deactivating</literal> indicates that the unit is currently in the process of + deactivation.</para> + + <para><varname>SubState</varname> encodes states of the same state machine that + <varname>ActiveState</varname> covers, but knows more fine-grained states that are + unit-type-specific. Where <varname>ActiveState</varname> only covers six high-level states, + <varname>SubState</varname> covers possibly many more low-level unit-type-specific states that are + mapped to the six high-level states. Note that multiple low-level states might map to the same + high-level state, but not vice versa. Not all high-level states have low-level counterparts on all unit + types. At this point the low-level states are not documented here, and are more likely to be extended + later on than the common high-level states explained above.</para> + + <para><varname>FragmentPath</varname> contains the unit file path this unit was read from, if there is + one (if not, it contains the empty string).</para> + + <para><varname>UnitFileState</varname> encodes the install state of the unit file of + <varname>FragmentPath</varname>. It currently knows the following states: <literal>enabled</literal>, + <literal>enabled-runtime</literal>, <literal>linked</literal>, <literal>linked-runtime</literal>, + <literal>masked</literal>, <literal>masked-runtime</literal>, <literal>static</literal>, + <literal>disabled</literal>, and <literal>invalid</literal>. <literal>enabled</literal> indicates that a + unit file is permanently enabled. <literal>enable-runtime</literal> indicates the unit file is only + temporarily enabled and will no longer be enabled after a reboot (that means, it is enabled via + <filename>/run/</filename> symlinks, rather than <filename>/etc/</filename>). <literal>linked</literal> + indicates that a unit is linked into <filename>/etc/</filename> permanently. <literal>linked-runtime</literal> + indicates that a unit is linked into <filename>/run/</filename> temporarily (until the next + reboot). <literal>masked</literal> indicates that the unit file is masked permanently. + <literal>masked-runtime</literal> indicates that it is masked in <filename>/run/</filename> temporarily + (until the next reboot). <literal>static</literal> indicates that the unit is statically enabled, i.e. + always enabled and doesn't need to be enabled explicitly. <literal>invalid</literal> indicates that it + could not be determined whether the unit file is enabled.</para> + + <para><varname>InactiveExitTimestamp</varname>, <varname>InactiveExitTimestampMonotonic</varname>, + <varname>ActiveEnterTimestamp</varname>, <varname>ActiveEnterTimestampMonotonic</varname>, + <varname>ActiveExitTimestamp</varname>, <varname>ActiveExitTimestampMonotonic</varname>, + <varname>InactiveEnterTimestamp</varname>, and <varname>InactiveEnterTimestampMonotonic</varname> + contain <constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> 64-bit microsecond + timestamps of the last time a unit left the inactive state, entered the active state, exited the active + state, or entered an inactive state. These are the points in time where the unit transitioned + <literal>inactive</literal>/<literal>failed</literal> → <literal>activating</literal>, + <literal>activating</literal> → <literal>active</literal>, <literal>active</literal> → + <literal>deactivating</literal>, and finally <literal>deactivating</literal> → + <literal>inactive</literal>/<literal>failed</literal>. The fields are 0 in case such a transition has + not yet been recorded on this boot.</para> + + <para><varname>CanStart</varname>, <varname>CanStop</varname>, and <varname>CanReload</varname> encode + as booleans whether the unit supports the start, stop or reload operations. Even if a unit supports + such an operation, the client might not necessary have the necessary privileges to execute them.</para> + + <para><varname>CanIsolate</varname> encodes as a boolean whether the unit may be started in isolation + mode.</para> + + <para><varname>Job</varname> encodes the job ID and job object path of the job currently scheduled or + executed for this unit, if there is any. If no job is scheduled or executed, the job id field will be + 0.</para> + + <para><varname>StopWhenUnneeded</varname>, <varname>RefuseManualStart</varname>, + <varname>RefuseManualStop</varname>, <varname>AllowIsolate</varname>, + <varname>DefaultDependencies</varname>, <varname>OnFailureIsolate</varname>, + <varname>IgnoreOnIsolate</varname>, <varname>IgnoreOnSnapshot</varname> map directly to the + corresponding configuration booleans in the unit file.</para> + + <para><varname>DefaultControlGroup</varname> contains the main control group of this unit as a + string. This refers to a group in systemd's own <literal>name=systemd</literal> hierarchy, which + systemd uses to watch and manipulate the unit and all its processes.</para> + + <para><varname>NeedDaemonReload</varname> is a boolean that indicates whether the configuration file + this unit is loaded from (i.e. <varname>FragmentPath</varname> or <varname>SourcePath</varname>) has + changed since the configuration was read and hence whether a configuration reload is + recommended.</para> + + <para><varname>JobTimeoutUSec</varname> maps directly to the corresponding configuration setting in the + unit file.</para> + + <para><varname>ConditionTimestamp</varname> and <varname>ConditionTimestampMonotonic</varname> contain + the <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps of + the last time the configured conditions of the unit have been checked or 0 if they have never been + checked. Conditions are checked when a unit is requested to start.</para> + + <para><varname>ConditionResult</varname> contains the condition result of the last time the configured + conditions of this unit were checked. </para> + + <para><varname>Conditions</varname> contains all configured conditions of the unit. For each condition, + five fields are given: condition type (e.g. <varname>ConditionPathExists</varname>), whether the + condition is a trigger condition, whether the condition is reversed, the right hand side of the + condition (e.g. the path in case of <varname>ConditionPathExists</varname>), and the status. The status + can be 0, in which case the condition hasn't been checked yet, a positive value, in which case the + condition passed, or a negative value, in which case the condition failed. Currently only 0, +1, and -1 + are used, but additional values may be used in the future, retaining the meaning of + zero/positive/negative values.</para> + + <para><varname>LoadError</varname> contains a pair of strings. If the unit failed to load (as encoded + in <varname>LoadState</varname>, see above), then this will include a D-Bus error pair consisting of + the error ID and an explanatory human readable string of what happened. If it loaded successfully, this + will be a pair of empty strings.</para> + + <para><varname>Transient</varname> contains a boolean that indicates whether the unit was created as a + transient unit (i.e. via <function>CreateTransientUnit()</function> on the manager object).</para> + </refsect2> + + <refsect2> + <title>Security</title> + + <para>Similarly to methods on the <interfacename>Manager</interfacename> object, read-only access is + allowed for everyone. All operations are allowed for clients with the + <constant>CAP_SYS_ADMIN</constant> capability or when the + <interfacename>org.freedesktop.systemd1.manage-units</interfacename> privilege is granted by + polkit.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Service Unit Objects</title> + + <para>All service unit objects implement the + <interfacename>org.freedesktop.systemd1.Service</interfacename> interface (described here) in addition to + the generic <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice" interface="org.freedesktop.systemd1.Service"> +node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { + interface org.freedesktop.systemd1.Service { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Restart = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PIDFile = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NotifyAccess = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutStartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutStopUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TimeoutAbortUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TimeoutStartFailureMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TimeoutStopFailureMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeMaxUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RootDirectoryStartOnly = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemainAfterExit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b GuessMainPID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (aiai) RestartPreventExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (aiai) RestartForceExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (aiai) SuccessExitStatus = ...; + readonly u MainPID = ...; + readonly u ControlPID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s BusName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u FileDescriptorStoreMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NFileDescriptorStore = ...; + readonly s StatusText = '...'; + readonly i StatusErrno = ...; + readonly s Result = '...'; + readonly s ReloadResult = '...'; + readonly s CleanResult = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s USBFunctionDescriptors = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s USBFunctionStrings = '...'; + readonly u UID = ...; + readonly u GID = ...; + readonly u NRestarts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OOMPolicy = '...'; + readonly t ExecMainStartTimestamp = ...; + readonly t ExecMainStartTimestampMonotonic = ...; + readonly t ExecMainExitTimestamp = ...; + readonly t ExecMainExitTimestampMonotonic = ...; + readonly u ExecMainPID = ...; + readonly i ExecMainCode = ...; + readonly i ExecMainStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecCondition = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecConditionEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPre = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStartPreEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStart = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStartEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStartPostEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecReload = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecReloadEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStop = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStopEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStopPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStopPostEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressureLimitPercent = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--method GetProcesses is not documented!--> + + <!--method AttachProcesses is not documented!--> + + <!--property Type is not documented!--> + + <!--property Restart is not documented!--> + + <!--property PIDFile is not documented!--> + + <!--property NotifyAccess is not documented!--> + + <!--property RestartUSec is not documented!--> + + <!--property TimeoutStartFailureMode is not documented!--> + + <!--property TimeoutStopFailureMode is not documented!--> + + <!--property RuntimeMaxUSec is not documented!--> + + <!--property WatchdogUSec is not documented!--> + + <!--property RootDirectoryStartOnly is not documented!--> + + <!--property RemainAfterExit is not documented!--> + + <!--property GuessMainPID is not documented!--> + + <!--property RestartPreventExitStatus is not documented!--> + + <!--property RestartForceExitStatus is not documented!--> + + <!--property SuccessExitStatus is not documented!--> + + <!--property BusName is not documented!--> + + <!--property FileDescriptorStoreMax is not documented!--> + + <!--property NFileDescriptorStore is not documented!--> + + <!--property StatusErrno is not documented!--> + + <!--property ReloadResult is not documented!--> + + <!--property CleanResult is not documented!--> + + <!--property USBFunctionDescriptors is not documented!--> + + <!--property USBFunctionStrings is not documented!--> + + <!--property UID is not documented!--> + + <!--property GID is not documented!--> + + <!--property NRestarts is not documented!--> + + <!--property OOMPolicy is not documented!--> + + <!--property ExecCondition is not documented!--> + + <!--property ExecConditionEx is not documented!--> + + <!--property ExecStartPreEx is not documented!--> + + <!--property ExecStartEx is not documented!--> + + <!--property ExecStartPostEx is not documented!--> + + <!--property ExecReloadEx is not documented!--> + + <!--property ExecStopEx is not documented!--> + + <!--property ExecStopPost is not documented!--> + + <!--property ExecStopPostEx is not documented!--> + + <!--property Slice is not documented!--> + + <!--property MemoryCurrent is not documented!--> + + <!--property CPUUsageNSec is not documented!--> + + <!--property EffectiveCPUs is not documented!--> + + <!--property EffectiveMemoryNodes is not documented!--> + + <!--property TasksCurrent is not documented!--> + + <!--property IPIngressBytes is not documented!--> + + <!--property IPIngressPackets is not documented!--> + + <!--property IPEgressBytes is not documented!--> + + <!--property IPEgressPackets is not documented!--> + + <!--property IOReadBytes is not documented!--> + + <!--property IOReadOperations is not documented!--> + + <!--property IOWriteBytes is not documented!--> + + <!--property IOWriteOperations is not documented!--> + + <!--property Delegate is not documented!--> + + <!--property DelegateControllers is not documented!--> + + <!--property CPUAccounting is not documented!--> + + <!--property CPUWeight is not documented!--> + + <!--property StartupCPUWeight is not documented!--> + + <!--property CPUShares is not documented!--> + + <!--property StartupCPUShares is not documented!--> + + <!--property CPUQuotaPerSecUSec is not documented!--> + + <!--property CPUQuotaPeriodUSec is not documented!--> + + <!--property AllowedCPUs is not documented!--> + + <!--property AllowedMemoryNodes is not documented!--> + + <!--property IOAccounting is not documented!--> + + <!--property IOWeight is not documented!--> + + <!--property StartupIOWeight is not documented!--> + + <!--property IODeviceWeight is not documented!--> + + <!--property IOReadBandwidthMax is not documented!--> + + <!--property IOWriteBandwidthMax is not documented!--> + + <!--property IOReadIOPSMax is not documented!--> + + <!--property IOWriteIOPSMax is not documented!--> + + <!--property IODeviceLatencyTargetUSec is not documented!--> + + <!--property BlockIOAccounting is not documented!--> + + <!--property BlockIOWeight is not documented!--> + + <!--property StartupBlockIOWeight is not documented!--> + + <!--property BlockIODeviceWeight is not documented!--> + + <!--property BlockIOReadBandwidth is not documented!--> + + <!--property BlockIOWriteBandwidth is not documented!--> + + <!--property MemoryAccounting is not documented!--> + + <!--property DefaultMemoryLow is not documented!--> + + <!--property DefaultMemoryMin is not documented!--> + + <!--property MemoryMin is not documented!--> + + <!--property MemoryLow is not documented!--> + + <!--property MemoryHigh is not documented!--> + + <!--property MemoryMax is not documented!--> + + <!--property MemorySwapMax is not documented!--> + + <!--property MemoryLimit is not documented!--> + + <!--property DevicePolicy is not documented!--> + + <!--property DeviceAllow is not documented!--> + + <!--property TasksAccounting is not documented!--> + + <!--property TasksMax is not documented!--> + + <!--property IPAccounting is not documented!--> + + <!--property IPAddressAllow is not documented!--> + + <!--property IPAddressDeny is not documented!--> + + <!--property IPIngressFilterPath is not documented!--> + + <!--property IPEgressFilterPath is not documented!--> + + <!--property DisableControllers is not documented!--> + + <!--property ManagedOOMSwap is not documented!--> + + <!--property ManagedOOMMemoryPressure is not documented!--> + + <!--property ManagedOOMMemoryPressureLimitPercent is not documented!--> + + <!--property EnvironmentFiles is not documented!--> + + <!--property PassEnvironment is not documented!--> + + <!--property UnsetEnvironment is not documented!--> + + <!--property UMask is not documented!--> + + <!--property LimitCPUSoft is not documented!--> + + <!--property LimitFSIZE is not documented!--> + + <!--property LimitFSIZESoft is not documented!--> + + <!--property LimitDATA is not documented!--> + + <!--property LimitDATASoft is not documented!--> + + <!--property LimitSTACK is not documented!--> + + <!--property LimitSTACKSoft is not documented!--> + + <!--property LimitCORE is not documented!--> + + <!--property LimitCORESoft is not documented!--> + + <!--property LimitRSS is not documented!--> + + <!--property LimitRSSSoft is not documented!--> + + <!--property LimitNOFILE is not documented!--> + + <!--property LimitNOFILESoft is not documented!--> + + <!--property LimitAS is not documented!--> + + <!--property LimitASSoft is not documented!--> + + <!--property LimitNPROC is not documented!--> + + <!--property LimitNPROCSoft is not documented!--> + + <!--property LimitMEMLOCK is not documented!--> + + <!--property LimitMEMLOCKSoft is not documented!--> + + <!--property LimitLOCKS is not documented!--> + + <!--property LimitLOCKSSoft is not documented!--> + + <!--property LimitSIGPENDING is not documented!--> + + <!--property LimitSIGPENDINGSoft is not documented!--> + + <!--property LimitMSGQUEUE is not documented!--> + + <!--property LimitMSGQUEUESoft is not documented!--> + + <!--property LimitNICE is not documented!--> + + <!--property LimitNICESoft is not documented!--> + + <!--property LimitRTPRIO is not documented!--> + + <!--property LimitRTPRIOSoft is not documented!--> + + <!--property LimitRTTIME is not documented!--> + + <!--property LimitRTTIMESoft is not documented!--> + + <!--property WorkingDirectory is not documented!--> + + <!--property RootDirectory is not documented!--> + + <!--property RootImage is not documented!--> + + <!--property RootImageOptions is not documented!--> + + <!--property RootHash is not documented!--> + + <!--property RootHashPath is not documented!--> + + <!--property RootHashSignature is not documented!--> + + <!--property RootHashSignaturePath is not documented!--> + + <!--property RootVerity is not documented!--> + + <!--property MountImages is not documented!--> + + <!--property OOMScoreAdjust is not documented!--> + + <!--property CoredumpFilter is not documented!--> + + <!--property Nice is not documented!--> + + <!--property IOSchedulingClass is not documented!--> + + <!--property IOSchedulingPriority is not documented!--> + + <!--property CPUSchedulingPolicy is not documented!--> + + <!--property CPUSchedulingPriority is not documented!--> + + <!--property CPUAffinity is not documented!--> + + <!--property CPUAffinityFromNUMA is not documented!--> + + <!--property NUMAPolicy is not documented!--> + + <!--property NUMAMask is not documented!--> + + <!--property TimerSlackNSec is not documented!--> + + <!--property CPUSchedulingResetOnFork is not documented!--> + + <!--property NonBlocking is not documented!--> + + <!--property StandardInput is not documented!--> + + <!--property StandardInputFileDescriptorName is not documented!--> + + <!--property StandardInputData is not documented!--> + + <!--property StandardOutput is not documented!--> + + <!--property StandardOutputFileDescriptorName is not documented!--> + + <!--property StandardError is not documented!--> + + <!--property StandardErrorFileDescriptorName is not documented!--> + + <!--property TTYPath is not documented!--> + + <!--property TTYReset is not documented!--> + + <!--property TTYVHangup is not documented!--> + + <!--property TTYVTDisallocate is not documented!--> + + <!--property SyslogPriority is not documented!--> + + <!--property SyslogIdentifier is not documented!--> + + <!--property SyslogLevelPrefix is not documented!--> + + <!--property SyslogLevel is not documented!--> + + <!--property SyslogFacility is not documented!--> + + <!--property LogLevelMax is not documented!--> + + <!--property LogRateLimitIntervalUSec is not documented!--> + + <!--property LogRateLimitBurst is not documented!--> + + <!--property LogExtraFields is not documented!--> + + <!--property LogNamespace is not documented!--> + + <!--property AmbientCapabilities is not documented!--> + + <!--property User is not documented!--> + + <!--property Group is not documented!--> + + <!--property DynamicUser is not documented!--> + + <!--property RemoveIPC is not documented!--> + + <!--property SetCredential is not documented!--> + + <!--property LoadCredential is not documented!--> + + <!--property SupplementaryGroups is not documented!--> + + <!--property PAMName is not documented!--> + + <!--property ReadWritePaths is not documented!--> + + <!--property ReadOnlyPaths is not documented!--> + + <!--property InaccessiblePaths is not documented!--> + + <!--property PrivateTmp is not documented!--> + + <!--property PrivateDevices is not documented!--> + + <!--property ProtectClock is not documented!--> + + <!--property ProtectKernelTunables is not documented!--> + + <!--property ProtectKernelModules is not documented!--> + + <!--property ProtectKernelLogs is not documented!--> + + <!--property ProtectControlGroups is not documented!--> + + <!--property PrivateNetwork is not documented!--> + + <!--property PrivateUsers is not documented!--> + + <!--property PrivateMounts is not documented!--> + + <!--property ProtectHome is not documented!--> + + <!--property ProtectSystem is not documented!--> + + <!--property SameProcessGroup is not documented!--> + + <!--property UtmpIdentifier is not documented!--> + + <!--property UtmpMode is not documented!--> + + <!--property SELinuxContext is not documented!--> + + <!--property AppArmorProfile is not documented!--> + + <!--property SmackProcessLabel is not documented!--> + + <!--property IgnoreSIGPIPE is not documented!--> + + <!--property NoNewPrivileges is not documented!--> + + <!--property SystemCallFilter is not documented!--> + + <!--property SystemCallArchitectures is not documented!--> + + <!--property SystemCallErrorNumber is not documented!--> + + <!--property SystemCallLog is not documented!--> + + <!--property Personality is not documented!--> + + <!--property LockPersonality is not documented!--> + + <!--property RestrictAddressFamilies is not documented!--> + + <!--property RuntimeDirectoryPreserve is not documented!--> + + <!--property RuntimeDirectoryMode is not documented!--> + + <!--property RuntimeDirectory is not documented!--> + + <!--property StateDirectoryMode is not documented!--> + + <!--property StateDirectory is not documented!--> + + <!--property CacheDirectoryMode is not documented!--> + + <!--property CacheDirectory is not documented!--> + + <!--property LogsDirectoryMode is not documented!--> + + <!--property LogsDirectory is not documented!--> + + <!--property ConfigurationDirectoryMode is not documented!--> + + <!--property ConfigurationDirectory is not documented!--> + + <!--property TimeoutCleanUSec is not documented!--> + + <!--property MemoryDenyWriteExecute is not documented!--> + + <!--property RestrictRealtime is not documented!--> + + <!--property RestrictSUIDSGID is not documented!--> + + <!--property RestrictNamespaces is not documented!--> + + <!--property BindPaths is not documented!--> + + <!--property BindReadOnlyPaths is not documented!--> + + <!--property TemporaryFileSystem is not documented!--> + + <!--property MountAPIVFS is not documented!--> + + <!--property KeyringMode is not documented!--> + + <!--property ProtectProc is not documented!--> + + <!--property ProcSubset is not documented!--> + + <!--property ProtectHostname is not documented!--> + + <!--property NetworkNamespacePath is not documented!--> + + <!--property KillMode is not documented!--> + + <!--property KillSignal is not documented!--> + + <!--property RestartKillSignal is not documented!--> + + <!--property FinalKillSignal is not documented!--> + + <!--property SendSIGKILL is not documented!--> + + <!--property SendSIGHUP is not documented!--> + + <!--property WatchdogSignal is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Service"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Service"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Type"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Restart"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PIDFile"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NotifyAccess"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStartUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStopUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutAbortUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStartFailureMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStopFailureMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeMaxUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootDirectoryStartOnly"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemainAfterExit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GuessMainPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartPreventExitStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartForceExitStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SuccessExitStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MainPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BusName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FileDescriptorStoreMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NFileDescriptorStore"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StatusText"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StatusErrno"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReloadResult"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CleanResult"/> + + <variablelist class="dbus-property" generated="True" extra-ref="USBFunctionDescriptors"/> + + <variablelist class="dbus-property" generated="True" extra-ref="USBFunctionStrings"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NRestarts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OOMPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainStartTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainStartTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainExitTimestamp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainExitTimestampMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainCode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMainStatus"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecCondition"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecConditionEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPre"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPreEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStart"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPost"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPostEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecReload"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecReloadEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStop"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStopEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPost"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPostEx"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimitPercent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Environment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Nice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/> + + <variablelist class="dbus-property" generated="True" extra-ref="User"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Group"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Personality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most properties of the Service interface map directly to the corresponding settings in service + unit files. For the sake of brevity, here's a list of all exceptions only:</para> + + <para><varname>TimeoutStartUSec</varname>, <varname>TimeoutStopUSec</varname> and + <varname>TimeoutAbortUSec</varname> contain the start, stop and abort timeouts, in microseconds. Note + the slight difference in naming when compared to the matching unit file settings (see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>7</manvolnum></citerefentry>): + these bus properties strictly use microseconds (and thus are suffixed <varname>…USec</varname>) while + the unit file settings default to a time unit of seconds (and thus are suffixed + <varname>…Sec</varname>), unless a different unit is explicitly specified. This reflects that fact that + internally the service manager deals in microsecond units only, and the bus properties are a relatively + low-level (binary) concept exposing this. The unit file settings on the other hand are relatively + high-level (string-based) concepts and thus support more user friendly time specifications which + default to second time units but allow other units too, if specified.</para> + + <para><varname>WatchdogTimestamp</varname> and <varname>WatchdogTimestampMonotonic</varname> contain + <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps of the + last watchdog ping received from the service, or 0 if none was ever received.</para> + + <para><varname>ExecStartPre</varname>, <varname>ExecStart</varname>, <varname>ExecStartPost</varname>, + <varname>ExecReload</varname>, <varname>ExecStop</varname>, and <varname>ExecStop</varname> are arrays + of structures where each struct contains: the binary path to execute; an array with all arguments to + pass to the executed command, starting with argument 0; a boolean whether it should be considered a + failure if the process exits uncleanly; two pairs of + <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps when + the process began and finished running the last time, or 0 if it never ran or never finished running; + the PID of the process, or 0 if it has not run yet; the exit code and status of the last run. This + field hence maps more or less to the corresponding setting in the service unit file but is augmented + with runtime data.</para> + + <para><varname>LimitCPU</varname> (and related properties) map more or less directly to the + corresponding settings in the service unit files except that if they aren't set, their value is + 18446744073709551615 (i.e. -1).</para> + + <para><varname>Capabilities</varname> contains the configured capabilities, as formatted with + <citerefentry project="man-pages"><refentrytitle>cap_to_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><varname>SecureBits</varname>, <varname>CapabilityBoundingSet</varname>, + <varname>MountFlags</varname> also correspond to the configured settings of the unit files, but + instead of being formatted as strings, they are encoded as the actual binary flags they are. + </para> + + <para><varname>ExecMainStartTimestamp</varname>, <varname>ExecMainStartTimestampMonotonic</varname>, + <varname>ExecMainExitTimestamp</varname>, <varname>ExecMainExitTimestampMonotonic</varname>, + <varname>ExecMainPID</varname>, <varname>ExecMainCode</varname>, <varname>ExecMainStatus</varname> + contain information about the main process of the service as far as it is known. This is often the same + runtime information that is stored in <varname>ExecStart</varname>. However, it deviates for + <varname>Type=forking</varname> services where the main process of the service is not forked off + systemd directly. These fields either contain information of the last run of the process or of the + current running process.</para> + + <para><varname>MainPID</varname> and <varname>ControlPID</varname> contain the main and control PID of + the service. The main PID is the current main PID of the service and is 0 when the service currently + has no main PID. The control PID is the PID of the current start/stop/reload process running and is 0 + if no such process is currently running. That means that <varname>ExecMainPID</varname> and + <varname>MainPID</varname> differ in the way that the latter immediately reflects whether a main + process is currently running while the latter possible contains information collected from the last run + even if the process is no longer around.</para> + + <para><varname>StatusText</varname> contains the status text passed to the service manager via a call + to + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This may be used by services to inform the service manager about its internal state with a nice + explanatory string.</para> + + <para><varname>Result</varname> encodes the execution result of the last run of the service. It is + useful to determine the reason a service failed if it is in the <literal>failed</literal> state (see + <varname>ActiveState</varname> above). The following values are currently known: + <literal>success</literal> is set if the unit didn't fail. <literal>resources</literal> indicates that + not enough resources were available to fork off and execute the service + processes. <literal>timeout</literal> indicates that a timeout occurred while executing a service + operation. <literal>exit-code</literal> indicates that a service process exited with an unclean exit + code. <literal>signal</literal> indicates that a service process exited with an uncaught + signal. <literal>core-dump</literal> indicates that a service process exited uncleanly and dumped + core. <literal>watchdog</literal> indicates that a service did not send out watchdog ping messages + often enough. <literal>start-limit</literal> indicates that a service has been started too frequently + in a specific time frame (as configured in <varname>StartLimitInterval</varname>, + <varname>StartLimitBurst</varname>).</para> + + <para><varname>ControlGroup</varname> indicates the control group path the processes of this service + unit are placed in.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Socket Unit Objects</title> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket" interface="org.freedesktop.systemd1.Socket"> +node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket { + interface org.freedesktop.systemd1.Socket { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s BindIPv6Only = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Backlog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s BindToDevice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SocketUser = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SocketGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u SocketMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Accept = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b FlushPending = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Writable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b KeepAlive = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KeepAliveTimeUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KeepAliveIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u KeepAliveProbes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DeferAcceptUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoDelay = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Priority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t ReceiveBuffer = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SendBuffer = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IPTOS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IPTTL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t PipeSize = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b FreeBind = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Transparent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Broadcast = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PassCredentials = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PassSecurity = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PassPacketInfo = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Timestamping = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveOnStop = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) Listen = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Symlinks = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Mark = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u MaxConnections = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u MaxConnectionsPerSource = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly x MessageQueueMaxMessages = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly x MessageQueueMessageSize = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TCPCongestion = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ReusePort = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SmackLabel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SmackLabelIPIn = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SmackLabelIPOut = '...'; + readonly u ControlPID = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NConnections = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NAccepted = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NRefused = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s FileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SocketProtocol = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TriggerLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u TriggerLimitBurst = ...; + readonly u UID = ...; + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPre = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStopPre = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStopPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressureLimitPercent = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--method GetProcesses is not documented!--> + + <!--method AttachProcesses is not documented!--> + + <!--property BindIPv6Only is not documented!--> + + <!--property Backlog is not documented!--> + + <!--property TimeoutUSec is not documented!--> + + <!--property BindToDevice is not documented!--> + + <!--property SocketUser is not documented!--> + + <!--property SocketGroup is not documented!--> + + <!--property SocketMode is not documented!--> + + <!--property DirectoryMode is not documented!--> + + <!--property Writable is not documented!--> + + <!--property KeepAlive is not documented!--> + + <!--property KeepAliveTimeUSec is not documented!--> + + <!--property KeepAliveIntervalUSec is not documented!--> + + <!--property KeepAliveProbes is not documented!--> + + <!--property DeferAcceptUSec is not documented!--> + + <!--property NoDelay is not documented!--> + + <!--property Priority is not documented!--> + + <!--property ReceiveBuffer is not documented!--> + + <!--property SendBuffer is not documented!--> + + <!--property IPTOS is not documented!--> + + <!--property IPTTL is not documented!--> + + <!--property PipeSize is not documented!--> + + <!--property FreeBind is not documented!--> + + <!--property Transparent is not documented!--> + + <!--property Broadcast is not documented!--> + + <!--property PassCredentials is not documented!--> + + <!--property PassSecurity is not documented!--> + + <!--property PassPacketInfo is not documented!--> + + <!--property Timestamping is not documented!--> + + <!--property RemoveOnStop is not documented!--> + + <!--property Listen is not documented!--> + + <!--property Symlinks is not documented!--> + + <!--property Mark is not documented!--> + + <!--property MaxConnections is not documented!--> + + <!--property MaxConnectionsPerSource is not documented!--> + + <!--property MessageQueueMaxMessages is not documented!--> + + <!--property MessageQueueMessageSize is not documented!--> + + <!--property TCPCongestion is not documented!--> + + <!--property ReusePort is not documented!--> + + <!--property SmackLabel is not documented!--> + + <!--property SmackLabelIPIn is not documented!--> + + <!--property SmackLabelIPOut is not documented!--> + + <!--property NRefused is not documented!--> + + <!--property FileDescriptorName is not documented!--> + + <!--property SocketProtocol is not documented!--> + + <!--property TriggerLimitIntervalUSec is not documented!--> + + <!--property TriggerLimitBurst is not documented!--> + + <!--property UID is not documented!--> + + <!--property GID is not documented!--> + + <!--property ExecStopPre is not documented!--> + + <!--property ExecStopPost is not documented!--> + + <!--property Slice is not documented!--> + + <!--property MemoryCurrent is not documented!--> + + <!--property CPUUsageNSec is not documented!--> + + <!--property EffectiveCPUs is not documented!--> + + <!--property EffectiveMemoryNodes is not documented!--> + + <!--property TasksCurrent is not documented!--> + + <!--property IPIngressBytes is not documented!--> + + <!--property IPIngressPackets is not documented!--> + + <!--property IPEgressBytes is not documented!--> + + <!--property IPEgressPackets is not documented!--> + + <!--property IOReadBytes is not documented!--> + + <!--property IOReadOperations is not documented!--> + + <!--property IOWriteBytes is not documented!--> + + <!--property IOWriteOperations is not documented!--> + + <!--property Delegate is not documented!--> + + <!--property DelegateControllers is not documented!--> + + <!--property CPUAccounting is not documented!--> + + <!--property CPUWeight is not documented!--> + + <!--property StartupCPUWeight is not documented!--> + + <!--property CPUShares is not documented!--> + + <!--property StartupCPUShares is not documented!--> + + <!--property CPUQuotaPerSecUSec is not documented!--> + + <!--property CPUQuotaPeriodUSec is not documented!--> + + <!--property AllowedCPUs is not documented!--> + + <!--property AllowedMemoryNodes is not documented!--> + + <!--property IOAccounting is not documented!--> + + <!--property IOWeight is not documented!--> + + <!--property StartupIOWeight is not documented!--> + + <!--property IODeviceWeight is not documented!--> + + <!--property IOReadBandwidthMax is not documented!--> + + <!--property IOWriteBandwidthMax is not documented!--> + + <!--property IOReadIOPSMax is not documented!--> + + <!--property IOWriteIOPSMax is not documented!--> + + <!--property IODeviceLatencyTargetUSec is not documented!--> + + <!--property BlockIOAccounting is not documented!--> + + <!--property BlockIOWeight is not documented!--> + + <!--property StartupBlockIOWeight is not documented!--> + + <!--property BlockIODeviceWeight is not documented!--> + + <!--property BlockIOReadBandwidth is not documented!--> + + <!--property BlockIOWriteBandwidth is not documented!--> + + <!--property MemoryAccounting is not documented!--> + + <!--property DefaultMemoryLow is not documented!--> + + <!--property DefaultMemoryMin is not documented!--> + + <!--property MemoryMin is not documented!--> + + <!--property MemoryLow is not documented!--> + + <!--property MemoryHigh is not documented!--> + + <!--property MemoryMax is not documented!--> + + <!--property MemorySwapMax is not documented!--> + + <!--property MemoryLimit is not documented!--> + + <!--property DevicePolicy is not documented!--> + + <!--property DeviceAllow is not documented!--> + + <!--property TasksAccounting is not documented!--> + + <!--property TasksMax is not documented!--> + + <!--property IPAccounting is not documented!--> + + <!--property IPAddressAllow is not documented!--> + + <!--property IPAddressDeny is not documented!--> + + <!--property IPIngressFilterPath is not documented!--> + + <!--property IPEgressFilterPath is not documented!--> + + <!--property DisableControllers is not documented!--> + + <!--property ManagedOOMSwap is not documented!--> + + <!--property ManagedOOMMemoryPressure is not documented!--> + + <!--property ManagedOOMMemoryPressureLimitPercent is not documented!--> + + <!--property EnvironmentFiles is not documented!--> + + <!--property PassEnvironment is not documented!--> + + <!--property UnsetEnvironment is not documented!--> + + <!--property UMask is not documented!--> + + <!--property LimitCPUSoft is not documented!--> + + <!--property LimitFSIZE is not documented!--> + + <!--property LimitFSIZESoft is not documented!--> + + <!--property LimitDATA is not documented!--> + + <!--property LimitDATASoft is not documented!--> + + <!--property LimitSTACK is not documented!--> + + <!--property LimitSTACKSoft is not documented!--> + + <!--property LimitCORE is not documented!--> + + <!--property LimitCORESoft is not documented!--> + + <!--property LimitRSS is not documented!--> + + <!--property LimitRSSSoft is not documented!--> + + <!--property LimitNOFILE is not documented!--> + + <!--property LimitNOFILESoft is not documented!--> + + <!--property LimitAS is not documented!--> + + <!--property LimitASSoft is not documented!--> + + <!--property LimitNPROC is not documented!--> + + <!--property LimitNPROCSoft is not documented!--> + + <!--property LimitMEMLOCK is not documented!--> + + <!--property LimitMEMLOCKSoft is not documented!--> + + <!--property LimitLOCKS is not documented!--> + + <!--property LimitLOCKSSoft is not documented!--> + + <!--property LimitSIGPENDING is not documented!--> + + <!--property LimitSIGPENDINGSoft is not documented!--> + + <!--property LimitMSGQUEUE is not documented!--> + + <!--property LimitMSGQUEUESoft is not documented!--> + + <!--property LimitNICE is not documented!--> + + <!--property LimitNICESoft is not documented!--> + + <!--property LimitRTPRIO is not documented!--> + + <!--property LimitRTPRIOSoft is not documented!--> + + <!--property LimitRTTIME is not documented!--> + + <!--property LimitRTTIMESoft is not documented!--> + + <!--property WorkingDirectory is not documented!--> + + <!--property RootDirectory is not documented!--> + + <!--property RootImage is not documented!--> + + <!--property RootImageOptions is not documented!--> + + <!--property RootHash is not documented!--> + + <!--property RootHashPath is not documented!--> + + <!--property RootHashSignature is not documented!--> + + <!--property RootHashSignaturePath is not documented!--> + + <!--property RootVerity is not documented!--> + + <!--property MountImages is not documented!--> + + <!--property OOMScoreAdjust is not documented!--> + + <!--property CoredumpFilter is not documented!--> + + <!--property Nice is not documented!--> + + <!--property IOSchedulingClass is not documented!--> + + <!--property IOSchedulingPriority is not documented!--> + + <!--property CPUSchedulingPolicy is not documented!--> + + <!--property CPUSchedulingPriority is not documented!--> + + <!--property CPUAffinity is not documented!--> + + <!--property CPUAffinityFromNUMA is not documented!--> + + <!--property NUMAPolicy is not documented!--> + + <!--property NUMAMask is not documented!--> + + <!--property TimerSlackNSec is not documented!--> + + <!--property CPUSchedulingResetOnFork is not documented!--> + + <!--property NonBlocking is not documented!--> + + <!--property StandardInput is not documented!--> + + <!--property StandardInputFileDescriptorName is not documented!--> + + <!--property StandardInputData is not documented!--> + + <!--property StandardOutput is not documented!--> + + <!--property StandardOutputFileDescriptorName is not documented!--> + + <!--property StandardError is not documented!--> + + <!--property StandardErrorFileDescriptorName is not documented!--> + + <!--property TTYPath is not documented!--> + + <!--property TTYReset is not documented!--> + + <!--property TTYVHangup is not documented!--> + + <!--property TTYVTDisallocate is not documented!--> + + <!--property SyslogPriority is not documented!--> + + <!--property SyslogIdentifier is not documented!--> + + <!--property SyslogLevelPrefix is not documented!--> + + <!--property SyslogLevel is not documented!--> + + <!--property SyslogFacility is not documented!--> + + <!--property LogLevelMax is not documented!--> + + <!--property LogRateLimitIntervalUSec is not documented!--> + + <!--property LogRateLimitBurst is not documented!--> + + <!--property LogExtraFields is not documented!--> + + <!--property LogNamespace is not documented!--> + + <!--property AmbientCapabilities is not documented!--> + + <!--property User is not documented!--> + + <!--property Group is not documented!--> + + <!--property DynamicUser is not documented!--> + + <!--property RemoveIPC is not documented!--> + + <!--property SetCredential is not documented!--> + + <!--property LoadCredential is not documented!--> + + <!--property SupplementaryGroups is not documented!--> + + <!--property PAMName is not documented!--> + + <!--property ReadWritePaths is not documented!--> + + <!--property ReadOnlyPaths is not documented!--> + + <!--property InaccessiblePaths is not documented!--> + + <!--property PrivateTmp is not documented!--> + + <!--property PrivateDevices is not documented!--> + + <!--property ProtectClock is not documented!--> + + <!--property ProtectKernelTunables is not documented!--> + + <!--property ProtectKernelModules is not documented!--> + + <!--property ProtectKernelLogs is not documented!--> + + <!--property ProtectControlGroups is not documented!--> + + <!--property PrivateNetwork is not documented!--> + + <!--property PrivateUsers is not documented!--> + + <!--property PrivateMounts is not documented!--> + + <!--property ProtectHome is not documented!--> + + <!--property ProtectSystem is not documented!--> + + <!--property SameProcessGroup is not documented!--> + + <!--property UtmpIdentifier is not documented!--> + + <!--property UtmpMode is not documented!--> + + <!--property SELinuxContext is not documented!--> + + <!--property AppArmorProfile is not documented!--> + + <!--property SmackProcessLabel is not documented!--> + + <!--property IgnoreSIGPIPE is not documented!--> + + <!--property NoNewPrivileges is not documented!--> + + <!--property SystemCallFilter is not documented!--> + + <!--property SystemCallArchitectures is not documented!--> + + <!--property SystemCallErrorNumber is not documented!--> + + <!--property SystemCallLog is not documented!--> + + <!--property Personality is not documented!--> + + <!--property LockPersonality is not documented!--> + + <!--property RestrictAddressFamilies is not documented!--> + + <!--property RuntimeDirectoryPreserve is not documented!--> + + <!--property RuntimeDirectoryMode is not documented!--> + + <!--property RuntimeDirectory is not documented!--> + + <!--property StateDirectoryMode is not documented!--> + + <!--property StateDirectory is not documented!--> + + <!--property CacheDirectoryMode is not documented!--> + + <!--property CacheDirectory is not documented!--> + + <!--property LogsDirectoryMode is not documented!--> + + <!--property LogsDirectory is not documented!--> + + <!--property ConfigurationDirectoryMode is not documented!--> + + <!--property ConfigurationDirectory is not documented!--> + + <!--property TimeoutCleanUSec is not documented!--> + + <!--property MemoryDenyWriteExecute is not documented!--> + + <!--property RestrictRealtime is not documented!--> + + <!--property RestrictSUIDSGID is not documented!--> + + <!--property RestrictNamespaces is not documented!--> + + <!--property BindPaths is not documented!--> + + <!--property BindReadOnlyPaths is not documented!--> + + <!--property TemporaryFileSystem is not documented!--> + + <!--property MountAPIVFS is not documented!--> + + <!--property KeyringMode is not documented!--> + + <!--property ProtectProc is not documented!--> + + <!--property ProcSubset is not documented!--> + + <!--property ProtectHostname is not documented!--> + + <!--property NetworkNamespacePath is not documented!--> + + <!--property KillMode is not documented!--> + + <!--property KillSignal is not documented!--> + + <!--property RestartKillSignal is not documented!--> + + <!--property FinalKillSignal is not documented!--> + + <!--property SendSIGKILL is not documented!--> + + <!--property SendSIGHUP is not documented!--> + + <!--property WatchdogSignal is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Socket"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Socket"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindIPv6Only"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Backlog"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindToDevice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SocketUser"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SocketGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SocketMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Accept"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FlushPending"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Writable"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeepAlive"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeepAliveTimeUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeepAliveIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeepAliveProbes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeferAcceptUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NoDelay"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Priority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReceiveBuffer"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendBuffer"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPTOS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPTTL"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PipeSize"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FreeBind"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Transparent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Broadcast"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassCredentials"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassSecurity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassPacketInfo"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Timestamping"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoveOnStop"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Listen"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Symlinks"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Mark"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MaxConnections"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MaxConnectionsPerSource"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MessageQueueMaxMessages"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MessageQueueMessageSize"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TCPCongestion"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReusePort"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackLabel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackLabelIPIn"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackLabelIPOut"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NConnections"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NAccepted"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NRefused"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SocketProtocol"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TriggerLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TriggerLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPre"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPost"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPre"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPost"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimitPercent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Environment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Nice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/> + + <variablelist class="dbus-property" generated="True" extra-ref="User"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Group"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Personality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most of the properties map directly to the corresponding settings in socket unit files. As socket + units can include <varname>ExecStartPre</varname> (and similar) fields which contain information about + processes to execute. They also share most of the fields related to the execution context that Service + objects expose (see above).</para> + + <para>In addition to these properties there are the following:</para> + + <para><varname>NAccepted</varname> contains the accumulated number of connections ever accepted on this + socket. This only applies to sockets with <varname>Accept</varname> set to <literal>yes</literal>, + i.e. those where systemd is responsible for accepted connections. </para> + + <para>Similarly <varname>NConnections</varname> contains the number of currently open connections on + this socket. It only applies only to socket units with <varname>Accept</varname> set to + <literal>yes</literal>.</para> + + <para><varname>Result</varname> encodes the reason why a socket unit failed if it is in the + <literal>failed</literal> state (see <varname>ActiveState</varname> above). The values + <literal>success</literal>, <literal>resources</literal>, <literal>timeout</literal>, + <literal>exit-code</literal>, <literal>signal</literal> and <literal>core-dump</literal> have the same + meaning as they have for the corresponding field of service units (see above). In addition to that, + the value <literal>service-failed-permanent</literal> indicates that the service of this socket failed + continuously.</para> + + <para><varname>FlushPending</varname> specifies whether to flush the socket + just before entering the listening state. This setting only applies to sockets with + <varname>Accept=</varname> set to <literal>no</literal>.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Target Unit Objects</title> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/basic_2etarget" interface="org.freedesktop.systemd1.Target"> +node /org/freedesktop/systemd1/unit/basic_2etarget { + interface org.freedesktop.systemd1.Target { + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <para>Target units have neither type-specific methods nor properties.</para> + </refsect1> + + + <refsect1> + <title>Device Unit Objects</title> + + <para>All device unit objects implement the <interfacename>org.freedesktop.systemd1.Device</interfacename> interface (described here) + in addition to the generic <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/dev_2dttyS0_2edevice" interface="org.freedesktop.systemd1.Device"> +node /org/freedesktop/systemd1/unit/dev_2dttyS0_2edevice { + interface org.freedesktop.systemd1.Device { + properties: + readonly s SysFSPath = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Device"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Device"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SysFSPath"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Device units only expose a single type-specific property:</para> + + <para><varname>SysFSPath</varname> contains the sysfs path of the kernel device this object corresponds + to.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Mount Unit Objects</title> + + <para>All mount unit objects implement the <interfacename>org.freedesktop.systemd1.Mount</interfacename> + interface (described here) in addition to the generic + <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/home_2emount" interface="org.freedesktop.systemd1.Mount"> +node /org/freedesktop/systemd1/unit/home_2emount { + interface org.freedesktop.systemd1.Mount { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Where = '...'; + readonly s What = '...'; + readonly s Options = '...'; + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutUSec = ...; + readonly u ControlPID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SloppyOptions = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LazyUnmount = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ForceUnmount = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ReadWriteOnly = ...; + readonly s Result = '...'; + readonly u UID = ...; + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecMount = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecUnmount = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecRemount = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressureLimitPercent = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--method GetProcesses is not documented!--> + + <!--method AttachProcesses is not documented!--> + + <!--property Where is not documented!--> + + <!--property What is not documented!--> + + <!--property Options is not documented!--> + + <!--property Type is not documented!--> + + <!--property TimeoutUSec is not documented!--> + + <!--property DirectoryMode is not documented!--> + + <!--property SloppyOptions is not documented!--> + + <!--property LazyUnmount is not documented!--> + + <!--property ForceUnmount is not documented!--> + + <!--property ReadWriteOnly is not documented!--> + + <!--property UID is not documented!--> + + <!--property GID is not documented!--> + + <!--property ExecUnmount is not documented!--> + + <!--property ExecRemount is not documented!--> + + <!--property Slice is not documented!--> + + <!--property MemoryCurrent is not documented!--> + + <!--property CPUUsageNSec is not documented!--> + + <!--property EffectiveCPUs is not documented!--> + + <!--property EffectiveMemoryNodes is not documented!--> + + <!--property TasksCurrent is not documented!--> + + <!--property IPIngressBytes is not documented!--> + + <!--property IPIngressPackets is not documented!--> + + <!--property IPEgressBytes is not documented!--> + + <!--property IPEgressPackets is not documented!--> + + <!--property IOReadBytes is not documented!--> + + <!--property IOReadOperations is not documented!--> + + <!--property IOWriteBytes is not documented!--> + + <!--property IOWriteOperations is not documented!--> + + <!--property Delegate is not documented!--> + + <!--property DelegateControllers is not documented!--> + + <!--property CPUAccounting is not documented!--> + + <!--property CPUWeight is not documented!--> + + <!--property StartupCPUWeight is not documented!--> + + <!--property CPUShares is not documented!--> + + <!--property StartupCPUShares is not documented!--> + + <!--property CPUQuotaPerSecUSec is not documented!--> + + <!--property CPUQuotaPeriodUSec is not documented!--> + + <!--property AllowedCPUs is not documented!--> + + <!--property AllowedMemoryNodes is not documented!--> + + <!--property IOAccounting is not documented!--> + + <!--property IOWeight is not documented!--> + + <!--property StartupIOWeight is not documented!--> + + <!--property IODeviceWeight is not documented!--> + + <!--property IOReadBandwidthMax is not documented!--> + + <!--property IOWriteBandwidthMax is not documented!--> + + <!--property IOReadIOPSMax is not documented!--> + + <!--property IOWriteIOPSMax is not documented!--> + + <!--property IODeviceLatencyTargetUSec is not documented!--> + + <!--property BlockIOAccounting is not documented!--> + + <!--property BlockIOWeight is not documented!--> + + <!--property StartupBlockIOWeight is not documented!--> + + <!--property BlockIODeviceWeight is not documented!--> + + <!--property BlockIOReadBandwidth is not documented!--> + + <!--property BlockIOWriteBandwidth is not documented!--> + + <!--property MemoryAccounting is not documented!--> + + <!--property DefaultMemoryLow is not documented!--> + + <!--property DefaultMemoryMin is not documented!--> + + <!--property MemoryMin is not documented!--> + + <!--property MemoryLow is not documented!--> + + <!--property MemoryHigh is not documented!--> + + <!--property MemoryMax is not documented!--> + + <!--property MemorySwapMax is not documented!--> + + <!--property MemoryLimit is not documented!--> + + <!--property DevicePolicy is not documented!--> + + <!--property DeviceAllow is not documented!--> + + <!--property TasksAccounting is not documented!--> + + <!--property TasksMax is not documented!--> + + <!--property IPAccounting is not documented!--> + + <!--property IPAddressAllow is not documented!--> + + <!--property IPAddressDeny is not documented!--> + + <!--property IPIngressFilterPath is not documented!--> + + <!--property IPEgressFilterPath is not documented!--> + + <!--property DisableControllers is not documented!--> + + <!--property ManagedOOMSwap is not documented!--> + + <!--property ManagedOOMMemoryPressure is not documented!--> + + <!--property ManagedOOMMemoryPressureLimitPercent is not documented!--> + + <!--property EnvironmentFiles is not documented!--> + + <!--property PassEnvironment is not documented!--> + + <!--property UnsetEnvironment is not documented!--> + + <!--property UMask is not documented!--> + + <!--property LimitCPUSoft is not documented!--> + + <!--property LimitFSIZE is not documented!--> + + <!--property LimitFSIZESoft is not documented!--> + + <!--property LimitDATA is not documented!--> + + <!--property LimitDATASoft is not documented!--> + + <!--property LimitSTACK is not documented!--> + + <!--property LimitSTACKSoft is not documented!--> + + <!--property LimitCORE is not documented!--> + + <!--property LimitCORESoft is not documented!--> + + <!--property LimitRSS is not documented!--> + + <!--property LimitRSSSoft is not documented!--> + + <!--property LimitNOFILE is not documented!--> + + <!--property LimitNOFILESoft is not documented!--> + + <!--property LimitAS is not documented!--> + + <!--property LimitASSoft is not documented!--> + + <!--property LimitNPROC is not documented!--> + + <!--property LimitNPROCSoft is not documented!--> + + <!--property LimitMEMLOCK is not documented!--> + + <!--property LimitMEMLOCKSoft is not documented!--> + + <!--property LimitLOCKS is not documented!--> + + <!--property LimitLOCKSSoft is not documented!--> + + <!--property LimitSIGPENDING is not documented!--> + + <!--property LimitSIGPENDINGSoft is not documented!--> + + <!--property LimitMSGQUEUE is not documented!--> + + <!--property LimitMSGQUEUESoft is not documented!--> + + <!--property LimitNICE is not documented!--> + + <!--property LimitNICESoft is not documented!--> + + <!--property LimitRTPRIO is not documented!--> + + <!--property LimitRTPRIOSoft is not documented!--> + + <!--property LimitRTTIME is not documented!--> + + <!--property LimitRTTIMESoft is not documented!--> + + <!--property WorkingDirectory is not documented!--> + + <!--property RootDirectory is not documented!--> + + <!--property RootImage is not documented!--> + + <!--property RootImageOptions is not documented!--> + + <!--property RootHash is not documented!--> + + <!--property RootHashPath is not documented!--> + + <!--property RootHashSignature is not documented!--> + + <!--property RootHashSignaturePath is not documented!--> + + <!--property RootVerity is not documented!--> + + <!--property MountImages is not documented!--> + + <!--property OOMScoreAdjust is not documented!--> + + <!--property CoredumpFilter is not documented!--> + + <!--property Nice is not documented!--> + + <!--property IOSchedulingClass is not documented!--> + + <!--property IOSchedulingPriority is not documented!--> + + <!--property CPUSchedulingPolicy is not documented!--> + + <!--property CPUSchedulingPriority is not documented!--> + + <!--property CPUAffinity is not documented!--> + + <!--property CPUAffinityFromNUMA is not documented!--> + + <!--property NUMAPolicy is not documented!--> + + <!--property NUMAMask is not documented!--> + + <!--property TimerSlackNSec is not documented!--> + + <!--property CPUSchedulingResetOnFork is not documented!--> + + <!--property NonBlocking is not documented!--> + + <!--property StandardInput is not documented!--> + + <!--property StandardInputFileDescriptorName is not documented!--> + + <!--property StandardInputData is not documented!--> + + <!--property StandardOutput is not documented!--> + + <!--property StandardOutputFileDescriptorName is not documented!--> + + <!--property StandardError is not documented!--> + + <!--property StandardErrorFileDescriptorName is not documented!--> + + <!--property TTYPath is not documented!--> + + <!--property TTYReset is not documented!--> + + <!--property TTYVHangup is not documented!--> + + <!--property TTYVTDisallocate is not documented!--> + + <!--property SyslogPriority is not documented!--> + + <!--property SyslogIdentifier is not documented!--> + + <!--property SyslogLevelPrefix is not documented!--> + + <!--property SyslogLevel is not documented!--> + + <!--property SyslogFacility is not documented!--> + + <!--property LogLevelMax is not documented!--> + + <!--property LogRateLimitIntervalUSec is not documented!--> + + <!--property LogRateLimitBurst is not documented!--> + + <!--property LogExtraFields is not documented!--> + + <!--property LogNamespace is not documented!--> + + <!--property AmbientCapabilities is not documented!--> + + <!--property User is not documented!--> + + <!--property Group is not documented!--> + + <!--property DynamicUser is not documented!--> + + <!--property RemoveIPC is not documented!--> + + <!--property SetCredential is not documented!--> + + <!--property LoadCredential is not documented!--> + + <!--property SupplementaryGroups is not documented!--> + + <!--property PAMName is not documented!--> + + <!--property ReadWritePaths is not documented!--> + + <!--property ReadOnlyPaths is not documented!--> + + <!--property InaccessiblePaths is not documented!--> + + <!--property PrivateTmp is not documented!--> + + <!--property PrivateDevices is not documented!--> + + <!--property ProtectClock is not documented!--> + + <!--property ProtectKernelTunables is not documented!--> + + <!--property ProtectKernelModules is not documented!--> + + <!--property ProtectKernelLogs is not documented!--> + + <!--property ProtectControlGroups is not documented!--> + + <!--property PrivateNetwork is not documented!--> + + <!--property PrivateUsers is not documented!--> + + <!--property PrivateMounts is not documented!--> + + <!--property ProtectHome is not documented!--> + + <!--property ProtectSystem is not documented!--> + + <!--property SameProcessGroup is not documented!--> + + <!--property UtmpIdentifier is not documented!--> + + <!--property UtmpMode is not documented!--> + + <!--property SELinuxContext is not documented!--> + + <!--property AppArmorProfile is not documented!--> + + <!--property SmackProcessLabel is not documented!--> + + <!--property IgnoreSIGPIPE is not documented!--> + + <!--property NoNewPrivileges is not documented!--> + + <!--property SystemCallFilter is not documented!--> + + <!--property SystemCallArchitectures is not documented!--> + + <!--property SystemCallErrorNumber is not documented!--> + + <!--property SystemCallLog is not documented!--> + + <!--property Personality is not documented!--> + + <!--property LockPersonality is not documented!--> + + <!--property RestrictAddressFamilies is not documented!--> + + <!--property RuntimeDirectoryPreserve is not documented!--> + + <!--property RuntimeDirectoryMode is not documented!--> + + <!--property RuntimeDirectory is not documented!--> + + <!--property StateDirectoryMode is not documented!--> + + <!--property StateDirectory is not documented!--> + + <!--property CacheDirectoryMode is not documented!--> + + <!--property CacheDirectory is not documented!--> + + <!--property LogsDirectoryMode is not documented!--> + + <!--property LogsDirectory is not documented!--> + + <!--property ConfigurationDirectoryMode is not documented!--> + + <!--property ConfigurationDirectory is not documented!--> + + <!--property TimeoutCleanUSec is not documented!--> + + <!--property MemoryDenyWriteExecute is not documented!--> + + <!--property RestrictRealtime is not documented!--> + + <!--property RestrictSUIDSGID is not documented!--> + + <!--property RestrictNamespaces is not documented!--> + + <!--property BindPaths is not documented!--> + + <!--property BindReadOnlyPaths is not documented!--> + + <!--property TemporaryFileSystem is not documented!--> + + <!--property MountAPIVFS is not documented!--> + + <!--property KeyringMode is not documented!--> + + <!--property ProtectProc is not documented!--> + + <!--property ProcSubset is not documented!--> + + <!--property ProtectHostname is not documented!--> + + <!--property NetworkNamespacePath is not documented!--> + + <!--property KillMode is not documented!--> + + <!--property KillSignal is not documented!--> + + <!--property RestartKillSignal is not documented!--> + + <!--property FinalKillSignal is not documented!--> + + <!--property SendSIGKILL is not documented!--> + + <!--property SendSIGHUP is not documented!--> + + <!--property WatchdogSignal is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Mount"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Mount"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Where"/> + + <variablelist class="dbus-property" generated="True" extra-ref="What"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Options"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Type"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SloppyOptions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LazyUnmount"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ForceUnmount"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadWriteOnly"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecMount"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecUnmount"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecRemount"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimitPercent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Environment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Nice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/> + + <variablelist class="dbus-property" generated="True" extra-ref="User"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Group"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Personality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most of the properties map directly to the corresponding settings in mount unit files. As mount + units invoke the <filename>/usr/bin/mount</filename> command, their bus objects include implicit + <varname>ExecMount</varname> (and similar) fields which contain information about processes to + execute. They also share most of the fields related to the execution context that Service objects + expose (see above). In addition to these properties there are the following:</para> + + <para><varname>ControlPID</varname> contains the PID of the currently running + <filename>/usr/bin/mount</filename> or <filename>/usr/bin/umount</filename> command if there is one + running, otherwise 0.</para> + + <para><varname>Result</varname> contains a value explaining why a mount unit failed if it failed. It + can take the values <literal>success</literal>, <literal>resources</literal>, + <literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>, or + <literal>core-dump</literal> which have the identical meaning as the corresponding values of the + corresponding field of service unit objects (see above).</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Automount Unit Objects</title> + + <para>All automount unit objects implement the + <interfacename>org.freedesktop.systemd1.Automount</interfacename> interface (described here) in addition + to the generic <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount" interface="org.freedesktop.systemd1.Automount"> +node /org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount { + interface org.freedesktop.systemd1.Automount { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Where = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutIdleUSec = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--property Where is not documented!--> + + <!--property DirectoryMode is not documented!--> + + <!--property TimeoutIdleUSec is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Automount"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Automount"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Where"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutIdleUSec"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most of the properties map directly to the corresponding settings in the automount unit + files.</para> + + <para><varname>Result</varname> knows the values <literal>success</literal> and + <literal>resources</literal> at this time. They have the same meanings as the corresponding values of + the corresponding field of the Service object.</para> + </refsect2> + </refsect1> + + + <refsect1> + <title>Timer Unit Objects</title> + + <para>All timer unit objects implement the <interfacename>org.freedesktop.systemd1.Timer</interfacename> + interface (described here) in addition to the generic + <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer" interface="org.freedesktop.systemd1.Timer"> +node /org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer { + interface org.freedesktop.systemd1.Timer { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Unit = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(stt) TimersMonotonic = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sst) TimersCalendar = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b OnClockChange = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b OnTimezoneChange = ...; + readonly t NextElapseUSecRealtime = ...; + readonly t NextElapseUSecMonotonic = ...; + readonly t LastTriggerUSec = ...; + readonly t LastTriggerUSecMonotonic = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AccuracyUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RandomizedDelayUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b FixedRandomDelay = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Persistent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b WakeSystem = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemainAfterElapse = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--property OnClockChange is not documented!--> + + <!--property OnTimezoneChange is not documented!--> + + <!--property LastTriggerUSec is not documented!--> + + <!--property LastTriggerUSecMonotonic is not documented!--> + + <!--property AccuracyUSec is not documented!--> + + <!--property RandomizedDelayUSec is not documented!--> + + <!--property FixedRandomDelay is not documented!--> + + <!--property Persistent is not documented!--> + + <!--property WakeSystem is not documented!--> + + <!--property RemainAfterElapse is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Timer"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Timer"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Unit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimersMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimersCalendar"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OnClockChange"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OnTimezoneChange"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NextElapseUSecRealtime"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NextElapseUSecMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LastTriggerUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LastTriggerUSecMonotonic"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AccuracyUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RandomizedDelayUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FixedRandomDelay"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Persistent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WakeSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemainAfterElapse"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para><varname>Unit</varname> contains the name of the unit to activate when the timer elapses.</para> + + <para><varname>TimersMonotonic</varname> contains an array of structs that contain information about + all monotonic timers of this timer unit. The structs contain a string identifying the timer base, which + is one of <literal>OnActiveUSec</literal>, <literal>OnBootUSec</literal>, + <literal>OnStartupUSec</literal>, <literal>OnUnitActiveUSec</literal>, or + <literal>OnUnitInactiveUSec</literal> which correspond to the settings of the same names in the timer + unit files; the microsecond offset from this timer base in monotonic time; the next elapsation point on + the <constant>CLOCK_MONOTONIC</constant> clock, relative to its epoch.</para> + + <para><varname>TimersCalendar</varname> contains an array of structs that contain information about all + realtime/calendar timers of this timer unit. The structs contain a string identifying the timer base, + which may only be <literal>OnCalendar</literal> for now; the calendar specification string; the next + elapsation point on the <constant>CLOCK_REALTIME</constant> clock, relative to its epoch.</para> + + <para><varname>NextElapseUSecRealtime</varname> contains the next elapsation point on the + <constant>CLOCK_REALTIME</constant> clock in miscroseconds since the epoch, or 0 if this timer event + does not include at least one calendar event.</para> + + <para>Similarly, <varname>NextElapseUSecMonotonic</varname> contains the next elapsation point on the + <constant>CLOCK_MONOTONIC</constant> clock in microseconds since the epoch, or 0 if this timer event + does not include at least one monotonic event.</para> + + <para><varname>Result</varname> knows the values <literal>success</literal> and + <literal>resources</literal> with the same meanings as the matching values of the corresponding + property of the service interface.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Swap Unit Objects</title> + + <para>All swap unit objects implement the <interfacename>org.freedesktop.systemd1.Swap</interfacename> + interface (described here) in addition to the generic + <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/dev_2dsda3_2eswap" interface="org.freedesktop.systemd1.Swap"> +node /org/freedesktop/systemd1/unit/dev_2dsda3_2eswap { + interface org.freedesktop.systemd1.Swap { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + readonly s What = '...'; + readonly i Priority = ...; + readonly s Options = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutUSec = ...; + readonly u ControlPID = ...; + readonly s Result = '...'; + readonly u UID = ...; + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecActivate = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecDeactivate = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressureLimitPercent = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--method GetProcesses is not documented!--> + + <!--method AttachProcesses is not documented!--> + + <!--property What is not documented!--> + + <!--property Priority is not documented!--> + + <!--property Options is not documented!--> + + <!--property TimeoutUSec is not documented!--> + + <!--property UID is not documented!--> + + <!--property GID is not documented!--> + + <!--property ExecDeactivate is not documented!--> + + <!--property Slice is not documented!--> + + <!--property MemoryCurrent is not documented!--> + + <!--property CPUUsageNSec is not documented!--> + + <!--property EffectiveCPUs is not documented!--> + + <!--property EffectiveMemoryNodes is not documented!--> + + <!--property TasksCurrent is not documented!--> + + <!--property IPIngressBytes is not documented!--> + + <!--property IPIngressPackets is not documented!--> + + <!--property IPEgressBytes is not documented!--> + + <!--property IPEgressPackets is not documented!--> + + <!--property IOReadBytes is not documented!--> + + <!--property IOReadOperations is not documented!--> + + <!--property IOWriteBytes is not documented!--> + + <!--property IOWriteOperations is not documented!--> + + <!--property Delegate is not documented!--> + + <!--property DelegateControllers is not documented!--> + + <!--property CPUAccounting is not documented!--> + + <!--property CPUWeight is not documented!--> + + <!--property StartupCPUWeight is not documented!--> + + <!--property CPUShares is not documented!--> + + <!--property StartupCPUShares is not documented!--> + + <!--property CPUQuotaPerSecUSec is not documented!--> + + <!--property CPUQuotaPeriodUSec is not documented!--> + + <!--property AllowedCPUs is not documented!--> + + <!--property AllowedMemoryNodes is not documented!--> + + <!--property IOAccounting is not documented!--> + + <!--property IOWeight is not documented!--> + + <!--property StartupIOWeight is not documented!--> + + <!--property IODeviceWeight is not documented!--> + + <!--property IOReadBandwidthMax is not documented!--> + + <!--property IOWriteBandwidthMax is not documented!--> + + <!--property IOReadIOPSMax is not documented!--> + + <!--property IOWriteIOPSMax is not documented!--> + + <!--property IODeviceLatencyTargetUSec is not documented!--> + + <!--property BlockIOAccounting is not documented!--> + + <!--property BlockIOWeight is not documented!--> + + <!--property StartupBlockIOWeight is not documented!--> + + <!--property BlockIODeviceWeight is not documented!--> + + <!--property BlockIOReadBandwidth is not documented!--> + + <!--property BlockIOWriteBandwidth is not documented!--> + + <!--property MemoryAccounting is not documented!--> + + <!--property DefaultMemoryLow is not documented!--> + + <!--property DefaultMemoryMin is not documented!--> + + <!--property MemoryMin is not documented!--> + + <!--property MemoryLow is not documented!--> + + <!--property MemoryHigh is not documented!--> + + <!--property MemoryMax is not documented!--> + + <!--property MemorySwapMax is not documented!--> + + <!--property MemoryLimit is not documented!--> + + <!--property DevicePolicy is not documented!--> + + <!--property DeviceAllow is not documented!--> + + <!--property TasksAccounting is not documented!--> + + <!--property TasksMax is not documented!--> + + <!--property IPAccounting is not documented!--> + + <!--property IPAddressAllow is not documented!--> + + <!--property IPAddressDeny is not documented!--> + + <!--property IPIngressFilterPath is not documented!--> + + <!--property IPEgressFilterPath is not documented!--> + + <!--property DisableControllers is not documented!--> + + <!--property ManagedOOMSwap is not documented!--> + + <!--property ManagedOOMMemoryPressure is not documented!--> + + <!--property ManagedOOMMemoryPressureLimitPercent is not documented!--> + + <!--property EnvironmentFiles is not documented!--> + + <!--property PassEnvironment is not documented!--> + + <!--property UnsetEnvironment is not documented!--> + + <!--property UMask is not documented!--> + + <!--property LimitCPUSoft is not documented!--> + + <!--property LimitFSIZE is not documented!--> + + <!--property LimitFSIZESoft is not documented!--> + + <!--property LimitDATA is not documented!--> + + <!--property LimitDATASoft is not documented!--> + + <!--property LimitSTACK is not documented!--> + + <!--property LimitSTACKSoft is not documented!--> + + <!--property LimitCORE is not documented!--> + + <!--property LimitCORESoft is not documented!--> + + <!--property LimitRSS is not documented!--> + + <!--property LimitRSSSoft is not documented!--> + + <!--property LimitNOFILE is not documented!--> + + <!--property LimitNOFILESoft is not documented!--> + + <!--property LimitAS is not documented!--> + + <!--property LimitASSoft is not documented!--> + + <!--property LimitNPROC is not documented!--> + + <!--property LimitNPROCSoft is not documented!--> + + <!--property LimitMEMLOCK is not documented!--> + + <!--property LimitMEMLOCKSoft is not documented!--> + + <!--property LimitLOCKS is not documented!--> + + <!--property LimitLOCKSSoft is not documented!--> + + <!--property LimitSIGPENDING is not documented!--> + + <!--property LimitSIGPENDINGSoft is not documented!--> + + <!--property LimitMSGQUEUE is not documented!--> + + <!--property LimitMSGQUEUESoft is not documented!--> + + <!--property LimitNICE is not documented!--> + + <!--property LimitNICESoft is not documented!--> + + <!--property LimitRTPRIO is not documented!--> + + <!--property LimitRTPRIOSoft is not documented!--> + + <!--property LimitRTTIME is not documented!--> + + <!--property LimitRTTIMESoft is not documented!--> + + <!--property WorkingDirectory is not documented!--> + + <!--property RootDirectory is not documented!--> + + <!--property RootImage is not documented!--> + + <!--property RootImageOptions is not documented!--> + + <!--property RootHash is not documented!--> + + <!--property RootHashPath is not documented!--> + + <!--property RootHashSignature is not documented!--> + + <!--property RootHashSignaturePath is not documented!--> + + <!--property RootVerity is not documented!--> + + <!--property MountImages is not documented!--> + + <!--property OOMScoreAdjust is not documented!--> + + <!--property CoredumpFilter is not documented!--> + + <!--property Nice is not documented!--> + + <!--property IOSchedulingClass is not documented!--> + + <!--property IOSchedulingPriority is not documented!--> + + <!--property CPUSchedulingPolicy is not documented!--> + + <!--property CPUSchedulingPriority is not documented!--> + + <!--property CPUAffinity is not documented!--> + + <!--property CPUAffinityFromNUMA is not documented!--> + + <!--property NUMAPolicy is not documented!--> + + <!--property NUMAMask is not documented!--> + + <!--property TimerSlackNSec is not documented!--> + + <!--property CPUSchedulingResetOnFork is not documented!--> + + <!--property NonBlocking is not documented!--> + + <!--property StandardInput is not documented!--> + + <!--property StandardInputFileDescriptorName is not documented!--> + + <!--property StandardInputData is not documented!--> + + <!--property StandardOutput is not documented!--> + + <!--property StandardOutputFileDescriptorName is not documented!--> + + <!--property StandardError is not documented!--> + + <!--property StandardErrorFileDescriptorName is not documented!--> + + <!--property TTYPath is not documented!--> + + <!--property TTYReset is not documented!--> + + <!--property TTYVHangup is not documented!--> + + <!--property TTYVTDisallocate is not documented!--> + + <!--property SyslogPriority is not documented!--> + + <!--property SyslogIdentifier is not documented!--> + + <!--property SyslogLevelPrefix is not documented!--> + + <!--property SyslogLevel is not documented!--> + + <!--property SyslogFacility is not documented!--> + + <!--property LogLevelMax is not documented!--> + + <!--property LogRateLimitIntervalUSec is not documented!--> + + <!--property LogRateLimitBurst is not documented!--> + + <!--property LogExtraFields is not documented!--> + + <!--property LogNamespace is not documented!--> + + <!--property AmbientCapabilities is not documented!--> + + <!--property User is not documented!--> + + <!--property Group is not documented!--> + + <!--property DynamicUser is not documented!--> + + <!--property RemoveIPC is not documented!--> + + <!--property SetCredential is not documented!--> + + <!--property LoadCredential is not documented!--> + + <!--property SupplementaryGroups is not documented!--> + + <!--property PAMName is not documented!--> + + <!--property ReadWritePaths is not documented!--> + + <!--property ReadOnlyPaths is not documented!--> + + <!--property InaccessiblePaths is not documented!--> + + <!--property PrivateTmp is not documented!--> + + <!--property PrivateDevices is not documented!--> + + <!--property ProtectClock is not documented!--> + + <!--property ProtectKernelTunables is not documented!--> + + <!--property ProtectKernelModules is not documented!--> + + <!--property ProtectKernelLogs is not documented!--> + + <!--property ProtectControlGroups is not documented!--> + + <!--property PrivateNetwork is not documented!--> + + <!--property PrivateUsers is not documented!--> + + <!--property PrivateMounts is not documented!--> + + <!--property ProtectHome is not documented!--> + + <!--property ProtectSystem is not documented!--> + + <!--property SameProcessGroup is not documented!--> + + <!--property UtmpIdentifier is not documented!--> + + <!--property UtmpMode is not documented!--> + + <!--property SELinuxContext is not documented!--> + + <!--property AppArmorProfile is not documented!--> + + <!--property SmackProcessLabel is not documented!--> + + <!--property IgnoreSIGPIPE is not documented!--> + + <!--property NoNewPrivileges is not documented!--> + + <!--property SystemCallFilter is not documented!--> + + <!--property SystemCallArchitectures is not documented!--> + + <!--property SystemCallErrorNumber is not documented!--> + + <!--property SystemCallLog is not documented!--> + + <!--property Personality is not documented!--> + + <!--property LockPersonality is not documented!--> + + <!--property RestrictAddressFamilies is not documented!--> + + <!--property RuntimeDirectoryPreserve is not documented!--> + + <!--property RuntimeDirectoryMode is not documented!--> + + <!--property RuntimeDirectory is not documented!--> + + <!--property StateDirectoryMode is not documented!--> + + <!--property StateDirectory is not documented!--> + + <!--property CacheDirectoryMode is not documented!--> + + <!--property CacheDirectory is not documented!--> + + <!--property LogsDirectoryMode is not documented!--> + + <!--property LogsDirectory is not documented!--> + + <!--property ConfigurationDirectoryMode is not documented!--> + + <!--property ConfigurationDirectory is not documented!--> + + <!--property TimeoutCleanUSec is not documented!--> + + <!--property MemoryDenyWriteExecute is not documented!--> + + <!--property RestrictRealtime is not documented!--> + + <!--property RestrictSUIDSGID is not documented!--> + + <!--property RestrictNamespaces is not documented!--> + + <!--property BindPaths is not documented!--> + + <!--property BindReadOnlyPaths is not documented!--> + + <!--property TemporaryFileSystem is not documented!--> + + <!--property MountAPIVFS is not documented!--> + + <!--property KeyringMode is not documented!--> + + <!--property ProtectProc is not documented!--> + + <!--property ProcSubset is not documented!--> + + <!--property ProtectHostname is not documented!--> + + <!--property NetworkNamespacePath is not documented!--> + + <!--property KillMode is not documented!--> + + <!--property KillSignal is not documented!--> + + <!--property RestartKillSignal is not documented!--> + + <!--property FinalKillSignal is not documented!--> + + <!--property SendSIGKILL is not documented!--> + + <!--property SendSIGHUP is not documented!--> + + <!--property WatchdogSignal is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Swap"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Swap"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="What"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Priority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Options"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="GID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecActivate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ExecDeactivate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimitPercent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Environment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/> + + <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Nice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/> + + <variablelist class="dbus-property" generated="True" extra-ref="User"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Group"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/> + + <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Personality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most of the properties map directly to the corresponding settings in swap unit files. As mount + units invoke the + <citerefentry project="man-pages"><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command, + their bus objects include implicit <varname>ExecActivate</varname> (and similar) fields which contain + information about processes to execute. They also share most of the fields related to the execution + context that Service objects expose (see above). In addition to these properties there are the + following:</para> + + <para><varname>ControlPID</varname> contains the PID of the currently running + <citerefentry project="man-pages"><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> or + <citerefentry project="man-pages"><refentrytitle>swapoff</refentrytitle><manvolnum>8</manvolnum></citerefentry> + command if there is one running, otherwise 0.</para> + + <para><varname>Result</varname> contains a value explaining why a mount unit failed if it failed. It + can take the values <literal>success</literal>, <literal>resources</literal>, + <literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>, or + <literal>core-dump</literal> which have the identical meanings as the corresponding values of the + corresponding field of service unit objects (see above).</para> + </refsect2> + </refsect1> + + + <refsect1> + <title>Path Unit Objects</title> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/cups_2epath" interface="org.freedesktop.systemd1.Path"> +node /org/freedesktop/systemd1/unit/cups_2epath { + interface org.freedesktop.systemd1.Path { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Unit = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) Paths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MakeDirectory = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + readonly s Result = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--property MakeDirectory is not documented!--> + + <!--property DirectoryMode is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Path"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Path"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Unit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Paths"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MakeDirectory"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most properties correspond directly with the matching settings in path unit files.</para> + + <para>The others:</para> + + <para><varname>Paths</varname> contains an array of structs. Each struct contains the condition to + watch, which can be one of <literal>PathExists</literal>, <literal>PathExistsGlob</literal>, + <literal>PathChanged</literal>, <literal>PathModified</literal>, or <literal>DirectoryNotEmpty</literal> + which correspond directly to the matching settings in the path unit files; and the path to watch, + possibly including glob expressions.</para> + + <para><varname>Result</varname> contains a result value which can be <literal>success</literal> or + <literal>resources</literal> which have the same meaning as the corresponding field of the Service + interface.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Slice Unit Objects</title> + + <para>All slice unit objects implement the <interfacename>org.freedesktop.systemd1.Slice</interfacename> + interface (described here) in addition to the generic + <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/system_2eslice" interface="org.freedesktop.systemd1.Slice"> +node /org/freedesktop/systemd1/unit/system_2eslice { + interface org.freedesktop.systemd1.Slice { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressureLimitPercent = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--method GetProcesses is not documented!--> + + <!--method AttachProcesses is not documented!--> + + <!--property Slice is not documented!--> + + <!--property MemoryCurrent is not documented!--> + + <!--property CPUUsageNSec is not documented!--> + + <!--property EffectiveCPUs is not documented!--> + + <!--property EffectiveMemoryNodes is not documented!--> + + <!--property TasksCurrent is not documented!--> + + <!--property IPIngressBytes is not documented!--> + + <!--property IPIngressPackets is not documented!--> + + <!--property IPEgressBytes is not documented!--> + + <!--property IPEgressPackets is not documented!--> + + <!--property IOReadBytes is not documented!--> + + <!--property IOReadOperations is not documented!--> + + <!--property IOWriteBytes is not documented!--> + + <!--property IOWriteOperations is not documented!--> + + <!--property Delegate is not documented!--> + + <!--property DelegateControllers is not documented!--> + + <!--property CPUAccounting is not documented!--> + + <!--property CPUWeight is not documented!--> + + <!--property StartupCPUWeight is not documented!--> + + <!--property CPUShares is not documented!--> + + <!--property StartupCPUShares is not documented!--> + + <!--property CPUQuotaPerSecUSec is not documented!--> + + <!--property CPUQuotaPeriodUSec is not documented!--> + + <!--property AllowedCPUs is not documented!--> + + <!--property AllowedMemoryNodes is not documented!--> + + <!--property IOAccounting is not documented!--> + + <!--property IOWeight is not documented!--> + + <!--property StartupIOWeight is not documented!--> + + <!--property IODeviceWeight is not documented!--> + + <!--property IOReadBandwidthMax is not documented!--> + + <!--property IOWriteBandwidthMax is not documented!--> + + <!--property IOReadIOPSMax is not documented!--> + + <!--property IOWriteIOPSMax is not documented!--> + + <!--property IODeviceLatencyTargetUSec is not documented!--> + + <!--property BlockIOAccounting is not documented!--> + + <!--property BlockIOWeight is not documented!--> + + <!--property StartupBlockIOWeight is not documented!--> + + <!--property BlockIODeviceWeight is not documented!--> + + <!--property BlockIOReadBandwidth is not documented!--> + + <!--property BlockIOWriteBandwidth is not documented!--> + + <!--property MemoryAccounting is not documented!--> + + <!--property DefaultMemoryLow is not documented!--> + + <!--property DefaultMemoryMin is not documented!--> + + <!--property MemoryMin is not documented!--> + + <!--property MemoryLow is not documented!--> + + <!--property MemoryHigh is not documented!--> + + <!--property MemoryMax is not documented!--> + + <!--property MemorySwapMax is not documented!--> + + <!--property MemoryLimit is not documented!--> + + <!--property DevicePolicy is not documented!--> + + <!--property DeviceAllow is not documented!--> + + <!--property TasksAccounting is not documented!--> + + <!--property TasksMax is not documented!--> + + <!--property IPAccounting is not documented!--> + + <!--property IPAddressAllow is not documented!--> + + <!--property IPAddressDeny is not documented!--> + + <!--property IPIngressFilterPath is not documented!--> + + <!--property IPEgressFilterPath is not documented!--> + + <!--property DisableControllers is not documented!--> + + <!--property ManagedOOMSwap is not documented!--> + + <!--property ManagedOOMMemoryPressure is not documented!--> + + <!--property ManagedOOMMemoryPressureLimitPercent is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Slice"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Slice"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimitPercent"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Properties</title> + + <para>Most properties correspond directly with the matching settings in slice unit files.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Scope Unit Objects</title> + + <para>All scope unit objects implement the <interfacename>org.freedesktop.systemd1.Scope</interfacename> + interface (described here) in addition to the generic + <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/session_2d1_2escope" interface="org.freedesktop.systemd1.Scope"> +node /org/freedesktop/systemd1/unit/session_2d1_2escope { + interface org.freedesktop.systemd1.Scope { + methods: + Abandon(); + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + signals: + RequestStop(); + properties: + readonly s Controller = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutStopUSec = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeMaxUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressureLimitPercent = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + </programlisting> + + <!--method GetProcesses is not documented!--> + + <!--method AttachProcesses is not documented!--> + + <!--property RuntimeMaxUSec is not documented!--> + + <!--property Slice is not documented!--> + + <!--property MemoryCurrent is not documented!--> + + <!--property CPUUsageNSec is not documented!--> + + <!--property EffectiveCPUs is not documented!--> + + <!--property EffectiveMemoryNodes is not documented!--> + + <!--property TasksCurrent is not documented!--> + + <!--property IPIngressBytes is not documented!--> + + <!--property IPIngressPackets is not documented!--> + + <!--property IPEgressBytes is not documented!--> + + <!--property IPEgressPackets is not documented!--> + + <!--property IOReadBytes is not documented!--> + + <!--property IOReadOperations is not documented!--> + + <!--property IOWriteBytes is not documented!--> + + <!--property IOWriteOperations is not documented!--> + + <!--property Delegate is not documented!--> + + <!--property DelegateControllers is not documented!--> + + <!--property CPUAccounting is not documented!--> + + <!--property CPUWeight is not documented!--> + + <!--property StartupCPUWeight is not documented!--> + + <!--property CPUShares is not documented!--> + + <!--property StartupCPUShares is not documented!--> + + <!--property CPUQuotaPerSecUSec is not documented!--> + + <!--property CPUQuotaPeriodUSec is not documented!--> + + <!--property AllowedCPUs is not documented!--> + + <!--property AllowedMemoryNodes is not documented!--> + + <!--property IOAccounting is not documented!--> + + <!--property IOWeight is not documented!--> + + <!--property StartupIOWeight is not documented!--> + + <!--property IODeviceWeight is not documented!--> + + <!--property IOReadBandwidthMax is not documented!--> + + <!--property IOWriteBandwidthMax is not documented!--> + + <!--property IOReadIOPSMax is not documented!--> + + <!--property IOWriteIOPSMax is not documented!--> + + <!--property IODeviceLatencyTargetUSec is not documented!--> + + <!--property BlockIOAccounting is not documented!--> + + <!--property BlockIOWeight is not documented!--> + + <!--property StartupBlockIOWeight is not documented!--> + + <!--property BlockIODeviceWeight is not documented!--> + + <!--property BlockIOReadBandwidth is not documented!--> + + <!--property BlockIOWriteBandwidth is not documented!--> + + <!--property MemoryAccounting is not documented!--> + + <!--property DefaultMemoryLow is not documented!--> + + <!--property DefaultMemoryMin is not documented!--> + + <!--property MemoryMin is not documented!--> + + <!--property MemoryLow is not documented!--> + + <!--property MemoryHigh is not documented!--> + + <!--property MemoryMax is not documented!--> + + <!--property MemorySwapMax is not documented!--> + + <!--property MemoryLimit is not documented!--> + + <!--property DevicePolicy is not documented!--> + + <!--property DeviceAllow is not documented!--> + + <!--property TasksAccounting is not documented!--> + + <!--property TasksMax is not documented!--> + + <!--property IPAccounting is not documented!--> + + <!--property IPAddressAllow is not documented!--> + + <!--property IPAddressDeny is not documented!--> + + <!--property IPIngressFilterPath is not documented!--> + + <!--property IPEgressFilterPath is not documented!--> + + <!--property DisableControllers is not documented!--> + + <!--property ManagedOOMSwap is not documented!--> + + <!--property ManagedOOMMemoryPressure is not documented!--> + + <!--property ManagedOOMMemoryPressureLimitPercent is not documented!--> + + <!--property KillMode is not documented!--> + + <!--property KillSignal is not documented!--> + + <!--property RestartKillSignal is not documented!--> + + <!--property FinalKillSignal is not documented!--> + + <!--property SendSIGKILL is not documented!--> + + <!--property SendSIGHUP is not documented!--> + + <!--property WatchdogSignal is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Scope"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Scope"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Abandon()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/> + + <variablelist class="dbus-signal" generated="True" extra-ref="RequestStop"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Controller"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStopUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Result"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RuntimeMaxUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Slice"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/> + + <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/> + + <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/> + + <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimitPercent"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/> + + <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/> + + <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Abandon()</function> may be used to place a scope unit in the "abandoned" state. This + may be used to inform the system manager that the manager that created the scope lost interest in the + scope (for example, because it is terminating), without wanting to shut down the scope entirely.</para> + </refsect2> + + <refsect2> + <title>Signals</title> + + <para><function>RequestStop</function> is sent to the peer that is configured in the + <varname>Controller</varname> property when systemd is requested to terminate the scope unit. A program + registering a scope can use this to cleanly shut down the processes it added to the scope instead of + letting systemd do it with the usual <constant>SIGTERM</constant> logic.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para>All properties correspond directly with the matching properties of service units.</para> + + <para><varname>Controller</varname> contains the bus name (unique or well-known) that is notified when + the scope unit is to be shut down via a <function>RequestStop</function> signal (see below). This is + set when the scope is created. If not set, the scope's processes will terminated with + <constant>SIGTERM</constant> directly.</para> + </refsect2> + </refsect1> + + + <refsect1> + <title>Job Objects</title> + + <para>Job objects encapsulate scheduled or running jobs. Each unit can have none or one jobs in the + execution queue. Each job is attached to exactly one unit.</para> + + <programlisting executable="systemd" node="/org/freedesktop/systemd1/job/666" interface="org.freedesktop.systemd1.Job"> +node /org/freedesktop/systemd1/job/666 { + interface org.freedesktop.systemd1.Job { + methods: + Cancel(); + GetAfter(out a(usssoo) jobs); + GetBefore(out a(usssoo) jobs); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Id = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (so) Unit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s JobType = '...'; + readonly s State = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--method GetAfter is not documented!--> + + <!--method GetBefore is not documented!--> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Job"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Job"/> + + <variablelist class="dbus-method" generated="True" extra-ref="Cancel()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetAfter()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="GetBefore()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Id"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Unit"/> + + <variablelist class="dbus-property" generated="True" extra-ref="JobType"/> + + <variablelist class="dbus-property" generated="True" extra-ref="State"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para><function>Cancel()</function> cancels the job. Note that this will remove a job from the queue if + it is not yet executed but generally will not cause a job that is already in the process of being + executed to be aborted. This operation may also be requested via the <function>CancelJob()</function> + method of the Manager object (see above), which is sometimes useful to reduce roundtrips.</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>Id</varname> is the numeric Id of the job. During the runtime of a systemd instance each + numeric ID is only assigned once.</para> + + <para><varname>Unit</varname> refers to the unit this job belongs to. It is a structure consisting of + the name of the unit and a bus path to the unit's object.</para> + + <para><varname>JobType</varname> refers to the job's type and is one of <literal>start</literal>, + <literal>verify-active</literal>, <literal>stop</literal>, <literal>reload</literal>, + <literal>restart</literal>, <literal>try-restart</literal>, or <literal>reload-or-start</literal>. Note + that later versions might define additional values.</para> + + <para><varname>State</varname> refers to the job's state and is one of <literal>waiting</literal> and + <literal>running</literal>. The former indicates that a job is currently queued but has not begun to + execute yet. The latter indicates that a job is currently being executed.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.systemd1.Manager</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.systemd1 \ + --object-path /org/freedesktop/systemd1 + </programlisting> + </example> + + <example> + <title>Introspect a unit on the bus</title> + + <programlisting> +$ busctl introspect org.freedesktop.systemd1 \ + $(busctl call org.freedesktop.systemd1 \ + /org/freedesktop/systemd1 \ + org.freedesktop.systemd1.Manager \ + GetUnit s systemd-resolved.service | cut -d'"' -f2) + </programlisting> + </example> + + <example> + <title>Introspect <interfacename>org.freedesktop.systemd1.Job</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system --dest org.freedesktop.systemd1 \ + --object-path /org/freedesktop/systemd1/job/1292 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> +</refentry> diff --git a/man/org.freedesktop.timedate1.xml b/man/org.freedesktop.timedate1.xml new file mode 100644 index 0000000..52efa68 --- /dev/null +++ b/man/org.freedesktop.timedate1.xml @@ -0,0 +1,205 @@ +<?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-or-later --> + +<refentry id="org.freedesktop.timedate1" conditional='ENABLE_TIMEDATED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>org.freedesktop.timedate1</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>org.freedesktop.timedate1</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>org.freedesktop.timedate1</refname> + <refpurpose>The D-Bus interface of systemd-timedated</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para> + <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is a system service that can be used to control the system time and related settings. This page + describes the D-Bus interface.</para> + </refsect1> + + <refsect1> + <title>The D-Bus API</title> + + <para>The service exposes the following interfaces on the bus:</para> + + <programlisting executable="systemd-timedated" node="/org/freedesktop/timedate1" interface="org.freedesktop.timedate1"> +node /org/freedesktop/timedate1 { + interface org.freedesktop.timedate1 { + methods: + SetTime(in x usec_utc, + in b relative, + in b interactive); + SetTimezone(in s timezone, + in b interactive); + SetLocalRTC(in b local_rtc, + in b fix_system, + in b interactive); + SetNTP(in b use_ntp, + in b interactive); + ListTimezones(out as timezones); + properties: + readonly s Timezone = '...'; + readonly b LocalRTC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CanNTP = ...; + readonly b NTP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b NTPSynchronized = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TimeUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t RTCTimeUSec = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + </programlisting> + + <!--Autogenerated cross-references for systemd.directives, do not edit--> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.timedate1"/> + + <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.timedate1"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetTime()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetTimezone()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetLocalRTC()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="SetNTP()"/> + + <variablelist class="dbus-method" generated="True" extra-ref="ListTimezones()"/> + + <variablelist class="dbus-property" generated="True" extra-ref="Timezone"/> + + <variablelist class="dbus-property" generated="True" extra-ref="LocalRTC"/> + + <variablelist class="dbus-property" generated="True" extra-ref="CanNTP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NTP"/> + + <variablelist class="dbus-property" generated="True" extra-ref="NTPSynchronized"/> + + <variablelist class="dbus-property" generated="True" extra-ref="TimeUSec"/> + + <variablelist class="dbus-property" generated="True" extra-ref="RTCTimeUSec"/> + + <!--End of Autogenerated section--> + + <refsect2> + <title>Methods</title> + + <para>Use <function>SetTime()</function> to change the system clock. Pass a value of microseconds since + the UNIX epoch (1 Jan 1970 UTC). If <varname>relative</varname> is true, the passed usec value will be + added to the current system time. If it is false, the current system time will be set to the passed usec + value. If the system time is set with this method, the RTC will be updated as well.</para> + + <para>Use <function>SetTimezone()</function> to set the system timezone. Pass a value like + <literal>Europe/Berlin</literal> to set the timezone. Valid timezones are listed in + <filename>/usr/share/zoneinfo/zone.tab</filename>. If the RTC is configured to be maintained in local + time, it will be updated accordingly.</para> + + <para>Use <function>SetLocalRTC()</function> to control whether the RTC is in local time or UTC. It is + strongly recommended to maintain the RTC in UTC. However, some OSes (Windows) maintain the RTC in local + time, which might make it necessary to enable this feature. Note that this might create various problems as + daylight changes could be missed. If <varname>fix_system</varname> is <literal>true</literal>, + the time from the RTC is read again and the system clock is adjusted according to the new setting. If + <varname>fix_system</varname> is <literal>false</literal>, the system time is written to the RTC + taking the new setting into account. Use <varname>fix_system=true</varname> in installers and livecds + where the RTC is probably more reliable than the system time. Use <varname>fix_system=false</varname> + in configuration UIs that are run during normal operation and where the system clock is probably more + reliable than the RTC.</para> + + <para>Use <function>SetNTP()</function> to control whether the system clock is synchronized with the + network using <filename>systemd-timesyncd</filename>. This will enable and start or disable and stop + the chosen time synchronization service.</para> + + <para><function>ListTimezones()</function> returns a list of time zones known on the local system as an + array of names (<literal>["Africa/Abidjan", "Africa/Accra", ..., "UTC"]</literal>).</para> + </refsect2> + + <refsect2> + <title>Properties</title> + + <para><varname>Timezone</varname> shows the currently configured time zone. + <varname>LocalRTC</varname> shows whether the RTC is configured to use UTC (false), or the local time + zone (true). <varname>CanNTP</varname> shows whether a service to perform time synchronization over the + network is available, and <varname>NTP</varname> shows whether such a service is enabled.</para> + + <para><varname>NTPSynchronized</varname> shows whether the kernel reports the time as synchronized + (c.f. + <citerefentry project="man-pages"><refentrytitle>adjtimex</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + <varname>TimeUSec</varname> and <varname>RTCTimeUSec</varname> show the current time on the system and + in the RTC. The purpose of those three properties is to allow remote clients to access this information + over D-Bus. Local clients can access the information directly.</para> + + <para>Whenever the <varname>Timezone</varname> and <varname>LocalRTC</varname> settings are changed via + the daemon, <function>PropertyChanged</function> signals are sent out to which clients can subscribe. + </para> + + <para>Note that this service will not inform you about system time changes. Use + <citerefentry project="man-pages"><refentrytitle>timerfd</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with <constant>CLOCK_REALTIME</constant> and <constant>TFD_TIMER_CANCEL_ON_SET</constant> for that. + </para> + </refsect2> + + <refsect2> + <title>Security</title> + + <para>The <varname>interactive</varname> boolean parameters can be used to control whether + <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink> + should interactively ask the user for authentication credentials if required.</para> + + <para>The polkit action for <function>SetTimezone()</function> is + <interfacename>org.freedesktop.timedate1.set-timezone</interfacename>. For + <function>SetLocalRTC()</function> it is + <interfacename>org.freedesktop.timedate1.set-local-rtc</interfacename>, for + <function>SetTime()</function> it is <interfacename>org.freedesktop.timedate1.set-time</interfacename> + and for <function>SetNTP()</function> it is + <interfacename>org.freedesktop.timedate1.set-ntp</interfacename>. + <function>ListTimezones()</function> does not require any privileges. + </para> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Introspect <interfacename>org.freedesktop.timedate1</interfacename> on the bus</title> + + <programlisting> +$ gdbus introspect --system \ + --dest org.freedesktop.timedate1 \ + --object-path /org/freedesktop/timedate1 + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>Versioning</title> + + <para>These D-Bus interfaces follow <ulink url="http://0pointer.de/blog/projects/versioning-dbus.html"> + the usual interface versioning guidelines</ulink>.</para> + </refsect1> + + <refsect1> + <title>See also</title> + + <para><ulink url="https://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html">More information on how the system clock and RTC interact</ulink></para> + </refsect1> +</refentry> diff --git a/man/os-release.xml b/man/os-release.xml new file mode 100644 index 0000000..6741806 --- /dev/null +++ b/man/os-release.xml @@ -0,0 +1,385 @@ +<?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-or-later --> + +<refentry id="os-release"> + <refentryinfo> + <title>os-release</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>os-release</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>os-release</refname> + <refpurpose>Operating system identification</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/os-release</filename></para> + <para><filename>/usr/lib/os-release</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/os-release</filename> and + <filename>/usr/lib/os-release</filename> files contain operating + system identification data.</para> + + <para>The basic file format of <filename>os-release</filename> is + a newline-separated list of environment-like shell-compatible + variable assignments. It is possible to source the configuration + from shell scripts, however, beyond mere variable assignments, no + shell features are supported (this means variable expansion is + explicitly not supported), allowing applications to read the file + without implementing a shell compatible execution engine. Variable + assignment values must be enclosed in double or single quotes if + they include spaces, semicolons or other special characters + outside of A–Z, a–z, 0–9. Shell special characters ("$", quotes, + backslash, backtick) must be escaped with backslashes, following + shell style. All strings should be in UTF-8 format, and + non-printable characters should not be used. It is not supported + to concatenate multiple individually quoted strings. Lines + beginning with "#" shall be ignored as comments. Blank lines are + permitted and ignored.</para> + + <para>The file <filename>/etc/os-release</filename> takes + precedence over <filename>/usr/lib/os-release</filename>. + Applications should check for the former, and exclusively use its + data if it exists, and only fall back to + <filename>/usr/lib/os-release</filename> if it is missing. + Applications should not read data from both files at the same + time. <filename>/usr/lib/os-release</filename> is the recommended + place to store OS release information as part of vendor trees. + <filename>/etc/os-release</filename> should be a relative symlink + to <filename>/usr/lib/os-release</filename>, to provide + compatibility with applications only looking at + <filename>/etc/</filename>. A relative symlink instead of an + absolute symlink is necessary to avoid breaking the link in a + chroot or initrd environment such as dracut.</para> + + <para><filename>os-release</filename> contains data that is + defined by the operating system vendor and should generally not be + changed by the administrator.</para> + + <para>As this file only encodes names and identifiers it should + not be localized.</para> + + <para>The <filename>/etc/os-release</filename> and + <filename>/usr/lib/os-release</filename> files might be symlinks + to other files, but it is important that the file is available + from earliest boot on, and hence must be located on the root file + system.</para> + + <para>For a longer rationale for <filename>os-release</filename> + please refer to the <ulink + url="http://0pointer.de/blog/projects/os-release">Announcement of <filename>/etc/os-release</filename></ulink>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following OS identifications parameters may be set using + <filename>os-release</filename>:</para> + + <variablelist class='environment-variables'> + + <varlistentry> + <term><varname>NAME=</varname></term> + + <listitem><para>A string identifying the operating system, + without a version component, and suitable for presentation to + the user. If not set, defaults to + <literal>NAME=Linux</literal>. Example: + <literal>NAME=Fedora</literal> or <literal>NAME="Debian + GNU/Linux"</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VERSION=</varname></term> + + <listitem><para>A string identifying the operating system + version, excluding any OS name information, possibly including + a release code name, and suitable for presentation to the + user. This field is optional. Example: + <literal>VERSION=17</literal> or <literal>VERSION="17 (Beefy + Miracle)"</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ID=</varname></term> + + <listitem><para>A lower-case string (no spaces or other + characters outside of 0–9, a–z, ".", "_" and "-") identifying + the operating system, excluding any version information and + suitable for processing by scripts or usage in generated + filenames. If not set, defaults to + <literal>ID=linux</literal>. Example: + <literal>ID=fedora</literal> or + <literal>ID=debian</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ID_LIKE=</varname></term> + + <listitem><para>A space-separated list of operating system + identifiers in the same syntax as the <varname>ID=</varname> + setting. It should list identifiers of operating systems that + are closely related to the local operating system in regards + to packaging and programming interfaces, for example listing + one or more OS identifiers the local OS is a derivative from. + An OS should generally only list other OS identifiers it + itself is a derivative of, and not any OSes that are derived + from it, though symmetric relationships are possible. Build + scripts and similar should check this variable if they need to + identify the local operating system and the value of + <varname>ID=</varname> is not recognized. Operating systems + should be listed in order of how closely the local operating + system relates to the listed ones, starting with the closest. + This field is optional. Example: for an operating system with + <literal>ID=centos</literal>, an assignment of + <literal>ID_LIKE="rhel fedora"</literal> would be appropriate. + For an operating system with <literal>ID=ubuntu</literal>, an + assignment of <literal>ID_LIKE=debian</literal> is + appropriate.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VERSION_CODENAME=</varname></term> + + <listitem><para> + A lower-case string (no spaces or other characters outside of + 0–9, a–z, ".", "_" and "-") identifying the operating system + release code name, excluding any OS name information or + release version, and suitable for processing by scripts or + usage in generated filenames. This field is optional and may + not be implemented on all systems. + Examples: + <literal>VERSION_CODENAME=buster</literal>, + <literal>VERSION_CODENAME=xenial</literal> + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VERSION_ID=</varname></term> + + <listitem><para>A lower-case string (mostly numeric, no spaces + or other characters outside of 0–9, a–z, ".", "_" and "-") + identifying the operating system version, excluding any OS + name information or release code name, and suitable for + processing by scripts or usage in generated filenames. This + field is optional. Example: <literal>VERSION_ID=17</literal> + or <literal>VERSION_ID=11.04</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PRETTY_NAME=</varname></term> + + <listitem><para>A pretty operating system name in a format + suitable for presentation to the user. May or may not contain + a release code name or OS version of some kind, as suitable. + If not set, defaults to + <literal>PRETTY_NAME="Linux"</literal>. Example: + <literal>PRETTY_NAME="Fedora 17 (Beefy + Miracle)"</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ANSI_COLOR=</varname></term> + + <listitem><para>A suggested presentation color when showing the OS name on the console. This should + be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting + graphical rendition. This field is optional. Example: <literal>ANSI_COLOR="0;31"</literal> for red, + <literal>ANSI_COLOR="1;34"</literal> for light blue, or + <literal>ANSI_COLOR="0;38;2;60;110;180"</literal> for Fedora blue.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPE_NAME=</varname></term> + + <listitem><para>A CPE name for the operating system, in URI + binding syntax, following the + <ulink url="http://scap.nist.gov/specifications/cpe/">Common + Platform Enumeration Specification</ulink> as proposed by the + NIST. This field is optional. Example: + <literal>CPE_NAME="cpe:/o:fedoraproject:fedora:17"</literal> + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>HOME_URL=</varname></term> + <term><varname>DOCUMENTATION_URL=</varname></term> + <term><varname>SUPPORT_URL=</varname></term> + <term><varname>BUG_REPORT_URL=</varname></term> + <term><varname>PRIVACY_POLICY_URL=</varname></term> + + <listitem><para>Links to resources on the Internet related to + the operating system. + <varname>HOME_URL=</varname> should refer to the homepage of + the operating system, or alternatively some homepage of the + specific version of the operating system. + <varname>DOCUMENTATION_URL=</varname> should refer to the main + documentation page for this operating system. + <varname>SUPPORT_URL=</varname> should refer to the main + support page for the operating system, if there is any. This + is primarily intended for operating systems which vendors + provide support for. <varname>BUG_REPORT_URL=</varname> should + refer to the main bug reporting page for the operating system, + if there is any. This is primarily intended for operating + systems that rely on community QA. + <varname>PRIVACY_POLICY_URL=</varname> should refer to the + main privacy policy page for the operating system, if there is + any. These settings are optional, and providing only some of + these settings is common. These URLs are intended to be + exposed in "About this system" UIs behind links with captions + such as "About this Operating System", "Obtain Support", + "Report a Bug", or "Privacy Policy". The values should be in + <ulink url="https://tools.ietf.org/html/rfc3986">RFC3986 + format</ulink>, and should be <literal>http:</literal> or + <literal>https:</literal> URLs, and possibly + <literal>mailto:</literal> or <literal>tel:</literal>. Only + one URL shall be listed in each setting. If multiple resources + need to be referenced, it is recommended to provide an online + landing page linking all available resources. Examples: + <literal>HOME_URL="https://fedoraproject.org/"</literal> and + <literal>BUG_REPORT_URL="https://bugzilla.redhat.com/"</literal></para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>BUILD_ID=</varname></term> + + <listitem><para>A string uniquely identifying the system image + used as the origin for a distribution (it is not updated with + system updates). The field can be identical between different + VERSION_IDs as BUILD_ID is an only a unique identifier to a + specific version. Distributions that release each update as a + new version would only need to use VERSION_ID as each build is + already distinct based on the VERSION_ID. This field is + optional. Example: <literal>BUILD_ID="2013-03-20.3"</literal> + or <literal>BUILD_ID=201303203</literal>. + + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VARIANT=</varname></term> + + <listitem><para> + A string identifying a specific variant or edition of the + operating system suitable for presentation to the user. This + field may be used to inform the user that the configuration of + this system is subject to a specific divergent set of rules or + default configuration settings. This field is optional and may + not be implemented on all systems. + Examples: + <literal>VARIANT="Server Edition"</literal>, + <literal>VARIANT="Smart Refrigerator Edition"</literal> + Note: this field is for display purposes only. The + <varname>VARIANT_ID</varname> field should be used for making + programmatic decisions. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VARIANT_ID=</varname></term> + + <listitem><para> + A lower-case string (no spaces or other characters outside of + 0–9, a–z, ".", "_" and "-"), identifying a specific variant or + edition of the operating system. This may be interpreted by + other packages in order to determine a divergent default + configuration. This field is optional and may not be + implemented on all systems. + Examples: + <literal>VARIANT_ID=server</literal>, + <literal>VARIANT_ID=embedded</literal> + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LOGO=</varname></term> + + <listitem><para> + A string, specifying the name of an icon as defined by <ulink + url="http://standards.freedesktop.org/icon-theme-spec/latest"> + freedesktop.org Icon Theme Specification</ulink>. This can be + used by graphical applications to display an operating + system's or distributor's logo. This field is optional and + may not necessarily be implemented on all systems. + Examples: + <literal>LOGO=fedora-logo</literal>, + <literal>LOGO=distributor-logo-opensuse</literal> + </para></listitem> + </varlistentry> + + </variablelist> + + <para>If you are reading this file from C code or a shell script + to determine the OS or a specific version of it, use the + <varname>ID</varname> and <varname>VERSION_ID</varname> fields, + possibly with <varname>ID_LIKE</varname> as fallback for + <varname>ID</varname>. When looking for an OS identification + string for presentation to the user use the + <varname>PRETTY_NAME</varname> field.</para> + + <para>Note that operating system vendors may choose not to provide + version information, for example to accommodate for rolling + releases. In this case, <varname>VERSION</varname> and + <varname>VERSION_ID</varname> may be unset. Applications should + not rely on these fields to be set.</para> + + <para>Operating system vendors may extend the file + format and introduce new fields. It is highly + recommended to prefix new fields with an OS specific + name in order to avoid name clashes. Applications + reading this file must ignore unknown fields. Example: + <literal>DEBIAN_BTS="debbugs://bugs.debian.org/"</literal></para> + + <para>Container and sandbox runtime managers may make the host's + identification data available to applications by providing the host's + <filename>/etc/os-release</filename> (if available, otherwise + <filename>/usr/lib/os-release</filename> as a fallback) as + <filename>/run/host/os-release</filename>.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <programlisting>NAME=Fedora +VERSION="32 (Workstation Edition)" +ID=fedora +VERSION_ID=32 +PRETTY_NAME="Fedora 32 (Workstation Edition)" +ANSI_COLOR="0;38;2;60;110;180" +LOGO=fedora-logo-icon +CPE_NAME="cpe:/o:fedoraproject:fedora:32" +HOME_URL="https://fedoraproject.org/" +DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" +SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" +BUG_REPORT_URL="https://bugzilla.redhat.com/" +REDHAT_BUGZILLA_PRODUCT="Fedora" +REDHAT_BUGZILLA_PRODUCT_VERSION=32 +REDHAT_SUPPORT_PRODUCT="Fedora" +REDHAT_SUPPORT_PRODUCT_VERSION=32 +PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" +VARIANT="Workstation Edition" +VARIANT_ID=workstation</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>lsb_release</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/pam_systemd.xml b/man/pam_systemd.xml new file mode 100644 index 0000000..21a2581 --- /dev/null +++ b/man/pam_systemd.xml @@ -0,0 +1,349 @@ +<?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-or-later --> + +<refentry id="pam_systemd" conditional='HAVE_PAM'> + + <refentryinfo> + <title>pam_systemd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>pam_systemd</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>pam_systemd</refname> + <refpurpose>Register user sessions in the systemd login manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>pam_systemd.so</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>pam_systemd</command> registers user sessions with + the systemd login manager + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + and hence the systemd control group hierarchy.</para> + + <para>The module also applies various resource management and runtime parameters to the new session, as + configured in the <ulink url="https://systemd.io/USER_RECORD">JSON User Record</ulink> of the user, when + one is defined.</para> + + <para>On login, this module — in conjunction with <filename>systemd-logind.service</filename> — ensures the + following:</para> + + <orderedlist> + <listitem><para>If it does not exist yet, the user runtime directory <filename>/run/user/$UID</filename> is + either created or mounted as new <literal>tmpfs</literal> file system with quota applied, and its ownership + changed to the user that is logging in.</para></listitem> + + <listitem><para>The <varname>$XDG_SESSION_ID</varname> environment variable is initialized. If auditing is + available and <command>pam_loginuid.so</command> was run before this module (which is highly recommended), the + variable is initialized from the auditing session id (<filename>/proc/self/sessionid</filename>). Otherwise, an + independent session counter is used.</para></listitem> + + <listitem><para>A new systemd scope unit is created for the session. If this is the first concurrent session of + the user, an implicit per-user slice unit below <filename>user.slice</filename> is automatically created and the + scope placed into it. An instance of the system service <filename>user@.service</filename>, which runs the + systemd user manager instance, is started.</para></listitem> + + <listitem><para>The <literal>$TZ</literal>, <literal>$EMAIL</literal> and <literal>$LANG</literal> + environment variables are configured for the user, based on the respective data from the user's JSON + record (if it is defined). Moreover, any environment variables explicitly configured in the user record + are imported, and the umask, nice level, and resource limits initialized.</para></listitem> + </orderedlist> + + <para>On logout, this module ensures the following:</para> + + <orderedlist> + <listitem><para>If enabled in + <citerefentry><refentrytitle>logind.conf</refentrytitle> + <manvolnum>5</manvolnum></citerefentry> (<varname>KillUserProcesses=</varname>), all processes of the session are + terminated. If the last concurrent session of a user ends, the user's systemd instance will be terminated too, + and so will the user's slice unit.</para></listitem> + + <listitem><para>If the last concurrent session of a user ends, + the user runtime directory <filename>/run/user/$UID</filename> and all its + contents are removed, too.</para></listitem> + </orderedlist> + + <para>If the system was not booted up with systemd as init system, + this module does nothing and immediately returns + <constant>PAM_SUCCESS</constant>.</para> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist class='pam-directives'> + + <varlistentry> + <term><varname>class=</varname></term> + + <listitem><para>Takes a string argument which sets the session class. The <varname>XDG_SESSION_CLASS</varname> + environment variable (see below) takes precedence. One of <literal>user</literal>, <literal>greeter</literal>, + <literal>lock-screen</literal> or <literal>background</literal>. See + <citerefentry><refentrytitle>sd_session_get_class</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details about the session class.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>type=</varname></term> + + <listitem><para>Takes a string argument which sets the session type. The <varname>XDG_SESSION_TYPE</varname> + environment variable (see below) takes precedence. One of <literal>unspecified</literal>, + <literal>tty</literal>, <literal>x11</literal>, <literal>wayland</literal> or <literal>mir</literal>. See + <citerefentry><refentrytitle>sd_session_get_type</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details about the session type.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>desktop=</varname></term> + + <listitem><para>Takes a single, short identifier string for the desktop environment. The + <varname>XDG_SESSION_DESKTOP</varname> environment variable (see below) takes precedence. This may be used to + indicate the session desktop used, where this applies and if this information is available. For example: + <literal>GNOME</literal>, or <literal>KDE</literal>. It is recommended to use the same identifiers and + capitalization as for <varname>$XDG_CURRENT_DESKTOP</varname>, as defined by the <ulink + url="http://standards.freedesktop.org/desktop-entry-spec/latest/">Desktop Entry + Specification</ulink>. (However, note that the option only takes a single item, and not a colon-separated list + like <varname>$XDG_CURRENT_DESKTOP</varname>.) See + <citerefentry><refentrytitle>sd_session_get_desktop</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + further details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>debug</varname><optional>=</optional></term> + + <listitem><para>Takes an optional boolean argument. If yes or without the argument, the module will log + debugging information as it operates.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Module Types Provided</title> + + <para>Only <option>session</option> is provided.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <para>The following environment variables are initialized by the module and available to the processes of the + user's session:</para> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$XDG_SESSION_ID</varname></term> + + <listitem><para>A short session identifier, suitable to be used in filenames. The string itself should be + considered opaque, although often it is just the audit session ID as reported by + <filename>/proc/self/sessionid</filename>. Each ID will be assigned only once during machine uptime. It may + hence be used to uniquely label files or other resources of this session. Combine this ID with the boot + identifier, as returned by + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>, for a + globally unique identifier.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_RUNTIME_DIR</varname></term> + + <listitem><para>Path to a user-private user-writable directory + that is bound to the user login time on the machine. It is + automatically created the first time a user logs in and + removed on the user's final logout. If a user logs in twice at + the same time, both sessions will see the same + <varname>$XDG_RUNTIME_DIR</varname> and the same contents. If + a user logs in once, then logs out again, and logs in again, + the directory contents will have been lost in between, but + applications should not rely on this behavior and must be able + to deal with stale files. To store session-private data in + this directory, the user should include the value of + <varname>$XDG_SESSION_ID</varname> in the filename. This + directory shall be used for runtime file system objects such + as <constant>AF_UNIX</constant> sockets, FIFOs, PID files and + similar. It is guaranteed that this directory is local and + offers the greatest possible file system feature set the + operating system provides. For further details, see the <ulink + url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG + Base Directory Specification</ulink>. <varname>$XDG_RUNTIME_DIR</varname> + is not set if the current user is not the original user of the session.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$TZ</varname></term> + <term><varname>$EMAIL</varname></term> + <term><varname>$LANG</varname></term> + + <listitem><para>If a JSON user record is known for the user logging in these variables are + initialized from the respective data in the record.</para></listitem> + </varlistentry> + + </variablelist> + + <para>The following environment variables are read by the module and may be used by the PAM service to pass + metadata to the module. If these variables are not set when the PAM module is invoked but can be determined + otherwise they are set by the module, so that these variables are initialized for the session and applications if + known at all.</para> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$XDG_SESSION_TYPE</varname></term> + + <listitem><para>The session type. This may be used instead of <varname>type=</varname> on the module parameter + line, and is usually preferred.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_SESSION_CLASS</varname></term> + + <listitem><para>The session class. This may be used instead of <varname>class=</varname> on the module parameter + line, and is usually preferred.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_SESSION_DESKTOP</varname></term> + + <listitem><para>The desktop identifier. This may be used instead of <varname>desktop=</varname> on the module + parameter line, and is usually preferred.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_SEAT</varname></term> + + <listitem><para>The seat name the session shall be registered + for, if any.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_VTNR</varname></term> + + <listitem><para>The VT number the session shall be registered + for, if any. (Only applies to seats with a VT available, such + as <literal>seat0</literal>)</para></listitem> + </varlistentry> + </variablelist> + + <para>If not set, <command>pam_systemd</command> will initialize + <varname>$XDG_SEAT</varname> and <varname>$XDG_VTNR</varname> + based on the <varname>$DISPLAY</varname> variable (if the latter is set).</para> + </refsect1> + + <refsect1> + <title>Session limits</title> + + <para>PAM modules earlier in the stack, that is those that come before <command>pam_systemd.so</command>, + can set session scope limits using the PAM context objects. The data for these objects is provided as <constant>NUL</constant>-terminated C strings + and maps directly to the respective unit resource control directives. Note that these limits apply to individual sessions of the user, + they do not apply to all user processes as a combined whole. In particular, the per-user <command>user@.service</command> unit instance, + which runs the <command>systemd --user</command> manager process and its children, and is tracked outside of any session, being shared + by all the user's sessions, is not covered by these limits. + </para> + + <para> See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information about the resources. + Also, see <citerefentry project='man-pages'><refentrytitle>pam_set_data</refentrytitle><manvolnum>3</manvolnum></citerefentry> for additional information about how to set + the context objects. + </para> + + <variablelist class='pam-directives'> + <varlistentry> + <term><varname>systemd.memory_max=</varname></term> + + <listitem><para>Sets unit <varname>MemoryMax=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.tasks_max=</varname></term> + + <listitem><para>Sets unit <varname>TasksMax=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.cpu_weight=</varname></term> + + <listitem><para>Sets unit <varname>CPUWeight=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.io_weight=</varname></term> + + <listitem><para>Sets unit <varname>IOWeight=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.runtime_max_sec=</varname></term> + + <listitem><para>Sets unit <varname>RuntimeMaxSec=</varname>.</para></listitem> + </varlistentry> + </variablelist> + + <para>Example data as can be provided from an another PAM module: + <programlisting> +pam_set_data(handle, "systemd.memory_max", (void *)"200M", cleanup); +pam_set_data(handle, "systemd.tasks_max", (void *)"50", cleanup); +pam_set_data(handle, "systemd.cpu_weight", (void *)"100", cleanup); +pam_set_data(handle, "systemd.io_weight", (void *)"340", cleanup); +pam_set_data(handle, "systemd.runtime_max_sec", (void *)"3600", cleanup); + </programlisting> + </para> + + </refsect1> + + <refsect1> + <title>Example</title> + + <para>Here's an example PAM configuration fragment that allows users sessions to be managed by + <filename>systemd-logind.service</filename>:</para> + + <programlisting>#%PAM-1.0 +auth sufficient pam_unix.so +-auth sufficient pam_systemd_home.so +auth required pam_deny.so + +account required pam_nologin.so +-account sufficient pam_systemd_home.so +account sufficient pam_unix.so +account required pam_permit.so + +-password sufficient pam_systemd_home.so +password sufficient pam_unix.so sha512 shadow try_first_pass try_authtok +password required pam_deny.so + +-session optional pam_keyinit.so revoke +-session optional pam_loginuid.so +-session optional pam_systemd_home.so +<command>-session optional pam_systemd.so</command> +session required pam_unix.so</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>pam_systemd_home</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam_loginuid</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml new file mode 100644 index 0000000..93e8435 --- /dev/null +++ b/man/pam_systemd_home.xml @@ -0,0 +1,166 @@ +<?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-or-later --> + +<refentry id="pam_systemd_home" conditional='ENABLE_PAM_HOME'> + + <refentryinfo> + <title>pam_systemd_home</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>pam_systemd_home</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>pam_systemd_home</refname> + <refpurpose>Automatically mount home directories managed by <filename>systemd-homed.service</filename> on + login, and unmount them on logout</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>pam_systemd_home.so</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>pam_systemd_home</command> ensures that home directories managed by + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + are automatically activated (mounted) on user login, and are deactivated (unmounted) when the last + session of the user ends.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist class='pam-directives'> + + <varlistentry> + <term><varname>suspend=</varname></term> + + <listitem><para>Takes a boolean argument. If true, the home directory of the user will be suspended + automatically during system suspend; if false it will remain active. Automatic suspending of the home + directory improves security substantially as secret key material is automatically removed from memory + before the system is put to sleep and must be re-acquired (through user re-authentication) when + coming back from suspend. It is recommended to set this parameter for all PAM applications that have + support for automatically re-authenticating via PAM on system resume. If multiple sessions of the + same user are open in parallel the user's home directory will be left unsuspended on system suspend + as long as at least one of the sessions does not set this parameter to on. Defaults to + off.</para> + + <para>Note that TTY logins generally do not support re-authentication on system resume. + Re-authentication on system resume is primarily a concept implementable in graphical environments, in + the form of lock screens brought up automatically when the system goes to sleep. This means that if a + user concurrently uses graphical login sessions that implement the required re-authentication + mechanism and console logins that do not, the home directory is not locked during suspend, due to the + logic explained above. That said, it is possible to set this field for TTY logins too, ignoring the + fact that TTY logins actually don't support the re-authentication mechanism. In that case the TTY + sessions will appear hung until the user logs in on another virtual terminal (regardless if via + another TTY session or graphically) which will resume the home directory and unblock the original TTY + session. (Do note that lack of screen locking on TTY sessions means even though the TTY session + appears hung, keypresses can still be queued into it, and the existing screen contents be read + without re-authentication; this limitation is unrelated to the home directory management + <command>pam_systemd_home</command> and <filename>systemd-homed.service</filename> implement.)</para> + + <para>Turning this option on by default is highly recommended for all sessions, but only if the + service managing these sessions correctly implements the aforementioned re-authentication. Note that + the re-authentication must take place from a component running outside of the user's context, so that + it does not require access to the user's home directory for operation. Traditionally, most desktop + environments do not implement screen locking this way, and need to be updated + accordingly.</para> + + <para>This setting may also be controlled via the <varname>$SYSTEMD_HOME_SUSPEND</varname> + environment variable (see below), which <command>pam_systemd_home</command> reads during initialization and sets + for sessions. If both the environment variable is set and the module parameter specified the latter + takes precedence.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>debug</varname><optional>=</optional></term> + + <listitem><para>Takes an optional boolean argument. If yes or without the argument, the module will log + debugging information as it operates.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Module Types Provided</title> + + <para>The module provides all four management operations: <option>auth</option>, <option>account</option>, + <option>session</option>, <option>password</option>.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <para>The following environment variables are initialized by the module and available to the processes of the + user's session:</para> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$SYSTEMD_HOME=1</varname></term> + + <listitem><para>Indicates that the user's home directory is managed by <filename>systemd-homed.service</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_HOME_SUSPEND=</varname></term> + + <listitem><para>Indicates whether the session has been registered with the suspend mechanism enabled + or disabled (see above). The variable's value is either <literal>0</literal> or + <literal>1</literal>. Note that the module both reads the variable when initializing, and sets it for + sessions.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Example</title> + + <para>Here's an example PAM configuration fragment that permits users managed by + <filename>systemd-homed.service</filename> to log in:</para> + + <programlisting>#%PAM-1.0 +auth sufficient pam_unix.so +<command>-auth sufficient pam_systemd_home.so</command> +auth required pam_deny.so + +account required pam_nologin.so +<command>-account sufficient pam_systemd_home.so</command> +account sufficient pam_unix.so +account required pam_permit.so + +<command>-password sufficient pam_systemd_home.so</command> +password sufficient pam_unix.so sha512 shadow try_first_pass try_authtok +password required pam_deny.so + +-session optional pam_keyinit.so revoke +-session optional pam_loginuid.so +<command>-session optional pam_systemd_home.so</command> +-session optional pam_systemd.so +session required pam_unix.so</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/path-documents.c b/man/path-documents.c new file mode 100644 index 0000000..a6c1f93 --- /dev/null +++ b/man/path-documents.c @@ -0,0 +1,9 @@ +#include <stdio.h> +#include <sd-path.h> + +int main(void) { + char *t; + + sd_path_lookup(SD_PATH_USER_DOCUMENTS, NULL, &t); + printf("~/Documents: %s\n", t); +} diff --git a/man/portablectl.xml b/man/portablectl.xml new file mode 100644 index 0000000..3653207 --- /dev/null +++ b/man/portablectl.xml @@ -0,0 +1,426 @@ +<?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-or-later --> + +<refentry id="portablectl" conditional='ENABLE_PORTABLED' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>portablectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>portablectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>portablectl</refname> + <refpurpose>Attach, detach or inspect portable service images</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>portablectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>portablectl</command> may be used to attach, detach or inspect portable service images. It's + primarily a command interfacing with + <citerefentry><refentrytitle>systemd-portabled.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para>Portable service images contain an OS file system tree along with + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> unit file + information. A service image may be "attached" to the local system. If attached, a set of unit files are copied + from the image to the host, and extended with <varname>RootDirectory=</varname> or <varname>RootImage=</varname> + assignments (in case of service units) pointing to the image file or directory, ensuring the services will run + within the file system context of the image.</para> + + <para>Portable service images are an efficient way to bundle multiple related services and other units together, + and transfer them as a whole between systems. When these images are attached the local system the contained units + may run in most ways like regular system-provided units, either with full privileges or inside strict sandboxing, + depending on the selected configuration.</para> + + <para>Specifically portable service images may be of the following kind:</para> + + <itemizedlist> + <listitem><para>Directory trees containing an OS, including the top-level directories <filename>/usr/</filename>, + <filename>/etc/</filename>, and so on.</para></listitem> + + <listitem><para>btrfs subvolumes containing OS trees, similar to normal directory trees.</para></listitem> + + <listitem><para>Binary "raw" disk images containing MBR or GPT partition tables and Linux file system + partitions. (These must be regular files, with the <filename>.raw</filename> suffix.)</para></listitem> + </itemizedlist> + + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + + <varlistentry> + <term><command>list</command></term> + + <listitem><para>List available portable service images. This will list all portable service images discovered + in the portable image search paths (see below), along with brief metadata and state information. Note that many + of the commands below may both operate on images inside and outside of the search paths. This command is hence + mostly a convenience option, the commands are generally not restricted to what this list + shows.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>attach</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term> + + <listitem><para>Attach a portable service image to the host system. Expects a file system path to a portable + service image file or directory as first argument. If the specified path contains no slash character + (<literal>/</literal>) it is understood as image filename that is searched for in the portable service image + search paths (see below). To reference a file in the current working directory prefix the filename with + <literal>./</literal> to avoid this search path logic.</para> + + <para>When a portable service is attached four operations are executed:</para> + + <orderedlist> + + <listitem><para>All unit files of types <filename>.service</filename>, <filename>.socket</filename>, + <filename>.target</filename>, <filename>.timer</filename> and <filename>.path</filename> which match the + indicated unit file name prefix are copied from the image to the host's + <filename>/etc/systemd/system.attached/</filename> directory (or + <filename>/run/systemd/system.attached/</filename> — depending whether <option>--runtime</option> is + specified, see above), which is included in the built-in unit search path of the system service + manager.</para></listitem> + + <listitem><para>For unit files of type <filename>.service</filename> a drop-in is added to these copies that + adds <varname>RootDirectory=</varname> or <varname>RootImage=</varname> settings (see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details), that ensures these services are run within the file system of the originating portable service + image.</para></listitem> + + <listitem><para>A second drop-in is created: the "profile" drop-in, that may contain additional security + settings (and other settings). A number of profiles are available by default but administrators may define + their own ones. See below.</para></listitem> + + <listitem><para>If the portable service image file is not already in the search path (see below), a symbolic + link to it is created in <filename>/etc/portables/</filename> or + <filename>/run/portables/</filename>, to make sure it is included in it.</para></listitem> + </orderedlist> + + <para>By default all unit files whose names start with a prefix generated from the image's file name are copied + out. Specifically, the prefix is determined from the image file name with any suffix such as + <filename>.raw</filename> removed, truncated at the first occurrence of an underscore character + (<literal>_</literal>), if there is one. The underscore logic is supposed to be used to versioning so that the + an image file <filename>foobar_47.11.raw</filename> will result in a unit file matching prefix of + <filename>foobar</filename>. This prefix is then compared with all unit files names contained in the image in + the usual directories, but only unit file names where the prefix is followed by <literal>-</literal>, + <literal>.</literal> or <literal>@</literal> are considered. Example: if a portable service image file is named + <filename>foobar_47.11.raw</filename> then by default all its unit files with names such as + <filename>foobar-quux-waldi.service</filename>, <filename>foobar.service</filename> or + <filename>foobar@.service</filename> will be considered. It's possible to override the matching prefix: all + strings listed on the command line after the image file name are considered prefixes, overriding the implicit + logic where the prefix is derived from the image file name.</para> + + <para>By default, after the unit files are attached the service manager's configuration is reloaded, except + when <option>--no-reload</option> is specified (see above). This ensures that the new units made available to + the service manager are seen by it.</para> + + <para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable service(s) are + immediately started (blocking operation unless <option>--no-block</option> is passed) and/or enabled after + attaching the image.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>detach</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term> + + <listitem><para>Detaches a portable service image from the host. This undoes the operations executed by the + <command>attach</command> command above, and removes the unit file copies, drop-ins and image symlink + again. This command expects an image name or path as parameter. Note that if a path is specified only the last + component of it (i.e. the file or directory name itself, not the path to it) is used for finding matching unit + files. This is a convenience feature to allow all arguments passed as <command>attach</command> also to + <command>detach</command>.</para></listitem> + + <para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable service(s) are + immediately stopped (blocking operation) and/or disabled before detaching the image. Prefix(es) are also accepted, + to be used in case the unit names do not match the image name as described in the <command>attach</command>.</para> + </varlistentry> + + <varlistentry> + <term><command>inspect</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term> + + <listitem><para>Extracts various metadata from a portable service image and presents it to the + caller. Specifically, the + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file of the + image is retrieved as well as all matching unit files. By default a short summary showing the most relevant + metadata in combination with a list of matching unit files is shown (that is the unit files + <command>attach</command> would install to the host system). If combined with <option>--cat</option> (see + above), the <filename>os-release</filename> data and the units files' contents is displayed unprocessed. This + command is useful to determine whether an image qualifies as portable service image, and which unit files are + included. This command expects the path to the image as parameter, optionally followed by a list of unit file + prefixes to consider, similar to the <command>attach</command> command described above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>is-attached</command> <replaceable>IMAGE</replaceable></term> + + <listitem><para>Determines whether the specified image is currently attached or not. Unless combined with the + <option>--quiet</option> switch this will show a short state identifier for the image. Specifically:</para> + + <table> + <title>Image attachment states</title> + <tgroup cols='2'> + <colspec colname='state'/> + <colspec colname='description'/> + <thead> + <row> + <entry>State</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry><option>detached</option></entry> + <entry>The image is currently not attached.</entry> + </row> + <row> + <entry><option>attached</option></entry> + <entry>The image is currently attached, i.e. its unit files have been made available to the host system.</entry> + </row> + <row> + <entry><option>attached-runtime</option></entry> + <entry>Like <option>attached</option>, but the unit files have been made available transiently only, i.e. the <command>attach</command> command has been invoked with the <option>--runtime</option> option.</entry> + </row> + <row> + <entry><option>enabled</option></entry> + <entry>The image is currently attached, and at least one unit file associated with it has been enabled.</entry> + </row> + <row> + <entry><option>enabled-runtime</option></entry> + <entry>Like <option>enabled</option>, but the unit files have been made available transiently only, i.e. the <command>attach</command> command has been invoked with the <option>--runtime</option> option.</entry> + </row> + <row> + <entry><option>running</option></entry> + <entry>The image is currently attached, and at least one unit file associated with it is running.</entry> + </row> + <row> + <entry><option>running-runtime</option></entry> + <entry>The image is currently attached transiently, and at least one unit file associated with it is running.</entry> + </row> + </tbody> + </tgroup> + </table> + + </listitem> + </varlistentry> + + <varlistentry> + <term><command>read-only</command> <replaceable>IMAGE</replaceable> [<replaceable>BOOL</replaceable>]</term> + + <listitem><para>Marks or (unmarks) a portable service image read-only. Takes an image name, followed by a + boolean as arguments. If the boolean is omitted, positive is implied, i.e. the image is marked + read-only.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>remove</command> <replaceable>IMAGE</replaceable>…</term> + + <listitem><para>Removes one or more portable service images. Note that this command will only remove the + specified image path itself — it refers to a symbolic link then the symbolic link is removed and not the + image it points to.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-limit</command> [<replaceable>IMAGE</replaceable>] <replaceable>BYTES</replaceable></term> + + <listitem><para>Sets the maximum size in bytes that a specific portable service image, or all images, may grow + up to on disk (disk quota). Takes either one or two parameters. The first, optional parameter refers to a + portable service image name. If specified, the size limit of the specified image is changed. If omitted, the + overall size limit of the sum of all images stored locally is changed. The final argument specifies the size + limit in bytes, possibly suffixed by the usual K, M, G, T units. If the size limit shall be disabled, specify + <literal>-</literal> as size.</para> + + <para>Note that per-image size limits are only supported on btrfs file systems. Also, depending on + <varname>BindPaths=</varname> settings in the portable service's unit files directories from the host might be + visible in the image environment during runtime which are not affected by this setting, as only the image + itself is counted against this limit.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Suppresses additional informational output while running.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option> <replaceable>PROFILE</replaceable></term> + <term><option>--profile=</option><replaceable>PROFILE</replaceable></term> + + <listitem><para>When attaching an image, select the profile to use. By default the <literal>default</literal> + profile is used. For details about profiles, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--copy=</option></term> + + <listitem><para>When attaching an image, select whether to prefer copying or symlinking of files installed into + the host system. Takes one of <literal>copy</literal> (to prefer copying of files), <literal>symlink</literal> + (to prefer creation of symbolic links) or <literal>auto</literal> for an intermediary mode where security + profile drop-ins are symlinked while unit files are copied. Note that this option expresses a preference only, + in cases where symbolic links cannot be created — for example when the image operated on is a raw disk image, + and hence not directly referentiable from the host file system — copying of files is used + unconditionally.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--runtime</option></term> + + <listitem><para>When specified the unit and drop-in files are placed in + <filename>/run/systemd/system.attached/</filename> instead of + <filename>/etc/systemd/system.attached/</filename>. Images attached with this option set hence remain attached + only until the next reboot, while they are normally attached persistently.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-reload</option></term> + + <listitem><para>Don't reload the service manager after attaching or detaching a portable service + image. Normally the service manager is reloaded to ensure it is aware of added or removed unit + files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cat</option></term> + + <listitem><para>When inspecting portable service images, show the (unprocessed) contents of the metadata files + pulled from the image, instead of brief summaries. Specifically, this will show the + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> and unit file + contents of the image.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--enable</option></term> + + <listitem><para>Immediately enable/disable the portable service after attaching/detaching.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--now</option></term> + + <listitem><para>Immediately start/stop the portable service after attaching/before detaching.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-block</option></term> + + <listitem><para>Don't block waiting for attach --now to complete.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="no-ask-password" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Files and Directories</title> + + <para>Portable service images are preferably stored in <filename>/var/lib/portables/</filename>, but are also + searched for in <filename>/etc/portables/</filename>, <filename>/run/systemd/portables/</filename>, + <filename>/usr/local/lib/portables/</filename> and <filename>/usr/lib/portables/</filename>. It's recommended not + to place image files directly in <filename>/etc/portables/</filename> or + <filename>/run/systemd/portables/</filename> (as these are generally not suitable for storing large or non-textual + data), but use these directories only for linking images located elsewhere into the image search path.</para> + + <para>When a portable service image is attached, matching unit files are copied onto the host into the + <filename>/etc/systemd/system.attached/</filename> and <filename>/run/systemd/system.attached/</filename> + directories. When an image is detached, the unit files are removed again from these directories.</para> + </refsect1> + + <refsect1> + <title>Profiles</title> + + <para>When portable service images are attached a "profile" drop-in is linked in, which may be used to enforce + additional security (and other) restrictions locally. Four profile drop-ins are defined by default, and shipped in + <filename>/usr/lib/systemd/portable/profile/</filename>. Additional, local profiles may be defined by placing them + in <filename>/etc/systemd/portable/profile/</filename>. The default profiles are:</para> + + <table> + <title>Profiles</title> + <tgroup cols='2'> + <colspec colname='state'/> + <colspec colname='description'/> + <thead> + <row> + <entry>Name</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>default</filename></entry> + <entry>This is the default profile if no other profile name is set via the <option>--profile=</option> (see above). It's fairly restrictive, but should be useful for common, unprivileged system workloads. This includes write access to the logging framework, as well as IPC access to the D-Bus system.</entry> + </row> + <row> + <entry><filename>nonetwork</filename></entry> + <entry>Very similar to <filename>default</filename>, but networking is turned off for any services of the portable service image.</entry> + </row> + <row> + <entry><filename>strict</filename></entry> + <entry>A profile with very strict settings. This profile excludes IPC (D-Bus) and network access.</entry> + </row> + <row> + <entry><filename>trusted</filename></entry> + <entry>A profile with very relaxed settings. In this profile the services run with full privileges.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>For details on these profiles and their effects see their precise definitions, + e.g. <filename>/usr/lib/systemd/portable/profile/default/service.conf</filename> and similar.</para> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-portabled.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/print-unit-path.c b/man/print-unit-path.c new file mode 100644 index 0000000..23b58a2 --- /dev/null +++ b/man/print-unit-path.c @@ -0,0 +1,64 @@ +#include <stdio.h> +#include <string.h> +#include <unistd.h> +#include <sys/types.h> + +#include <systemd/sd-bus.h> +#define _cleanup_(f) __attribute__((cleanup(f))) + +/* This is equivalent to: + * busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \ + * org.freedesktop.systemd1.Manager GetUnitByPID $$ + * + * Compile with 'cc -lsystemd print-unit-path.c' + */ + +#define DESTINATION "org.freedesktop.systemd1" +#define PATH "/org/freedesktop/systemd1" +#define INTERFACE "org.freedesktop.systemd1.Manager" +#define MEMBER "GetUnitByPID" + +static int log_error(int error, const char *message) { + fprintf(stderr, "%s: %s\n", message, strerror(-error)); + return error; +} + +static int print_unit_path(sd_bus *bus) { + _cleanup_(sd_bus_message_unrefp) sd_bus_message *m = NULL; + _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL; + _cleanup_(sd_bus_message_unrefp) sd_bus_message *reply = NULL; + int r; + + r = sd_bus_message_new_method_call(bus, &m, + DESTINATION, PATH, INTERFACE, MEMBER); + if (r < 0) + return log_error(r, "Failed to create bus message"); + + r = sd_bus_message_append(m, "u", (unsigned) getpid()); + if (r < 0) + return log_error(r, "Failed to append to bus message"); + + r = sd_bus_call(bus, m, -1, &error, &reply); + if (r < 0) + return log_error(r, "Call failed"); + + const char *ans; + r = sd_bus_message_read(reply, "o", &ans); + if (r < 0) + return log_error(r, "Failed to read reply"); + + printf("Unit path is \"%s\".\n", ans); + + return 0; +} + +int main(int argc, char **argv) { + _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL; + int r; + + r = sd_bus_open_system(&bus); + if (r < 0) + return log_error(r, "Failed to acquire bus"); + + print_unit_path(bus); +} diff --git a/man/pstore.conf.xml b/man/pstore.conf.xml new file mode 100644 index 0000000..ef3226c --- /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-or-later --> + +<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 + [PStore] 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/repart.d.xml b/man/repart.d.xml new file mode 100644 index 0000000..6e31843 --- /dev/null +++ b/man/repart.d.xml @@ -0,0 +1,634 @@ +<?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"> +<refentry id="repart.d" conditional='ENABLE_REPART' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>repart.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>repart.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>repart.d</refname> + <refpurpose>Partition Definition Files for Automatic Boot-Time Repartitioning</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><literallayout><filename>/etc/repart.d/*.conf</filename> +<filename>/run/repart.d/*.conf</filename> +<filename>/usr/lib/repart.d/*.conf</filename> + </literallayout></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>repart.d/*.conf</filename> files describe basic properties of partitions of block + devices of the local system. They may be used to declare types, names and sizes of partitions that shall + exist. The + <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry> + service reads these files and attempts to add new partitions currently missing and enlarge existing + partitions according to these definitions. Operation is generally incremental, i.e. when applied, what + exists already is left intact, and partitions are never shrunk, moved or deleted.</para> + + <para>These definition files are useful for implementing operating system images that are prepared and + delivered with minimally sized images (for example lacking any state or swap partitions), and which on + first boot automatically take possession of any remaining disk space following a few basic rules.</para> + + <para>Currently, support for partition definition files is only implemented for GPT partitition + tables.</para> + + <para>Partition files are generally matched against any partitions already existing on disk in a simple + algorithm: the partition files are sorted by their filename (ignoring the directory prefix), and then + compared in order against existing partitions matching the same partition type UUID. Specifically, the + first existing partition with a specific partition type UUID is assigned the first definition file with + the same partition type UUID, and the second existing partition with a specific type UUID the second + partition file with the same type UUID, and so on. Any left-over partition files that have no matching + existing partition are assumed to define new partition that shall be created. Such partitions are + appended to the end of the partition table, in the order defined by their names utilizing the first + partition slot greater than the highest slot number currently in use. Any existing partitions that have + no matching partition file are left as they are.</para> + + <para>Note that these definitions may only be used to created and initialize new partitions or grow + existing ones. In the latter case it will not grow the contained files systems however; separate + mechanisms, such as + <citerefentry><refentrytitle>systemd-growfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> may be + used to grow the file systems inside of these partitions.</para> + </refsect1> + + <refsect1> + <title>[Partition] Section Options</title> + + <variablelist> + <varlistentry> + <term><varname>Type=</varname></term> + + <listitem><para>The GPT partition type UUID to match. This may be a GPT partition type UUID such as + <constant>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</constant>, or one of the following special + identifiers:</para> + + <table> + <title>GPT partition type identifiers</title> + + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="name" /> + <colspec colname="explanation" /> + + <thead> + <row> + <entry>Identifier</entry> + <entry>Explanation</entry> + </row> + </thead> + + <tbody> + <row> + <entry><constant>esp</constant></entry> + <entry>EFI System Partition</entry> + </row> + + <row> + <entry><constant>xbootldr</constant></entry> + <entry>Extended Boot Loader Partition</entry> + </row> + + <row> + <entry><constant>swap</constant></entry> + <entry>Swap partition</entry> + </row> + + <row> + <entry><constant>home</constant></entry> + <entry>Home (<filename>/home/</filename>) partition</entry> + </row> + + <row> + <entry><constant>srv</constant></entry> + <entry>Server data (<filename>/srv/</filename>) partition</entry> + </row> + + <row> + <entry><constant>var</constant></entry> + <entry>Variable data (<filename>/var/</filename>) partition</entry> + </row> + + <row> + <entry><constant>tmp</constant></entry> + <entry>Temporary data (<filename>/var/tmp/</filename>) partition</entry> + </row> + + <row> + <entry><constant>linux-generic</constant></entry> + <entry>Generic Linux file system partition</entry> + </row> + + <row> + <entry><constant>root</constant></entry> + <entry>Root file system partition type appropriate for the local architecture (an alias for an architecture root file system partition type listed below, e.g. <constant>root-x86-64</constant>)</entry> + </row> + + <row> + <entry><constant>root-verity</constant></entry> + <entry>Verity data for the root file system partition for the local architecture</entry> + </row> + + <row> + <entry><constant>root-secondary</constant></entry> + <entry>Root file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture)</entry> + </row> + + <row> + <entry><constant>root-secondary-verity</constant></entry> + <entry>Verity data for the root file system partition of the secondary architecture</entry> + </row> + + <row> + <entry><constant>root-x86</constant></entry> + <entry>Root file system partition for the x86 (32bit, aka i386) architecture</entry> + </row> + + <row> + <entry><constant>root-x86-verity</constant></entry> + <entry>Verity data for the x86 (32bit) root file system partition</entry> + </row> + + <row> + <entry><constant>root-x86-64</constant></entry> + <entry>Root file system partition for the x86_64 (64bit, aka amd64) architecture</entry> + </row> + + <row> + <entry><constant>root-x86-64-verity</constant></entry> + <entry>Verity data for the x86_64 (64bit) root file system partition</entry> + </row> + + <row> + <entry><constant>root-arm</constant></entry> + <entry>Root file system partition for the ARM (32bit) architecture</entry> + </row> + + <row> + <entry><constant>root-arm-verity</constant></entry> + <entry>Verity data for the ARM (32bit) root file system partition</entry> + </row> + + <row> + <entry><constant>root-arm64</constant></entry> + <entry>Root file system partition for the ARM (64bit, aka aarch64) architecture</entry> + </row> + + <row> + <entry><constant>root-arm64-verity</constant></entry> + <entry>Verity data for the ARM (64bit, aka aarch64) root file system partition</entry> + </row> + + <row> + <entry><constant>root-ia64</constant></entry> + <entry>Root file system partition for the ia64 architecture</entry> + </row> + + <row> + <entry><constant>root-ia64-verity</constant></entry> + <entry>Verity data for the ia64 root file system partition</entry> + </row> + + <row> + <entry><constant>root-riscv32</constant></entry> + <entry>Root file system partition for the RISC-V 32-bit architecture</entry> + </row> + + <row> + <entry><constant>root-riscv32-verity</constant></entry> + <entry>Verity data for the RISC-V 32-bit root file system partition</entry> + </row> + + <row> + <entry><constant>root-riscv64</constant></entry> + <entry>Root file system partition for the RISC-V 64-bit architecture</entry> + </row> + + <row> + <entry><constant>root-riscv64-verity</constant></entry> + <entry>Verity data for the RISC-V 64-bit root file system partition</entry> + </row> + + <row> + <entry><constant>usr</constant></entry> + <entry><filename>/usr/</filename> file system partition type appropriate for the local architecture (an alias for an architecture <filename>/usr/</filename> file system partition type listed below, e.g. <constant>usr-x86-64</constant>)</entry> + </row> + + <row> + <entry><constant>usr-verity</constant></entry> + <entry>Verity data for the <filename>/usr/</filename> file system partition for the local architecture</entry> + </row> + + <row> + <entry><constant>usr-secondary</constant></entry> + <entry><filename>/usr/</filename> file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture)</entry> + </row> + + <row> + <entry><constant>usr-secondary-verity</constant></entry> + <entry>Verity data for the <filename>/usr/</filename> file system partition of the secondary architecture</entry> + </row> + + <row> + <entry><constant>usr-x86</constant></entry> + <entry><filename>/usr/</filename> file system partition for the x86 (32bit, aka i386) architecture</entry> + </row> + + <row> + <entry><constant>usr-x86-verity</constant></entry> + <entry>Verity data for the x86 (32bit) <filename>/usr/</filename> file system partition</entry> + </row> + + <row> + <entry><constant>usr-x86-64</constant></entry> + <entry><filename>/usr/</filename> file system partition for the x86_64 (64bit, aka amd64) architecture</entry> + </row> + + <row> + <entry><constant>usr-x86-64-verity</constant></entry> + <entry>Verity data for the x86_64 (64bit) <filename>/usr/</filename> file system partition</entry> + </row> + + <row> + <entry><constant>usr-arm</constant></entry> + <entry><filename>/usr/</filename> file system partition for the ARM (32bit) architecture</entry> + </row> + + <row> + <entry><constant>usr-arm-verity</constant></entry> + <entry>Verity data for the ARM (32bit) <filename>/usr/</filename> file system partition</entry> + </row> + + <row> + <entry><constant>usr-arm64</constant></entry> + <entry><filename>/usr/</filename> file system partition for the ARM (64bit, aka aarch64) architecture</entry> + </row> + + <row> + <entry><constant>usr-arm64-verity</constant></entry> + <entry>Verity data for the ARM (64bit, aka aarch64) <filename>/usr/</filename> file system partition</entry> + </row> + + <row> + <entry><constant>usr-ia64</constant></entry> + <entry><filename>/usr/</filename> file system partition for the ia64 architecture</entry> + </row> + + <row> + <entry><constant>usr-ia64-verity</constant></entry> + <entry>Verity data for the ia64 <filename>/usr/</filename> file system partition</entry> + </row> + + <row> + <entry><constant>usr-riscv32</constant></entry> + <entry><filename>/usr/</filename> file system partition for the RISC-V 32-bit architecture</entry> + </row> + + <row> + <entry><constant>usr-riscv32-verity</constant></entry> + <entry>Verity data for the RISC-V 32-bit <filename>/usr/</filename> file system partition</entry> + </row> + + <row> + <entry><constant>usr-riscv64</constant></entry> + <entry><filename>/usr/</filename> file system partition for the RISC-V 64-bit architecture</entry> + </row> + + <row> + <entry><constant>usr-riscv64-verity</constant></entry> + <entry>Verity data for the RISC-V 64-bit <filename>/usr/</filename> file system partition</entry> + </row> + + + </tbody> + </tgroup> + </table> + + <para>This setting defaults to <constant>linux-generic</constant>.</para> + + <para>Most of the partition type UUIDs listed above are defined in the <ulink + url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Label=</varname></term> + + <listitem><para>The textual label to assign to the partition if none is assigned yet. Note that this + setting is not used for matching. It is also not used when a label is already set for an existing + partition. It is thus only used when a partition is newly created or when an existing one had a no + label set (that is: an empty label). If not specified a label derived from the partition type is + automatically used. Simple specifier expansion is supported, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>UUID=</varname></term> + + <listitem><para>The UUID to assign to the partition if none is assigned yet. Note that this + setting is not used for matching. It is also not used when a UUID is already set for an existing + partition. It is thus only used when a partition is newly created or when an existing one had a + all-zero UUID set. If not specified a UUID derived from the partition type is automatically + used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Priority=</varname></term> + + <listitem><para>A numeric priority to assign to this partition, in the range -2147483648…2147483647, + with smaller values indicating higher priority, and higher values indicating smaller priority. This + priority is used in case the configured size constraints on the defined partitions do not permit + fitting all partitions onto the available disk space. If the partitions do not fit, the highest + numeric partition priority of all defined partitions is determined, and all defined partitions with + this priority are removed from the list of new partitions to create (which may be multiple, if the + same priority is used for multiple partitions). The fitting algorithm is then tried again. If the + partitions still do not fit, the now highest numeric partition priority is determined, and the + matching partitions removed too, and so on. Partitions of a priority of 0 or lower are never + removed. If all partitions with a priority above 0 are removed and the partitions still do not fit on + the device the operation fails. Note that this priority has no effect on ordering partitions, for + that use the alphabetical order of the filenames of the partition definition files. Defaults to + 0.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Weight=</varname></term> + + <listitem><para>A numeric weight to assign to this partition in the range 0…1000000. Available disk + space is assigned the defined partitions according to their relative weights (subject to the size + constraints configured with <varname>SizeMinBytes=</varname>, <varname>SizeMaxBytes=</varname>), so + that a partition with weight 2000 gets double the space as one with weight 1000, and a partition with + weight 333 a third of that. Defaults to 1000.</para> + + <para>The <varname>Weight=</varname> setting is used to distribute available disk space in an + "elastic" fashion, based on the disk size and existing partitions. If a partition shall have a fixed + size use both <varname>SizeMinBytes=</varname> and <varname>SizeMaxBytes=</varname> with the same + value in order to fixate the size to one value, in which case the weight has no + effect.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PaddingWeight=</varname></term> + + <listitem><para>Similar to <varname>Weight=</varname> but sets a weight for the free space after the + partition (the "padding"). When distributing available space the weights of all partitions and all + defined padding is summed, and then each partition and padding gets the fraction defined by its + weight. Defaults to 0, i.e. by default no padding is applied.</para> + + <para>Padding is useful if empty space shall be left for later additions or a safety margin at the + end of the device or between partitions.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SizeMinBytes=</varname></term> + <term><varname>SizeMaxBytes=</varname></term> + + <listitem><para>Specifies minimum and maximum size constraints in bytes. Takes the usual K, M, G, T, + … suffixes (to the base of 1024). If <varname>SizeMinBytes=</varname> is specified the partition is + created at or grown to at least the specified size. If <varname>SizeMaxBytes=</varname> is specified + the partition is created at or grown to at most the specified size. The precise size is determined + through the weight value value configured with <varname>Weight=</varname>, see above. When + <varname>SizeMinBytes=</varname> is set equal to <varname>SizeMaxBytes=</varname> the configured + weight has no effect as the partition is explicitly sized to the specified fixed value. Note that + partitions are never created smaller than 4096 bytes, and since partitions are never shrunk the + previous size of the partition (in case the partition already exists) is also enforced as lower bound + for the new size. The values should be specified as multiples of 4096 bytes, and are rounded upwards + (in case of <varname>SizeMinBytes=</varname>) or downwards (in case of + <varname>SizeMaxBytes=</varname>) otherwise. If the backing device does not provide enough space to + fulfill the constraints placing the partition will fail. For partitions that shall be created, + depending on the setting of <varname>Priority=</varname> (see above) the partition might be dropped + and the placing algorithm restarted. By default a minimum size constraint of 10M and no maximum size + constraint is set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PaddingMinBytes=</varname></term> + <term><varname>PaddingMaxBytes=</varname></term> + + <listitem><para>Specifies minimum and maximum size constraints in bytes for the free space after the + partition (the "padding"). Semantics are similar to <varname>SizeMinBytes=</varname> and + <varname>SizeMaxBytes=</varname>, except that unlike partition sizes free space can be shrunk and can + be as small as zero. By default no size constraints on padding are set, so that only + <varname>PaddingWeight=</varname> determines the size of the padding applied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CopyBlocks=</varname></term> + + <listitem><para>Takes a path to a regular file, block device node or directory. If specified and the + partition is newly created the data from the specified path is written to the newly created + partition, on the block level. If a directory is specified the backing block device of the file + system the directory is on is determined and the data read directly from that. This option is useful + to efficiently replicate existing file systems on the block level on a new partition, for example to + build a simple OS installer or OS image builder.</para> + + <para>The file specified here must have a size that is a multiple of the basic block size 512 and not + be empty. If this option is used, the size allocation algorithm is slightly altered: the partition is + created as least as big as required to fit the data in, i.e. the data size is an additional minimum + size value taken into consideration for the allocation algorithm, similar to and in addition to the + <varname>SizeMin=</varname> value configured above.</para> + + <para>This option has no effect if the partition it is declared for already exists, i.e. existing + data is never overwritten. Note that the data is copied in before the partition table is updated, + i.e. before the partition actually is persistently created. This provides robustness: it is + guaranteed that the partition either doesn't exist or exists fully populated; it is not possible that + the partition exists but is not or only partially populated.</para> + + <para>This option cannot be combined with <varname>Format=</varname> or + <varname>CopyFiles=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Format=</varname></term> + + <listitem><para>Takes a file system name, such as <literal>ext4</literal>, <literal>btrfs</literal>, + <literal>xfs</literal> or <literal>vfat</literal>, or the special value <literal>swap</literal>. If + specified and the partition is newly created it is formatted with the specified file system (or as + swap device). The file system UUID and label are automatically derived from the partition UUID and + label. If this option is used, the size allocation algorithm is slightly altered: the partition is + created as least as big as required for the minimal file system of the specified type (or 4KiB if the + minimal size is not known).</para> + + <para>This option has no effect if the partition already exists.</para> + + <para>Similar to the behaviour of <varname>CopyBlocks=</varname> the file system is formatted before + the partition is created, ensuring that the partition only ever exists with a fully initialized + file system.</para> + + <para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CopyFiles=</varname></term> + + <listitem><para>Takes a pair of colon separated absolute file system paths. The first path refers to + a source file or directory on the host, the second path refers to a target in the file system of the + newly created partition and formatted file system. This setting may be used to copy files or + directories from the host into the file system that is created due to the <varname>Format=</varname> + option. If <varname>CopyFiles=</varname> is used without <varname>Format=</varname> specified + explicitly, <literal>Format=</literal> with a suitable default is implied (currently + <literal>ext4</literal>, but this may change in the future). This option may be used multiple times + to copy multiple files or directories from host into the newly formatted file system. The colon and + second path may be omitted in which case the source path is also used as the target path (relative to + the root of the newly created file system). If the source path refers to a directory it is copied + recursively.</para> + + <para>This option has no effect if the partition already exists: it cannot be used to copy additional + files into an existing partition, it may only be used to populate a file system created anew.</para> + + <para>The copy operation is executed before the file system is registered in the partition table, + thus ensuring that a file system populated this way only ever exists fully initialized.</para> + + <para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Encrypt=</varname></term> + + <listitem><para>Takes a boolean parameter, defaulting to false. If true the partition will be + formatted with a LUKS2 superblock, before the blocks configured with <varname>CopyBlocks=</varname> + are copied in or the file system configured with <varname>Format=</varname> is created.</para> + + <para>The LUKS2 UUID is automatically derived from the partition UUID in a stable fashion. A single + key is added to the LUKS2 superblock, configurable with the <option>--key-file=</option> switch to + <command>systemd-repart</command>.</para> + + <para>When used this slightly alters the size allocation logic as the implicit, minimal size limits + of <varname>Format=</varname> and <varname>CopyBlocks=</varname> are increased by the space necessary + for the LUKS2 superblock (see above).</para> + + <para>This option has no effect if the partition already exists.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FactoryReset=</varname></term> + + <listitem><para>Takes a boolean argument. If specified the partition is marked for removal during a + factory reset operation. This functionality is useful to implement schemes where images can be reset + into their original state by removing partitions and creating them anew. Defaults to off.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Specifiers</title> + + <para>Specifiers may be used in the <varname>Label=</varname> setting. The following expansions are understood:</para> + <table class='specifiers'> + <title>Specifiers available</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="spec" /> + <colspec colname="mean" /> + <colspec colname="detail" /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Meaning</entry> + <entry>Details</entry> + </row> + </thead> + <tbody> + <xi:include href="standard-specifiers.xml" xpointer="a"/> + <xi:include href="standard-specifiers.xml" xpointer="b"/> + <xi:include href="standard-specifiers.xml" xpointer="B"/> + <xi:include href="standard-specifiers.xml" xpointer="H"/> + <xi:include href="standard-specifiers.xml" xpointer="l"/> + <xi:include href="standard-specifiers.xml" xpointer="m"/> + <xi:include href="standard-specifiers.xml" xpointer="o"/> + <xi:include href="standard-specifiers.xml" xpointer="v"/> + <xi:include href="standard-specifiers.xml" xpointer="w"/> + <xi:include href="standard-specifiers.xml" xpointer="W"/> + <xi:include href="standard-specifiers.xml" xpointer="percent"/> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Grow the root partition to the full disk size at first boot</title> + + <para>With the following file the root partition is automatically grown to the full disk if possible during boot.</para> + + <para><programlisting># /usr/lib/repart.d/50-root.conf +[Partition] +Type=root +</programlisting></para> + </example> + + <example> + <title>Create a swap and home partition automatically on boot, if missing</title> + + <para>The home partition gets all available disk space while the swap partition gets 1G at most and 64M + at least. We set a priority > 0 on the swap partition to ensure the swap partition is not used if not + enough space is available. For every three bytes assigned to the home partition the swap partition gets + assigned one.</para> + + <para><programlisting># /usr/lib/repart.d/60-home.conf +[Partition] +Type=home +</programlisting></para> + + <para><programlisting># /usr/lib/repart.d/70-swap.conf +[Partition] +Type=swap +SizeMinBytes=64M +SizeMaxBytes=1G +Priority=1 +Weight=333 +</programlisting></para> + </example> + + <example> + <title>Create B partitions in an A/B Verity setup, if missing</title> + + <para>Let's say the vendor intends to update OS images in an A/B setup, i.e. with two root partitions + (and two matching Verity partitions) that shall be used alternatingly during upgrades. To minimize + image sizes the original image is shipped only with one root and one Verity partition (the "A" set), + and the second root and Verity partitions (the "B" set) shall be created on first boot on the free + space on the medium.</para> + + <para><programlisting># /usr/lib/repart.d/50-root.conf +[Partition] +Type=root +SizeMinBytes=512M +SizeMaxBytes=512M +</programlisting></para> + + <para><programlisting># /usr/lib/repart.d/60-root-verity.conf +[Partition] +Type=root-verity +SizeMinBytes=64M +SizeMaxBytes=64M +</programlisting></para> + + <para>The definitions above cover the "A" set of root partition (of a fixed 512M size) and Verity + partition for the root partition (of a fixed 64M size). Let's use symlinks to create the "B" set of + partitions, since after all they shall have the same properties and sizes as the "A" set.</para> + +<para><programlisting># ln -s 50-root.conf /usr/lib/repart.d/70-root-b.conf +# ln -s 60-root-verity.conf /usr/lib/repart.d/80-root-verity-b.conf +</programlisting></para> + </example> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>sfdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/resolvectl.xml b/man/resolvectl.xml new file mode 100644 index 0000000..fb6cae7 --- /dev/null +++ b/man/resolvectl.xml @@ -0,0 +1,465 @@ +<?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-or-later --> + +<refentry id="resolvectl" conditional='ENABLE_RESOLVE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>resolvectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>resolvectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>resolvectl</refname> + <refname>resolvconf</refname> + <refpurpose>Resolve domain names, IPV4 and IPv6 addresses, DNS resource records, and services; introspect and reconfigure the DNS resolver</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>resolvectl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>resolvectl</command> may be used to resolve domain names, IPv4 and IPv6 addresses, DNS resource + records and services with the + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + resolver service. By default, the specified list of parameters will be resolved as hostnames, retrieving their IPv4 + and IPv6 addresses. If the parameters specified are formatted as IPv4 or IPv6 operation the reverse operation is + done, and a hostname is retrieved for the specified addresses.</para> + + <para>The program's output contains information about the protocol used for the look-up and on which network + interface the data was discovered. It also contains information on whether the information could be + authenticated. All data for which local DNSSEC validation succeeds is considered authenticated. Moreover all data + originating from local, trusted sources is also reported authenticated, including resolution of the local host + name, the <literal>localhost</literal> hostname or all data from <filename>/etc/hosts</filename>.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + <variablelist> + + <varlistentry> + <term><command>query</command> <replaceable>HOSTNAME|ADDRESS</replaceable>…</term> + + <listitem><para>Resolve domain names, IPv4 and IPv6 addresses.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>service</command> + [[<replaceable>NAME</replaceable>] <replaceable>TYPE</replaceable>] + <replaceable>DOMAIN</replaceable></term> + + <listitem><para>Resolve <ulink url="https://tools.ietf.org/html/rfc6763">DNS-SD</ulink> and + <ulink url="https://tools.ietf.org/html/rfc2782">SRV</ulink> services, depending on the specified list of parameters. + If three parameters are passed the first is assumed to be the DNS-SD service name, the second the SRV service type, + and the third the domain to search in. In this case a full DNS-SD style SRV and TXT lookup is executed. If only two + parameters are specified, the first is assumed to be the SRV service type, and the second the domain to look in. In + this case no TXT RR is requested. Finally, if only one parameter is specified, it is assumed to be a domain name, + that is already prefixed with an SRV type, and an SRV lookup is done (no TXT).</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>openpgp</command> <replaceable>EMAIL@DOMAIN</replaceable>…</term> + + <listitem><para>Query PGP keys stored as <ulink url="https://tools.ietf.org/html/rfc7929">OPENPGPKEY</ulink> + resource records. Specified e-mail addresses are converted to the corresponding DNS domain name, and any + OPENPGPKEY keys are printed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>tlsa</command> + [<replaceable>FAMILY</replaceable>] + <replaceable>DOMAIN</replaceable>[:<replaceable>PORT</replaceable>]…</term> + + <listitem><para>Query TLS public keys stored as <ulink url="https://tools.ietf.org/html/rfc6698">TLSA</ulink> + resource records. A query will be performed for each of the specified names prefixed with the port and family + (<literal>_<replaceable>port</replaceable>._<replaceable>family</replaceable>.<replaceable>domain</replaceable></literal>). + The port number may be specified after a colon (<literal>:</literal>), otherwise <constant>443</constant> will be used + by default. The family may be specified as the first argument, otherwise <constant>tcp</constant> will be used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>status</command> [<replaceable>LINK</replaceable>…]</term> + + <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> + + <varlistentry> + <term><command>statistics</command></term> + + <listitem><para>Shows general resolver statistics, including information whether DNSSEC is + enabled and available, as well as resolution and validation statistics.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>reset-statistics</command></term> + + <listitem><para>Resets the statistics counters shown in <command>statistics</command> to zero. + This operation requires root privileges.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>flush-caches</command></term> + + <listitem><para>Flushes all DNS resource record caches the service maintains locally. This is mostly equivalent + to sending the <constant>SIGUSR2</constant> to the <command>systemd-resolved</command> + service.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>reset-server-features</command></term> + + <listitem><para>Flushes all feature level information the resolver learnt about specific servers, and ensures + that the server feature probing logic is started from the beginning with the next look-up request. This is + mostly equivalent to sending the <constant>SIGRTMIN+1</constant> to the <command>systemd-resolved</command> + service.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>dns</command> [<replaceable>LINK</replaceable> [<replaceable>SERVER</replaceable>…]]</term> + <term><command>domain</command> [<replaceable>LINK</replaceable> [<replaceable>DOMAIN</replaceable>…]]</term> + <term><command>default-route</command> [<replaceable>LINK</replaceable> [<replaceable>BOOL</replaceable>…]]</term> + <term><command>llmnr</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term> + <term><command>mdns</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term> + <term><command>dnssec</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term> + <term><command>dnsovertls</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term> + <term><command>nta</command> [<replaceable>LINK</replaceable> [<replaceable>DOMAIN</replaceable>…]]</term> + + <listitem> + <para>Get/set per-interface DNS configuration. These commands may be used to configure various DNS + settings 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 <command>dns</command> command expects IPv4 or + IPv6 address specifications of DNS servers to use. Each address can optionally take a port number + separated with <literal>:</literal>, a network interface name or index separated with + <literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>. When + IPv6 address is specified with a port number, then the address must be in the square brackets. That + is, the acceptable full formats are <literal>111.222.333.444:9953%ifname#example.com</literal> for + IPv4 and <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. The + <command>domain</command> command expects valid DNS domains, possibly prefixed with + <literal>~</literal>, and configures a per-interface search or route-only domain. The + <command>default-route</command> 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 <command>llmnr</command>, <command>mdns</command>, + <command>dnssec</command> and <command>dnsovertls</command> commands may be used to configure the + per-interface LLMNR, MulticastDNS, DNSSEC and DNSOverTLS settings. Finally, <command>nta</command> + command may be used to configure additional per-interface DNSSEC NTA domains.</para> + + <para>Commands <command>dns</command>, <command>domain</command> and <command>nta</command> can take + a single empty string argument to clear their respective value lists.</para> + + <para>For details about these settings, their possible values and their effect, see the + corresponding settings in + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>revert <replaceable>LINK</replaceable></command></term> + + <listitem><para>Revert the per-interface DNS configuration. If the DNS configuration is reverted all + per-interface DNS setting are reset to their defaults, undoing all effects of <command>dns</command>, + <command>domain</command>, <command>default-route</command>, <command>llmnr</command>, + <command>mdns</command>, <command>dnssec</command>, <command>dnsovertls</command>, + <command>nta</command>. Note that when a network interface disappears all configuration is lost + automatically, an explicit reverting is not necessary in that case.</para></listitem> + </varlistentry> + + <xi:include href="systemctl.xml" xpointer="log-level" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Options</title> + <variablelist> + <varlistentry> + <term><option>-4</option></term> + <term><option>-6</option></term> + + <listitem><para>By default, when resolving a hostname, both IPv4 and IPv6 + addresses are acquired. By specifying <option>-4</option> only IPv4 addresses are requested, by specifying + <option>-6</option> only IPv6 addresses are requested.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-i</option> <replaceable>INTERFACE</replaceable></term> + <term><option>--interface=</option><replaceable>INTERFACE</replaceable></term> + + <listitem><para>Specifies the network interface to execute the query on. This may either be specified as numeric + interface index or as network interface string (e.g. <literal>en0</literal>). Note that this option has no + effect if system-wide DNS configuration (as configured in <filename>/etc/resolv.conf</filename> or + <filename>/etc/systemd/resolve.conf</filename>) in place of per-link configuration is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option> <replaceable>PROTOCOL</replaceable></term> + <term><option>--protocol=</option><replaceable>PROTOCOL</replaceable></term> + + <listitem><para>Specifies the network protocol for the query. May be one of <literal>dns</literal> + (i.e. classic unicast DNS), <literal>llmnr</literal> (<ulink + url="https://tools.ietf.org/html/rfc4795">Link-Local Multicast Name Resolution</ulink>), + <literal>llmnr-ipv4</literal>, <literal>llmnr-ipv6</literal> (LLMNR via the indicated underlying IP + protocols), <literal>mdns</literal> (<ulink url="https://www.ietf.org/rfc/rfc6762.txt">Multicast DNS</ulink>), + <literal>mdns-ipv4</literal>, <literal>mdns-ipv6</literal> (MDNS via the indicated underlying IP protocols). + By default the lookup is done via all protocols suitable for the lookup. If used, limits the set of + protocols that may be used. Use this option multiple times to enable resolving via multiple protocols at the + same time. The setting <literal>llmnr</literal> is identical to specifying this switch once with + <literal>llmnr-ipv4</literal> and once via <literal>llmnr-ipv6</literal>. Note that this option does not force + the service to resolve the operation with the specified protocol, as that might require a suitable network + interface and configuration. + The special value <literal>help</literal> may be used to list known values. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-t</option> <replaceable>TYPE</replaceable></term> + <term><option>--type=</option><replaceable>TYPE</replaceable></term> + <term><option>-c</option> <replaceable>CLASS</replaceable></term> + <term><option>--class=</option><replaceable>CLASS</replaceable></term> + + <listitem><para>Specifies the DNS resource record type (e.g. A, AAAA, MX, …) and class (e.g. IN, ANY, …) to + look up. If these options are used a DNS resource record set matching the specified class and type is + requested. The class defaults to IN if only a type is specified. + The special value <literal>help</literal> may be used to list known values. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--service-address=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean parameter. If true (the default), when doing a service lookup with + <option>--service</option> the hostnames contained in the SRV resource records are resolved as well.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--service-txt=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean parameter. If true (the default), when doing a DNS-SD service lookup with + <option>--service</option> the TXT service metadata record is resolved as well.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cname=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean parameter. If true (the default), DNS CNAME or DNAME redirections are + followed. Otherwise, if a CNAME or DNAME record is encountered while resolving, an error is + returned.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--search=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean parameter. If true (the default), any specified single-label hostnames will be + searched in the domains configured in the search domain list, if it is non-empty. Otherwise, the search domain + logic is disabled.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--raw</option><optional>=payload|packet</optional></term> + + <listitem><para>Dump the answer as binary data. If there is no argument or if the argument is + <literal>payload</literal>, the payload of the packet is exported. If the argument is + <literal>packet</literal>, the whole packet is dumped in wire format, prefixed by + length specified as a little-endian 64-bit number. This format allows multiple packets + to be dumped and unambiguously parsed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--legend=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Takes a boolean parameter. If true (the default), column headers and meta information about the + query response are shown. Otherwise, this output is suppressed.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Compatibility with + <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry></title> + + <para><command>resolvectl</command> is a multi-call binary. When invoked as <literal>resolvconf</literal> + (generally achieved by means of a symbolic link of this name to the <command>resolvectl</command> binary) it + is run in a limited + <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry> + compatibility mode. It accepts mostly the same arguments and pushes all data into + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + similar to how <option>dns</option> and <option>domain</option> commands operate. Note that + <command>systemd-resolved.service</command> is the only supported backend, which is different from other + implementations of this command.</para> + + <para><filename>/etc/resolv.conf</filename> will only be updated with servers added with this command + when <filename>/etc/resolv.conf</filename> is a symlink to + <filename>/run/systemd/resolve/resolv.conf</filename>, and not a static file. See the discussion of + <filename>/etc/resolv.conf</filename> handling in + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para>Not all operations supported by other implementations are supported natively. Specifically:</para> + + <variablelist> + <varlistentry> + <term><option>-a</option></term> + <listitem><para>Registers per-interface DNS configuration data with + <command>systemd-resolved</command>. Expects a network interface name as only command line argument. Reads + <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>-compatible + DNS configuration data from its standard input. Relevant fields are <literal>nameserver</literal> and + <literal>domain</literal>/<literal>search</literal>. This command is mostly identical to invoking + <command>resolvectl</command> with a combination of <option>dns</option> and <option>domain</option> + commands.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-d</option></term> + <listitem><para>Unregisters per-interface DNS configuration data with <command>systemd-resolved</command>. This + command is mostly identical to invoking <command>resolvectl revert</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-f</option></term> + + <listitem><para>When specified <option>-a</option> and <option>-d</option> will not complain about missing + network interfaces and will silently execute no operation in that case.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-x</option></term> + + <listitem><para>This switch for "exclusive" operation is supported only partially. It is mapped to an + additional configured search domain of <literal>~.</literal> — i.e. ensures that DNS traffic is preferably + routed to the DNS servers on this interface, unless there are other, more specific domains configured on other + interfaces.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-m</option></term> + <term><option>-p</option></term> + + <listitem><para>These switches are not supported and are silently ignored.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-u</option></term> + <term><option>-I</option></term> + <term><option>-i</option></term> + <term><option>-l</option></term> + <term><option>-R</option></term> + <term><option>-r</option></term> + <term><option>-v</option></term> + <term><option>-V</option></term> + <term><option>--enable-updates</option></term> + <term><option>--disable-updates</option></term> + <term><option>--are-updates-enabled</option></term> + + <listitem><para>These switches are not supported and the command will fail if used.</para></listitem> + </varlistentry> + + </variablelist> + + <para>See + <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details on those command line options.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Retrieve the addresses of the <literal>www.0pointer.net</literal> domain</title> + + <programlisting>$ resolvectl query www.0pointer.net +www.0pointer.net: 2a01:238:43ed:c300:10c3:bcf3:3266:da74 + 85.214.157.71 + +-- Information acquired via protocol DNS in 611.6ms. +-- Data is authenticated: no +</programlisting> + </example> + + <example> + <title>Retrieve the domain of the <literal>85.214.157.71</literal> IP address</title> + + <programlisting>$ resolvectl query 85.214.157.71 +85.214.157.71: gardel.0pointer.net + +-- Information acquired via protocol DNS in 1.2997s. +-- Data is authenticated: no +</programlisting> + </example> + + <example> + <title>Retrieve the MX record of the <literal>yahoo.com</literal> domain</title> + + <programlisting>$ resolvectl --legend=no -t MX query yahoo.com +yahoo.com. IN MX 1 mta7.am0.yahoodns.net +yahoo.com. IN MX 1 mta6.am0.yahoodns.net +yahoo.com. IN MX 1 mta5.am0.yahoodns.net +</programlisting> + </example> + + <example> + <title>Resolve an SRV service</title> + + <programlisting>$ resolvectl service _xmpp-server._tcp gmail.com +_xmpp-server._tcp/gmail.com: alt1.xmpp-server.l.google.com:5269 [priority=20, weight=0] + 173.194.210.125 + alt4.xmpp-server.l.google.com:5269 [priority=20, weight=0] + 173.194.65.125 + … +</programlisting> + </example> + + <example> + <title>Retrieve a PGP key</title> + + <programlisting>$ resolvectl openpgp zbyszek@fedoraproject.org +d08ee310438ca124a6149ea5cc21b6313b390dce485576eff96f8722._openpgpkey.fedoraproject.org. IN OPENPGPKEY + mQINBFBHPMsBEACeInGYJCb+7TurKfb6wGyTottCDtiSJB310i37/6ZYoeIay/5soJjlMyf + MFQ9T2XNT/0LM6gTa0MpC1st9LnzYTMsT6tzRly1D1UbVI6xw0g0vE5y2Cjk3xUwAynCsSs + … +</programlisting> + </example> + + <example> + <title>Retrieve a TLS key (<literal>tcp</literal> and + <literal>:443</literal> could be skipped)</title> + + <programlisting>$ resolvectl tlsa tcp fedoraproject.org:443 +_443._tcp.fedoraproject.org IN TLSA 0 0 1 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0 + -- Cert. usage: CA constraint + -- Selector: Full Certificate + -- Matching type: SHA-256 +</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.dnssd</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml new file mode 100644 index 0000000..35a5740 --- /dev/null +++ b/man/resolved.conf.xml @@ -0,0 +1,333 @@ +<?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-or-later --> + +<refentry id="resolved.conf" conditional='ENABLE_RESOLVE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>resolved.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>resolved.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>resolved.conf</refname> + <refname>resolved.conf.d</refname> + <refpurpose>Network Name Resolution configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/resolved.conf</filename></para> + <para><filename>/etc/systemd/resolved.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/resolved.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/resolved.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These configuration files control local DNS and LLMNR + name resolution.</para> + + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>The following options are available in the [Resolve] section:</para> + + <variablelist class='network-directives'> + + <varlistentry> + <term><varname>DNS=</varname></term> + <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can + optionally take a port number separated with <literal>:</literal>, a network interface name or index separated with + <literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>. When IPv6 address is + specified with a port number, then the address must be in the square brackets. That is, the acceptable full formats + are <literal>111.222.333.444:9953%ifname#example.com</literal> for IPv4 and + <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. DNS requests are sent to one of the listed + DNS servers in parallel to suitable per-link DNS servers acquired from + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> or + set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS + servers listed in <filename>/etc/resolv.conf</filename> are used instead, if that file exists and any servers + are configured in it. This setting defaults to the empty list.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FallbackDNS=</varname></term> + <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see + <varname>DNS=</varname> for acceptable format of addresses. Any per-link DNS servers obtained from + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + take precedence over this setting, as do any servers set via <varname>DNS=</varname> above or + <filename>/etc/resolv.conf</filename>. This setting is hence only used if no other DNS server information is + known. If this option is not given, a compiled-in list of DNS servers is used instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Domains=</varname></term> + <listitem><para>A space-separated list of domains optionally prefixed with <literal>~</literal>, + used for two distinct purposes described below. Defaults to the empty list.</para> + + <para>Any domains <emphasis>not</emphasis> prefixed with <literal>~</literal> are used as search + suffixes when resolving single-label hostnames (domain names which contain no dot), in order to + qualify them into fully-qualified domain names (FQDNs). These "search domains" are strictly processed + in the order they are specified in, until the name with the suffix appended is found. For + compatibility reasons, if this setting is not specified, the search domains listed in + <filename>/etc/resolv.conf</filename> with the <varname>search</varname> keyword are used instead, if + that file exists and any domains are configured in it.</para> + + <para>The domains prefixed with <literal>~</literal> are called "routing domains". All domains listed + here (both search domains and routing domains after removing the <literal>~</literal> prefix) define + a search path that preferably directs DNS queries to this interface. This search path has an effect + only when suitable per-link DNS servers are known. Such servers may be defined through the + <varname>DNS=</varname> setting (see above) and dynamically at run time, for example from DHCP + leases. If no per-link DNS servers are known, routing domains have no effect.</para> + + <para>Use the construct <literal>~.</literal> (which is composed from <literal>~</literal> to + indicate a routing domain and <literal>.</literal> to indicate the DNS root domain that is the + implied suffix of all DNS domains) to use the DNS servers defined for this link preferably for all + domains.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LLMNR=</varname></term> + <listitem><para>Takes a boolean argument or + <literal>resolve</literal>. Controls Link-Local Multicast Name + Resolution support (<ulink + url="https://tools.ietf.org/html/rfc4795">RFC 4795</ulink>) on + the local host. If true, enables full LLMNR responder and + resolver support. If false, disables both. If set to + <literal>resolve</literal>, only resolution support is enabled, + but responding is disabled. Note that + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + also maintains per-link LLMNR settings. LLMNR will be + enabled on a link only if the per-link and the + global setting is on.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MulticastDNS=</varname></term> + <listitem><para>Takes a boolean argument or + <literal>resolve</literal>. Controls Multicast DNS support (<ulink + url="https://tools.ietf.org/html/rfc6762">RFC 6762</ulink>) on + the local host. If true, enables full Multicast DNS responder and + resolver support. If false, disables both. If set to + <literal>resolve</literal>, only resolution support is enabled, + but responding is disabled. Note that + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + also maintains per-link Multicast DNS settings. Multicast DNS will be + enabled on a link only if the per-link and the + global setting is on.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DNSSEC=</varname></term> + <listitem><para>Takes a boolean argument or + <literal>allow-downgrade</literal>. If true all DNS lookups are + DNSSEC-validated locally (excluding LLMNR and Multicast + DNS). If the response to a lookup request is detected to be invalid + a lookup failure is returned to applications. Note that + this mode requires a DNS server that supports DNSSEC. If the + DNS server does not properly support DNSSEC all validations + will fail. If set to <literal>allow-downgrade</literal> DNSSEC + validation is attempted, but if the server does not support + DNSSEC properly, DNSSEC mode is automatically disabled. Note + that this mode makes DNSSEC validation vulnerable to + "downgrade" attacks, where an attacker might be able to + trigger a downgrade to non-DNSSEC mode by synthesizing a DNS + response that suggests DNSSEC was not supported. If set to + false, DNS lookups are not DNSSEC validated.</para> + + <para>Note that DNSSEC validation requires retrieval of + additional DNS data, and thus results in a small DNS look-up + time penalty.</para> + + <para>DNSSEC requires knowledge of "trust anchors" to prove + data integrity. The trust anchor for the Internet root domain + is built into the resolver, additional trust anchors may be + defined with + <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Trust anchors may change at regular intervals, and old trust + anchors may be revoked. In such a case DNSSEC validation is + not possible until new trust anchors are configured locally or + the resolver software package is updated with the new root + trust anchor. In effect, when the built-in trust anchor is + revoked and <varname>DNSSEC=</varname> is true, all further + lookups will fail, as it cannot be proved anymore whether + lookups are correctly signed, or validly unsigned. If + <varname>DNSSEC=</varname> is set to + <literal>allow-downgrade</literal> the resolver will + automatically turn off DNSSEC validation in such a case.</para> + + <para>Client programs looking up DNS data will be informed + whether lookups could be verified using DNSSEC, or whether the + returned data could not be verified (either because the data + was found unsigned in the DNS, or the DNS server did not + support DNSSEC or no appropriate trust anchors were known). In + the latter case it is assumed that client programs employ a + secondary scheme to validate the returned DNS data, should + this be required.</para> + + <para>It is recommended to set <varname>DNSSEC=</varname> to + true on systems where it is known that the DNS server supports + DNSSEC correctly, and where software or trust anchor updates + happen regularly. On other systems it is recommended to set + <varname>DNSSEC=</varname> to + <literal>allow-downgrade</literal>.</para> + + <para>In addition to this global DNSSEC setting + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + also maintains per-link DNSSEC settings. For system DNS + servers (see above), only the global DNSSEC setting is in + effect. For per-link DNS servers the per-link + setting is in effect, unless it is unset in which case the + global setting is used instead.</para> + + <para>Site-private DNS zones generally conflict with DNSSEC + operation, unless a negative (if the private zone is not + signed) or positive (if the private zone is signed) trust + anchor is configured for them. If + <literal>allow-downgrade</literal> mode is selected, it is + attempted to detect site-private DNS zones using top-level + domains (TLDs) that are not known by the DNS root server. This + logic does not work in all private zone setups.</para> + + <para>Defaults to <literal>allow-downgrade</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DNSOverTLS=</varname></term> + <listitem> + <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. If the hostname was specified in <varname>DNS=</varname> + by using the format format <literal>address#server_name</literal> it + is used to validate its certificate and also to enable Server Name + Indication (SNI) when opening a TLS connection. Otherwise + the certificate is checked against the server's IP. + If the DNS server does not support DNS-over-TLS all DNS requests will fail.</para> + + <para>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" + attacks, where an attacker might be able to trigger a downgrade + to non-encrypted mode by synthesizing a response that suggests + DNS-over-TLS was not supported. If set to false, DNS lookups + are send over UDP.</para> + + <para>Note that DNS-over-TLS requires additional data to be + send for setting up an encrypted connection, and thus results + in a small DNS look-up time penalty.</para> + + <para>Note that in <literal>opportunistic</literal> mode the + resolver is not capable of authenticating the server, so it is + vulnerable to "man-in-the-middle" attacks.</para> + + <para>In addition to this global <varname>DNSOverTLS=</varname> setting + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + also maintains per-link <varname>DNSOverTLS=</varname> settings. For system DNS servers (see above), only the global + <varname>DNSOverTLS=</varname> setting is in effect. For per-link DNS servers the per-link setting is in effect, unless + it is unset in which case the global setting is used instead.</para> + + <para>Defaults to off.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Cache=</varname></term> + <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. If <literal>no-negative</literal>, only positive answers are cached.</para> + + <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> + </varlistentry> + + <varlistentry> + <term><varname>DNSStubListener=</varname></term> + <listitem><para>Takes a boolean argument or one of <literal>udp</literal> and <literal>tcp</literal>. If + <literal>udp</literal>, a DNS stub resolver will listen for UDP requests on address 127.0.0.53 + port 53. If <literal>tcp</literal>, the stub will listen for TCP requests on the same address and port. If + <literal>yes</literal> (the default), the stub listens for both UDP and TCP requests. If <literal>no</literal>, the stub + listener is disabled.</para> + + <para>Note that the DNS stub listener is turned off implicitly when its listening address and port are already + in use.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DNSStubListenerExtra=</varname></term> + <listitem><para>Takes an IPv4 or IPv6 address to listen on. The address may be optionally + prefixed with a protocol name (<literal>udp</literal> or <literal>tcp</literal>) separated with + <literal>:</literal>. If the protocol is not specified, the service will listen on both UDP and + TCP. It may be also optionally suffixed by a numeric port number with separator + <literal>:</literal>. When an IPv6 address is specified with a port number, then the address + must be in the square brackets. If the port is not specified, then the service uses port 53. + Note that this is independent of the primary DNS stub configured with + <varname>DNSStubListener=</varname>, and only configures <emphasis>additional</emphasis> + sockets to listen on. This option can be specified multiple times. If an empty string is + assigned, then the all previous assignments are cleared. Defaults to unset.</para> + + <para>Examples: + <programlisting>DNSStubListenerExtra=192.168.10.10 +DNSStubListenerExtra=2001:db8:0:f102::10 +DNSStubListenerExtra=192.168.10.11:9953 +DNSStubListenerExtra=[2001:db8:0:f102::11]:9953 +DNSStubListenerExtra=tcp:192.168.10.12 +DNSStubListenerExtra=udp:2001:db8:0:f102::12 +DNSStubListenerExtra=tcp:192.168.10.13:9953 +DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953</programlisting> + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReadEtcHosts=</varname></term> + <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default), + <command>systemd-resolved</command> will read <filename>/etc/hosts</filename>, and try to resolve + hosts or address by using the entries in the file before sending query to DNS servers. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ResolveUnicastSingleLabel=</varname></term> + <listitem><para>Takes a boolean argument. When false (the default), + <command>systemd-resolved</command> will not resolve A and AAAA queries for single-label names over + classic DNS. Note that such names may still be resolved if search domains are specified (see + <varname>Domains=</varname> above), or using other mechanisms, in particular via LLMNR or from + <filename>/etc/hosts</filename>. When true, queries for single-label names will be forwarded to + global DNS servers even if no search domains are defined. + </para> + + <para>This option is provided for compatibility with configurations where <emphasis>public DNS + servers are not used</emphasis>. Forwarding single-label names to servers not under your control is + not standard-conformant, see <ulink + url="https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/">IAB + Statement</ulink>, and may create a privacy and security risk.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>4</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/rules/meson.build b/man/rules/meson.build new file mode 100644 index 0000000..cacbbd7 --- /dev/null +++ b/man/rules/meson.build @@ -0,0 +1,1123 @@ +# Do not edit. Generated by update-man-rules.py. +# Update with: +# ninja -C build man/update-man-rules +manpages = [ +['binfmt.d', '5', [], 'ENABLE_BINFMT'], + ['bootctl', '1', [], 'ENABLE_EFI'], + ['bootup', '7', [], ''], + ['busctl', '1', [], ''], + ['coredump.conf', '5', ['coredump.conf.d'], 'ENABLE_COREDUMP'], + ['coredumpctl', '1', [], 'ENABLE_COREDUMP'], + ['crypttab', '5', [], 'HAVE_LIBCRYPTSETUP'], + ['daemon', '7', [], ''], + ['dnssec-trust-anchors.d', + '5', + ['systemd.negative', 'systemd.positive'], + 'ENABLE_RESOLVE'], + ['environment.d', '5', [], 'ENABLE_ENVIRONMENT_D'], + ['file-hierarchy', '7', [], ''], + ['halt', '8', ['poweroff', 'reboot'], ''], + ['homectl', '1', [], 'ENABLE_HOMED'], + ['homed.conf', '5', ['homed.conf.d'], 'ENABLE_HOMED'], + ['hostname', '5', [], ''], + ['hostnamectl', '1', [], 'ENABLE_HOSTNAMED'], + ['hwdb', '7', [], 'ENABLE_HWDB'], + ['journal-remote.conf', '5', ['journal-remote.conf.d'], 'HAVE_MICROHTTPD'], + ['journal-upload.conf', '5', ['journal-upload.conf.d'], 'HAVE_MICROHTTPD'], + ['journalctl', '1', [], ''], + ['journald.conf', '5', ['journald.conf.d', 'journald@.conf'], ''], + ['kernel-command-line', '7', [], ''], + ['kernel-install', '8', [], ''], + ['libudev', '3', [], ''], + ['loader.conf', '5', [], 'ENABLE_EFI'], + ['locale.conf', '5', [], ''], + ['localectl', '1', [], 'ENABLE_LOCALED'], + ['localtime', '5', [], ''], + ['loginctl', '1', [], 'ENABLE_LOGIND'], + ['logind.conf', '5', ['logind.conf.d'], 'ENABLE_LOGIND'], + ['machine-id', '5', [], ''], + ['machine-info', '5', [], ''], + ['machinectl', '1', [], 'ENABLE_MACHINED'], + ['modules-load.d', '5', [], 'HAVE_KMOD'], + ['networkctl', '1', [], 'ENABLE_NETWORKD'], + ['networkd.conf', '5', ['networkd.conf.d'], 'ENABLE_NETWORKD'], + ['nss-myhostname', '8', ['libnss_myhostname.so.2'], 'ENABLE_NSS_MYHOSTNAME'], + ['nss-mymachines', '8', ['libnss_mymachines.so.2'], 'ENABLE_NSS_MYMACHINES'], + ['nss-resolve', '8', ['libnss_resolve.so.2'], 'ENABLE_NSS_RESOLVE'], + ['nss-systemd', '8', ['libnss_systemd.so.2'], 'ENABLE_NSS_SYSTEMD'], + ['oomctl', '1', [], 'ENABLE_OOMD'], + ['oomd.conf', '5', ['oomd.conf.d'], 'ENABLE_OOMD'], + ['org.freedesktop.LogControl1', '5', [], ''], + ['org.freedesktop.home1', '5', [], 'ENABLE_HOMED'], + ['org.freedesktop.hostname1', '5', [], 'ENABLE_HOSTNAMED'], + ['org.freedesktop.import1', '5', [], 'ENABLE_IMPORTD'], + ['org.freedesktop.locale1', '5', [], 'ENABLE_LOCALED'], + ['org.freedesktop.login1', '5', [], 'ENABLE_LOGIND'], + ['org.freedesktop.machine1', '5', [], 'ENABLE_MACHINED'], + ['org.freedesktop.oom1', '5', [], 'ENABLE_OOMD'], + ['org.freedesktop.resolve1', '5', [], 'ENABLE_RESOLVE'], + ['org.freedesktop.systemd1', '5', [], ''], + ['org.freedesktop.timedate1', '5', [], 'ENABLE_TIMEDATED'], + ['os-release', '5', [], ''], + ['pam_systemd', '8', [], 'HAVE_PAM'], + ['pam_systemd_home', '8', [], 'ENABLE_PAM_HOME'], + ['portablectl', '1', [], 'ENABLE_PORTABLED'], + ['pstore.conf', '5', ['pstore.conf.d'], 'ENABLE_PSTORE'], + ['repart.d', '5', [], 'ENABLE_REPART'], + ['resolvectl', '1', ['resolvconf'], 'ENABLE_RESOLVE'], + ['resolved.conf', '5', ['resolved.conf.d'], 'ENABLE_RESOLVE'], + ['runlevel', '8', [], 'HAVE_SYSV_COMPAT'], + ['sd-bus-errors', + '3', + ['SD_BUS_ERROR_ACCESS_DENIED', + 'SD_BUS_ERROR_ADDRESS_IN_USE', + 'SD_BUS_ERROR_AUTH_FAILED', + 'SD_BUS_ERROR_BAD_ADDRESS', + 'SD_BUS_ERROR_DISCONNECTED', + 'SD_BUS_ERROR_FAILED', + 'SD_BUS_ERROR_FILE_EXISTS', + 'SD_BUS_ERROR_FILE_NOT_FOUND', + 'SD_BUS_ERROR_INCONSISTENT_MESSAGE', + 'SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED', + 'SD_BUS_ERROR_INVALID_ARGS', + 'SD_BUS_ERROR_INVALID_SIGNATURE', + 'SD_BUS_ERROR_IO_ERROR', + 'SD_BUS_ERROR_LIMITS_EXCEEDED', + 'SD_BUS_ERROR_MATCH_RULE_INVALID', + 'SD_BUS_ERROR_MATCH_RULE_NOT_FOUND', + 'SD_BUS_ERROR_NAME_HAS_NO_OWNER', + 'SD_BUS_ERROR_NOT_SUPPORTED', + 'SD_BUS_ERROR_NO_MEMORY', + 'SD_BUS_ERROR_NO_NETWORK', + 'SD_BUS_ERROR_NO_REPLY', + 'SD_BUS_ERROR_NO_SERVER', + 'SD_BUS_ERROR_PROPERTY_READ_ONLY', + 'SD_BUS_ERROR_SERVICE_UNKNOWN', + 'SD_BUS_ERROR_TIMEOUT', + 'SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN', + 'SD_BUS_ERROR_UNKNOWN_INTERFACE', + 'SD_BUS_ERROR_UNKNOWN_METHOD', + 'SD_BUS_ERROR_UNKNOWN_OBJECT', + 'SD_BUS_ERROR_UNKNOWN_PROPERTY'], + ''], + ['sd-bus', '3', [], ''], + ['sd-daemon', + '3', + ['SD_ALERT', + 'SD_CRIT', + 'SD_DEBUG', + 'SD_EMERG', + 'SD_ERR', + 'SD_INFO', + 'SD_NOTICE', + 'SD_WARNING'], + ''], + ['sd-event', '3', [], ''], + ['sd-hwdb', '3', [], ''], + ['sd-id128', + '3', + ['SD_ID128_CONST_STR', + 'SD_ID128_FORMAT_STR', + 'SD_ID128_FORMAT_VAL', + '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'], + ''], + ['sd-journal', '3', [], ''], + ['sd-login', '3', [], 'HAVE_PAM'], + ['sd_booted', '3', [], ''], + ['sd_bus_add_match', + '3', + ['sd_bus_add_match_async', + 'sd_bus_match_signal', + 'sd_bus_match_signal_async'], + ''], + ['sd_bus_add_node_enumerator', '3', [], ''], + ['sd_bus_add_object', + '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', + 'sd_bus_add_fallback_vtable', + 'sd_bus_add_filter', + 'sd_bus_add_object_vtable'], + ''], + ['sd_bus_add_object_manager', '3', [], ''], + ['sd_bus_attach_event', '3', ['sd_bus_detach_event', 'sd_bus_get_event'], ''], + ['sd_bus_call', '3', ['sd_bus_call_async'], ''], + ['sd_bus_call_method', + '3', + ['sd_bus_call_method_async', + 'sd_bus_call_method_asyncv', + 'sd_bus_call_methodv'], + ''], + ['sd_bus_can_send', '3', [], ''], + ['sd_bus_close', '3', ['sd_bus_default_flush_close', 'sd_bus_flush'], ''], + ['sd_bus_creds_get_pid', + '3', + ['sd_bus_creds_get_audit_login_uid', + 'sd_bus_creds_get_audit_session_id', + 'sd_bus_creds_get_cgroup', + 'sd_bus_creds_get_cmdline', + 'sd_bus_creds_get_comm', + 'sd_bus_creds_get_description', + 'sd_bus_creds_get_egid', + 'sd_bus_creds_get_euid', + 'sd_bus_creds_get_exe', + 'sd_bus_creds_get_fsgid', + 'sd_bus_creds_get_fsuid', + 'sd_bus_creds_get_gid', + 'sd_bus_creds_get_owner_uid', + 'sd_bus_creds_get_ppid', + 'sd_bus_creds_get_selinux_context', + 'sd_bus_creds_get_session', + 'sd_bus_creds_get_sgid', + 'sd_bus_creds_get_slice', + 'sd_bus_creds_get_suid', + 'sd_bus_creds_get_supplementary_gids', + 'sd_bus_creds_get_tid', + 'sd_bus_creds_get_tid_comm', + 'sd_bus_creds_get_tty', + 'sd_bus_creds_get_uid', + 'sd_bus_creds_get_unique_name', + 'sd_bus_creds_get_unit', + 'sd_bus_creds_get_user_slice', + 'sd_bus_creds_get_user_unit', + 'sd_bus_creds_get_well_known_names', + 'sd_bus_creds_has_bounding_cap', + 'sd_bus_creds_has_effective_cap', + 'sd_bus_creds_has_inheritable_cap', + 'sd_bus_creds_has_permitted_cap'], + ''], + ['sd_bus_creds_new_from_pid', + '3', + ['sd_bus_creds_get_augmented_mask', + 'sd_bus_creds_get_mask', + 'sd_bus_creds_ref', + 'sd_bus_creds_unref', + 'sd_bus_creds_unrefp'], + ''], + ['sd_bus_default', + '3', + ['sd_bus_default_system', + 'sd_bus_default_user', + 'sd_bus_open', + 'sd_bus_open_system', + 'sd_bus_open_system_machine', + 'sd_bus_open_system_remote', + 'sd_bus_open_system_with_description', + 'sd_bus_open_user', + 'sd_bus_open_user_with_description', + 'sd_bus_open_with_description'], + ''], + ['sd_bus_emit_signal', + '3', + ['sd_bus_emit_interfaces_added', + 'sd_bus_emit_interfaces_added_strv', + 'sd_bus_emit_interfaces_removed', + 'sd_bus_emit_interfaces_removed_strv', + 'sd_bus_emit_object_added', + 'sd_bus_emit_object_removed', + 'sd_bus_emit_properties_changed', + 'sd_bus_emit_properties_changed_strv', + 'sd_bus_emit_signalv'], + ''], + ['sd_bus_enqueue_for_read', '3', [], ''], + ['sd_bus_error', + '3', + ['SD_BUS_ERROR_MAKE_CONST', + 'SD_BUS_ERROR_NULL', + 'sd_bus_error_copy', + 'sd_bus_error_free', + 'sd_bus_error_get_errno', + 'sd_bus_error_has_name', + 'sd_bus_error_has_names', + 'sd_bus_error_has_names_sentinel', + 'sd_bus_error_is_set', + 'sd_bus_error_move', + 'sd_bus_error_set', + 'sd_bus_error_set_const', + 'sd_bus_error_set_errno', + 'sd_bus_error_set_errnof', + 'sd_bus_error_set_errnofv', + 'sd_bus_error_setf'], + ''], + ['sd_bus_error_add_map', + '3', + ['SD_BUS_ERROR_END', 'SD_BUS_ERROR_MAP', 'sd_bus_error_map'], + ''], + ['sd_bus_get_current_handler', + '3', + ['sd_bus_get_current_message', + 'sd_bus_get_current_slot', + 'sd_bus_get_current_userdata'], + ''], + ['sd_bus_get_fd', + '3', + ['sd_bus_get_events', 'sd_bus_get_timeout', 'sd_bus_set_fd'], + ''], + ['sd_bus_get_n_queued_read', '3', ['sd_bus_get_n_queued_write'], ''], + ['sd_bus_get_name_creds', '3', ['sd_bus_get_owner_creds'], ''], + ['sd_bus_get_name_machine_id', '3', [], ''], + ['sd_bus_interface_name_is_valid', + '3', + ['sd_bus_member_name_is_valid', + 'sd_bus_object_path_is_valid', + 'sd_bus_service_name_is_valid'], + ''], + ['sd_bus_is_open', '3', ['sd_bus_is_ready'], ''], + ['sd_bus_list_names', '3', [], ''], + ['sd_bus_message_append', '3', ['sd_bus_message_appendv'], ''], + ['sd_bus_message_append_array', + '3', + ['sd_bus_message_append_array_iovec', + 'sd_bus_message_append_array_memfd', + 'sd_bus_message_append_array_space'], + ''], + ['sd_bus_message_append_basic', '3', [], ''], + ['sd_bus_message_append_string_memfd', + '3', + ['sd_bus_message_append_string_iovec', 'sd_bus_message_append_string_space'], + ''], + ['sd_bus_message_append_strv', '3', [], ''], + ['sd_bus_message_at_end', '3', [], ''], + ['sd_bus_message_copy', '3', [], ''], + ['sd_bus_message_dump', '3', [], ''], + ['sd_bus_message_get_cookie', '3', ['sd_bus_message_get_reply_cookie'], ''], + ['sd_bus_message_get_monotonic_usec', + '3', + ['sd_bus_message_get_realtime_usec', 'sd_bus_message_get_seqnum'], + ''], + ['sd_bus_message_get_signature', + '3', + ['sd_bus_message_has_signature', 'sd_bus_message_is_empty'], + ''], + ['sd_bus_message_get_type', + '3', + ['sd_bus_message_get_creds', + 'sd_bus_message_get_errno', + 'sd_bus_message_get_error', + 'sd_bus_message_is_method_call', + 'sd_bus_message_is_method_error', + 'sd_bus_message_is_signal'], + ''], + ['sd_bus_message_new', + '3', + ['SD_BUS_MESSAGE_METHOD_CALL', + 'SD_BUS_MESSAGE_METHOD_ERROR', + 'SD_BUS_MESSAGE_METHOD_RETURN', + 'SD_BUS_MESSAGE_SIGNAL', + 'sd_bus_message_get_bus', + 'sd_bus_message_ref', + 'sd_bus_message_unref', + 'sd_bus_message_unrefp'], + ''], + ['sd_bus_message_new_method_call', + '3', + ['sd_bus_message_new_method_return'], + ''], + ['sd_bus_message_new_method_error', + '3', + ['sd_bus_message_new_method_errno', + 'sd_bus_message_new_method_errnof', + 'sd_bus_message_new_method_errorf'], + ''], + ['sd_bus_message_new_signal', '3', [], ''], + ['sd_bus_message_open_container', + '3', + ['sd_bus_message_close_container', + 'sd_bus_message_enter_container', + 'sd_bus_message_exit_container'], + ''], + ['sd_bus_message_read', + '3', + ['sd_bus_message_peek_type', 'sd_bus_message_readv'], + ''], + ['sd_bus_message_read_array', '3', [], ''], + ['sd_bus_message_read_basic', '3', [], ''], + ['sd_bus_message_read_strv', '3', [], ''], + ['sd_bus_message_rewind', '3', [], ''], + ['sd_bus_message_seal', '3', [], ''], + ['sd_bus_message_sensitive', '3', [], ''], + ['sd_bus_message_set_destination', + '3', + ['sd_bus_message_get_destination', + 'sd_bus_message_get_interface', + 'sd_bus_message_get_member', + 'sd_bus_message_get_path', + 'sd_bus_message_get_sender', + 'sd_bus_message_set_sender'], + ''], + ['sd_bus_message_set_expect_reply', + '3', + ['sd_bus_message_get_allow_interactive_authorization', + 'sd_bus_message_get_auto_start', + 'sd_bus_message_get_expect_reply', + 'sd_bus_message_set_allow_interactive_authorization', + 'sd_bus_message_set_auto_start'], + ''], + ['sd_bus_message_skip', '3', [], ''], + ['sd_bus_message_verify_type', '3', [], ''], + ['sd_bus_negotiate_fds', + '3', + ['sd_bus_get_creds_mask', + 'sd_bus_negotiate_creds', + 'sd_bus_negotiate_timestamp'], + ''], + ['sd_bus_new', + '3', + ['sd_bus_close_unref', + 'sd_bus_close_unrefp', + 'sd_bus_flush_close_unref', + 'sd_bus_flush_close_unrefp', + 'sd_bus_ref', + 'sd_bus_unref', + 'sd_bus_unrefp'], + ''], + ['sd_bus_path_encode', + '3', + ['sd_bus_path_decode', 'sd_bus_path_decode_many', 'sd_bus_path_encode_many'], + ''], + ['sd_bus_process', '3', [], ''], + ['sd_bus_query_sender_creds', '3', ['sd_bus_query_sender_privilege'], ''], + ['sd_bus_reply_method_error', + '3', + ['sd_bus_reply_method_errno', + 'sd_bus_reply_method_errnof', + 'sd_bus_reply_method_errnofv', + 'sd_bus_reply_method_errorf', + 'sd_bus_reply_method_errorfv'], + ''], + ['sd_bus_reply_method_return', '3', ['sd_bus_reply_method_returnv'], ''], + ['sd_bus_request_name', + '3', + ['sd_bus_release_name', + 'sd_bus_release_name_async', + 'sd_bus_request_name_async'], + ''], + ['sd_bus_send', '3', ['sd_bus_send_to'], ''], + ['sd_bus_set_address', '3', ['sd_bus_get_address', 'sd_bus_set_exec'], ''], + ['sd_bus_set_close_on_exit', '3', ['sd_bus_get_close_on_exit'], ''], + ['sd_bus_set_connected_signal', '3', ['sd_bus_get_connected_signal'], ''], + ['sd_bus_set_description', + '3', + ['sd_bus_get_allow_interactive_authorization', + 'sd_bus_get_description', + 'sd_bus_get_scope', + 'sd_bus_get_tid', + 'sd_bus_get_unique_name', + 'sd_bus_is_anonymous', + 'sd_bus_is_trusted', + 'sd_bus_set_allow_interactive_authorization', + 'sd_bus_set_anonymous', + 'sd_bus_set_trusted'], + ''], + ['sd_bus_set_exit_on_disconnect', '3', ['sd_bus_get_exit_on_disconnect'], ''], + ['sd_bus_set_method_call_timeout', + '3', + ['sd_bus_get_method_call_timeout'], + ''], + ['sd_bus_set_property', + '3', + ['sd_bus_get_property', + 'sd_bus_get_property_string', + 'sd_bus_get_property_strv', + 'sd_bus_get_property_trivial', + 'sd_bus_set_propertyv'], + ''], + ['sd_bus_set_sender', '3', ['sd_bus_get_sender'], ''], + ['sd_bus_set_server', + '3', + ['sd_bus_get_bus_id', + 'sd_bus_is_bus_client', + 'sd_bus_is_monitor', + 'sd_bus_is_server', + 'sd_bus_set_bus_client', + 'sd_bus_set_monitor'], + ''], + ['sd_bus_set_watch_bind', '3', ['sd_bus_get_watch_bind'], ''], + ['sd_bus_slot_get_bus', + '3', + ['sd_bus_slot_get_current_handler', + 'sd_bus_slot_get_current_message', + 'sd_bus_slot_get_current_userdata'], + ''], + ['sd_bus_slot_ref', '3', ['sd_bus_slot_unref', 'sd_bus_slot_unrefp'], ''], + ['sd_bus_slot_set_description', '3', ['sd_bus_slot_get_description'], ''], + ['sd_bus_slot_set_destroy_callback', + '3', + ['sd_bus_destroy_t', + 'sd_bus_slot_get_destroy_callback', + 'sd_bus_track_get_destroy_callback', + 'sd_bus_track_set_destroy_callback'], + ''], + ['sd_bus_slot_set_floating', '3', ['sd_bus_slot_get_floating'], ''], + ['sd_bus_slot_set_userdata', '3', ['sd_bus_slot_get_userdata'], ''], + ['sd_bus_start', '3', [], ''], + ['sd_bus_track_add_name', + '3', + ['sd_bus_track_add_sender', + 'sd_bus_track_contains', + 'sd_bus_track_count', + 'sd_bus_track_count_name', + 'sd_bus_track_count_sender', + 'sd_bus_track_first', + 'sd_bus_track_next', + 'sd_bus_track_remove_name', + 'sd_bus_track_remove_sender'], + ''], + ['sd_bus_track_new', + '3', + ['sd_bus_track_get_bus', + 'sd_bus_track_get_recursive', + 'sd_bus_track_get_userdata', + 'sd_bus_track_ref', + 'sd_bus_track_set_recursive', + 'sd_bus_track_set_userdata', + 'sd_bus_track_unref', + 'sd_bus_track_unrefp'], + ''], + ['sd_bus_wait', '3', [], ''], + ['sd_event_add_child', + '3', + ['sd_event_add_child_pidfd', + 'sd_event_child_handler_t', + 'sd_event_source_get_child_pid', + 'sd_event_source_get_child_pidfd', + 'sd_event_source_get_child_pidfd_own', + 'sd_event_source_get_child_process_own', + 'sd_event_source_send_child_signal', + 'sd_event_source_set_child_pidfd_own', + 'sd_event_source_set_child_process_own'], + ''], + ['sd_event_add_defer', + '3', + ['sd_event_add_exit', 'sd_event_add_post', 'sd_event_handler_t'], + ''], + ['sd_event_add_inotify', + '3', + ['sd_event_inotify_handler_t', 'sd_event_source_get_inotify_mask'], + ''], + ['sd_event_add_io', + '3', + ['sd_event_io_handler_t', + 'sd_event_source', + 'sd_event_source_get_io_events', + 'sd_event_source_get_io_fd', + 'sd_event_source_get_io_fd_own', + 'sd_event_source_get_io_revents', + 'sd_event_source_set_io_events', + 'sd_event_source_set_io_fd', + 'sd_event_source_set_io_fd_own'], + ''], + ['sd_event_add_signal', + '3', + ['sd_event_signal_handler_t', 'sd_event_source_get_signal'], + ''], + ['sd_event_add_time', + '3', + ['sd_event_add_time_relative', + 'sd_event_source_get_time', + 'sd_event_source_get_time_accuracy', + 'sd_event_source_get_time_clock', + 'sd_event_source_set_time', + 'sd_event_source_set_time_accuracy', + 'sd_event_source_set_time_relative', + 'sd_event_time_handler_t'], + ''], + ['sd_event_exit', '3', ['sd_event_get_exit_code'], ''], + ['sd_event_get_fd', '3', [], ''], + ['sd_event_new', + '3', + ['sd_event', + 'sd_event_default', + 'sd_event_get_tid', + 'sd_event_ref', + 'sd_event_unref', + 'sd_event_unrefp'], + ''], + ['sd_event_now', '3', [], ''], + ['sd_event_run', '3', ['sd_event_loop'], ''], + ['sd_event_set_watchdog', '3', ['sd_event_get_watchdog'], ''], + ['sd_event_source_get_event', '3', [], ''], + ['sd_event_source_get_pending', '3', [], ''], + ['sd_event_source_set_description', + '3', + ['sd_event_source_get_description'], + ''], + ['sd_event_source_set_destroy_callback', + '3', + ['sd_event_destroy_t', 'sd_event_source_get_destroy_callback'], + ''], + ['sd_event_source_set_enabled', + '3', + ['SD_EVENT_OFF', + 'SD_EVENT_ON', + 'SD_EVENT_ONESHOT', + 'sd_event_source_get_enabled'], + ''], + ['sd_event_source_set_exit_on_failure', + '3', + ['sd_event_source_get_exit_on_failure'], + ''], + ['sd_event_source_set_floating', '3', ['sd_event_source_get_floating'], ''], + ['sd_event_source_set_prepare', '3', [], ''], + ['sd_event_source_set_priority', + '3', + ['SD_EVENT_PRIORITY_IDLE', + 'SD_EVENT_PRIORITY_IMPORTANT', + 'SD_EVENT_PRIORITY_NORMAL', + 'sd_event_source_get_priority'], + ''], + ['sd_event_source_set_userdata', '3', ['sd_event_source_get_userdata'], ''], + ['sd_event_source_unref', + '3', + ['sd_event_source_disable_unref', + 'sd_event_source_disable_unrefp', + 'sd_event_source_ref', + 'sd_event_source_unrefp'], + ''], + ['sd_event_wait', + '3', + ['SD_EVENT_ARMED', + 'SD_EVENT_EXITING', + 'SD_EVENT_FINISHED', + 'SD_EVENT_INITIAL', + 'SD_EVENT_PENDING', + 'SD_EVENT_PREPARING', + 'SD_EVENT_RUNNING', + 'sd_event_dispatch', + 'sd_event_get_iteration', + 'sd_event_get_state', + 'sd_event_prepare'], + ''], + ['sd_get_seats', + '3', + ['sd_get_machine_names', 'sd_get_sessions', 'sd_get_uids'], + 'HAVE_PAM'], + ['sd_hwdb_get', + '3', + ['SD_HWDB_FOREACH_PROPERTY', 'sd_hwdb_enumerate', 'sd_hwdb_seek'], + ''], + ['sd_hwdb_new', '3', ['sd_hwdb_ref', 'sd_hwdb_unref'], ''], + ['sd_id128_get_machine', + '3', + ['sd_id128_get_boot', + 'sd_id128_get_boot_app_specific', + 'sd_id128_get_invocation', + 'sd_id128_get_machine_app_specific'], + ''], + ['sd_id128_randomize', '3', [], ''], + ['sd_id128_to_string', '3', ['sd_id128_from_string'], ''], + ['sd_is_fifo', + '3', + ['sd_is_mq', + 'sd_is_socket', + 'sd_is_socket_inet', + 'sd_is_socket_sockaddr', + 'sd_is_socket_unix', + 'sd_is_special'], + ''], + ['sd_journal_add_match', + '3', + ['sd_journal_add_conjunction', + 'sd_journal_add_disjunction', + 'sd_journal_flush_matches'], + ''], + ['sd_journal_enumerate_fields', + '3', + ['SD_JOURNAL_FOREACH_FIELD', 'sd_journal_restart_fields'], + ''], + ['sd_journal_get_catalog', '3', ['sd_journal_get_catalog_for_message_id'], ''], + ['sd_journal_get_cursor', '3', ['sd_journal_test_cursor'], ''], + ['sd_journal_get_cutoff_realtime_usec', + '3', + ['sd_journal_get_cutoff_monotonic_usec'], + ''], + ['sd_journal_get_data', + '3', + ['SD_JOURNAL_FOREACH_DATA', + 'sd_journal_enumerate_available_data', + 'sd_journal_enumerate_data', + 'sd_journal_get_data_threshold', + 'sd_journal_restart_data', + 'sd_journal_set_data_threshold'], + ''], + ['sd_journal_get_fd', + '3', + ['SD_JOURNAL_APPEND', + 'SD_JOURNAL_INVALIDATE', + 'SD_JOURNAL_NOP', + 'sd_journal_get_events', + 'sd_journal_get_timeout', + 'sd_journal_process', + 'sd_journal_reliable_fd', + 'sd_journal_wait'], + ''], + ['sd_journal_get_realtime_usec', '3', ['sd_journal_get_monotonic_usec'], ''], + ['sd_journal_get_usage', '3', [], ''], + ['sd_journal_has_runtime_files', '3', ['sd_journal_has_persistent_files'], ''], + ['sd_journal_next', + '3', + ['SD_JOURNAL_FOREACH', + 'SD_JOURNAL_FOREACH_BACKWARDS', + 'sd_journal_next_skip', + 'sd_journal_previous', + 'sd_journal_previous_skip'], + ''], + ['sd_journal_open', + '3', + ['SD_JOURNAL_ALL_NAMESPACES', + 'SD_JOURNAL_CURRENT_USER', + 'SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE', + 'SD_JOURNAL_LOCAL_ONLY', + 'SD_JOURNAL_OS_ROOT', + 'SD_JOURNAL_RUNTIME_ONLY', + 'SD_JOURNAL_SYSTEM', + 'sd_journal', + 'sd_journal_close', + 'sd_journal_open_directory', + 'sd_journal_open_directory_fd', + 'sd_journal_open_files', + 'sd_journal_open_files_fd', + 'sd_journal_open_namespace'], + ''], + ['sd_journal_print', + '3', + ['SD_JOURNAL_SUPPRESS_LOCATION', + 'sd_journal_perror', + 'sd_journal_perror_with_location', + 'sd_journal_print_with_location', + 'sd_journal_printv', + 'sd_journal_printv_with_location', + 'sd_journal_send', + 'sd_journal_send_with_location', + 'sd_journal_sendv', + 'sd_journal_sendv_with_location'], + ''], + ['sd_journal_query_unique', + '3', + ['SD_JOURNAL_FOREACH_UNIQUE', + 'sd_journal_enumerate_available_unique', + 'sd_journal_enumerate_unique', + 'sd_journal_restart_unique'], + ''], + ['sd_journal_seek_head', + '3', + ['sd_journal_seek_cursor', + 'sd_journal_seek_monotonic_usec', + 'sd_journal_seek_realtime_usec', + 'sd_journal_seek_tail'], + ''], + ['sd_journal_stream_fd', '3', [], ''], + ['sd_listen_fds', + '3', + ['SD_LISTEN_FDS_START', 'sd_listen_fds_with_names'], + ''], + ['sd_login_monitor_new', + '3', + ['sd_login_monitor', + 'sd_login_monitor_flush', + 'sd_login_monitor_get_events', + 'sd_login_monitor_get_fd', + 'sd_login_monitor_get_timeout', + 'sd_login_monitor_unref', + 'sd_login_monitor_unrefp'], + 'HAVE_PAM'], + ['sd_machine_get_class', '3', ['sd_machine_get_ifindices'], ''], + ['sd_notify', + '3', + ['sd_notify_barrier', + 'sd_notifyf', + 'sd_pid_notify', + 'sd_pid_notify_with_fds', + 'sd_pid_notifyf'], + ''], + ['sd_path_lookup', '3', ['sd_path_lookup_strv'], ''], + ['sd_pid_get_owner_uid', + '3', + ['sd_peer_get_cgroup', + 'sd_peer_get_machine_name', + 'sd_peer_get_owner_uid', + 'sd_peer_get_session', + 'sd_peer_get_slice', + 'sd_peer_get_unit', + 'sd_peer_get_user_slice', + 'sd_peer_get_user_unit', + 'sd_pid_get_cgroup', + 'sd_pid_get_machine_name', + 'sd_pid_get_session', + 'sd_pid_get_slice', + 'sd_pid_get_unit', + 'sd_pid_get_user_slice', + 'sd_pid_get_user_unit'], + 'HAVE_PAM'], + ['sd_seat_get_active', + '3', + ['sd_seat_can_graphical', 'sd_seat_can_tty', 'sd_seat_get_sessions'], + 'HAVE_PAM'], + ['sd_session_is_active', + '3', + ['sd_session_get_class', + 'sd_session_get_desktop', + 'sd_session_get_display', + 'sd_session_get_remote_host', + 'sd_session_get_remote_user', + 'sd_session_get_seat', + 'sd_session_get_service', + 'sd_session_get_state', + 'sd_session_get_tty', + 'sd_session_get_type', + 'sd_session_get_uid', + 'sd_session_get_vt', + 'sd_session_is_remote'], + 'HAVE_PAM'], + ['sd_uid_get_state', + '3', + ['sd_uid_get_display', + 'sd_uid_get_seats', + 'sd_uid_get_sessions', + 'sd_uid_is_on_seat'], + 'HAVE_PAM'], + ['sd_watchdog_enabled', '3', [], ''], + ['shutdown', '8', [], ''], + ['sysctl.d', '5', [], ''], + ['systemctl', '1', [], ''], + ['systemd-analyze', '1', [], 'ENABLE_ANALYZE'], + ['systemd-ask-password-console.service', + '8', + ['systemd-ask-password-console.path', + 'systemd-ask-password-wall.path', + 'systemd-ask-password-wall.service'], + ''], + ['systemd-ask-password', '1', [], ''], + ['systemd-backlight@.service', '8', ['systemd-backlight'], 'ENABLE_BACKLIGHT'], + ['systemd-binfmt.service', '8', ['systemd-binfmt'], 'ENABLE_BINFMT'], + ['systemd-bless-boot-generator', '8', [], 'ENABLE_EFI'], + ['systemd-bless-boot.service', '8', ['systemd-bless-boot'], 'ENABLE_EFI'], + ['systemd-boot-check-no-failures.service', + '8', + ['systemd-boot-check-no-failures'], + ''], + ['systemd-boot-system-token.service', '8', [], 'ENABLE_EFI'], + ['systemd-boot', '7', ['sd-boot'], 'ENABLE_EFI'], + ['systemd-cat', '1', [], ''], + ['systemd-cgls', '1', [], ''], + ['systemd-cgtop', '1', [], ''], + ['systemd-coredump', + '8', + ['systemd-coredump.socket', 'systemd-coredump@.service'], + 'ENABLE_COREDUMP'], + ['systemd-cryptsetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'], + ['systemd-cryptsetup@.service', + '8', + ['systemd-cryptsetup'], + 'HAVE_LIBCRYPTSETUP'], + ['systemd-debug-generator', '8', [], ''], + ['systemd-delta', '1', [], ''], + ['systemd-detect-virt', '1', [], ''], + ['systemd-dissect', '1', [], 'HAVE_BLKID'], + ['systemd-environment-d-generator', + '8', + ['30-systemd-environment-d-generator'], + 'ENABLE_ENVIRONMENT_D'], + ['systemd-escape', '1', [], ''], + ['systemd-firstboot', '1', ['systemd-firstboot.service'], 'ENABLE_FIRSTBOOT'], + ['systemd-fsck@.service', + '8', + ['systemd-fsck', 'systemd-fsck-root.service'], + ''], + ['systemd-fstab-generator', '8', [], ''], + ['systemd-getty-generator', '8', [], ''], + ['systemd-gpt-auto-generator', '8', [], 'HAVE_BLKID'], + ['systemd-halt.service', + '8', + ['systemd-kexec.service', + 'systemd-poweroff.service', + 'systemd-reboot.service', + 'systemd-shutdown'], + ''], + ['systemd-hibernate-resume-generator', '8', [], 'ENABLE_HIBERNATE'], + ['systemd-hibernate-resume@.service', + '8', + ['systemd-hibernate-resume'], + 'ENABLE_HIBERNATE'], + ['systemd-homed.service', '8', ['systemd-homed'], 'ENABLE_HOMED'], + ['systemd-hostnamed.service', '8', ['systemd-hostnamed'], 'ENABLE_HOSTNAMED'], + ['systemd-hwdb', '8', [], 'ENABLE_HWDB'], + ['systemd-id128', '1', [], ''], + ['systemd-importd.service', '8', ['systemd-importd'], 'ENABLE_IMPORTD'], + ['systemd-inhibit', '1', [], ''], + ['systemd-initctl.service', + '8', + ['systemd-initctl', 'systemd-initctl.socket'], + 'HAVE_SYSV_COMPAT'], + ['systemd-journal-gatewayd.service', + '8', + ['systemd-journal-gatewayd', 'systemd-journal-gatewayd.socket'], + 'HAVE_MICROHTTPD'], + ['systemd-journal-remote.service', + '8', + ['systemd-journal-remote', 'systemd-journal-remote.socket'], + 'HAVE_MICROHTTPD'], + ['systemd-journal-upload.service', + '8', + ['systemd-journal-upload'], + 'HAVE_MICROHTTPD'], + ['systemd-journald.service', + '8', + ['systemd-journald', + 'systemd-journald-audit.socket', + 'systemd-journald-dev-log.socket', + 'systemd-journald-varlink@.socket', + 'systemd-journald.socket', + 'systemd-journald@.service', + 'systemd-journald@.socket'], + ''], + ['systemd-localed.service', '8', ['systemd-localed'], 'ENABLE_LOCALED'], + ['systemd-logind.service', '8', ['systemd-logind'], 'ENABLE_LOGIND'], + ['systemd-machine-id-commit.service', '8', [], ''], + ['systemd-machine-id-setup', '1', [], ''], + ['systemd-machined.service', '8', ['systemd-machined'], 'ENABLE_MACHINED'], + ['systemd-makefs@.service', + '8', + ['systemd-growfs', + 'systemd-growfs@.service', + 'systemd-makefs', + 'systemd-mkswap@.service'], + ''], + ['systemd-modules-load.service', '8', ['systemd-modules-load'], 'HAVE_KMOD'], + ['systemd-mount', '1', ['systemd-umount'], ''], + ['systemd-network-generator.service', + '8', + ['systemd-network-generator'], + 'ENABLE_NETWORKD'], + ['systemd-networkd-wait-online.service', + '8', + ['systemd-networkd-wait-online'], + 'ENABLE_NETWORKD'], + ['systemd-networkd.service', '8', ['systemd-networkd'], 'ENABLE_NETWORKD'], + ['systemd-notify', '1', [], ''], + ['systemd-nspawn', '1', [], ''], + ['systemd-oomd.service', '8', ['systemd-oomd'], 'ENABLE_OOMD'], + ['systemd-path', '1', [], ''], + ['systemd-portabled.service', '8', ['systemd-portabled'], 'ENABLE_PORTABLED'], + ['systemd-pstore.service', '8', ['systemd-pstore'], 'ENABLE_PSTORE'], + ['systemd-quotacheck.service', + '8', + ['systemd-quotacheck'], + 'ENABLE_QUOTACHECK'], + ['systemd-random-seed.service', + '8', + ['systemd-random-seed'], + 'ENABLE_RANDOMSEED'], + ['systemd-rc-local-generator', '8', [], 'HAVE_SYSV_COMPAT'], + ['systemd-remount-fs.service', '8', ['systemd-remount-fs'], ''], + ['systemd-repart', '8', ['systemd-repart.service'], 'ENABLE_REPART'], + ['systemd-resolved.service', '8', ['systemd-resolved'], 'ENABLE_RESOLVE'], + ['systemd-rfkill.service', + '8', + ['systemd-rfkill', 'systemd-rfkill.socket'], + 'ENABLE_RFKILL'], + ['systemd-run-generator', '8', [], ''], + ['systemd-run', '1', [], ''], + ['systemd-sleep.conf', '5', ['sleep.conf.d'], ''], + ['systemd-socket-activate', '1', [], ''], + ['systemd-socket-proxyd', '8', [], ''], + ['systemd-suspend.service', + '8', + ['systemd-hibernate.service', + 'systemd-hybrid-sleep.service', + 'systemd-sleep', + 'systemd-suspend-then-hibernate.service'], + ''], + ['systemd-sysctl.service', '8', ['systemd-sysctl'], ''], + ['systemd-system-update-generator', '8', [], ''], + ['systemd-system.conf', + '5', + ['system.conf.d', 'systemd-user.conf', 'user.conf.d'], + ''], + ['systemd-sysusers', '8', ['systemd-sysusers.service'], ''], + ['systemd-sysv-generator', '8', [], 'HAVE_SYSV_COMPAT'], + ['systemd-time-wait-sync.service', + '8', + ['systemd-time-wait-sync'], + 'ENABLE_TIMESYNCD'], + ['systemd-timedated.service', '8', ['systemd-timedated'], 'ENABLE_TIMEDATED'], + ['systemd-timesyncd.service', '8', ['systemd-timesyncd'], 'ENABLE_TIMESYNCD'], + ['systemd-tmpfiles', + '8', + ['systemd-tmpfiles-clean.service', + 'systemd-tmpfiles-clean.timer', + 'systemd-tmpfiles-setup-dev.service', + 'systemd-tmpfiles-setup.service'], + ''], + ['systemd-tty-ask-password-agent', '1', [], ''], + ['systemd-udev-settle.service', '8', [], ''], + ['systemd-udevd.service', + '8', + ['systemd-udevd', + 'systemd-udevd-control.socket', + 'systemd-udevd-kernel.socket'], + ''], + ['systemd-update-done.service', '8', ['systemd-update-done'], ''], + ['systemd-update-utmp.service', + '8', + ['systemd-update-utmp', 'systemd-update-utmp-runlevel.service'], + 'ENABLE_UTMP'], + ['systemd-user-sessions.service', '8', ['systemd-user-sessions'], 'HAVE_PAM'], + ['systemd-userdbd.service', '8', ['systemd-userdbd'], 'ENABLE_USERDB'], + ['systemd-vconsole-setup.service', + '8', + ['systemd-vconsole-setup'], + 'ENABLE_VCONSOLE'], + ['systemd-veritysetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'], + ['systemd-veritysetup@.service', + '8', + ['systemd-veritysetup'], + 'HAVE_LIBCRYPTSETUP'], + ['systemd-volatile-root.service', '8', ['systemd-volatile-root'], ''], + ['systemd-xdg-autostart-generator', '8', [], 'ENABLE_XDG_AUTOSTART'], + ['systemd', '1', ['init'], ''], + ['systemd.automount', '5', [], ''], + ['systemd.device', '5', [], ''], + ['systemd.dnssd', '5', [], 'ENABLE_RESOLVE'], + ['systemd.environment-generator', '7', [], 'ENABLE_ENVIRONMENT_D'], + ['systemd.exec', '5', [], ''], + ['systemd.generator', '7', [], ''], + ['systemd.journal-fields', '7', [], ''], + ['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', [], ''], + ['systemd.offline-updates', '7', [], ''], + ['systemd.path', '5', [], ''], + ['systemd.preset', '5', [], ''], + ['systemd.resource-control', '5', [], ''], + ['systemd.scope', '5', [], ''], + ['systemd.service', '5', [], ''], + ['systemd.slice', '5', [], ''], + ['systemd.socket', '5', [], ''], + ['systemd.special', '7', [], ''], + ['systemd.swap', '5', [], ''], + ['systemd.syntax', '7', [], ''], + ['systemd.target', '5', [], ''], + ['systemd.time', '7', [], ''], + ['systemd.timer', '5', [], ''], + ['systemd.unit', '5', [], ''], + ['sysusers.d', '5', [], 'ENABLE_SYSUSERS'], + ['telinit', '8', [], 'HAVE_SYSV_COMPAT'], + ['timedatectl', '1', [], 'ENABLE_TIMEDATECTL'], + ['timesyncd.conf', '5', ['timesyncd.conf.d'], 'ENABLE_TIMESYNCD'], + ['tmpfiles.d', '5', [], ''], + ['udev', '7', [], ''], + ['udev.conf', '5', [], ''], + ['udev_device_get_syspath', + '3', + ['udev_device_get_action', + 'udev_device_get_devnode', + 'udev_device_get_devnum', + 'udev_device_get_devpath', + 'udev_device_get_devtype', + 'udev_device_get_driver', + 'udev_device_get_is_initialized', + 'udev_device_get_parent', + 'udev_device_get_parent_with_subsystem_devtype', + 'udev_device_get_subsystem', + 'udev_device_get_sysname', + 'udev_device_get_sysnum', + 'udev_device_get_udev'], + ''], + ['udev_device_has_tag', + '3', + ['udev_device_get_current_tags_list_entry', + 'udev_device_get_devlinks_list_entry', + 'udev_device_get_properties_list_entry', + 'udev_device_get_property_value', + 'udev_device_get_sysattr_list_entry', + 'udev_device_get_sysattr_value', + 'udev_device_get_tags_list_entry', + 'udev_device_has_current_tag', + 'udev_device_set_sysattr_value'], + ''], + ['udev_device_new_from_syspath', + '3', + ['udev_device_new_from_device_id', + 'udev_device_new_from_devnum', + 'udev_device_new_from_environment', + 'udev_device_new_from_subsystem_sysname', + 'udev_device_ref', + 'udev_device_unref'], + ''], + ['udev_enumerate_add_match_subsystem', + '3', + ['udev_enumerate_add_match_is_initialized', + 'udev_enumerate_add_match_parent', + 'udev_enumerate_add_match_property', + 'udev_enumerate_add_match_sysattr', + 'udev_enumerate_add_match_sysname', + 'udev_enumerate_add_match_tag', + 'udev_enumerate_add_nomatch_subsystem', + 'udev_enumerate_add_nomatch_sysattr'], + ''], + ['udev_enumerate_new', + '3', + ['udev_enumerate_ref', 'udev_enumerate_unref'], + ''], + ['udev_enumerate_scan_devices', + '3', + ['udev_enumerate_add_syspath', + 'udev_enumerate_get_list_entry', + 'udev_enumerate_get_udev', + 'udev_enumerate_scan_subsystems'], + ''], + ['udev_list_entry', + '3', + ['udev_list_entry_get_by_name', + 'udev_list_entry_get_name', + 'udev_list_entry_get_next', + 'udev_list_entry_get_value'], + ''], + ['udev_monitor_filter_update', + '3', + ['udev_monitor_filter_add_match_subsystem_devtype', + 'udev_monitor_filter_add_match_tag', + 'udev_monitor_filter_remove'], + ''], + ['udev_monitor_new_from_netlink', + '3', + ['udev_monitor_ref', 'udev_monitor_unref'], + ''], + ['udev_monitor_receive_device', + '3', + ['udev_monitor_enable_receiving', + 'udev_monitor_get_fd', + 'udev_monitor_get_udev', + 'udev_monitor_set_receive_buffer_size'], + ''], + ['udev_new', '3', ['udev_ref', 'udev_unref'], ''], + ['udevadm', '8', [], ''], + ['user@.service', + '5', + ['systemd-user-runtime-dir', 'user-runtime-dir@.service'], + ''], + ['userdbctl', '1', [], 'ENABLE_USERDB'], + ['vconsole.conf', '5', [], 'ENABLE_VCONSOLE'] +] +# Really, do not edit. diff --git a/man/runlevel.xml b/man/runlevel.xml new file mode 100644 index 0000000..f5e1e00 --- /dev/null +++ b/man/runlevel.xml @@ -0,0 +1,162 @@ +<?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-or-later --> + +<refentry id="runlevel" conditional='HAVE_SYSV_COMPAT' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>runlevel</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>runlevel</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>runlevel</refname> + <refpurpose>Print previous and current SysV runlevel</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>runlevel</command> + <arg choice="opt" rep="repeat">options</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Overview</title> + + <para>"Runlevels" are an obsolete way to start and stop groups of + services used in SysV init. systemd provides a compatibility layer + that maps runlevels to targets, and associated binaries like + <command>runlevel</command>. Nevertheless, only one runlevel can + be "active" at a given time, while systemd can activate multiple + targets concurrently, so the mapping to runlevels is confusing + and only approximate. Runlevels should not be used in new code, + and are mostly useful as a shorthand way to refer the matching + systemd targets in kernel boot parameters.</para> + + <table> + <title>Mapping between runlevels and systemd targets</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="runlevel" /> + <colspec colname="target" /> + <thead> + <row> + <entry>Runlevel</entry> + <entry>Target</entry> + </row> + </thead> + <tbody> + <row> + <entry>0</entry> + <entry><filename>poweroff.target</filename></entry> + </row> + <row> + <entry>1</entry> + <entry><filename>rescue.target</filename></entry> + </row> + <row> + <entry>2, 3, 4</entry> + <entry><filename>multi-user.target</filename></entry> + </row> + <row> + <entry>5</entry> + <entry><filename>graphical.target</filename></entry> + </row> + <row> + <entry>6</entry> + <entry><filename>reboot.target</filename></entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Description</title> + + <para><command>runlevel</command> prints the previous and current + SysV runlevel if they are known.</para> + + <para>The two runlevel characters are separated by a single space + character. If a runlevel cannot be determined, N is printed + instead. If neither can be determined, the word "unknown" is + printed.</para> + + <para>Unless overridden in the environment, this will check the + utmp database for recent runlevel changes.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following option is understood:</para> + + <variablelist> + <varlistentry> + <term><option>--help</option></term> + + <xi:include href="standard-options.xml" xpointer="help-text" /> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>If one or both runlevels could be determined, 0 is returned, + a non-zero failure code otherwise.</para> + + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$RUNLEVEL</varname></term> + + <listitem><para>If <varname>$RUNLEVEL</varname> is set, + <command>runlevel</command> will print this value as current + runlevel and ignore utmp.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$PREVLEVEL</varname></term> + + <listitem><para>If <varname>$PREVLEVEL</varname> is set, + <command>runlevel</command> will print this value as previous + runlevel and ignore utmp.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Files</title> + + <variablelist> + <varlistentry> + <term><filename>/run/utmp</filename></term> + + <listitem><para>The utmp database <command>runlevel</command> reads the previous and current runlevel + from.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd-bus-container-append.c b/man/sd-bus-container-append.c new file mode 100644 index 0000000..e350ea0 --- /dev/null +++ b/man/sd-bus-container-append.c @@ -0,0 +1,17 @@ +#include <systemd/sd-bus.h> + +int append_strings_to_message(sd_bus_message *m, const char *const *arr) { + int r; + + r = sd_bus_message_open_container(m, 'a', "s"); + if (r < 0) + return r; + + for (const char *s = *arr; *s; s++) { + r = sd_bus_message_append(m, "s", s); + if (r < 0) + return r; + } + + return sd_bus_message_close_container(m); +} diff --git a/man/sd-bus-container-read.c b/man/sd-bus-container-read.c new file mode 100644 index 0000000..b6c95f4 --- /dev/null +++ b/man/sd-bus-container-read.c @@ -0,0 +1,25 @@ +#include <stdio.h> + +#include <systemd/sd-bus.h> + +int read_strings_from_message(sd_bus_message *m) { + int r; + + r = sd_bus_message_enter_container(m, 'a', "s"); + if (r < 0) + return r; + + for (;;) { + const char *s; + + r = sd_bus_message_read(m, "s", &s); + if (r < 0) + return r; + if (r == 0) + break; + + printf("%s\n", s); + } + + return sd_bus_message_exit_container(m); +} diff --git a/man/sd-bus-errors.xml b/man/sd-bus-errors.xml new file mode 100644 index 0000000..a69efe0 --- /dev/null +++ b/man/sd-bus-errors.xml @@ -0,0 +1,275 @@ +<?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-or-later --> + +<refentry id="sd-bus-errors" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-bus-errors</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-bus-errors</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-bus-errors</refname> + <refname>SD_BUS_ERROR_FAILED</refname> + <refname>SD_BUS_ERROR_NO_MEMORY</refname> + <refname>SD_BUS_ERROR_SERVICE_UNKNOWN</refname> + <refname>SD_BUS_ERROR_NAME_HAS_NO_OWNER</refname> + <refname>SD_BUS_ERROR_NO_REPLY</refname> + <refname>SD_BUS_ERROR_IO_ERROR</refname> + <refname>SD_BUS_ERROR_BAD_ADDRESS</refname> + <refname>SD_BUS_ERROR_NOT_SUPPORTED</refname> + <refname>SD_BUS_ERROR_LIMITS_EXCEEDED</refname> + <refname>SD_BUS_ERROR_ACCESS_DENIED</refname> + <refname>SD_BUS_ERROR_AUTH_FAILED</refname> + <refname>SD_BUS_ERROR_NO_SERVER</refname> + <refname>SD_BUS_ERROR_TIMEOUT</refname> + <refname>SD_BUS_ERROR_NO_NETWORK</refname> + <refname>SD_BUS_ERROR_ADDRESS_IN_USE</refname> + <refname>SD_BUS_ERROR_DISCONNECTED</refname> + <refname>SD_BUS_ERROR_INVALID_ARGS</refname> + <refname>SD_BUS_ERROR_FILE_NOT_FOUND</refname> + <refname>SD_BUS_ERROR_FILE_EXISTS</refname> + <refname>SD_BUS_ERROR_UNKNOWN_METHOD</refname> + <refname>SD_BUS_ERROR_UNKNOWN_OBJECT</refname> + <refname>SD_BUS_ERROR_UNKNOWN_INTERFACE</refname> + <refname>SD_BUS_ERROR_UNKNOWN_PROPERTY</refname> + <refname>SD_BUS_ERROR_PROPERTY_READ_ONLY</refname> + <refname>SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN</refname> + <refname>SD_BUS_ERROR_INVALID_SIGNATURE</refname> + <refname>SD_BUS_ERROR_INCONSISTENT_MESSAGE</refname> + <refname>SD_BUS_ERROR_MATCH_RULE_NOT_FOUND</refname> + <refname>SD_BUS_ERROR_MATCH_RULE_INVALID</refname> + <refname>SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED</refname> + + <refpurpose>Standard D-Bus error names</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + +<funcsynopsisinfo>#define SD_BUS_ERROR_FAILED "org.freedesktop.DBus.Error.Failed" +#define SD_BUS_ERROR_NO_MEMORY "org.freedesktop.DBus.Error.NoMemory" +#define SD_BUS_ERROR_SERVICE_UNKNOWN "org.freedesktop.DBus.Error.ServiceUnknown" +#define SD_BUS_ERROR_NAME_HAS_NO_OWNER "org.freedesktop.DBus.Error.NameHasNoOwner" +#define SD_BUS_ERROR_NO_REPLY "org.freedesktop.DBus.Error.NoReply" +#define SD_BUS_ERROR_IO_ERROR "org.freedesktop.DBus.Error.IOError" +#define SD_BUS_ERROR_BAD_ADDRESS "org.freedesktop.DBus.Error.BadAddress" +#define SD_BUS_ERROR_NOT_SUPPORTED "org.freedesktop.DBus.Error.NotSupported" +#define SD_BUS_ERROR_LIMITS_EXCEEDED "org.freedesktop.DBus.Error.LimitsExceeded" +#define SD_BUS_ERROR_ACCESS_DENIED "org.freedesktop.DBus.Error.AccessDenied" +#define SD_BUS_ERROR_AUTH_FAILED "org.freedesktop.DBus.Error.AuthFailed" +#define SD_BUS_ERROR_NO_SERVER "org.freedesktop.DBus.Error.NoServer" +#define SD_BUS_ERROR_TIMEOUT "org.freedesktop.DBus.Error.Timeout" +#define SD_BUS_ERROR_NO_NETWORK "org.freedesktop.DBus.Error.NoNetwork" +#define SD_BUS_ERROR_ADDRESS_IN_USE "org.freedesktop.DBus.Error.AddressInUse" +#define SD_BUS_ERROR_DISCONNECTED "org.freedesktop.DBus.Error.Disconnected" +#define SD_BUS_ERROR_INVALID_ARGS "org.freedesktop.DBus.Error.InvalidArgs" +#define SD_BUS_ERROR_FILE_NOT_FOUND "org.freedesktop.DBus.Error.FileNotFound" +#define SD_BUS_ERROR_FILE_EXISTS "org.freedesktop.DBus.Error.FileExists" +#define SD_BUS_ERROR_UNKNOWN_METHOD "org.freedesktop.DBus.Error.UnknownMethod" +#define SD_BUS_ERROR_UNKNOWN_OBJECT "org.freedesktop.DBus.Error.UnknownObject" +#define SD_BUS_ERROR_UNKNOWN_INTERFACE "org.freedesktop.DBus.Error.UnknownInterface" +#define SD_BUS_ERROR_UNKNOWN_PROPERTY "org.freedesktop.DBus.Error.UnknownProperty" +#define SD_BUS_ERROR_PROPERTY_READ_ONLY "org.freedesktop.DBus.Error.PropertyReadOnly" +#define SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN "org.freedesktop.DBus.Error.UnixProcessIdUnknown" +#define SD_BUS_ERROR_INVALID_SIGNATURE "org.freedesktop.DBus.Error.InvalidSignature" +#define SD_BUS_ERROR_INCONSISTENT_MESSAGE "org.freedesktop.DBus.Error.InconsistentMessage" +#define SD_BUS_ERROR_MATCH_RULE_NOT_FOUND "org.freedesktop.DBus.Error.MatchRuleNotFound" +#define SD_BUS_ERROR_MATCH_RULE_INVALID "org.freedesktop.DBus.Error.MatchRuleInvalid" +#define SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED \ + "org.freedesktop.DBus.Error.InteractiveAuthorizationRequired"</funcsynopsisinfo> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>In addition to the error names user programs define, D-Bus + knows a number of generic, standardized error names that are + listed below.</para> + + <para>In addition to this list, in sd-bus, the special error + namespace <literal>System.Error.</literal> is used to map + arbitrary Linux system errors (as defined by <citerefentry + project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + to D-Bus errors and back. For example, the error + <constant>EUCLEAN</constant> is mapped to + <literal>System.Error.EUCLEAN</literal> and back.</para> + + <variablelist> + + <varlistentry> + <term><constant>SD_BUS_ERROR_FAILED</constant></term> + <listitem><para>A generic error indication. See the error + message for further details. This error name should be + avoided, in favor of a more expressive error + name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_ERROR_NO_MEMORY</constant></term> + <listitem><para>A memory allocation failed, and the requested + operation could not be completed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_ERROR_SERVICE_UNKNOWN</constant></term> + <listitem><para>The contacted bus service is unknown and + cannot be activated.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_ERROR_NAME_HAS_NO_OWNER</constant></term> + <listitem><para>The specified bus service name currently has + no owner.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_NO_REPLY</constant></term> + <listitem><para>A message did not receive a reply. This error + is usually generated after a timeout.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_IO_ERROR</constant></term> + <listitem><para>Generic input/output error, for example when + accessing a socket or other I/O context.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_BAD_ADDRESS</constant></term> + <listitem><para>The specified D-Bus bus address string is + malformed.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_NOT_SUPPORTED</constant></term> + <listitem><para>The requested operation is not supported on + the local system.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_LIMITS_EXCEEDED</constant></term> + <listitem><para>Some limited resource has been + exhausted.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_ACCESS_DENIED</constant></term> + <listitem><para>Access to a resource has been denied due to security restrictions.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_AUTH_FAILED</constant></term> + <listitem><para>Authentication did not complete successfully.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_NO_SERVER</constant></term> + <listitem><para>Unable to connect to the specified server.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_TIMEOUT</constant></term> + <listitem><para>An operation timed out. Note that method calls + which timeout generate a + <constant>SD_BUS_ERROR_NO_REPLY</constant>.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_NO_NETWORK</constant></term> + <listitem><para>No network available to execute requested network operation on.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_ADDRESS_IN_USE</constant></term> + <listitem><para>The specified network address is already being listened on.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_DISCONNECTED</constant></term> + <listitem><para>The connection has been terminated.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_INVALID_ARGS</constant></term> + <listitem><para>One or more invalid arguments have been passed.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_FILE_NOT_FOUND</constant></term> + <listitem><para>The requested file could not be found.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_FILE_EXISTS</constant></term> + <listitem><para>The requested file already exists.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_UNKNOWN_METHOD</constant></term> + <listitem><para>The requested method does not exist in the selected interface.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_UNKNOWN_OBJECT</constant></term> + <listitem><para>The requested object does not exist in the selected service.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_UNKNOWN_INTERFACE</constant></term> + <listitem><para>The requested interface does not exist on the selected object.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_UNKNOWN_PROPERTY</constant></term> + <listitem><para>The requested property does not exist in the selected interface.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_PROPERTY_READ_ONLY</constant></term> + <listitem><para>A write operation was requested on a read-only property.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN</constant></term> + <listitem><para>The requested PID is not known.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_INVALID_SIGNATURE</constant></term> + <listitem><para>The specified message signature is not + valid.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_INCONSISTENT_MESSAGE</constant></term> + <listitem><para>The passed message does not validate + correctly.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_MATCH_RULE_NOT_FOUND</constant></term> + <listitem><para>The specified match rule does not exist.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_MATCH_RULE_INVALID</constant></term> + <listitem><para>The specified match rule is invalid.</para></listitem> + </varlistentry> + <varlistentry> + <term><constant>SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED</constant></term> + <listitem><para>Access to the requested operation is not + permitted. However, it might be available after interactive + authentication. This is usually returned by method calls + supporting a framework for additional interactive + authorization, when interactive authorization was not enabled + with the + <citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for the method call message.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>strerror</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-bus.xml b/man/sd-bus.xml new file mode 100644 index 0000000..05fce44 --- /dev/null +++ b/man/sd-bus.xml @@ -0,0 +1,191 @@ +<?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-or-later --> + +<refentry id="sd-bus" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-bus</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-bus</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-bus</refname> + <refpurpose>A lightweight D-Bus IPC client library</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-bus.h</filename> provides an implementation of a D-Bus IPC client. See + <ulink url="https://www.freedesktop.org/software/dbus/" /> + for more information about D-Bus IPC. + </para> + + <para>See + <literallayout><citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_object</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_object_manager</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_object_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_fallback</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_fallback_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_filter</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_add_node_enumerator</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_call_method_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_can_send</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>, +<citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_interfaces_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_interfaces_added_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_interfaces_removed</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_interfaces_removed_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_object_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_object_removed</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_properties_changed</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_properties_changed_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_emit_signalv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_bus_id</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_creds_mask</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_current_handler</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_current_message</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_current_slot</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_current_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_exit_on_disconnect</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_method_call_timeout</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_n_queued_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_name_machine_id</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_property</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_property_trivial</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_property_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_property_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_scope</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_tid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_unique_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_interface_name_is_valid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_is_monitor</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_is_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_is_server</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_list_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_append_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_append_string_memfd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_append_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_at_end</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_close_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_copy</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_dump</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_enter_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_exit_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_cookie</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_signature</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_type</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_open_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_peek_type</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_read_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_read_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_rewind</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_seal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_set_expect_reply</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_verify_type</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_negotiate_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_path_encode</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_query_sender_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_query_sender_privilege</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_reply_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_send_to</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_exit_on_disconnect</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_method_call_timeout</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_monitor</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_property</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_propertyv</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_server</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry> +<citerefentry><refentrytitle>sd_bus_slot_get_current_handler</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_slot_get_current_message</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_slot_get_current_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_slot_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_track_add_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> +</literallayout> + for more information about the functions available.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>dbus-send</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-daemon.xml b/man/sd-daemon.xml new file mode 100644 index 0000000..5dee3e8 --- /dev/null +++ b/man/sd-daemon.xml @@ -0,0 +1,114 @@ +<?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-or-later --> + +<refentry id="sd-daemon" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-daemon</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-daemon</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-daemon</refname> + <refname>SD_EMERG</refname> + <refname>SD_ALERT</refname> + <refname>SD_CRIT</refname> + <refname>SD_ERR</refname> + <refname>SD_WARNING</refname> + <refname>SD_NOTICE</refname> + <refname>SD_INFO</refname> + <refname>SD_DEBUG</refname> + <refpurpose>APIs for + new-style daemons</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-daemon.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-daemon.h</filename> provides APIs for new-style + daemons, as implemented by the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + service manager.</para> + + <para>See + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the functions implemented. In addition + to these functions, a couple of logging prefixes are defined as + macros:</para> + + <programlisting>#define SD_EMERG "<0>" /* system is unusable */ +#define SD_ALERT "<1>" /* action must be taken immediately */ +#define SD_CRIT "<2>" /* critical conditions */ +#define SD_ERR "<3>" /* error conditions */ +#define SD_WARNING "<4>" /* warning conditions */ +#define SD_NOTICE "<5>" /* normal but significant condition */ +#define SD_INFO "<6>" /* informational */ +#define SD_DEBUG "<7>" /* debug-level messages */</programlisting> + + <para>These prefixes are intended to be used in conjunction with stderr-based logging (or stdout-based + logging) as implemented by systemd. If a systemd service definition file is configured with + <varname>StandardError=journal</varname> or <varname>StandardError=kmsg</varname> (and similar with + <varname>StandardOutput=</varname>), these prefixes can be used to encode a log level in lines + printed. This is similar to the kernel <function>printk()</function>-style logging. See + <citerefentry><refentrytitle>klogctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for more + information.</para> + + <para>The log levels are identical to + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s + log level system. To use these prefixes simply prefix every line + with one of these strings. A line that is not prefixed will be + logged at the default log level SD_INFO.</para> + + <example> + <title>Hello World</title> + + <para>A daemon may log with the log level NOTICE by issuing this + call:</para> + + <programlisting>fprintf(stderr, SD_NOTICE "Hello World!\n");</programlisting> + </example> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fprintf</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-event.xml b/man/sd-event.xml new file mode 100644 index 0000000..a28c9b8 --- /dev/null +++ b/man/sd-event.xml @@ -0,0 +1,162 @@ +<?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-or-later --> + +<refentry id="sd-event" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-event</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-event</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-event</refname> + <refpurpose>A generic event loop implementation</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-event.h</filename> provides a generic event + loop implementation, based on Linux <citerefentry + project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + + <para>See + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_get_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_get_pending</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the functions available.</para> + + <para>The event loop design is targeted on running a separate + instance of the event loop in each thread; it has no concept of + distributing events from a single event loop instance onto + multiple worker threads. Dispatching events is strictly ordered + and subject to configurable priorities. In each event loop + iteration a single event source is dispatched. Each time an event + source is dispatched the kernel is polled for new events, before + the next event source is dispatched. The event loop is designed to + honor priorities and provide fairness within each priority. It is + not designed to provide optimal throughput, as this contradicts + these goals due the limitations of the underlying <citerefentry + project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry> + primitives.</para> + + <para>The event loop implementation provides the following features:</para> + + <orderedlist> + <listitem><para>I/O event sources, based on <citerefentry + project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>'s + file descriptor watching, including edge triggered events (<constant>EPOLLET</constant>). See <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Timer event sources, based on <citerefentry + project='man-pages'><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + supporting the <constant>CLOCK_MONOTONIC</constant>, + <constant>CLOCK_REALTIME</constant>, + <constant>CLOCK_BOOTIME</constant> clocks, as well as the + <constant>CLOCK_REALTIME_ALARM</constant> and + <constant>CLOCK_BOOTTIME_ALARM</constant> clocks that can resume + the system from suspend. When creating timer events a required + accuracy parameter may be specified which allows coalescing of + timer events to minimize power consumption. See <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>UNIX process signal events, based on + <citerefentry + project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + including full support for real-time signals, and queued parameters. See <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Child process state change events, based on + <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>. See <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Static event sources, of three types: defer, + post and exit, for invoking calls in each event loop, after + other event sources or at event loop termination. See + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Event sources may be assigned a 64bit priority + value, that controls the order in which event sources are + dispatched if multiple are pending simultaneously. See + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>The event loop may automatically send watchdog + notification messages to the service manager. See + <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>The event loop may be integrated into foreign + event loops, such as the GLib one. See + <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for an example.</para></listitem> + </orderedlist> + + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_get_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_get_pending</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-hwdb.xml b/man/sd-hwdb.xml new file mode 100644 index 0000000..254c218 --- /dev/null +++ b/man/sd-hwdb.xml @@ -0,0 +1,57 @@ +<?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-or-later --> + +<refentry id="sd-hwdb" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-hwdb</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-hwdb</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-hwdb</refname> + <refpurpose>Read-only access to the hardware description database</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-hwdb.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-hwdb.h</filename> allows read-only access the systemd database of hardware properties. + See <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> and + <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more + information about the database.</para> + + <para>See <citerefentry><refentrytitle>sd_hwdb_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and <citerefentry><refentrytitle>sd_hwdb_get</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + information about the functions available.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-id128.xml b/man/sd-id128.xml new file mode 100644 index 0000000..40a3cc5 --- /dev/null +++ b/man/sd-id128.xml @@ -0,0 +1,168 @@ +<?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-or-later --> + +<refentry id="sd-id128" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-id128</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-id128</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-id128</refname> + <refname>sd_id128_t</refname> + <refname>SD_ID128_MAKE</refname> + <refname>SD_ID128_MAKE_STR</refname> + <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> + <refpurpose>APIs for processing 128-bit IDs</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-id128.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-id128.h</filename> provides APIs to process and + generate 128-bit ID values. The 128-bit ID values processed and + generated by these APIs are a generalization of OSF UUIDs as + defined by <ulink url="https://tools.ietf.org/html/rfc4122">RFC + 4122</ulink> but use a simpler string format. These functions + impose no structure on the used IDs, much unlike OSF UUIDs or + Microsoft GUIDs, but are fully compatible with those types of IDs. + </para> + + <para>See + <citerefentry><refentrytitle>sd_id128_to_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the implemented functions.</para> + + <para>A 128-bit ID is implemented as the following + union type:</para> + + <programlisting>typedef union sd_id128 { + uint8_t bytes[16]; + uint64_t qwords[2]; +} sd_id128_t;</programlisting> + + <para>This union type allows accessing the 128-bit ID as 16 + separate bytes or two 64-bit words. It is generally safer to + access the ID components by their 8-bit array to avoid endianness + issues. This union is intended to be passed call-by-value (as + opposed to call-by-reference) and may be directly manipulated by + clients.</para> + + <para>A couple of macros are defined to denote and decode 128-bit + IDs:</para> + + <para><function>SD_ID128_MAKE()</function> may be used to denote a + constant 128-bit ID in source code. A commonly used idiom is to + assign a name to a 128-bit ID using this macro:</para> + + <programlisting>#define SD_MESSAGE_COREDUMP SD_ID128_MAKE(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1)</programlisting> + + <para><constant>SD_ID128_NULL</constant> may be used to refer to the 128bit ID consisting of only + <constant>NUL</constant> bytes.</para> + + <para><function>SD_ID128_MAKE_STR()</function> is similar to <function>SD_ID128_MAKE()</function>, but creates a + <type>const char*</type> expression that can be conveniently used in message formats and such:</para> + + <programlisting>#include <stdio.h> +#define SD_MESSAGE_COREDUMP_STR SD_ID128_MAKE_STR(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1) + +int main(int argc, char **argv) { + puts("Match for coredumps: MESSAGE_ID=" SD_MESSAGE_COREDUMP_STR); +} + </programlisting> + + <para><function>SD_ID128_CONST_STR()</function> may be used to + convert constant 128-bit IDs into constant strings for output. The + following example code will output the string + "fc2e22bc6ee647b6b90729ab34a250b1":</para> + <programlisting>int main(int argc, char *argv[]) { + puts("Match for coredumps: %s", SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP)); +}</programlisting> + + <para><constant>SD_ID128_FORMAT_STR</constant> and <function>SD_ID128_FORMAT_VAL()</function> may + be used to format a 128-bit ID in a + <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> + format string, as shown in the following example:</para> + + <programlisting>int main(int argc, char *argv[]) { + sd_id128_t id; + id = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + printf("The ID encoded in this C file is " SD_ID128_FORMAT_STR ".\n", SD_ID128_FORMAT_VAL(id)); + return 0; +}</programlisting> + + <para><constant>SD_ID128_UUID_FORMAT_STR</constant> is similar to + <constant>SD_ID128_FORMAT_STR</constant> 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[]) { + sd_id128_t a, b, c; + a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + b = SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e); + c = a; + assert(sd_id128_equal(a, c)); + assert(!sd_id128_equal(a, b)); + return 0; +}</programlisting> + + <para>Use <function>sd_id128_is_null()</function> to check if an 128bit ID consists of only + <constant>NUL</constant> bytes:</para> + + <programlisting>int main(int argc, char *argv[]) { + assert(sd_id128_is_null(SD_ID128_NULL)); +}</programlisting> + + <para>Note that new, randomized IDs may be generated with + <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>new</command> command.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_to_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-journal.xml b/man/sd-journal.xml new file mode 100644 index 0000000..4609868 --- /dev/null +++ b/man/sd-journal.xml @@ -0,0 +1,118 @@ +<?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-or-later --> + +<refentry id="sd-journal" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-journal</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-journal</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-journal</refname> + <refpurpose>APIs for submitting and querying log entries to and + from the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-journal.h</filename> provides APIs to submit + and query log entries. The APIs exposed act both as client for the + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + journal service and as parser for the journal files on disk. + </para> + + <para>See + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cutoff_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_usage</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_catalog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_has_runtime_files</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_journal_has_persistent_files</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the functions implemented.</para> + + <para>Command line access for submitting entries to the journal is + available with the + <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool. Command line access for querying entries from the journal is + available with the + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool.</para> + </refsect1> + + <refsect1> + <title>Thread safety</title> + + <para>Functions that operate on <structname>sd_journal</structname> objects are thread agnostic — given + <structname>sd_journal</structname> pointer may only be used from one specific thread at all times (and it has to + be the very same one during the entire lifetime of the object), but multiple, independent threads may use multiple, + independent objects safely. Other functions — those that are used to send entries to the journal, like + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and similar, + or those that are used to retrieve global information like + <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_journal_get_catalog_for_message_id</refentrytitle><manvolnum>3</manvolnum></citerefentry> + — are fully thread-safe and may be called from multiple threads in parallel.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cutoff_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_usage</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_catalog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_has_runtime_files</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_has_persistent_files</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd-login.xml b/man/sd-login.xml new file mode 100644 index 0000000..0127b69 --- /dev/null +++ b/man/sd-login.xml @@ -0,0 +1,247 @@ +<?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-or-later --> + +<refentry id="sd-login" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd-login</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd-login</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd-login</refname> + <refpurpose>APIs for + tracking logins</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + </funcsynopsis> + + <cmdsynopsis> + <command>pkg-config --cflags --libs libsystemd</command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>sd-login.h</filename> provides APIs to introspect + and monitor seat, login session and user status information on the + local system. </para> + + <para>Note that these APIs only allow purely passive access and + monitoring of seats, sessions and users. To actively make changes + to the seat configuration, terminate login sessions, or switch + session on a seat you need to utilize the D-Bus API of + systemd-logind, instead.</para> + + <para>These functions synchronously access data in + <filename>/proc/</filename>, <filename>/sys/fs/cgroup/</filename> + and <filename>/run/</filename>. All of these are virtual file + systems, hence the runtime cost of the accesses is relatively + cheap.</para> + + <para>It is possible (and often a very good choice) to mix calls + to the synchronous interface of <filename>sd-login.h</filename> + with the asynchronous D-Bus interface of systemd-logind. However, + if this is done you need to think a bit about possible races since + the stream of events from D-Bus and from + <filename>sd-login.h</filename> interfaces such as the login + monitor are asynchronous and not ordered against each + other.</para> + + <para>If the functions return string arrays, these are generally + <constant>NULL</constant> terminated and need to be freed by the + caller with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use, including the strings referenced therein. + Similarly, individual strings returned need to be freed, as + well.</para> + + <para>As a special exception, instead of an empty string array + <constant>NULL</constant> may be returned, which should be treated + equivalent to an empty string array.</para> + + <para>See + <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_seat_get_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_login_monitor_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information about the functions + implemented.</para> + </refsect1> + + <refsect1> + <title>Definition of Terms</title> + + <variablelist> + <varlistentry> + <term>seat</term> + + <listitem><para>A seat consists of all hardware devices assigned to a specific + workplace. It consists of at least one graphics device, and usually also includes + keyboard, mouse. It can also include video cameras, sound cards and more. Seats + are identified by seat names, which are strings (<= 255 characters), that start + with the four characters <literal>seat</literal> followed by at least one + character from the range [a-zA-Z0-9], <literal>_</literal> and + <literal>-</literal>. They are suitable for use as file names. Seat names may or + may not be stable and may be reused if a seat becomes available again. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>session</term> + + <listitem><para>A session is defined by the time a user is logged in until they + log out. A session is bound to one or no seats (the latter for 'virtual' ssh + logins). Multiple sessions can be attached to the same seat, but only one of them + can be active, the others are in the background. A session is identified by a + short string.</para> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + ensures that audit sessions are identical to systemd sessions, and uses the audit + session ID as session ID in systemd (if auditing is enabled). In general the + session identifier is a short string consisting only of [a-zA-Z0-9], + <literal>_</literal> and <literal>-</literal>, suitable for use as a file name. + Session IDs are unique on the local machine and are + never reused as long as the machine is online. A user (the way we know it on UNIX) + corresponds to the person using a computer. A single user can have multiple + sessions open at the same time. A user is identified by a numeric user id (UID) or + a user name (a string). A multi-session system allows multiple user sessions on + the same seat at the same time. A multi-seat system allows multiple independent + seats that can be individually and simultaneously used by different users.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>All hardware devices that are eligible to being assigned to a seat, are assigned + to one. A device can be assigned to only one seat at a time. If a device is not + assigned to any particular other seat it is implicitly assigned to the special default + seat called <literal>seat0</literal>.</para> + + <para>Note that hardware like printers, hard disks or network cards is generally not + assigned to a specific seat. They are available to all seats equally. (Well, with one + exception: USB sticks can be assigned to a seat.)</para> + + <para><literal>seat0</literal> always exists.</para> + </refsect1> + + <refsect1> + <title>udev Rules</title> + + <para>Assignment of hardware devices to seats is managed inside the udev database, via + settings on the devices:</para> + + <variablelist class='udev-directives'> + <varlistentry> + <term>Tag <literal>seat</literal></term> + + <listitem><para>When set, a device is eligible to be assigned to a seat. This tag + is set for graphics devices, mice, keyboards, video cards, sound cards and + more. Note that some devices like sound cards consist of multiple subdevices + (i.e. a PCM for input and another one for output). This tag will be set only for + the originating device, not for the individual subdevices. A UI for configuring + assignment of devices to seats should enumerate and subscribe to all devices with + this tag set and show them in the UI. Note that USB hubs can be assigned to a seat + as well, in which case all (current and future) devices plugged into it will also + be assigned to the same seat (unless they are explicitly assigned to another + seat). + </para></listitem> + </varlistentry> + + <varlistentry> + <term>Tag <literal>master-of-seat</literal></term> + + <listitem><para>When set, this device is enough for a seat to be considered + existent. This tag is usually set for the framebuffer device of graphics cards. A + seat hence consists of an arbitrary number of devices marked with the + <literal>seat</literal> tag, but (at least) one of these devices needs to be + tagged with <literal>master-of-seat</literal> before the seat is actually + considered to be around.</para></listitem> + </varlistentry> + + <varlistentry> + <term>Property <varname>ID_SEAT</varname></term> + + <listitem><para>This property specifies the name of the seat a specific device is + assigned to. If not set the device is assigned to <literal>seat0</literal>. Also, + to speed up enumeration of hardware belonging to a specific seat, the seat is also + set as tag on the device. I.e. if the property + <varname>ID_SEAT=seat-waldo</varname> is set for a device, the tag + <literal>seat-waldo</literal> will be set as well. Note that if a device is + assigned to <literal>seat0</literal>, it will usually not carry such a tag and you + need to enumerate all devices and check the <varname>ID_SEAT</varname> property + manually. Again, if a device is assigned to seat0 this is visible on the device in + two ways: with a property <varname>ID_SEAT=seat0</varname> and with no property + <varname>ID_SEAT</varname> set for it at all.</para></listitem> + </varlistentry> + + <varlistentry> + <term>Property <varname>ID_AUTOSEAT</varname></term> + + <listitem><para>When set to <literal>1</literal>, this device automatically + generates a new and independent seat, which is named after the path of the + device. This is set for specialized USB hubs like the Pluggable devices, which when + plugged in should create a hotplug seat without further configuration.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Property <varname>ID_FOR_SEAT</varname></term> + + <listitem><para>When creating additional (manual) seats starting from a graphics + device this is a good choice to name the seat after. It is created from the path + of the device. This is useful in UIs for configuring seats: as soon as you create + a new seat from a graphics device, read this property and prefix it with + <literal>seat-</literal> and use it as name for the seat.</para></listitem> + </varlistentry> + </variablelist> + + <para>A seat exists only and exclusively because a properly tagged device with the + right <varname>ID_SEAT</varname> property exists. Besides udev rules there is no + persistent data about seats stored on disk.</para> + + <para>Note that + <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry> + manages ACLs on a number of device classes, to allow user code to access the device + nodes attached to a seat as long as the user has an active session on it. This is + mostly transparent to applications. As mentioned above, for certain user software it + might be a good idea to watch whether they can access device nodes instead of thinking + about seats.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_seat_get_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_login_monitor_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + + <para> + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/multiseat">Multi-Seat on Linux</ulink> + may also be of historical interest. + </para> + </refsect1> +</refentry> diff --git a/man/sd_booted.xml b/man/sd_booted.xml new file mode 100644 index 0000000..d9b3ddc --- /dev/null +++ b/man/sd_booted.xml @@ -0,0 +1,68 @@ +<?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-or-later --> + +<refentry id="sd_booted" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_booted</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_booted</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_booted</refname> + <refpurpose>Test whether the system is running the systemd init system</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-daemon.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_booted</function></funcdef> + <paramdef>void</paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para><function>sd_booted()</function> checks whether the system + was booted up using the systemd init system.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, this call returns a negative errno-style error + code. If the system was booted up with systemd as init system, + this call returns a positive return value, zero otherwise.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + + <para>Internally, this function checks whether the directory + <filename>/run/systemd/system/</filename> exists. A simple check + like this can also be implemented trivially in shell or any other + language.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_add_match.xml b/man/sd_bus_add_match.xml new file mode 100644 index 0000000..1ce1c13 --- /dev/null +++ b/man/sd_bus_add_match.xml @@ -0,0 +1,173 @@ +<?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-or-later + + Copyright © 2016 Julian Orth +--> + +<refentry id="sd_bus_add_match" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_add_match</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_add_match</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_add_match</refname> + <refname>sd_bus_add_match_async</refname> + <refname>sd_bus_match_signal</refname> + <refname>sd_bus_match_signal_async</refname> + + <refpurpose>Add a match rule for incoming message dispatching</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype id="sd_bus_message_handler_t"> + <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>int <function>sd_bus_add_match</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>match</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_add_match_async</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>match</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>install_callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_match_signal</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>sender</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_match_signal_async</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>sender</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>install_callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_add_match()</function> installs a match rule for messages received on the specified bus + connection object <parameter>bus</parameter>. The syntax of the match rule expression passed in + <parameter>match</parameter> is described in the <ulink + url="https://dbus.freedesktop.org/doc/dbus-specification.html">D-Bus Specification</ulink>. The specified handler + function <parameter>callback</parameter> is called for eaching incoming message matching the specified expression, + the <parameter>userdata</parameter> parameter is passed as-is to the callback function. The match is installed + synchronously when connected to a bus broker, i.e. the call sends a control message requested the match to be added + to the broker and waits until the broker confirms the match has been installed successfully.</para> + + <para><function>sd_bus_add_match_async()</function> operates very similar to + <function>sd_bus_match_signal()</function>, however it installs the match asynchronously, in a non-blocking + fashion: a request is sent to the broker, but the call does not wait for a response. The + <parameter>install_callback</parameter> function is called when the response is later received, with the response + message from the broker as parameter. If this function is specified as <constant>NULL</constant> a default + implementation is used that terminates the bus connection should installing the match fail.</para> + + <para><function>sd_bus_match_signal()</function> is very similar to <function>sd_bus_add_match()</function>, but + only matches signals, and instead of a match expression accepts four parameters: <parameter>sender</parameter> (the + service name of the sender), <parameter>path</parameter> (the object path of the emitting object), + <parameter>interface</parameter> (the interface the signal belongs to), <parameter>member</parameter> (the signal + name), from which the match string is internally generated. Optionally, these parameters may be specified as + <constant>NULL</constant> in which case the relevant field of incoming signals is not tested.</para> + + <para><function>sd_bus_match_signal_async()</function> combines the signal matching logic of + <function>sd_bus_match_signal()</function> with the asynchronous behaviour of + <function>sd_bus_add_match_async()</function>.</para> + + <para>On success, and if non-<constant>NULL</constant>, the <parameter>slot</parameter> return parameter will be + set to a slot object that may be used as a reference to the installed match, and may be utilized to remove it again + at a later time with + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If specified + as <constant>NULL</constant> the lifetime of the match is bound to the lifetime of the bus object itself, and the + match is generally not removed independently. See + <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details.</para> + + <para>The message <parameter>m</parameter> passed to the callback is only borrowed, that is, the callback should + not call <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + on it. If the callback wants to hold on to the message beyond the lifetime of the callback, it needs to call + <citerefentry><refentrytitle>sd_bus_message_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry> to create a + new reference.</para> + + <para>If an error occurs during the callback invocation, the callback should return a negative error number + (optionally, a more precise error may be returned in <parameter>ret_error</parameter>, as well). If it wants other + callbacks that match the same rule to be called, it should return 0. Otherwise it should return a positive integer. + </para> + + <para>If the <parameter>bus</parameter> refers to a direct connection (i.e. not a bus connection, as set with + <citerefentry><refentrytitle>sd_bus_set_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>) the + match is only installed on the client side, and the synchronous and asynchronous functions operate the same.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para> + On success, <function>sd_bus_add_match()</function> and the other calls return 0 or a positive integer. On + failure, they return a negative errno-style error code. + </para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_add_node_enumerator.xml b/man/sd_bus_add_node_enumerator.xml new file mode 100644 index 0000000..da3989e --- /dev/null +++ b/man/sd_bus_add_node_enumerator.xml @@ -0,0 +1,137 @@ +<?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-or-later --> + +<refentry id="sd_bus_add_node_enumerator" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_add_node_enumerator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_add_node_enumerator</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_add_node_enumerator</refname> + + <refpurpose>Add a node enumerator for a D-Bus object path prefix</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_bus_node_enumerator_t</function>)</funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>prefix</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>char ***<parameter>ret_nodes</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_add_node_enumerator</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>sd_bus_node_enumerator_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_add_node_enumerator()</function> adds a D-Bus node enumerator for the + given path prefix. The given callback is called to enumerate all the available objects with + the given path prefix when required (e.g. when + <constant>org.freedesktop.DBus.Introspectable.Introspect</constant> or + <constant>org.freedesktop.DBus.ObjectManager.GetManagedObjects</constant> are called on a + D-Bus service managed by sd-bus).</para> + + <para><parameter>callback</parameter> is called with the path and userdata pointer registered + with <function>sd_bus_add_node_enumerator()</function>. When called, it should store all the + child object paths of the given path prefix in <parameter>ret_nodes</parameter> and return the + number of child objects under the given prefix. If an error occurs, it can either return a + negative integer, set <parameter>ret_error</parameter> to a non-empty error or do both. Any + errors returned by the callback are encoded as D-Bus errors and sent back to the caller. Errors + in <parameter>ret_error</parameter> take priority over negative return values.</para> + + <para>Note that a node enumerator callback will only ever be called for a single path prefix + and hence, for normal operation, <parameter>prefix</parameter> can be ignored. Also, a node + enumerator is only used to enumerate the available child objects under a given prefix. To + install a handler for a set of dynamic child objects, use + <citerefentry><refentrytitle>sd_bus_add_fallback_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>When <function>sd_bus_add_node_enumerator()</function> succeeds, a 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 node enumerator is not needed anymore, see + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_add_node_enumerator()</function> returns a non-negative + integer. On failure, it returns 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 + <parameter>path</parameter> is not a valid object path. + </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> + </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>, + <citerefentry><refentrytitle>sd_bus_add_fallback_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_add_object.xml b/man/sd_bus_add_object.xml new file mode 100644 index 0000000..00e4110 --- /dev/null +++ b/man/sd_bus_add_object.xml @@ -0,0 +1,653 @@ +<?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-or-later --> + +<refentry id="sd_bus_add_object" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_add_object</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_add_object</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_add_object</refname> + <refname>sd_bus_add_fallback</refname> + <refname>sd_bus_add_object_vtable</refname> + <refname>sd_bus_add_fallback_vtable</refname> + <refname>sd_bus_add_filter</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> + + <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/> + + <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</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>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_add_fallback</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>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</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> + + <funcprototype> + <funcdef>int <function>sd_bus_add_filter</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</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_ARGS_OFFSET( + <replaceable>member</replaceable>, + <replaceable>args</replaceable>, + <replaceable>result</replaceable>, + <replaceable>handler</replaceable>, + <replaceable>offset</replaceable>, + <replaceable>flags</replaceable>) + </constant> + </para> + <para> + <constant>SD_BUS_METHOD_WITH_ARGS( + <replaceable>member</replaceable>, + <replaceable>args</replaceable>, + <replaceable>result</replaceable>, + <replaceable>handler</replaceable>, + <replaceable>flags</replaceable>) + </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_ARGS( + <replaceable>member</replaceable>, + <replaceable>args</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> + <constant>SD_BUS_ARGS(<replaceable>...</replaceable>)</constant> + <constant>SD_BUS_RESULT(<replaceable>...</replaceable>)</constant> + <constant>SD_BUS_NO_ARGS</constant> + <constant>SD_BUS_NO_RESULT</constant> + </para> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_add_object_vtable()</function> is used to declare attributes for the + 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. An interface can have any number of vtables attached to it.</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><function>sd_bus_add_object()</function> attaches a callback directly to the object path + <parameter>path</parameter>. An object path can have any number of callbacks attached to it. + Each callback is prepended to the list of callbacks which are always called in order. + <function>sd_bus_add_fallback()</function> is similar to + <function>sd_bus_add_object()</function> but applies to fallback paths instead.</para> + + <para><function>sd_bus_add_filter()</function> installs a callback that is invoked for each + incoming D-Bus message. Filters can be used to handle logic common to all messages received by + a service (e.g. authentication or authorization).</para> + + <para>When a request is received, any associated callbacks are called sequentially until a + callback returns a non-zero integer. Return zero from a callback to give other callbacks the + chance to process the request. Callbacks are called in the following order: first, global + callbacks installed with <function>sd_bus_add_filter()</function> are called. Second, callbacks + attached directly to the request object path are called, followed by any D-Bus method callbacks + attached to the request object path, interface and member. Finally, the property callbacks + attached to the request object path, interface and member are called. If the final callback + returns zero, an error reply is sent back to the caller indicating no matching object for the + request was found.</para> + + <para>Note that you can return a positive integer from a callback without + immediately sending a reply. This informs sd-bus this callback will take responsibility for + replying to the request without forcing the callback to produce a reply immediately. This allows + a callback to perform any number of asynchronous operations required to construct a reply. + However, if producing a reply takes too long, the method call will time out at the caller.</para> + + <para>If a callback was invoked to handle a request that expects a reply and the callback + returns a negative value, the value is interpreted as a negative errno-style error code and sent + back to the caller as a D-Bus error as if + <citerefentry><refentrytitle>sd_bus_reply_method_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + was called. Additionally, all callbacks take a <structname>sd_bus_error</structname> output + parameter that can be used to provide more detailed error information. If + <parameter>ret_error</parameter> is set when the callback finishes, the corresponding D-Bus + error is sent back to the caller as if + <citerefentry><refentrytitle>sd_bus_reply_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry> + was called. Any error stored in <parameter>ret_error</parameter> takes priority over any + negative values returned by the same callback when determining which error to send back to + the caller. Use + <citerefentry><refentrytitle>sd_bus_error_set</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or one of its variants to set <parameter>ret_error</parameter> and return a negative integer + from a callback with a single function call. To send an error reply after a callback has already + finished, use + <citerefentry><refentrytitle>sd_bus_reply_method_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or one of its variants.</para> + + <para>For all 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_ARGS_OFFSET()</constant></term> + <term><constant>SD_BUS_METHOD_WITH_ARGS()</constant></term> + + <listitem><para>Declare a D-Bus method with the name <replaceable>member</replaceable>, + arguments <replaceable>args</replaceable> and result <replaceable>result</replaceable>. + <replaceable>args</replaceable> expects a sequence of argument type/name pairs wrapped in the + <constant>SD_BUS_ARGS()</constant> macro. The elements at even indices in this list describe the + types of the method's arguments. The method's parameter signature is the concatenation of all the + string literals at even indices in <replaceable>args</replaceable>. If a method has no parameters, + pass <constant>SD_BUS_NO_ARGS</constant> to <replaceable>args</replaceable>. The elements at uneven + indices describe the names of the method's arguments. <replaceable>result</replaceable> expects a + sequence of type/name pairs wrapped in the <constant>SD_BUS_RESULT()</constant> macro in the same + format as <constant>SD_BUS_ARGS()</constant>. The method's result signature is the concatenation of + all the string literals at even indices in <replaceable>result</replaceable>. If a method has no + result, pass <constant>SD_BUS_NO_RESULT</constant> to <replaceable>result</replaceable>. Note that + argument types are expected to be quoted string literals and argument names are expected to be + unquoted string literals. See below for a complete example.</para> + + <para>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. To send a reply from <parameter>handler</parameter>, call + <citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with the message the callback was invoked with. Parameter <replaceable>flags</replaceable> is a + combination of flags, see below.</para> + + <para><constant>SD_BUS_METHOD_WITH_ARGS()</constant> is a shorthand for calling + <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant> with an offset of zero.</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. <replaceable>in_names</replaceable> and + <replaceable>out_names</replaceable> should be created using the + <constant>SD_BUS_PARAM()</constant> macro, see below. In all other regards, this macro behaves + exactly the same as <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant>.</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> + + <para>Prefer using <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant> and + <constant>SD_BUS_METHOD_WITH_ARGS()</constant> over these macros as they allow specifying argument + types and names next to each other which is less error-prone than first specifying all argument + types followed by specifying all argument names.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_SIGNAL_WITH_ARGS()</constant></term> + + <listitem><para>Declare a D-Bus signal with the name <replaceable>member</replaceable> and + arguments <replaceable>args</replaceable>. <replaceable>args</replaceable> expects a sequence of + argument type/name pairs wrapped in the <constant>SD_BUS_ARGS()</constant> macro. The elements at + even indices in this list describe the types of the signal's arguments. The signal's parameter + signature is the concatenation of all the string literals at even indices in + <replaceable>args</replaceable>. If a signal has no parameters, pass + <constant>SD_BUS_NO_ARGS</constant> to <replaceable>args</replaceable>. The elements at uneven + indices describe the names of the signal's arguments. Parameter <replaceable>flags</replaceable> is + a combination of flags. See below for a complete example.</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><constant>SD_BUS_SIGNAL()</constant> is equivalent to + <constant>SD_BUS_SIGNAL_WITH_NAMES()</constant> with the <replaceable>names</replaceable> parameter + unset (i.e. no parameter names).</para> + + <para>Prefer using <constant>SD_BUS_SIGNAL_WITH_ARGS()</constant> over these macros as it allows + specifying argument types and names next to each other which is less error-prone than first + specifying all argument types followed by specifying all argument 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 is 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 a valid variable of the corresponding type. A default setter and getter + 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> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_SENSITIVE</constant></term> + + <listitem><para>Mark this vtable method entry as processing sensitive data. When set, + incoming method call messages and their outgoing reply messages are marked as sensitive using + <citerefentry><refentrytitle>sd_bus_message_sensitive</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + so that they are erased from memory when freed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_VTABLE_ABSOLUTE_OFFSET</constant></term> + + <listitem><para>Mark this vtable method or property entry so that the user data pointer passed to + its associated handler functions is determined slightly differently: instead of adding the offset + parameter of the entry to the user data pointer specified during vtable registration, the offset is + passed directly, converted to a pointer, without taking the user data pointer specified during + vtable registration into account.</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> return a non-negative 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>, + <citerefentry><refentrytitle>sd_bus_emit_properties_changed</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_emit_object_added</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_add_object_manager.xml b/man/sd_bus_add_object_manager.xml new file mode 100644 index 0000000..df2704a --- /dev/null +++ b/man/sd_bus_add_object_manager.xml @@ -0,0 +1,118 @@ +<?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-or-later --> + +<refentry id="sd_bus_add_object_manager" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_add_object_manager</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_add_object_manager</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_add_object_manager</refname> + + <refpurpose>Add a D-Bus object manager for a D-Bus object sub-tree</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_add_object_manager</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_add_object_manager()</function> installs a handler for the given path + that implements the <function>GetManagedObjects()</function> method of the + <constant>org.freedesktop.DBus.ObjectManager</constant> interface. See + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager"> + org.freedesktop.DBus.ObjectManager</ulink> for more information.</para> + + <para>To implement the <function>InterfacesAdded</function> and + <function>InterfacesRemoved</function> signals of the + <constant>org.freedesktop.DBus.ObjectManager</constant> interface, call + <citerefentry><refentrytitle>sd_bus_emit_interfaces_added</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_emit_interfaces_removed</refentrytitle><manvolnum>3</manvolnum></citerefentry> + whenever interfaces are added or removed from the sub-tree, respectively.</para> + + <para>When <function>sd_bus_add_object_manager()</function> succeeds, a 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 object manager is not needed anymore, see + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_add_object_manager()</function> returns a non-negative + integer. On failure, it returns 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 + <parameter>path</parameter> is not a valid object path. + </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> + </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>, + <citerefentry><refentrytitle>sd_bus_add_object_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_emit_interfaces_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_attach_event.xml b/man/sd_bus_attach_event.xml new file mode 100644 index 0000000..bb34d4a --- /dev/null +++ b/man/sd_bus_attach_event.xml @@ -0,0 +1,119 @@ +<?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-or-later --> + +<refentry id="sd_bus_attach_event" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_attach_event</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_attach_event</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_attach_event</refname> + <refname>sd_bus_detach_event</refname> + <refname>sd_bus_get_event</refname> + + <refpurpose>Attach a bus connection object to an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_attach_event</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_event *<parameter>e</parameter></paramdef> + <paramdef>int <parameter>priority</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_detach_event</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_event *<function>sd_bus_get_event</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_attach_event()</function> attaches the specified bus connection object to an + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> event loop object at + the specified priority (see + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for details on event loop priorities). When a bus connection object is attached to an event loop incoming messages + will be automatically read and processed, and outgoing messages written, whenever the event loop is run. When the + event loop is about to terminate, the bus connection is automatically flushed and closed (see + <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details on this). By default bus connection objects are not attached to any event loop. When a bus connection + object is attached to one it is not necessary to invoke + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> as this + functionality is handled automatically by the event loop.</para> + + <para><function>sd_bus_detach_event()</function> detaches a bus object from its event loop.</para> + + <para>The <function>sd_bus_get_event()</function> returns the event loop object the specified bus object is + currently attached to, or <constant>NULL</constant> if it is currently not attached to any.</para> + + <para>Note that <function>sd_bus_attach_event()</function> is only one of three supported ways to implement I/O + event handling for bus connections. Alternatively use + <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> for hooking up a + bus connection object with external or manual event loops. Or use + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> as a simple + synchronous, blocking I/O waiting call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_attach_event()</function> and <function>sd_bus_detach_event()</function> return + 0 or a positive integer. On failure, they return a negative errno-style error code.</para> + + <para><function>sd_bus_get_event()</function> returns an event loop object or <constant>NULL</constant>.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_call.xml b/man/sd_bus_call.xml new file mode 100644 index 0000000..1f7dfc2 --- /dev/null +++ b/man/sd_bus_call.xml @@ -0,0 +1,200 @@ +<?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-or-later --> + +<refentry id="sd_bus_call" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_call</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_call</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_call</refname> + <refname>sd_bus_call_async</refname> + + <refpurpose>Invoke a D-Bus method call</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/> + + <funcprototype> + <funcdef>int <function>sd_bus_call</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_call_async</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_call()</function> takes a complete bus message object and calls the + corresponding D-Bus method. On success, the response is stored in <parameter>reply</parameter>. + <parameter>usec</parameter> indicates the timeout in microseconds. If + <parameter>ret_error</parameter> is not <constant>NULL</constant> and + <function>sd_bus_call()</function> fails (either because of an internal error or because it + received a D-Bus error reply), <parameter>ret_error</parameter> is initialized to an instance of + <structname>sd_bus_error</structname> describing the error.</para> + + <para><function>sd_bus_call_async()</function> is like <function>sd_bus_call()</function> but works + asynchronously. The <parameter>callback</parameter> indicates the function to call when the response + arrives. The <parameter>userdata</parameter> pointer will be passed to the callback function, and may be + chosen freely by the caller. If <parameter>slot</parameter> is not <constant>NULL</constant> and + <function>sd_bus_call_async()</function> succeeds, <parameter>slot</parameter> is set to a slot object + which can be used to cancel the method call at a later time using + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If <parameter>slot</parameter> is <constant>NULL</constant>, the lifetime of the method call is bound to + the lifetime of the bus object itself, and it cannot be cancelled independently. See + <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for details. <parameter>callback</parameter> is called when a reply arrives with the reply, + <parameter>userdata</parameter> and an <structname>sd_bus_error</structname> output parameter as its + arguments. Unlike <function>sd_bus_call()</function>, the <structname>sd_bus_error</structname> output + parameter passed to the callback will be empty. To determine whether the method call succeeded, use + <citerefentry><refentrytitle>sd_bus_message_is_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry> + on the reply message passed to the callback instead. If the callback returns zero and the + <structname>sd_bus_error</structname> output parameter is still empty when the callback finishes, other + handlers registered with functions such as + <citerefentry><refentrytitle>sd_bus_add_filter</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> are + given a chance to process the message. If the callback returns a non-zero value or the + <structname>sd_bus_error</structname> output parameter is not empty when the callback finishes, no + further processing of the message is done. Generally, you want to return zero from the callback to give + other registered handlers a chance to process the reply as well. (Note that the + <structname>sd_bus_error</structname> parameter is an output parameter of the callback function, not an + input parameter; it can be used to propagate errors from the callback handler, it will not receive any + error that was received as method reply.)</para> + + <para>The message <parameter>m</parameter> passed to the callback is only borrowed, that is, the callback should + not call <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + on it. If the callback wants to hold on to the message beyond the lifetime of the callback, it needs to call + <citerefentry><refentrytitle>sd_bus_message_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry> to create a + new reference.</para> + + <para>If <parameter>usec</parameter> is zero, the default D-Bus method call timeout is used. See + <citerefentry><refentrytitle>sd_bus_get_method_call_timeout</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>When <function>sd_bus_call()</function> internally receives a D-Bus error reply, it will set + <parameter>ret_error</parameter> if it is not <constant>NULL</constant>, and will return a negative + value mapped from the error reply, see + <citerefentry><refentrytitle>sd_bus_error_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The input parameter <parameter>m</parameter> is <constant>NULL</constant>. + </para></listitem> + + <listitem><para>The input parameter <parameter>m</parameter> is not a D-Bus method call. + To create a new D-Bus method call, use + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para></listitem> + + <listitem><para>The input parameter <parameter>m</parameter> has the + <constant>BUS_MESSAGE_NO_REPLY_EXPECTED</constant> flag set.</para></listitem> + + <listitem><para>The input parameter <parameter>error</parameter> is + non-<constant>NULL</constant> but was not set to <constant>SD_BUS_ERROR_NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was allocated in a parent process and is being reused + in a child process after <function>fork()</function>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The input parameter <parameter>bus</parameter> is + <constant>NULL</constant> or the bus is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECONNRESET</constant></term> + + <listitem><para>The bus connection was closed while waiting for the response. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ETIMEDOUT</constant></term> + + <listitem><para>A response was not received within the given timeout.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ELOOP</constant></term> + + <listitem><para>The message <parameter>m</parameter> is addressed to its own client. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_call_method.xml b/man/sd_bus_call_method.xml new file mode 100644 index 0000000..762ea11 --- /dev/null +++ b/man/sd_bus_call_method.xml @@ -0,0 +1,143 @@ +<?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-or-later --> + +<refentry id="sd_bus_call_method" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_call_method</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_call_method</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_call_method</refname> + <refname>sd_bus_call_methodv</refname> + <refname>sd_bus_call_method_async</refname> + <refname>sd_bus_call_method_asyncv</refname> + + <refpurpose>Initialize a bus message object and invoke the corresponding D-Bus method call + </refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/> + + <funcprototype> + <funcdef>int <function>sd_bus_call_method</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_call_methodv</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_call_method_async</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_call_method_asyncv</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_call_method()</function> is a convenience function for initializing a + bus message object and calling the corresponding D-Bus method. It combines the + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> + functions into a single function call.</para> + + <para><function>sd_bus_call_method_async()</function> is a convenience function for initializing + a bus message object and calling the corresponding D-Bus method asynchronously. It combines the + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> + functions into a single function call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>See the man pages of + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a list of possible errors.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_property</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_emit_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_can_send.xml b/man/sd_bus_can_send.xml new file mode 100644 index 0000000..632d9bc --- /dev/null +++ b/man/sd_bus_can_send.xml @@ -0,0 +1,93 @@ +<?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-or-later --> + +<refentry id="sd_bus_can_send" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_can_send</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_can_send</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_can_send</refname> + + <refpurpose>Check which types can be sent over a bus object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>void <function>sd_bus_can_send</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_can_send()</function> is mostly used for checking if file descriptor + passing is available on the given bus. <parameter>type</parameter> can be any of the + <constant>SD_BUS_TYPE</constant> constants.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, <function>sd_bus_can_send()</function> returns a negative errno-style error + code. If values of the given type can be sent over the given bus, it returns a positive integer. + Otherwise, it returns zero.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus object <parameter>bus</parameter> could not be resolved.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The input parameter <parameter>bus</parameter> is + <constant>NULL</constant> or the bus is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus object <parameter>bus</parameter> was created in a different + process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_close.xml b/man/sd_bus_close.xml new file mode 100644 index 0000000..95427bd --- /dev/null +++ b/man/sd_bus_close.xml @@ -0,0 +1,119 @@ +<?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-or-later --> + +<refentry id="sd_bus_close" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_close</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_close</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_close</refname> + <refname>sd_bus_flush</refname> + <refname>sd_bus_default_flush_close</refname> + + <refpurpose>Close and flush a bus connection</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>void <function>sd_bus_close</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_flush</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_default_flush_close</function></funcdef> + <paramdef>void</paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <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 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> + + <para><function>sd_bus_flush()</function> synchronously writes out all outgoing queued message + on a bus connection if there are any. This function call may block if the peer is not processing + bus messages quickly.</para> + + <para>Before a program exits it is usually a good idea to flush any pending messages with + <function>sd_bus_flush()</function> and then close connections with + <function>sd_bus_close()</function> to ensure that no unwritten messages are lost, no further + messages may be queued and all incoming but unprocessed messages are released. After both + operations have been done, it is a good idea to also drop any remaining references to the bus + object so that it may be freed. Since these three operations are frequently done together a + helper call + <citerefentry><refentrytitle>sd_bus_flush_close_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + is provided that combines them into one.</para> + + <para><function>sd_bus_default_flush_close()</function> is similar to + <function>sd_bus_flush_close_unref()</function>, but does not take a bus pointer argument and + instead iterates over any of the "default" buses opened by + <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and similar calls. <function>sd_bus_default_flush_close()</function> is particularly useful to + clean up any buses opened using those calls before the program exits.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_flush()</function> returns a non-negative integer. On + failure, it returns a negative errno-style error code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_creds_get_pid.xml b/man/sd_bus_creds_get_pid.xml new file mode 100644 index 0000000..8f5b94e --- /dev/null +++ b/man/sd_bus_creds_get_pid.xml @@ -0,0 +1,527 @@ +<?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-or-later --> + +<refentry id="sd_bus_creds_get_pid" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_creds_get_pid</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_creds_get_pid</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_creds_get_pid</refname> + <refname>sd_bus_creds_get_ppid</refname> + <refname>sd_bus_creds_get_tid</refname> + <refname>sd_bus_creds_get_uid</refname> + <refname>sd_bus_creds_get_euid</refname> + <refname>sd_bus_creds_get_suid</refname> + <refname>sd_bus_creds_get_fsuid</refname> + <refname>sd_bus_creds_get_gid</refname> + <refname>sd_bus_creds_get_egid</refname> + <refname>sd_bus_creds_get_sgid</refname> + <refname>sd_bus_creds_get_fsgid</refname> + <refname>sd_bus_creds_get_supplementary_gids</refname> + <refname>sd_bus_creds_get_comm</refname> + <refname>sd_bus_creds_get_tid_comm</refname> + <refname>sd_bus_creds_get_exe</refname> + <refname>sd_bus_creds_get_cmdline</refname> + <refname>sd_bus_creds_get_cgroup</refname> + <refname>sd_bus_creds_get_unit</refname> + <refname>sd_bus_creds_get_slice</refname> + <refname>sd_bus_creds_get_user_unit</refname> + <refname>sd_bus_creds_get_user_slice</refname> + <refname>sd_bus_creds_get_session</refname> + <refname>sd_bus_creds_get_owner_uid</refname> + <refname>sd_bus_creds_has_effective_cap</refname> + <refname>sd_bus_creds_has_permitted_cap</refname> + <refname>sd_bus_creds_has_inheritable_cap</refname> + <refname>sd_bus_creds_has_bounding_cap</refname> + <refname>sd_bus_creds_get_selinux_context</refname> + <refname>sd_bus_creds_get_audit_session_id</refname> + <refname>sd_bus_creds_get_audit_login_uid</refname> + <refname>sd_bus_creds_get_tty</refname> + <refname>sd_bus_creds_get_unique_name</refname> + <refname>sd_bus_creds_get_well_known_names</refname> + <refname>sd_bus_creds_get_description</refname> + + <refpurpose>Retrieve fields from a credentials object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_pid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>pid_t *<parameter>pid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_ppid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>pid_t *<parameter>ppid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_tid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>pid_t *<parameter>tid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_uid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_euid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_suid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_fsuid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_gid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>gid_t *<parameter>gid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_egid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>gid_t *<parameter>gid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_sgid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>gid_t *<parameter>gid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_fsgid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>gid_t *<parameter>gid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_supplementary_gids</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const gid_t **<parameter>gids</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_comm</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>comm</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_tid_comm</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>comm</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_exe</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>exe</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_cmdline</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>char ***<parameter>cmdline</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_cgroup</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>cgroup</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_unit</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>unit</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_slice</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_user_unit</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>unit</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_user_slice</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_session</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_owner_uid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_has_effective_cap</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>int <parameter>capability</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_has_permitted_cap</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>int <parameter>capability</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_has_inheritable_cap</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>int <parameter>capability</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_has_bounding_cap</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>int <parameter>capability</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_selinux_context</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>context</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_audit_session_id</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uint32_t *<parameter>sessionid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_audit_login_uid</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>uid_t *<parameter>loginuid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_tty</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>tty</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_unique_name</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_well_known_names</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>char ***<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_get_description</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + <paramdef>const char **<parameter>name</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These functions return credential information from an + <parameter>sd_bus_creds</parameter> object. Credential objects may + be created with + <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + in which case they describe the credentials of the process + identified by the specified PID, with + <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + in which case they describe the credentials of a bus peer + identified by the specified bus name, with + <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + in which case they describe the credentials of the creator of a + bus, or with + <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + in which case they describe the credentials of the sender of the + message.</para> + + <para>Not all credential fields are part of every + <literal>sd_bus_creds</literal> object. Use + <citerefentry><refentrytitle>sd_bus_creds_get_mask</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to determine the mask of fields available.</para> + + <para><function>sd_bus_creds_get_pid()</function> will retrieve + the PID (process identifier). Similarly, + <function>sd_bus_creds_get_ppid()</function> will retrieve the + parent PID. Note that PID 1 has no parent process, in which case + -ENXIO is returned.</para> + + <para><function>sd_bus_creds_get_tid()</function> will retrieve the + TID (thread identifier).</para> + + <para><function>sd_bus_creds_get_uid()</function> will retrieve + the numeric UID (user identifier). Similarly, + <function>sd_bus_creds_get_euid()</function> returns the effective + UID, <function>sd_bus_creds_get_suid()</function> the saved UID + and <function>sd_bus_creds_get_fsuid()</function> the file system + UID.</para> + + <para><function>sd_bus_creds_get_gid()</function> will retrieve the + numeric GID (group identifier). Similarly, + <function>sd_bus_creds_get_egid()</function> returns the effective + GID, <function>sd_bus_creds_get_sgid()</function> the saved GID + and <function>sd_bus_creds_get_fsgid()</function> the file system + GID.</para> + + <para><function>sd_bus_creds_get_supplementary_gids()</function> + will retrieve the supplementary GIDs list.</para> + + <para><function>sd_bus_creds_get_comm()</function> will retrieve the + comm field (truncated name of the executable, as stored in + <filename>/proc/<replaceable>pid</replaceable>/comm</filename>). + </para> + + <para><function>sd_bus_creds_get_tid_comm()</function> will retrieve + the comm field of the thread (as stored in + <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. 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 + <filename>/proc/<replaceable>pid</replaceable>/cmdline</filename>). Note + that kernel threads do not have a command line, in which case + -ENXIO is returned.</para> + + <para><function>sd_bus_creds_get_cgroup()</function> will retrieve + the control group path. See <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>. + </para> + + <para><function>sd_bus_creds_get_unit()</function> will retrieve + the systemd unit name (in the system instance of systemd) that the + process is a part of. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For + processes that are not part of a unit, returns -ENXIO. + </para> + + <para><function>sd_bus_creds_get_user_unit()</function> will + retrieve the systemd unit name (in the user instance of systemd) + that the process is a part of. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For + processes that are not part of a user unit, returns -ENXIO. + </para> + + <para><function>sd_bus_creds_get_slice()</function> will retrieve + the systemd slice (a unit in the system instance of systemd) that + the process is a part of. See + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Similarly, + <function>sd_bus_creds_get_user_slice()</function> retrieves the + systemd slice of the process, in the user instance of systemd. + </para> + + <para><function>sd_bus_creds_get_session()</function> will + retrieve the identifier of the login session that the process is + a part of. Please note the login session may be limited to a stub + process or two. User processes may instead be started from their + systemd user manager, e.g. GUI applications started using DBus + activation, as well as service processes which are shared between + multiple logins of the same user. For processes that are not part + of a session, returns -ENXIO.</para> + + <para><function>sd_bus_creds_get_owner_uid()</function> will + retrieve the numeric UID (user identifier) of the user who owns + the user unit or login session that the process is a part of. See + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + For processes that are not part of a user unit or session, returns + -ENXIO. + </para> + + <para><function>sd_bus_creds_has_effective_cap()</function> will check whether the capability specified by + <parameter>capability</parameter> was set in the effective capabilities mask. A positive return value means that it + was set, zero means that it was not set, and a negative return value indicates an error. See <citerefentry + project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> and the + <varname>AmbientCapabilities=</varname> and <varname>CapabilityBoundingSet=</varname> settings in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_creds_has_permitted_cap()</function> is + similar to <function>sd_bus_creds_has_effective_cap()</function>, + but will check the permitted capabilities mask.</para> + + <para><function>sd_bus_creds_has_inheritable_cap()</function> is + similar to <function>sd_bus_creds_has_effective_cap()</function>, + but will check the inheritable capabilities mask.</para> + + <para><function>sd_bus_creds_has_bounding_cap()</function> is + similar to <function>sd_bus_creds_has_effective_cap()</function>, + but will check the bounding capabilities mask.</para> + + <para><function>sd_bus_creds_get_selinux_context()</function> will + retrieve the SELinux security context (label) of the process.</para> + + <para><function>sd_bus_creds_get_audit_session_id()</function> + will retrieve the audit session identifier of the process. Returns + -ENXIO for processes that are not part of an audit session.</para> + + <para><function>sd_bus_creds_get_audit_login_uid()</function> will + retrieve the audit user login identifier (the identifier of the + user who is "responsible" for the session). Returns -ENXIO for + processes that are not part of an audit session.</para> + + <para><function>sd_bus_creds_get_tty()</function> will retrieve + the controlling TTY, without the prefixing "/dev/". Returns -ENXIO + for processes that have no controlling TTY.</para> + + <para><function>sd_bus_creds_get_unique_name()</function> will + retrieve the D-Bus unique name. See <ulink + url="http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus">The + D-Bus specification</ulink>.</para> + + <para><function>sd_bus_creds_get_well_known_names()</function> will + retrieve the set of D-Bus well-known names. See <ulink + url="http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus">The + D-Bus specification</ulink>.</para> + + <para><function>sd_bus_creds_get_description()</function> will + retrieve a descriptive name of the bus connection of the + peer. This name is useful to discern multiple bus connections by + the same peer, and may be altered by the peer with the + <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call.</para> + + <para>All functions that take a <parameter>const + char**</parameter> parameter will store the answer there as an + address of a <constant>NUL</constant>-terminated string. It will be valid as long as + <parameter>c</parameter> remains valid, and should not be freed or + modified by the caller.</para> + + <para>All functions that take a <parameter>char***</parameter> + parameter will store the answer there as an address of an array + of strings. Each individual string is <constant>NUL</constant>-terminated, and the + array is <constant>NULL</constant>-terminated as a whole. It will be valid as long as + <parameter>c</parameter> remains valid, and should not be freed or + modified by the caller.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On + failure, these calls 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>-ENODATA</constant></term> + + <listitem><para>The given field is not available in the credentials object + <parameter>c</parameter>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The given field is not specified for the described process or peer. This will be + returned by <function>sd_bus_creds_get_unit()</function>, + <function>sd_bus_creds_get_slice()</function>, <function>sd_bus_creds_get_user_unit()</function>, + <function>sd_bus_creds_get_user_slice()</function>, and + <function>sd_bus_creds_get_session()</function> if the process is not part of a systemd system + unit, systemd user unit, systemd slice, or logind session. It will be returned by + <function>sd_bus_creds_get_owner_uid()</function> if the process is not part of a systemd user unit + or logind session. It will also be returned by <function>sd_bus_creds_get_exe()</function> and + <function>sd_bus_creds_get_cmdline()</function> for kernel threads (since these are not started + from an executable binary, nor have a command line), and by + <function>sd_bus_creds_get_audit_session_id()</function> and + <function>sd_bus_creds_get_audit_login_uid()</function> when the process is not part of an audit + session, and <function>sd_bus_creds_get_tty()</function> if the process has no controlling + TTY.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified pointer parameter is <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_creds_new_from_pid.xml b/man/sd_bus_creds_new_from_pid.xml new file mode 100644 index 0000000..ea3acc4 --- /dev/null +++ b/man/sd_bus_creds_new_from_pid.xml @@ -0,0 +1,315 @@ +<?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-or-later --> + +<refentry id="sd_bus_creds_new_from_pid" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_creds_new_from_pid</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_creds_new_from_pid</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_creds_new_from_pid</refname> + <refname>sd_bus_creds_get_mask</refname> + <refname>sd_bus_creds_get_augmented_mask</refname> + <refname>sd_bus_creds_ref</refname> + <refname>sd_bus_creds_unref</refname> + <refname>sd_bus_creds_unrefp</refname> + + <refpurpose>Retrieve credentials object for the specified PID</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_creds_new_from_pid</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>uint64_t <parameter>creds_mask</parameter></paramdef> + <paramdef>sd_bus_creds **<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>uint64_t <function>sd_bus_creds_get_mask</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>uint64_t <function>sd_bus_creds_get_augmented_mask</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_creds *<function>sd_bus_creds_ref</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_creds *<function>sd_bus_creds_unref</function></funcdef> + <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_creds_unrefp</function></funcdef> + <paramdef>sd_bus_creds **<parameter>c</parameter></paramdef> + </funcprototype> + </funcsynopsis> + + <para> + <constant>SD_BUS_CREDS_PID</constant>, + <constant>SD_BUS_CREDS_PPID</constant>, + <constant>SD_BUS_CREDS_TID</constant>, + <constant>SD_BUS_CREDS_UID</constant>, + <constant>SD_BUS_CREDS_EUID</constant>, + <constant>SD_BUS_CREDS_SUID</constant>, + <constant>SD_BUS_CREDS_FSUID</constant>, + <constant>SD_BUS_CREDS_GID</constant>, + <constant>SD_BUS_CREDS_EGID</constant>, + <constant>SD_BUS_CREDS_SGID</constant>, + <constant>SD_BUS_CREDS_FSGID</constant>, + <constant>SD_BUS_CREDS_SUPPLEMENTARY_GIDS</constant>, + <constant>SD_BUS_CREDS_COMM</constant>, + <constant>SD_BUS_CREDS_TID_COMM</constant>, + <constant>SD_BUS_CREDS_EXE</constant>, + <constant>SD_BUS_CREDS_CMDLINE</constant>, + <constant>SD_BUS_CREDS_CGROUP</constant>, + <constant>SD_BUS_CREDS_UNIT</constant>, + <constant>SD_BUS_CREDS_SLICE</constant>, + <constant>SD_BUS_CREDS_USER_UNIT</constant>, + <constant>SD_BUS_CREDS_USER_SLICE</constant>, + <constant>SD_BUS_CREDS_SESSION</constant>, + <constant>SD_BUS_CREDS_OWNER_UID</constant>, + <constant>SD_BUS_CREDS_EFFECTIVE_CAPS</constant>, + <constant>SD_BUS_CREDS_PERMITTED_CAPS</constant>, + <constant>SD_BUS_CREDS_INHERITABLE_CAPS</constant>, + <constant>SD_BUS_CREDS_BOUNDING_CAPS</constant>, + <constant>SD_BUS_CREDS_SELINUX_CONTEXT</constant>, + <constant>SD_BUS_CREDS_AUDIT_SESSION_ID</constant>, + <constant>SD_BUS_CREDS_AUDIT_LOGIN_UID</constant>, + <constant>SD_BUS_CREDS_TTY</constant>, + <constant>SD_BUS_CREDS_UNIQUE_NAME</constant>, + <constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant>, + <constant>SD_BUS_CREDS_DESCRIPTION</constant>, + <constant>SD_BUS_CREDS_AUGMENT</constant>, + <constant>_SD_BUS_CREDS_ALL</constant> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_creds_new_from_pid()</function> creates a + new credentials object and fills it with information about the + process <parameter>pid</parameter>. The pointer to this object + will be stored in the <parameter>ret</parameter> pointer. Note that + credential objects may also be created and retrieved via + <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>The information that will be stored is determined by + <parameter>creds_mask</parameter>. It may contain a subset of ORed + constants <constant>SD_BUS_CREDS_PID</constant>, + <constant>SD_BUS_CREDS_PPID</constant>, + <constant>SD_BUS_CREDS_TID</constant>, + <constant>SD_BUS_CREDS_UID</constant>, + <constant>SD_BUS_CREDS_EUID</constant>, + <constant>SD_BUS_CREDS_SUID</constant>, + <constant>SD_BUS_CREDS_FSUID</constant>, + <constant>SD_BUS_CREDS_GID</constant>, + <constant>SD_BUS_CREDS_EGID</constant>, + <constant>SD_BUS_CREDS_SGID</constant>, + <constant>SD_BUS_CREDS_FSGID</constant>, + <constant>SD_BUS_CREDS_SUPPLEMENTARY_GIDS</constant>, + <constant>SD_BUS_CREDS_COMM</constant>, + <constant>SD_BUS_CREDS_TID_COMM</constant>, + <constant>SD_BUS_CREDS_EXE</constant>, + <constant>SD_BUS_CREDS_CMDLINE</constant>, + <constant>SD_BUS_CREDS_CGROUP</constant>, + <constant>SD_BUS_CREDS_UNIT</constant>, + <constant>SD_BUS_CREDS_SLICE</constant>, + <constant>SD_BUS_CREDS_USER_UNIT</constant>, + <constant>SD_BUS_CREDS_USER_SLICE</constant>, + <constant>SD_BUS_CREDS_SESSION</constant>, + <constant>SD_BUS_CREDS_OWNER_UID</constant>, + <constant>SD_BUS_CREDS_EFFECTIVE_CAPS</constant>, + <constant>SD_BUS_CREDS_PERMITTED_CAPS</constant>, + <constant>SD_BUS_CREDS_INHERITABLE_CAPS</constant>, + <constant>SD_BUS_CREDS_BOUNDING_CAPS</constant>, + <constant>SD_BUS_CREDS_SELINUX_CONTEXT</constant>, + <constant>SD_BUS_CREDS_AUDIT_SESSION_ID</constant>, + <constant>SD_BUS_CREDS_AUDIT_LOGIN_UID</constant>, + <constant>SD_BUS_CREDS_TTY</constant>, + <constant>SD_BUS_CREDS_UNIQUE_NAME</constant>, + <constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant>, and + <constant>SD_BUS_CREDS_DESCRIPTION</constant>. Use the special + value <constant>_SD_BUS_CREDS_ALL</constant> to request all + supported fields. The <constant>SD_BUS_CREDS_AUGMENT</constant> + constant may not be ORed into the mask for invocations of + <function>sd_bus_creds_new_from_pid()</function>.</para> + + <para>Fields can be retrieved from the credentials object using + <citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and other functions which correspond directly to the constants + listed above.</para> + + <para>A mask of fields which were actually successfully retrieved + can be retrieved with + <function>sd_bus_creds_get_mask()</function>. If the credentials + object was created with + <function>sd_bus_creds_new_from_pid()</function>, this will be a + subset of fields requested in <parameter>creds_mask</parameter>. + </para> + + <para>Similar to <function>sd_bus_creds_get_mask()</function>, the + function <function>sd_bus_creds_get_augmented_mask()</function> + returns a bitmask of field constants. The mask indicates which + credential fields have been retrieved in a non-atomic fashion. For + credential objects created via + <function>sd_bus_creds_new_from_pid()</function>, this mask will be + identical to the mask returned by + <function>sd_bus_creds_get_mask()</function>. However, for + credential objects retrieved via + <function>sd_bus_get_name_creds()</function>, this mask will be set + for the credential fields that could not be determined atomically + at peer connection time, and which were later added by reading + augmenting credential data from + <filename>/proc/</filename>. Similarly, for credential objects + retrieved via <function>sd_bus_get_owner_creds()</function>, the + mask is set for the fields that could not be determined atomically + at bus creation time, but have been augmented. Similarly, for + credential objects retrieved via + <function>sd_bus_message_get_creds()</function>, the mask is set + for the fields that could not be determined atomically at message + sending time, but have been augmented. The mask returned by + <function>sd_bus_creds_get_augmented_mask()</function> is always a + subset of (or identical to) the mask returned by + <function>sd_bus_creds_get_mask()</function> for the same + object. The latter call hence returns all credential fields + available in the credential object, the former then marks the + subset of those that have been augmented. Note that augmented + fields are unsuitable for authorization decisions, as they may be + retrieved at different times, thus being subject to races. Hence, + augmented fields should be used exclusively for informational + purposes. + </para> + + <para><function>sd_bus_creds_ref()</function> creates a new + reference to the credentials object <parameter>c</parameter>. This + object will not be destroyed until + <function>sd_bus_creds_unref()</function> has been called as many + times plus once more. Once the reference count has dropped to zero, + <parameter>c</parameter> cannot be used anymore, so further + calls to <function>sd_bus_creds_ref(c)</function> or + <function>sd_bus_creds_unref(c)</function> are illegal.</para> + + <para><function>sd_bus_creds_unref()</function> destroys a reference + to <parameter>c</parameter>.</para> + + <para><function>sd_bus_creds_unrefp()</function> is similar to + <function>sd_bus_creds_unref()</function> but takes a pointer to a + pointer to an <type>sd_bus_creds</type> object. 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> + + <para><function>sd_bus_creds_ref()</function>, + <function>sd_bus_creds_unref()</function> and + <function>sd_bus_creds_unrefp()</function> execute no operation if + the passed in bus credentials object is + <constant>NULL</constant>.</para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_creds_new_from_pid()</function> + returns 0 or a positive integer. On failure, it returns a negative + errno-style error code.</para> + + <para><function>sd_bus_creds_get_mask()</function> returns the + mask of successfully acquired fields.</para> + + <para><function>sd_bus_creds_get_augmented_mask()</function> + returns the mask of fields that have been augmented from data in + <filename>/proc/</filename>, and are thus not suitable for + authorization decisions.</para> + + <para><function>sd_bus_creds_ref()</function> always returns the + argument.</para> + + <para><function>sd_bus_creds_unref()</function> always returns + <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>Reference ownership</title> + + <para>Function <function>sd_bus_creds_new_from_pid()</function> + creates a new object and the caller owns the sole reference. When + not needed anymore, this reference should be destroyed with + <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-ESRCH</constant></term> + + <listitem><para>Specified <parameter>pid</parameter> could not be found.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified parameter is invalid (<constant>NULL</constant> in case of output + parameters).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>One of the requested fields is unknown to the local system.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_default.xml b/man/sd_bus_default.xml new file mode 100644 index 0000000..4ae2641 --- /dev/null +++ b/man/sd_bus_default.xml @@ -0,0 +1,330 @@ +<?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-or-later --> + +<refentry id="sd_bus_default" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_default</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_default</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_default</refname> + <refname>sd_bus_default_user</refname> + <refname>sd_bus_default_system</refname> + + <refname>sd_bus_open</refname> + <refname>sd_bus_open_with_description</refname> + <refname>sd_bus_open_user</refname> + <refname>sd_bus_open_user_with_description</refname> + <refname>sd_bus_open_system</refname> + <refname>sd_bus_open_system_with_description</refname> + <refname>sd_bus_open_system_remote</refname> + <refname>sd_bus_open_system_machine</refname> + + <refpurpose>Acquire a connection to a system or user bus</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_default</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_default_user</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_default_system</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_with_description</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_user</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_user_with_description</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_system</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_system_with_description</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_system_remote</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>host</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_open_system_machine</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>machine</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_default()</function> acquires a bus + connection object to the user bus when invoked in user context, or + to the system bus otherwise. The connection object is associated + with the calling thread. Each time the function is invoked from + the same thread, the same object is returned, but its reference + count is increased by one, as long as at least one reference is + kept. When the last reference to the connection is dropped (using + the + <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call), the connection is terminated. Note that the connection is + not automatically terminated when the associated thread ends. It + is important to drop the last reference to the bus connection + explicitly before the thread ends, as otherwise, the connection will + leak. Also, queued but unread or unwritten messages keep the + bus referenced, see below.</para> + + <para><function>sd_bus_default_user()</function> returns a user + bus connection object associated with the calling thread. + <function>sd_bus_default_system()</function> is similar, but + connects to the system bus. Note that + <function>sd_bus_default()</function> is identical to these two + calls, depending on the execution context.</para> + + <para><function>sd_bus_open()</function> creates a new, + independent bus connection to the user bus when invoked in user + context, or the system bus + otherwise. <function>sd_bus_open_user()</function> is similar, but + connects only to the user bus. + <function>sd_bus_open_system()</function> does the same, but + connects to the system bus. In contrast to + <function>sd_bus_default()</function>, + <function>sd_bus_default_user()</function>, and + <function>sd_bus_default_system()</function>, these calls return + new, independent connection objects that are not associated with + the invoking thread and are not shared between multiple + invocations. It is recommended to share connections per thread to + efficiently make use the available resources. Thus, it is + recommended to use <function>sd_bus_default()</function>, + <function>sd_bus_default_user()</function> and + <function>sd_bus_default_system()</function> to connect to the + user or system buses.</para> + + <para><function>sd_bus_open_with_description()</function>, + <function>sd_bus_open_user_with_description()</function>, and + <function>sd_bus_open_system_with_description()</function> are similar to + <function>sd_bus_open()</function>, <function>sd_bus_open_user()</function>, and + <function>sd_bus_open_system()</function>, but allow a description string to be set, see + <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + <parameter>description</parameter> may be <constant>NULL</constant>, in which case this function + is equivalent to <function>sd_bus_open()</function>. This description string is used in log + messages about the bus object, and including a "name" for the bus makes them easier to + understand. Some messages are emitted during bus initialization, hence using this function is + preferable to setting the description later with + <function>sd_bus_open_with_description()</function>. The argument is copied internally and will + not be referenced after the function returns.</para> + + <para>If the <varname>$DBUS_SESSION_BUS_ADDRESS</varname> environment + variable is set + (cf. <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>), + it will be used as the address of the user bus. This variable can + contain multiple addresses separated by <literal>;</literal>. If + this variable is not set, a suitable default for the default user + D-Bus instance will be used.</para> + + <para>If the <varname>$DBUS_SYSTEM_BUS_ADDRESS</varname> + environment variable is set, it will be used as the address of the + system bus. This variable uses the same syntax as + <varname>$DBUS_SESSION_BUS_ADDRESS</varname>. If this variable is + not set, a suitable default for the default system D-Bus instance + will be used.</para> + + <para><function>sd_bus_open_system_remote()</function> connects to the system bus on + the specified host using + <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + <parameter>host</parameter> consists of an optional user name followed by the + <literal>@</literal> symbol, and the hostname, optionally followed by a + <literal>:</literal> and a port, optionally followed by a + <literal>/</literal> and a machine name. If the machine name is given, a connection + is created to the system bus in the specified container on the remote machine, and + otherwise a connection to the system bus on the specified host is created.</para> + + <para>Note that entering a container is a privileged operation, and will likely only + work for the root user on the remote machine.</para> + + <para><function>sd_bus_open_system_machine()</function> connects to the system bus in the specified + <parameter>machine</parameter>, where <parameter>machine</parameter> is the name of a local + container. See + <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a description of the address syntax, and + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more + information about the "machine" concept. Note that connections into local containers are only available + to privileged processes at this time.</para> + + <para>These calls allocate a bus connection object and initiate + the connection to a well-known bus of some form. An alternative to + using these high-level calls is to create an unconnected bus + object with + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and to connect it with + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + </refsect1> + + <refsect1> + <title>Reference ownership</title> + <para>The functions <function>sd_bus_open()</function>, + <function>sd_bus_open_user()</function>, + <function>sd_bus_open_system()</function>, + <function>sd_bus_open_system_remote()</function>, and + <function>sd_bus_open_system_machine()</function> return a new + connection object and the caller owns the sole reference. When not + needed anymore, this reference should be destroyed with + <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>The functions <function>sd_bus_default()</function>, + <function>sd_bus_default_user()</function> and + <function>sd_bus_default_system()</function> do not necessarily + create a new object, but increase the connection reference of an + existing connection object by one. Use + <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to drop the reference.</para> + + <para>Queued but unwritten/unread messages keep a reference to their bus connection object. For this reason, even + if an application dropped all references to a bus connection, it might not get destroyed right away. Until all + incoming queued messages are read, and until all outgoing unwritten messages are written, the bus object will stay + alive. <function>sd_bus_flush()</function> may be used to write all outgoing queued messages so they drop their + references. To flush the unread incoming messages, use <function>sd_bus_close()</function>, which will also close + the bus connection. When using the default bus logic, it is a good idea to first invoke + <function>sd_bus_flush()</function> followed by <function>sd_bus_close()</function> when a thread or process + terminates, and thus its bus connection object should be freed.</para> + + <para>Normally, slot objects (as created by + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> and similar + calls) keep a reference to their bus connection object, too. Thus, as long as a bus slot object remains referenced + its bus object will remain allocated too. Optionally, bus slot objects may be placed in "floating" mode. When in + floating mode the life cycle of the bus slot object is bound to the bus object, i.e. when the bus object is freed + the bus slot object is automatically unreferenced too. The floating state of a slot object may be controlled + explicitly with + <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + though usually floating bus slot objects are created by passing <constant>NULL</constant> as the + <parameter>slot</parameter> parameter of <function>sd_bus_add_match()</function> and related calls, thus indicating + that the caller is not directly interested in referencing and managing the bus slot object.</para> + + <para>The life cycle of the default bus connection should be the + responsibility of the code that creates/owns the thread the + default bus connection object is associated with. Library code + should neither call <function>sd_bus_flush()</function> nor + <function>sd_bus_close()</function> on default bus objects unless + it does so in its own private, self-allocated thread. Library code + should not use the default bus object in other threads unless it + is clear that the program using it will life cycle the bus + connection object and flush and close it before exiting from the + thread. In libraries where it is not clear that the calling + program will life cycle the bus connection object, it is hence + recommended to use <function>sd_bus_open_system()</function> + instead of <function>sd_bus_default_system()</function> and + related calls.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive + integer. On failure, these calls 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>The specified parameters are invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEDIUM</constant></term> + + <listitem><para>The requested bus type is not available because of invalid environment (for example + the user session bus is not available because <varname>$XDG_RUNTIME_DIR</varname> is not set). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESOCKTNOSUPPORT</constant></term> + + <listitem><para>The protocol version required to connect to the selected bus is not + supported.</para></listitem> + </varlistentry> + </variablelist> + + <para>In addition, other connection-related errors may be returned. See + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_emit_signal.xml b/man/sd_bus_emit_signal.xml new file mode 100644 index 0000000..08d5be4 --- /dev/null +++ b/man/sd_bus_emit_signal.xml @@ -0,0 +1,243 @@ +<?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-or-later --> + +<refentry id="sd_bus_emit_signal" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_emit_signal</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_emit_signal</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_emit_signal</refname> + <refname>sd_bus_emit_signalv</refname> + <refname>sd_bus_emit_interfaces_added</refname> + <refname>sd_bus_emit_interfaces_added_strv</refname> + <refname>sd_bus_emit_interfaces_removed</refname> + <refname>sd_bus_emit_interfaces_removed_strv</refname> + <refname>sd_bus_emit_properties_changed</refname> + <refname>sd_bus_emit_properties_changed_strv</refname> + <refname>sd_bus_emit_object_added</refname> + <refname>sd_bus_emit_object_removed</refname> + + <refpurpose>Convenience functions for emitting (standard) D-Bus signals</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus-vtable.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_signal</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>member</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_signalv</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>member</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_interfaces_added</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_interfaces_added_strv</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char **<parameter>interfaces</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_interfaces_removed</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_interfaces_removed_strv</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char **<parameter>interfaces</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_properties_changed</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>name</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_properties_changed_strv</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>names</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_object_added</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_emit_object_removed</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_emit_signal()</function> is a convenience function for initializing a + bus message object and emitting the corresponding D-Bus signal. It combines the + <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry> + functions into a single function call. <function>sd_bus_emit_signalv()</function> is + equivalent to <function>sd_bus_message_append()</function>, except that it is called with a + <literal>va_list</literal> instead of a variable number of arguments.</para> + + <para><function>sd_bus_emit_interfaces_added()</function> and + <function>sd_bus_emit_interfaces_removed()</function> are used to implement the + <function>InterfacesAdded</function> and <function>InterfacesRemoved</function> signals of the + <constant>org.freedesktop.DBus.ObjectManager</constant> interface. They take a path whose + interfaces have been modified as an argument and a variable list of interfaces that have been + added or removed, respectively. The final argument passed to + <function>sd_bus_emit_interfaces_added()</function> and + <function>sd_bus_emit_interfaces_removed()</function> <emphasis>must</emphasis> be + <constant>NULL</constant>. This allows both functions to safely determine the number of passed + interface arguments. <function>sd_bus_emit_interfaces_added_strv()</function> and + <function>sd_bus_emit_interfaces_removed_strv()</function> are identical to their respective + counterparts but both take the list of interfaces as a single argument instead of a variable + number of arguments.</para> + + <para><function>sd_bus_emit_properties_changed()</function> is used to implement the + <function>PropertiesChanged</function> signal of the + <constant>org.freedesktop.DBus.Properties</constant> interface. It takes an object path, + interface and a variable list of property names as its arguments. The final argument passed to + <function>sd_bus_emit_properties_changed()</function> <emphasis>must</emphasis> be + <constant>NULL</constant>. This allows it to safely determine the number of passed property + names. <function>sd_bus_emit_properties_changed_strv()</function> is identical to + <function>sd_bus_emit_properties_changed()</function> but takes the list of property names as a + single argument instead of a variable number of arguments.</para> + + <para><function>sd_bus_emit_object_added()</function> and + <function>sd_bus_emit_object_removed()</function> are convenience functions for emitting the + <function>InterfacesAdded</function> or <function>InterfacesRemoved</function> signals for all + interfaces registered on a specific object path, respectively. This includes any parent fallback + vtables if they are not overridden by a more applicable child vtable. It also includes all the + standard D-Bus interfaces implemented by sd-bus itself on any registered object.</para> + + <para>Note that <function>sd_bus_emit_interfaces_added()</function>, + <function>sd_bus_emit_interfaces_removed()</function>, + <function>sd_bus_emit_object_added()</function> and + <function>sd_bus_emit_object_removed()</function> require an object manager to have been + registered on the given object path or one of its parent object paths using + <citerefentry><refentrytitle>sd_bus_add_object_manager</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>-ESRCH</constant></term> + + <listitem><para>One of <function>sd_bus_emit_interfaces_added()</function>, + <function>sd_bus_emit_interfaces_removed()</function>, + <function>sd_bus_emit_object_added()</function> or + <function>sd_bus_emit_object_removed()</function> was called on an object without an + object manager registered on its own object path or one of its parent object paths. + </para></listitem> + </varlistentry> + </variablelist> + + <para>See the man pages of + <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more possible errors.</para> + </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>, + <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_enqueue_for_read.xml b/man/sd_bus_enqueue_for_read.xml new file mode 100644 index 0000000..82b91cb --- /dev/null +++ b/man/sd_bus_enqueue_for_read.xml @@ -0,0 +1,88 @@ +<?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-or-later --> + +<refentry id="sd_bus_enqueue_for_read" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_enqueue_for_read</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_enqueue_for_read</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_enqueue_for_read</refname> + + <refpurpose>Re-enqueue a bus message on a bus connection, for reading</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_enqueue_for_read</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_enqueue_for_read()</function> may be used to re-enqueue an incoming bus message on + the local read queue, so that it is processed and dispatched locally again, similar to how an incoming + message from the peer is processed. Takes a bus connection object and the message to enqueue. A reference + is taken of the message and the caller's reference thus remains in possession of the caller. The message + is enqueued at the end of the queue, thus will be dispatched after all other already queued messages are + dispatched.</para> + + <para>This call is primarily useful for dealing with incoming method calls that may be processed only + after an additional asynchronous operation completes. One example are PolicyKit authorization requests + that are determined to be necessary to authorize a newly incoming method call: when the PolicyKit response + is received the original method call may be re-enqueued to process it again, this time with the + authorization result known.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this function return 0 or a positive integer. On failure, it returns a negative errno-style + error code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_error.xml b/man/sd_bus_error.xml new file mode 100644 index 0000000..af2238e --- /dev/null +++ b/man/sd_bus_error.xml @@ -0,0 +1,384 @@ +<?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-or-later --> + +<refentry id="sd_bus_error" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_error</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_error</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_error</refname> + <refname>SD_BUS_ERROR_MAKE_CONST</refname> + <refname>SD_BUS_ERROR_NULL</refname> + <refname>sd_bus_error_free</refname> + <refname>sd_bus_error_set</refname> + <refname>sd_bus_error_setf</refname> + <refname>sd_bus_error_set_const</refname> + <refname>sd_bus_error_set_errno</refname> + <refname>sd_bus_error_set_errnof</refname> + <refname>sd_bus_error_set_errnofv</refname> + <refname>sd_bus_error_get_errno</refname> + <refname>sd_bus_error_copy</refname> + <refname>sd_bus_error_move</refname> + <refname>sd_bus_error_is_set</refname> + <refname>sd_bus_error_has_name</refname> + <refname>sd_bus_error_has_names_sentinel</refname> + <refname>sd_bus_error_has_names</refname> + + <refpurpose>sd-bus error handling</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcsynopsisinfo>typedef struct { + const char *name; + const char *message; + … +} sd_bus_error;</funcsynopsisinfo> + + <para> + <constant>SD_BUS_ERROR_MAKE_CONST(<replaceable>name</replaceable>, <replaceable>message</replaceable>)</constant> + </para> + <para> + <constant>SD_BUS_ERROR_NULL</constant> + </para> + + <funcprototype> + <funcdef>void <function>sd_bus_error_free</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_set</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>const char *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_setf</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_set_const</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>const char *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_set_errno</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_set_errnof</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_set_errnofv</function></funcdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_get_errno</function></funcdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_copy</function></funcdef> + <paramdef>sd_bus_error *<parameter>dst</parameter></paramdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_move</function></funcdef> + <paramdef>sd_bus_error *<parameter>dst</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_is_set</function></funcdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_has_name</function></funcdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_error_has_names_sentinel</function></funcdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <para> + #define sd_bus_error_has_names(e, ...) sd_bus_error_has_names_sentinel(e, ..., NULL) + </para> + </funcsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <structname>sd_bus_error</structname> structure carries + information about a D-Bus error condition. The functions described + below may be used to set and query fields in this structure. The + <structfield>name</structfield> field contains a short identifier + of an error. It should follow the rules for error names described + in the D-Bus specification, subsection <ulink + url="http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names">Valid + Names</ulink>. A number of common, standardized error names are + described in + <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but additional domain-specific errors may be defined by + applications. The <structfield>message</structfield> field usually + contains a human-readable string describing the details, but might + be <constant>NULL</constant>. An unset <structname>sd_bus_error</structname> structure + should have both fields initialized to <constant>NULL</constant>. Set an error + structure to <constant>SD_BUS_ERROR_NULL</constant> in order to + reset both fields to <constant>NULL</constant>. When no longer necessary, resources + held by the <structname>sd_bus_error</structname> structure should + be destroyed with <function>sd_bus_error_free()</function>.</para> + + <para><function>sd_bus_error_set()</function> sets an error + structure to the specified name and message strings. The strings + will be copied into internal, newly allocated memory. It is + essential to free the error structure again when it is not + required anymore (see above). The function will return an + <varname>errno</varname>-like negative value (see <citerefentry + project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + determined from the specified error name. Various well-known + D-Bus errors are converted to well-known <varname>errno</varname> + counterparts, and the other ones to <constant>-EIO</constant>. See + <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a list of well-known error names. Additional error mappings + may be defined with + <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If + <parameter>e</parameter> is <constant>NULL</constant>, no error structure is initialized, + but the error is still converted into an + <varname>errno</varname>-style error. If + <parameter>name</parameter> is <constant>NULL</constant>, it is + assumed that no error occurred, and 0 is returned. This means that + this function may be conveniently used in a + <function>return</function> statement. If + <parameter>message</parameter> is <constant>NULL</constant>, no message is set. This + call can fail if no memory may be allocated for the name and + message strings, in which case an + <constant>SD_BUS_ERROR_NO_MEMORY</constant> error might be set + instead and -ENOMEM be returned. Do not use this call on error + structures that are already initialized. If you intend to reuse an + error structure, free the old data stored in it with + <function>sd_bus_error_free()</function> first.</para> + + <para><function>sd_bus_error_setf()</function> is similar to + <function>sd_bus_error_set()</function>, but takes a <citerefentry + project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> + format string and corresponding arguments to generate the + <structfield>message</structfield> field.</para> + + <para><function>sd_bus_error_set_const()</function> is similar to + <function>sd_bus_error_set()</function>, but the string parameters + are not copied internally, and must hence remain constant and + valid for the lifetime of <parameter>e</parameter>. Use this call + to avoid memory allocations when setting error structures. Since + this call does not allocate memory, it will not fail with an + out-of-memory condition as + <function>sd_bus_error_set()</function> can, as described + above. Alternatively, the + <constant>SD_BUS_ERROR_MAKE_CONST()</constant> macro may be used + to generate a literal, constant bus error structure + on-the-fly.</para> + + <para><function>sd_bus_error_set_errno()</function> will set + <structfield>name</structfield> from an + <varname>errno</varname>-like value that is converted to a D-Bus + error. <citerefentry + project='die-net'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry> + will be used to set <structfield>message</structfield>. Well-known + D-Bus error names will be used for <structfield>name</structfield> + if applicable, otherwise a name in the + <literal>System.Error.</literal> namespace will be generated. The + sign of the specified error number is ignored. The absolute value + is used implicitly. The call always returns a negative value, for + convenient usage in <function>return</function> statements. This + call might fail due to lack of memory, in which case an + <constant>SD_BUS_ERROR_NO_MEMORY</constant> error is set instead, + and -ENOMEM is returned.</para> + + <para><function>sd_bus_error_set_errnof()</function> is similar to + <function>sd_bus_error_set_errno()</function>, but in addition to + <parameter>error</parameter>, takes a <citerefentry + project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> + format string and corresponding arguments. The + <structfield>message</structfield> field will be generated from + <parameter>format</parameter> and the arguments.</para> + + <para><function>sd_bus_error_set_errnofv()</function> is similar to + <function>sd_bus_error_set_errnof()</function>, but takes the + format string parameters as <citerefentry + project='man-pages'><refentrytitle>va_arg</refentrytitle><manvolnum>3</manvolnum></citerefentry> + parameter list.</para> + + <para><function>sd_bus_error_get_errno()</function> converts the + <structfield>name</structfield> field of an error structure to an + <varname>errno</varname>-like (positive) value using the same + rules as <function>sd_bus_error_set()</function>. If + <parameter>e</parameter> is <constant>NULL</constant>, 0 will be + returned.</para> + + <para><function>sd_bus_error_copy()</function> will initialize + <parameter>dst</parameter> using the values in + <parameter>e</parameter>. If the strings in + <parameter>e</parameter> were set using + <function>sd_bus_error_set_const()</function>, they will be shared. + Otherwise, they will be copied. Returns a converted + <varname>errno</varname>-like, negative error code.</para> + + <para><function>sd_bus_error_move()</function> is similar to <function>sd_bus_error_copy()</function>, but will + move any error information from <parameter>e</parameter> into <parameter>dst</parameter>, resetting the + former. This function cannot fail, as no new memory is allocated. Note that if <parameter>e</parameter> is not set + (or <constant>NULL</constant>) <parameter>dst</parameter> is initializated to + <constant>SD_BUS_ERROR_NULL</constant>. Moreover, if <parameter>dst</parameter> is <constant>NULL</constant> no + operation is executed on it and and resources held by <parameter>e</parameter> are freed and reset. Returns a + converted <varname>errno</varname>-like, negative error code.</para> + + <para><function>sd_bus_error_is_set()</function> will return a + non-zero value if <parameter>e</parameter> is + non-<constant>NULL</constant> and an error has been set, + <constant>false</constant> otherwise.</para> + + <para><function>sd_bus_error_has_name()</function> will return a + non-zero value if <parameter>e</parameter> is + non-<constant>NULL</constant> and an error with the same + <parameter>name</parameter> has been set, + <constant>false</constant> otherwise.</para> + + <para><function>sd_bus_error_has_names_sentinel()</function> is similar to + <function>sd_bus_error_has_name()</function>, but takes multiple names to check against. The list must be + terminated with <constant>NULL</constant>. <function>sd_bus_error_has_names()</function> + is a macro wrapper around <function>sd_bus_error_has_names_sentinel()</function> that adds the + <constant>NULL</constant> sentinel automatically.</para> + + <para><function>sd_bus_error_free()</function> will destroy + resources held by <parameter>e</parameter>. The parameter itself + will not be deallocated, and must be <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>d + by the caller if necessary. The function may also be called safely + on unset errors (error structures with both fields set to <constant>NULL</constant>), + in which case it performs no operation. This call will reset the + error structure after freeing the data, so that all fields are set + to <constant>NULL</constant>. The structure may be reused afterwards.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The functions <function>sd_bus_error_set()</function>, + <function>sd_bus_error_setf()</function>, and + <function>sd_bus_error_set_const()</function>, when successful, + return the negative errno value corresponding to the + <parameter>name</parameter> parameter. The functions + <function>sd_bus_error_set_errno()</function>, + <function>sd_bus_error_set_errnof()</function> and + <function>sd_bus_error_set_errnofv()</function>, when successful, + return the negative value of the <parameter>error</parameter> + parameter. If an error occurs, one of the negative error values + listed below will be returned.</para> + + <para><function>sd_bus_error_get_errno()</function> returns + <constant>false</constant> when <parameter>e</parameter> is + <constant>NULL</constant>, and a positive errno value mapped from + <parameter>e->name</parameter> otherwise.</para> + + <para><function>sd_bus_error_copy()</function> and <function>sd_bus_error_move()</function> return 0 or a positive + integer on success, and a negative error value converted from the error name otherwise.</para> + + <para><function>sd_bus_error_is_set()</function> returns a + non-zero value when <parameter>e</parameter> and the + <structfield>name</structfield> field are + non-<constant>NULL</constant>, zero otherwise.</para> + + <para><function>sd_bus_error_has_name()</function>, <function>sd_bus_error_has_names()</function>, and + <function>sd_bus_error_has_names_sentinel()</function> return a non-zero value when <parameter>e</parameter> is + non-<constant>NULL</constant> and the <structfield>name</structfield> field is equal to one of the given + names, zero otherwise.</para> + </refsect1> + + <refsect1> + <title>Reference ownership</title> + <para><structname>sd_bus_error</structname> is not reference + counted. Users should destroy resources held by it by calling + <function>sd_bus_error_free()</function>. Usually, error structures + are allocated on the stack or passed in as function parameters, + but they may also be allocated dynamically, in which case it is + the duty of the caller to <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + the memory held by the structure itself after freeing its contents + with <function>sd_bus_error_free()</function>.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Error was already set in <structname>sd_bus_error</structname> structure when one + the error-setting functions was called.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_error_add_map.xml b/man/sd_bus_error_add_map.xml new file mode 100644 index 0000000..f62b43f --- /dev/null +++ b/man/sd_bus_error_add_map.xml @@ -0,0 +1,139 @@ +<?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-or-later --> + +<refentry id="sd_bus_error_add_map" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_error_add_map</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_error_add_map</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_error_add_map</refname> + <refname>sd_bus_error_map</refname> + <refname>SD_BUS_ERROR_MAP</refname> + <refname>SD_BUS_ERROR_END</refname> + + <refpurpose>Additional sd-dbus error mappings</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcsynopsisinfo>typedef struct { + const char *name; + int code; + … +} sd_bus_error_map;</funcsynopsisinfo> + + </funcsynopsis> + + <para> + <constant>SD_BUS_ERROR_MAP(<replaceable>name</replaceable>, <replaceable>code</replaceable>)</constant> + </para> + <para> + <constant>SD_BUS_ERROR_MAP_END</constant> + </para> + + <funcprototype> + <funcdef>int <function>sd_bus_error_add_map</function></funcdef> + <paramdef>const sd_bus_map *<parameter>map</parameter></paramdef> + </funcprototype> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_error_add_map()</function> call may be + used to register additional mappings for converting D-Bus errors + to Linux <varname>errno</varname>-style errors. The mappings + defined with this call are consulted by calls such as + <citerefentry><refentrytitle>sd_bus_error_set</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or + <citerefentry><refentrytitle>sd_bus_error_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>. By + default, a number of generic, standardized mappings are known, as + documented in + <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Use + this call to add further, application-specific mappings.</para> + + <para>The function takes a pointer to an array of + <structname>sd_bus_error_map</structname> structures. A reference + to the specified array is added to the lookup tables for error + mappings. Note that the structure is not copied, and that it is hence + essential that the array stays available and constant during the + entire remaining runtime of the process.</para> + + <para>The mapping array should be put together with a series of + <constant>SD_BUS_ERROR_MAP()</constant> macro invocations that + take a literal name string and a (positive) + <varname>errno</varname>-style error number. The last entry of the + array should be an invocation of the + <constant>SD_BUS_ERROR_MAP_END</constant> macro. The array should not be + put together without use of these two macros.</para> + + <para>Note that the call is idempotent: it is safe to invoke it + multiple times with the parameter, which will only add the passed + mapping array once.</para> + + <para>Note that the memory allocated by this call is not intended + to be freed during the lifetime of the process. It should not be + freed explicitly.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_bus_error_add_map()</function> returns a + positive value when the new array was added to the lookup + tables. It returns zero when the same array was already added + before. On error, a negative <varname>errno</varname>-style error + code is returned. See below for known error codes.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The specified mapping array is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_get_current_handler.xml b/man/sd_bus_get_current_handler.xml new file mode 100644 index 0000000..c3756b8 --- /dev/null +++ b/man/sd_bus_get_current_handler.xml @@ -0,0 +1,86 @@ +<?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-or-later --> + +<refentry id="sd_bus_get_current_handler" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_get_current_handler</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_get_current_handler</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_get_current_handler</refname> + <refname>sd_bus_get_current_message</refname> + <refname>sd_bus_get_current_slot</refname> + <refname>sd_bus_get_current_userdata</refname> + + <refpurpose>Query information of the callback a bus object is currently running</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/> + + <funcprototype> + <funcdef>sd_bus_message_handler_t <function>sd_bus_get_current_handler</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_message* <function>sd_bus_get_current_message</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_slot* <function>sd_bus_get_current_slot</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void* <function>sd_bus_get_current_userdata</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Whenever sd-bus is about to invoke a user-supplied callback function, it stores the + current callback, D-Bus message, slot and userdata pointer and allows these to be queried via + <function>sd_bus_get_current_handler()</function>, + <function>sd_bus_get_current_message()</function>, + <function>sd_bus_get_current_slot()</function> and + <function>sd_bus_get_current_userdata()</function>, respectively. If <parameter>bus</parameter> + cannot be resolved or if execution does not reside in a user-supplied callback of + <parameter>bus</parameter>, these functions return <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return the requested object. On failure, they return + <constant>NULL</constant>.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_get_fd.xml b/man/sd_bus_get_fd.xml new file mode 100644 index 0000000..689bba6 --- /dev/null +++ b/man/sd_bus_get_fd.xml @@ -0,0 +1,198 @@ +<?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-or-later + + Copyright © 2016 Julian Orth +--> + +<refentry id="sd_bus_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_get_fd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_get_fd</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_get_fd</refname> + <refname>sd_bus_set_fd</refname> + <refname>sd_bus_get_events</refname> + <refname>sd_bus_get_timeout</refname> + + <refpurpose>Get the file descriptor, I/O events and timeout to wait for from a message bus + object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_get_fd</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_fd</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>input_fd</parameter></paramdef> + <paramdef>int <parameter>output_fd</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_events</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_timeout</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_get_fd()</function> returns the file descriptor used to communicate from + a message bus object. This descriptor can be used with + <citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or a similar function to wait for I/O events on the specified bus connection object. If the bus + object was configured with the <function>sd_bus_set_fd()</function> function, then the + <parameter>input_fd</parameter> file descriptor used in that call is returned.</para> + + <para><function>sd_bus_set_fd()</function> sets the file descriptors used to communicate from a + message bus object. Both <parameter>input_fd</parameter> and <parameter>output_fd</parameter> + must be valid file descriptors. The same file descriptor may be used as both the input and the + output file descriptor. This function must be called before the bus is started.</para> + + <para><function>sd_bus_get_events()</function> returns the I/O events to wait for, suitable for + passing to <function>poll()</function> or a similar call. Returns a combination of + <constant>POLLIN</constant>, <constant>POLLOUT</constant>, … events, or negative on error. + </para> + + <para><function>sd_bus_get_timeout()</function> returns the timeout in µs to pass to + <function>poll()</function> or a similar call when waiting for events on the specified bus + connection. The returned timeout may be zero, in which case a subsequent I/O polling call + should be invoked in non-blocking mode. The returned timeout may be + <constant>UINT64_MAX</constant> in which case the I/O polling call may block indefinitely, + without any applied timeout. Note that the returned timeout should be considered only a + maximum sleeping time. It is permissible (and even expected) that shorter timeouts are used by + the calling program, in case other event sources are polled in the same event loop. Note that + the returned time-value is relative and specified in microseconds. When converting this value in + order to pass it as third argument to <function>poll()</function> (which expects milliseconds), + care should be taken to use a division that rounds up to ensure the I/O polling operation + doesn't sleep for shorter than necessary, which might result in unintended busy looping + (alternatively, use + <citerefentry project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>3</manvolnum></citerefentry> + instead of plain <function>poll()</function>, which understands timeouts with nano-second + granularity).</para> + + <para>These three functions are useful to hook up a bus connection object with an external or + manual event loop involving <function>poll()</function> or a similar I/O polling call. Before + each invocation of the I/O polling call, all three functions should be invoked: the file + descriptor returned by <function>sd_bus_get_fd()</function> should be polled for the events + indicated by <function>sd_bus_get_events()</function>, and the I/O call should block for that up + to the timeout returned by <function>sd_bus_get_timeout()</function>. After each I/O polling + call the bus connection needs to process incoming or outgoing data, by invoking + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>Note that these functions are only one of three supported ways to implement I/O event + handling for bus connections. Alternatively use + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to attach a bus connection to an + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + event loop. Or use + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> + as a simple synchronous, blocking I/O waiting call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_get_fd()</function> returns the file descriptor used for + communication. On failure, it returns a negative errno-style error code.</para> + + <para>On success, <function>sd_bus_set_fd()</function> returns a non-negative integer. On + failure, it returns a negative errno-style error code.</para> + + <para>On success, <function>sd_bus_get_events()</function> returns the I/O event mask to use for + I/O event watching. On failure, it returns a negative errno-style error code.</para> + + <para>On success, <function>sd_bus_get_timeout()</function> returns a non-negative integer. On + failure, it returns 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>An invalid bus object was passed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was allocated in a parent process and is being reused + in a child process after <function>fork()</function>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus connection has been terminated.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Two distinct file descriptors were passed for input and output using + <function>sd_bus_set_fd()</function>, which <function>sd_bus_get_fd()</function> cannot + return.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADF</constant></term> + + <listitem><para>An invalid file descriptor was passed to + <function>sd_bus_set_fd()</function>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus cannot be resolved.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_get_n_queued_read.xml b/man/sd_bus_get_n_queued_read.xml new file mode 100644 index 0000000..c9978d8 --- /dev/null +++ b/man/sd_bus_get_n_queued_read.xml @@ -0,0 +1,100 @@ +<?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-or-later --> + +<refentry id="sd_bus_get_n_queued_read"> + + <refentryinfo> + <title>sd_bus_get_fd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_get_n_queued_read</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_get_n_queued_read</refname> + <refname>sd_bus_get_n_queued_write</refname> + + <refpurpose>Get the number of pending bus messages in the read and write queues of a bus connection object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_get_n_queued_read</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_n_queued_write</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t *<parameter>ret</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para> + <function>sd_bus_get_n_queued_read()</function> may be used to query the number of bus messages in the read queue + of a bus connection object. The read queue contains all messages read from the transport medium (e.g. network + socket) but not yet processed locally. The function expects two arguments: the bus object to query, and a pointer + to a 64bit counter variable to write the current queue size to. Use <function>sd_bus_process()</function> in + order to process queued messages, i.e. to reduce the size of the read queue (as well as, in fact, the write + queue, see below). + </para> + + <para> + Similarly, <function>sd_bus_get_n_queued_write()</function> may be used to query the number of currently pending + bus messages in the write queue of a bus connection object. The write queue contains all messages enqueued into + the connection with a call such as <function>sd_bus_send()</function> but not yet written to the transport + medium. The expected arguments are similar to <function>sd_bus_get_n_queued_read()</function>. Here too, use + <function>sd_bus_process()</function> to reduce the size of the write queue. Alternatively, use + <function>sd_bus_flush()</function> to synchronously write out any pending bus messages until the write queue is + empty. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ECHILD</constant></term> + + <listitem><para>The bus connection was created in a different process.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_get_name_creds.xml b/man/sd_bus_get_name_creds.xml new file mode 100644 index 0000000..6f0541d --- /dev/null +++ b/man/sd_bus_get_name_creds.xml @@ -0,0 +1,121 @@ +<?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-or-later --> + +<refentry id="sd_bus_get_name_creds" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_get_name_creds</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_get_name_creds</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_get_name_creds</refname> + <refname>sd_bus_get_owner_creds</refname> + + <refpurpose>Query bus client credentials</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_get_name_creds</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>uint64_t <parameter>mask</parameter></paramdef> + <paramdef>sd_bus_creds **<parameter>creds</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_owner_creds</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t <parameter>mask</parameter></paramdef> + <paramdef>sd_bus_creds **<parameter>creds</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_get_name_creds()</function> queries the credentials of the bus client + identified by <parameter>name</parameter>. The <parameter>mask</parameter> parameter is a combo of + <constant index='false'>SD_BUS_CREDS_*</constant> flags that indicate which credential info the caller is + interested in. See + <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a list of possible flags. On success, <parameter>creds</parameter> contains a new + <structname>sd_bus_creds</structname> instance with the requested information. Ownership of this instance + belongs to the caller and it should be freed once no longer needed by calling + <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_get_owner_creds()</function> queries the credentials of the creator of the given + bus. The <parameter>mask</parameter> and <parameter>creds</parameter> parameters behave the same as in + <function>sd_bus_get_name_creds()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>An argument is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus cannot be resolved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The bus has already been started.</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> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_get_name_machine_id.xml b/man/sd_bus_get_name_machine_id.xml new file mode 100644 index 0000000..8249485 --- /dev/null +++ b/man/sd_bus_get_name_machine_id.xml @@ -0,0 +1,98 @@ +<?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-or-later --> + +<refentry id="sd_bus_get_name_machine_id" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_get_name_machine_id</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_get_name_machine_id</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_get_name_machine_id</refname> + + <refpurpose>Retrieve a bus client's machine identity</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_get_name_machine_id</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>sd_id128_t *<parameter>machine</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_get_name_machine_id()</function> retrieves the D-Bus machine identity of the + machine that the bus client identified by <parameter>name</parameter> is running on. Internally, it calls + the <function>GetMachineId</function> method of the <constant>org.freedesktop.DBus.Peer</constant> + interface. The D-Bus machine identity is a 128-bit UUID. On Linux systems running systemd, this + corresponds to the contents of <filename>/etc/machine-id</filename>. On success, the machine identity is + stored in <parameter>machine</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this function returns a non-negative integer. On failure, it returns 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>An argument is invalid.</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> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_interface_name_is_valid.xml b/man/sd_bus_interface_name_is_valid.xml new file mode 100644 index 0000000..81a3fad --- /dev/null +++ b/man/sd_bus_interface_name_is_valid.xml @@ -0,0 +1,98 @@ +<?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-or-later --> + +<refentry id="sd_bus_interface_name_is_valid" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_interface_name_is_valid</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_interface_name_is_valid</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_interface_name_is_valid</refname> + <refname>sd_bus_service_name_is_valid</refname> + <refname>sd_bus_member_name_is_valid</refname> + <refname>sd_bus_object_path_is_valid</refname> + + <refpurpose>Check if a string is a valid bus name or object path</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_interface_name_is_valid</function></funcdef> + <paramdef>const char* <parameter>p</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_service_name_is_valid</function></funcdef> + <paramdef>const char* <parameter>p</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_member_name_is_valid</function></funcdef> + <paramdef>const char* <parameter>p</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_object_path_is_valid</function></funcdef> + <paramdef>const char* <parameter>p</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_interface_name_is_valid()</function> checks if a given string + <parameter>p</parameter> is a syntactically valid bus interface name. Similarly, + <function>sd_bus_service_name_is_valid()</function> checks if the argument is a valid bus service name, + <function>sd_bus_member_name_is_valid()</function> checks if the argument is a valid bus interface member + name, and <function>sd_bus_object_path_is_valid()</function> checks if the argument is a valid bus object + path. Those functions generally check that only allowed characters are used and that the length of the + string is within limits.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>Those functions return 1 if the argument is a valid interface / service / member name or object + path, and 0 if it is not. If the argument is <constant>NULL</constant>, an error is returned.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The <parameter>p</parameter> parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_is_open.xml b/man/sd_bus_is_open.xml new file mode 100644 index 0000000..8e0aed2 --- /dev/null +++ b/man/sd_bus_is_open.xml @@ -0,0 +1,103 @@ +<?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-or-later --> + +<refentry id="sd_bus_is_open" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_is_open</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_is_open</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_is_open</refname> + <refname>sd_bus_is_ready</refname> + + <refpurpose>Check whether the bus connection is open or ready</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_is_open</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_is_ready</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_is_open()</function> checks whether the specified bus connection is open, i.e. in the + process of being established, already established or in the process of being torn down. It returns zero when the + connection has not been started yet + (i.e. <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry> or some + equivalent call has not been invoked yet), or is fully terminated again (for example after + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>), it returns + positive otherwise.</para> + + <para><function>sd_bus_is_ready()</function> checks whether the specified connection is fully established, + i.e. completed the connection and authentication phases of the protocol and received the + <function>Hello()</function> method call response, and is not in the process of being torn down again. It returns + zero outside of this state, and positive otherwise. Effectively, this function returns positive while regular + messages can be sent or received on the connection.</para> + + <para>To be notified when the connection is fully established, use + <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + install a match for the <function>Connected()</function> signal on the + <literal>org.freedesktop.DBus.Local</literal> interface. To be notified when the connection is torn down again, + install a match for the <function>Disconnected()</function> signal on the + <literal>org.freedesktop.DBus.Local</literal> interface.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_list_names.xml b/man/sd_bus_list_names.xml new file mode 100644 index 0000000..d8f7e60 --- /dev/null +++ b/man/sd_bus_list_names.xml @@ -0,0 +1,110 @@ +<?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-or-later --> + +<refentry id="sd_bus_list_names" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_list_names</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_list_names</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_list_names</refname> + + <refpurpose>Retrieve information about registered names on a bus</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_list_names</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>char ***<parameter>acquired</parameter></paramdef> + <paramdef>char ***<parameter>activatable</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_list_names()</function> retrieves information about the registered names on a bus. + If <parameter>acquired</parameter> is not <constant>NULL</constant>, this function calls + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-list-names"> + org.freedesktop.DBus.ListNames</ulink> to retrieve the list of currently-owned names on the bus. If + <parameter>acquired</parameter> is not <constant>NULL</constant>, the function calls + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-list-activatable-names"> + org.freedesktop.DBus.ListActivableNames</ulink> to retrieve the list of all names on the bus that can be + activated. Note that ownership of the arrays returned by <function>sd_bus_list_names()</function> in + <parameter>acquired</parameter> and <parameter>activatable</parameter> is transferred to the caller and + hence, the caller is responsible for freeing these arrays and their contents.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_list_names()</function> returns a non-negative integer. On failure, + it returns 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><parameter>bus</parameter> or both <parameter>acquired</parameter> and + <parameter>activatable</parameter> were <constant>NULL</constant>. + </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>-ENOTCONN</constant></term> + + <listitem><para>The bus is not connected.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_message_append.xml b/man/sd_bus_message_append.xml new file mode 100644 index 0000000..a1c8736 --- /dev/null +++ b/man/sd_bus_message_append.xml @@ -0,0 +1,239 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_append" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_append</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_append</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_append</refname> + <refname>sd_bus_message_appendv</refname> + + <refpurpose>Attach fields to a D-Bus message based on a type string</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_append</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_appendv</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_append()</function> function appends a sequence of fields to + the D-Bus message object <parameter>m</parameter>. The type string <parameter>types</parameter> + describes the types of the field arguments that follow. For each type specified in the type + string, one or more arguments need to be specified, in the same order as declared in the type + string.</para> + + <para>The type string is composed of the elements shown in the table below. It contains zero or + more single "complete types". Each complete type may be one of the basic types or a fully + described container type. A container type may be a structure with the contained types, a + variant, an array with its element type, or a dictionary entry with the contained types. The + type string is <constant>NUL</constant>-terminated.</para> + + <para>In case of a basic type, one argument of the corresponding type is expected.</para> + + <para>A structure is denoted by a sequence of complete types between <literal>(</literal> and + <literal>)</literal>. This sequence cannot be empty — it must contain at least one type. + Arguments corresponding to this nested sequence follow the same rules as if they were not + nested.</para> + + <para>A variant is denoted by <literal>v</literal>. Corresponding arguments must begin with a + type string denoting a complete type, and following that, arguments corresponding to the + specified type.</para> + + <para>An array is denoted by <literal>a</literal> followed by a complete type. Corresponding + arguments must begin with the number of entries in the array, followed by the entries + themselves, matching the element type of the array.</para> + + <para>A dictionary is an array of dictionary entries, denoted by <literal>a</literal> followed + by a pair of complete types between <literal>{</literal> and <literal>}</literal>. The first of + those types must be a basic type. Corresponding arguments must begin with the number of + dictionary entries, followed by a pair of values for each entry matching the element type of the + dictionary entries.</para> + + <para><function>sd_bus_message_appendv()</function> is equivalent to + <function>sd_bus_message_append()</function>, except that it is called with a + <literal>va_list</literal> instead of a variable number of arguments. This function does not + call the <function>va_end()</function> macro. Because it invokes the + <function>va_arg()</function> macro, the value of <parameter>ap</parameter> is undefined after + the call.</para> + + <para>For further details on the D-Bus type system, please consult the + <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html#type-system">D-Bus Specification</ulink>. + </para> + + <table> + <title>Item type specifiers</title> + + <tgroup cols='5'> + <xi:include href="sd_bus_message_append_basic.xml" xpointer="xpointer(//table[@id='format-specifiers'])//colspec" /> + <xi:include href="sd_bus_message_append_basic.xml" xpointer="xpointer(//table[@id='format-specifiers']//thead)" /> + + <tbody> + <xi:include href="sd_bus_message_append_basic.xml" xpointer="xpointer(//table[@id='format-specifiers']//tbody/*)" /> + + <row> + <entry><literal>a</literal></entry> + <entry><constant>SD_BUS_TYPE_ARRAY</constant></entry> + <entry>array</entry> + <entry>determined by array type and size</entry> + <entry>int, followed by array contents</entry> + </row> + + <row> + <entry><literal>v</literal></entry> + <entry><constant>SD_BUS_TYPE_VARIANT</constant></entry> + <entry>variant</entry> + <entry>determined by the type argument</entry> + <entry>signature string, followed by variant contents</entry> + </row> + + <row> + <entry><literal>(</literal></entry> + <entry><constant>SD_BUS_TYPE_STRUCT_BEGIN</constant></entry> + <entry>array start</entry> + <entry morerows="1">determined by the nested types</entry> + <entry morerows="1">structure contents</entry> + </row> + <row> + <entry><literal>)</literal></entry> + <entry><constant>SD_BUS_TYPE_STRUCT_END</constant></entry> + <entry>array end</entry> + </row> + + <row> + <entry><literal>{</literal></entry> + <entry><constant>SD_BUS_TYPE_DICT_ENTRY_BEGIN</constant></entry> + <entry>dictionary entry start</entry> + <entry morerows="1">determined by the nested types</entry> + <entry morerows="1">dictionary contents</entry> + </row> + <row> + <entry><literal>}</literal></entry> + <entry><constant>SD_BUS_TYPE_DICT_ENTRY_END</constant></entry> + <entry>dictionary entry end</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>For types <literal>s</literal> and <literal>g</literal> (unicode string or signature), the pointer + may be <constant>NULL</constant>, which is equivalent to an empty string. For <literal>h</literal> (UNIX + file descriptor), the descriptor is duplicated by this call and the passed descriptor stays in possession + of the caller. See + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for the precise interpretation of those and other types.</para> + </refsect1> + + <refsect1> + <title>Types String Grammar</title> + + <programlisting>types ::= complete_type* +complete_type ::= basic_type | variant | structure | array | dictionary +basic_type ::= "y" | "n" | "q" | "u" | "i" | "x" | "t" | "d" | + "b" | "h" | + "s" | "o" | "g" +variant ::= "v" +structure ::= "(" complete_type+ ")" +array ::= "a" complete_type +dictionary ::= "a" "{" basic_type complete_type "}" +</programlisting> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Append a single basic type (the string <literal>a string</literal>): + </para> + + <programlisting>sd_bus_message *m; +… +sd_bus_message_append(m, "s", "a string");</programlisting> + + <para>Append all types of integers:</para> + + <programlisting>uint8_t y = 1; +int16_t n = 2; +uint16_t q = 3; +int32_t i = 4; +uint32_t u = 5; +int32_t x = 6; +uint32_t t = 7; +double d = 8.0; +sd_bus_message_append(m, "ynqiuxtd", y, n, q, i, u, x, t, d);</programlisting> + + <para>Append a structure composed of a string and a D-Bus path:</para> + + <programlisting>sd_bus_message_append(m, "(so)", "a string", "/a/path"); + </programlisting> + + <para>Append an array of UNIX file descriptors:</para> + + <programlisting>sd_bus_message_append(m, "ah", 3, STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO); + </programlisting> + + <para>Append a variant, with the real type "g" (signature), + and value "sdbusisgood":</para> + + <programlisting>sd_bus_message_append(m, "v", "g", "sdbusisgood");</programlisting> + + <para>Append a dictionary containing the mapping {1=>"a", 2=>"b", 3=>""}: + </para> + + <programlisting>sd_bus_message_append(m, "a{is}", 3, 1, "a", 2, "b", 3, NULL); + </programlisting> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code.</para> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_open_container</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_append_array.xml b/man/sd_bus_message_append_array.xml new file mode 100644 index 0000000..cc8e0db --- /dev/null +++ b/man/sd_bus_message_append_array.xml @@ -0,0 +1,179 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_append_array" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_append_array</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_append_array</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_append_array</refname> + <refname>sd_bus_message_append_array_memfd</refname> + <refname>sd_bus_message_append_array_iovec</refname> + <refname>sd_bus_message_append_array_space</refname> + + <refpurpose>Append an array of fields to a D-Bus + message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_append_array</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>void *<parameter>ptr</parameter></paramdef> + <paramdef>size_t <parameter>size</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_append_array_memfd</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>int <parameter>memfd</parameter></paramdef> + <paramdef>uint64_t <parameter>offset</parameter></paramdef> + <paramdef>uint64_t <parameter>size</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_append_array_iovec</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>const struct iovec *<parameter>iov</parameter></paramdef> + <paramdef>unsigned <parameter>n</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_append_array_space</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>size_t <parameter>size</parameter></paramdef> + <paramdef>void **<parameter>ptr</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_append_array()</function> + function appends an array to a D-Bus message + <parameter>m</parameter>. A container will be opened, the array + contents appended, and the container closed. The parameter + <parameter>type</parameter> determines how the pointer + <parameter>p</parameter> is interpreted. + <parameter>type</parameter> must be one of the "trivial" types + <literal>y</literal>, <literal>n</literal>, <literal>q</literal>, + <literal>i</literal>, <literal>u</literal>, <literal>x</literal>, + <literal>t</literal>, <literal>d</literal> (but not + <literal>b</literal>), as defined by the <ulink + url="http://dbus.freedesktop.org/doc/dbus-specification.html#basic-types">Basic + Types</ulink> section of the D-Bus specification, and listed in + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Pointer <parameter>p</parameter> must point to an array of size + <parameter>size</parameter> bytes containing items of the + respective type. Size <parameter>size</parameter> must be a + multiple of the size of the type <parameter>type</parameter>. As a + special case, <parameter>p</parameter> may be + <constant>NULL</constant>, if <parameter>size</parameter> is 0. + The memory pointed to by <parameter>p</parameter> is copied into + the memory area containing the message and stays in possession of + the caller. The caller may hence freely change the data after this + call without affecting the message the array was appended + to.</para> + + <para>The <function>sd_bus_message_append_array_memfd()</function> + function appends an array of a trivial type to message + <parameter>m</parameter>, similar to + <function>sd_bus_message_append_array()</function>. The contents + of the memory file descriptor <parameter>memfd</parameter> + starting at the specified offset and of the specified size is + used as the contents of the array. The offset and size must be a + multiple of the size of the type + <parameter>type</parameter>. However, as a special exception, if + the offset is specified as zero and the size specified as + UINT64_MAX the full memory file descriptor contents is used. The + memory file descriptor is sealed by this call if it has not been + sealed yet, and cannot be modified after this call. See + <citerefentry + project='man-pages'><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details about memory file descriptors. Appending arrays with + memory file descriptors enables efficient zero-copy data transfer, + as the memory file descriptor may be passed as-is to the + destination, without copying the memory in it to the destination + process. Not all protocol transports support passing memory file + descriptors between participants, in which case this call will + automatically fall back to copying. Also, as memory file + descriptor passing is inefficient for smaller amounts of data, + copying might still be enforced even where memory file descriptor + passing is supported.</para> + + <para>The <function>sd_bus_message_append_array_iovec()</function> + function appends an array of a trivial type to the message + <parameter>m</parameter>, similar to + <function>sd_bus_message_append_array()</function>. Contents of + the I/O vector array <parameter>iov</parameter> are used as the + contents of the array. The total size of + <parameter>iov</parameter> payload (the sum of + <structfield>iov_len</structfield> fields) must be a multiple of + the size of the type <parameter>type</parameter>. The + <parameter>iov</parameter> argument must point to + <parameter>n</parameter> I/O vector structures. Each structure may + have the <structname>iov_base</structname> field set, in which + case the memory pointed to will be copied into the message, or + unset (set to zero), in which case a block of zeros of length + <structname>iov_len</structname> bytes will be inserted. The + memory pointed at by <parameter>iov</parameter> may be changed + after this call.</para> + + <para>The <function>sd_bus_message_append_array_space()</function> + function appends space for an array of a trivial type to message + <parameter>m</parameter>. It behaves the same as + <function>sd_bus_message_append_array()</function>, but instead of + copying items to the message, it returns a pointer to the + destination area to the caller in pointer + <parameter>p</parameter>. The caller should subsequently write the + array contents to this memory. Modifications to the memory + pointed to should only occur until the next operation on the bus + message is invoked. Most importantly, the memory should not be + altered anymore when another field has been added to the message + or the message has been sealed.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On failure, they return a negative + errno-style error code.</para> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_append_basic.xml b/man/sd_bus_message_append_basic.xml new file mode 100644 index 0000000..aca4d1f --- /dev/null +++ b/man/sd_bus_message_append_basic.xml @@ -0,0 +1,261 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_append_basic" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_append_basic</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_append_basic</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_append_basic</refname> + + <refpurpose>Attach a single field to a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_append_basic</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>const void *<parameter>p</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_append_basic()</function> appends a + single field to the message <parameter>m</parameter>. The + parameter <parameter>type</parameter> determines how the pointer + <parameter>p</parameter> is interpreted. + <parameter>type</parameter> must be one of the basic types as + defined by the <ulink + url="http://dbus.freedesktop.org/doc/dbus-specification.html#basic-types">Basic + Types</ulink> section of the D-Bus specification, and listed in + the table below. + </para> + + <table id='format-specifiers'> + <title>Item type specifiers</title> + + <tgroup cols='5'> + <colspec colname='specifier' /> + <colspec colname='constant' /> + <colspec colname='description' /> + <colspec colname='size' /> + <colspec colname='ctype' /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Constant</entry> + <entry>Description</entry> + <entry>Size</entry> + <entry>Expected C Type</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>y</literal></entry> + <entry><constant>SD_BUS_TYPE_BYTE</constant></entry> + <entry>unsigned integer</entry> + <entry>1 byte</entry> + <entry>uint8_t</entry> + </row> + + <row> + <entry><literal>b</literal></entry> + <entry><constant>SD_BUS_TYPE_BOOLEAN</constant></entry> + <entry>boolean</entry> + <entry>4 bytes</entry> + <entry>int</entry> + </row> + + <row> + <entry><literal>n</literal></entry> + <entry><constant>SD_BUS_TYPE_INT16</constant></entry> + <entry>signed integer</entry> + <entry>2 bytes</entry> + <entry>int16_t</entry> + </row> + + <row> + <entry><literal>q</literal></entry> + <entry><constant>SD_BUS_TYPE_UINT16</constant></entry> + <entry>unsigned integer</entry> + <entry>2 bytes</entry> + <entry>uint16_t</entry> + </row> + + <row> + <entry><literal>i</literal></entry> + <entry><constant>SD_BUS_TYPE_INT32</constant></entry> + <entry>signed integer</entry> + <entry>4 bytes</entry> + <entry>int32_t</entry> + </row> + + <row> + <entry><literal>u</literal></entry> + <entry><constant>SD_BUS_TYPE_UINT32</constant></entry> + <entry>unsigned integer</entry> + <entry>4 bytes</entry> + <entry>uint32_t</entry> + </row> + + <row> + <entry><literal>x</literal></entry> + <entry><constant>SD_BUS_TYPE_INT64</constant></entry> + <entry>signed integer</entry> + <entry>8 bytes</entry> + <entry>int64_t</entry> + </row> + + <row> + <entry><literal>t</literal></entry> + <entry><constant>SD_BUS_TYPE_UINT64</constant></entry> + <entry>unsigned integer</entry> + <entry>8 bytes</entry> + <entry>uint64_t</entry> + </row> + + <row> + <entry><literal>d</literal></entry> + <entry><constant>SD_BUS_TYPE_DOUBLE</constant></entry> + <entry>floating-point</entry> + <entry>8 bytes</entry> + <entry>double</entry> + </row> + + <row> + <entry><literal>s</literal></entry> + <entry><constant>SD_BUS_TYPE_STRING</constant></entry> + <entry>Unicode string</entry> + <entry>variable</entry> + <entry>char[]</entry> + </row> + + <row> + <entry><literal>o</literal></entry> + <entry><constant>SD_BUS_TYPE_OBJECT_PATH</constant></entry> + <entry>object path</entry> + <entry>variable</entry> + <entry>char[]</entry> + </row> + + <row> + <entry><literal>g</literal></entry> + <entry><constant>SD_BUS_TYPE_SIGNATURE</constant></entry> + <entry>signature</entry> + <entry>variable</entry> + <entry>char[]</entry> + </row> + + <row> + <entry><literal>h</literal></entry> + <entry><constant>SD_BUS_TYPE_UNIX_FD</constant></entry> + <entry>UNIX file descriptor</entry> + <entry>4 bytes</entry> + <entry>int</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The value of the parameter is copied into a memory area held + by the message object, stays in the possession of the caller and + may hence be freely changed after this call without affecting the + bus message it has been added to. If <parameter>type</parameter> + is <literal>h</literal> (UNIX file descriptor), the descriptor is + duplicated by this call and the passed descriptor stays in + possession of the caller.</para> + + <para>For types <literal>s</literal>, <literal>o</literal>, and + <literal>g</literal>, the parameter <parameter>p</parameter> is + interpreted as a pointer to a <constant>NUL</constant>-terminated + character sequence. As a special case, a <constant>NULL</constant> + pointer is interpreted as an empty string. The string should be + valid Unicode string encoded as UTF-8. In case of the two latter + types, the additional requirements for a D-Bus object path or + type signature should be satisfied. Those requirements should be + verified by the recipient of the message. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this call returns 0 or a positive integer. On + failure, it returns a negative errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified parameter is invalid. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message has been sealed. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>Message is in invalid state. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>Message cannot be appended to. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_append_string_memfd.xml b/man/sd_bus_message_append_string_memfd.xml new file mode 100644 index 0000000..8559c60 --- /dev/null +++ b/man/sd_bus_message_append_string_memfd.xml @@ -0,0 +1,119 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_append_string_memfd" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_append_string_memfd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_append_string_memfd</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_append_string_memfd</refname> + <refname>sd_bus_message_append_string_iovec</refname> + <refname>sd_bus_message_append_string_space</refname> + + <refpurpose>Attach a string to a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_append_string_memfd</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>int <parameter>memfd</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_append_string_iovec</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const struct iovec *<parameter>iov</parameter></paramdef> + <paramdef>unsigned <parameter>n</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_append_string_space</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>size_t <parameter>size</parameter></paramdef> + <paramdef>char **<parameter>s</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The functions + <function>sd_bus_message_append_string_memfd()</function> and + <function>sd_bus_message_append_string_iovec()</function> can be + used to append a single string (item of type <literal>s</literal>) + to message <parameter>m</parameter>.</para> + + <para>In case of + <function>sd_bus_message_append_string_memfd()</function>, the + contents of <parameter>memfd</parameter> are the string. They must + satisfy the same constraints as described for the + <literal>s</literal> type in + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>In case of + <function>sd_bus_message_append_string_iovec()</function>, the + payload of <parameter>iov</parameter> is the string. It must + satisfy the same constraints as described for the + <literal>s</literal> type in + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>The <parameter>iov</parameter> argument must point to + <parameter>n</parameter> <structname>struct iovec</structname> + structures. Each structure may have the + <structname>iov_base</structname> field set, in which case the + memory pointed to will be copied into the message, or unset, in + which case a block of spaces (ASCII 32) of length + <structname>iov_len</structname> will be inserted. The + memory pointed at by <parameter>iov</parameter> may be changed + after this call.</para> + + <para>The + <function>sd_bus_message_append_string_space()</function> function appends + space for a string to message <parameter>m</parameter>. It behaves + similar to <function>sd_bus_message_append_basic()</function> with + type <literal>s</literal>, but instead of copying a string into + the message, it returns a pointer to the destination area to + the caller in pointer <parameter>p</parameter>. Space for the string + of length <parameter>size</parameter> plus the terminating + <constant>NUL</constant> is allocated.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, those calls return 0 or a positive integer. On failure, they return a negative + errno-style error code.</para> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_append_strv.xml b/man/sd_bus_message_append_strv.xml new file mode 100644 index 0000000..67ba404 --- /dev/null +++ b/man/sd_bus_message_append_strv.xml @@ -0,0 +1,81 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_append_strv" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_append_strv</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_append_strv</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_append_strv</refname> + + <refpurpose>Attach an array of strings to a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_append_strv</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char **<parameter>l</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_append()</function> function can be + used to append an array of strings to message + <parameter>m</parameter>. The parameter <parameter>l</parameter> + shall point to a <constant>NULL</constant>-terminated array of pointers + to <constant>NUL</constant>-terminated strings. Each string must + satisfy the same constraints as described for the + <literal>s</literal> type in + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>The memory pointed at by <parameter>p</parameter> and the + contents of the strings themselves are copied into the memory area + containing the message and may be changed after this call. Note + that the signature of <parameter>l</parameter> parameter is to be + treated as <type>const char *const *</type>, and the contents + will not be modified.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this call returns 0 or a positive integer. On failure, a negative errno-style error + code is returned.</para> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_at_end.xml b/man/sd_bus_message_at_end.xml new file mode 100644 index 0000000..9cff48a --- /dev/null +++ b/man/sd_bus_message_at_end.xml @@ -0,0 +1,86 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_at_end" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_message_at_end</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_at_end</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_at_end</refname> + + <refpurpose>Check if a message has been fully read</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_at_end</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>int <parameter>complete</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_at_end()</function> returns whether all data from the currently opened + container in <parameter>m</parameter> or all data from all containers in <parameter>m</parameter> has + been read. If <parameter>complete</parameter> is zero, this function returns whether all data from the + currently opened container has been read. If <parameter>complete</parameter> is non-zero, this function + returns whether all data from all containers in <parameter>m</parameter> has been read.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>If all data from all containers or the current container (depending on the value of + <parameter>complete</parameter>) has been read, <function>sd_bus_message_at_end()</function> returns a + positive integer. If there is still data left to be read, it returns zero. On failure, it returns 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>The <parameter>m</parameter> parameter is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message is not sealed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_message_copy.xml b/man/sd_bus_message_copy.xml new file mode 100644 index 0000000..278bc35 --- /dev/null +++ b/man/sd_bus_message_copy.xml @@ -0,0 +1,111 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_copy" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_copy</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_copy</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_copy</refname> + + <refpurpose>Copy the contents of one message to another</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_copy</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>all</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_copy()</function> copies the contents from + message <parameter>source</parameter> to <parameter>m</parameter>. If + <parameter>all</parameter> is false, a single complete type is copied + (basic or container). If <parameter>all</parameter> is true, the contents + are copied until the end of the currently open container or the end + of <parameter>source</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this call returns true if anything was copied, and false if + there was nothing to copy. On failure, it returns a negative errno-style error + code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para><parameter>source</parameter> or <parameter>m</parameter> are + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message <parameter>m</parameter> has been sealed or <parameter>source</parameter> + has <emphasis>not</emphasis> been sealed. </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>Destination message is in invalid state. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>Destination message cannot be appended to. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_dump.xml b/man/sd_bus_message_dump.xml new file mode 100644 index 0000000..eac0541 --- /dev/null +++ b/man/sd_bus_message_dump.xml @@ -0,0 +1,107 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_dump" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_dump</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_dump</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_dump</refname> + + <refpurpose>Produce a string representation of a message for debugging purposes</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_dump</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>FILE *<parameter>f</parameter></paramdef> + <paramdef>uint64_t <parameter>flags</parameter></paramdef> + </funcprototype> + </funcsynopsis> + + <para> + <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>, + <constant>SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY</constant> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_dump()</function> function writes a textual representation of the + message <parameter>m</parameter> to the stream <parameter>f</parameter>. This function is intended to be + used for debugging purposes, and the output is neither stable nor designed to be machine readable. + </para> + + <para>The <parameter>flags</parameter> parameter may be used to modify the output. With + <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>, a header that specifies the message type and flags + and some additional metadata is printed. When <constant>SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY</constant> is + not passed, the contents of the whole message are printed. When it <emphasis>is</emphasis> passed, + only the current container in printed.</para> + + <para>Note that this function moves the read pointer of the message. It may be necessary to reset the + position afterwards, for example with + <citerefentry><refentrytitle>sd_bus_message_rewind</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Output for a signal message (with <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>): + <programlisting> +‣ Type=signal Endian=l Flags=1 Version=1 Cookie=22 + Path=/value/a Interface=org.freedesktop.DBus.Properties Member=PropertiesChanged + MESSAGE "sa{sv}as" { + STRING "org.freedesktop.systemd.ValueTest"; + ARRAY "{sv}" { + DICT_ENTRY "sv" { + STRING "Value"; + VARIANT "s" { + STRING "object 0x1e, path /value/a"; + }; + }; + }; + ARRAY "s" { + STRING "Value2"; + STRING "AnExplicitProperty"; + }; + }; + </programlisting> + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this function returns 0 or a positive integer. On failure, it returns a negative + errno-style error code. No error codes are currently defined.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_get_cookie.xml b/man/sd_bus_message_get_cookie.xml new file mode 100644 index 0000000..148bda5 --- /dev/null +++ b/man/sd_bus_message_get_cookie.xml @@ -0,0 +1,107 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_get_cookie" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_get_cookie</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_get_cookie</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_get_cookie</refname> + <refname>sd_bus_message_get_reply_cookie</refname> + <refpurpose>Returns the transaction cookie of a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_cookie</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>uint64_t *<parameter>cookie</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_reply_cookie</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>uint64_t *<parameter>cookie</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_get_cookie()</function> returns the + transaction cookie of a message. The cookie uniquely identifies a + message within each bus peer, but is not globally unique. It is + assigned when a message is sent.</para> + + <para><function>sd_bus_message_get_reply_cookie()</function> + returns the transaction cookie of the message the specified + message is a response to. When a reply message is generated for a + method call message, its cookie is copied over into this field. + Note that while every message that is transferred is identified by + a cookie, only response messages carry a reply cookie + field.</para> + + <para>Both functions take a message object as first parameter and + a place to store the 64-bit cookie in.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On failure, they return a negative + errno-style error code.</para> + + <para>On success, the cookie/reply cookie is returned in the specified 64-bit unsigned integer + variable.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>A specified parameter is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENODATA</constant></term> + + <listitem><para>No cookie has been assigned to this message. This either indicates that the + message has not been sent yet and hence has no cookie assigned, or that the message is not a method + response message and hence carries a reply cookie field.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_get_monotonic_usec.xml b/man/sd_bus_message_get_monotonic_usec.xml new file mode 100644 index 0000000..605e2b4 --- /dev/null +++ b/man/sd_bus_message_get_monotonic_usec.xml @@ -0,0 +1,141 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_get_monotonic_usec" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_get_monotonic_usec</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_get_monotonic_usec</refname> + <refname>sd_bus_message_get_realtime_usec</refname> + <refname>sd_bus_message_get_seqnum</refname> + <refpurpose>Retrieve the sender timestamps and sequence number of a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_monotonic_usec</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_realtime_usec</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_seqnum</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>uint64_t *<parameter>seqnum</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_get_monotonic_usec()</function> + returns the monotonic timestamp of the time the message was sent. + This value is in microseconds since the + <constant>CLOCK_MONOTONIC</constant> epoch, see + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details.</para> + + <para>Similarly, + <function>sd_bus_message_get_realtime_usec()</function> returns + the realtime (wallclock) timestamp of the time the message was + sent. This value is in microseconds since Jan 1st, 1970, i.e. in + the <constant>CLOCK_REALTIME</constant> clock.</para> + + <para><function>sd_bus_message_get_seqnum()</function> returns the + kernel-assigned sequence number of the message. The kernel assigns + a global, monotonically increasing sequence number to all messages + transmitted on the local system, at the time the message was sent. + This sequence number is useful for determining message send order, + even across different buses of the local system. The sequence + number combined with the boot ID of the system (as returned by + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + is a suitable globally unique identifier for bus messages.</para> + + <para>Note that the sending order and receiving order of messages + might differ, in particular for broadcast messages. This means + that the sequence number and the timestamps of messages a client + reads are not necessarily monotonically increasing.</para> + + <para>These timestamps and the sequence number are attached to + each message by the kernel and cannot be manipulated by the + sender.</para> + + <para>Note that these timestamps are only available on some bus + transports, and only after support for them has been negotiated + with the + <citerefentry><refentrytitle>sd_bus_negotiate_timestamp</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On + failure, these calls return a negative errno-style error + code.</para> + + <para>On success, the timestamp or sequence number is returned in + the specified 64-bit unsigned integer variable.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>A specified parameter is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENODATA</constant></term> + + <listitem><para>No timestamp or sequence number information is attached to the passed message. This + error is returned if the underlying transport does not support timestamping or assigning of + sequence numbers, or if this feature has not been negotiated with + <citerefentry><refentrytitle>sd_bus_negotiate_timestamp</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_negotiate_timestamp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_get_signature.xml b/man/sd_bus_message_get_signature.xml new file mode 100644 index 0000000..203145b --- /dev/null +++ b/man/sd_bus_message_get_signature.xml @@ -0,0 +1,111 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_get_signature" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_message_get_signature</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_get_signature</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_get_signature</refname> + <refname>sd_bus_message_is_empty</refname> + <refname>sd_bus_message_has_signature</refname> + + <refpurpose>Query bus message signature</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>const char* <function>sd_bus_message_get_signature</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>int <parameter>complete</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_is_empty</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_has_signature</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>const char *<parameter>signature</parameter></paramdef> + </funcprototype> + </funcsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_get_signature()</function> returns the signature of message + <parameter>message</parameter>. If <parameter>complete</parameter> is true, the signature of the + whole message is returned, and just the signature of the currently open container otherwise. + </para> + + <para><function>sd_bus_message_is_empty()</function> returns true if the message is empty, + i.e. when its signature is empty.</para> + + <para><function>sd_bus_message_has_signature()</function> returns true if the signature of the + message <parameter>message</parameter> matches given <parameter>signature</parameter>. Parameter + <parameter>signature</parameter> may be <constant>NULL</constant>, this is treated the same as + an empty string, which is equivalent to calling <function>sd_bus_message_is_empty()</function>. + </para> +</refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_message_get_signature()</function> returns + the signature, and <constant>NULL</constant> on error.</para> + + <para>The other functions return 0 or a positive integer on success. 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>The <parameter>message</parameter> parameter is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>NULL</constant></term> + + <listitem><para>The <parameter>message</parameter> parameter is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_get_type.xml b/man/sd_bus_message_get_type.xml new file mode 100644 index 0000000..dd86316 --- /dev/null +++ b/man/sd_bus_message_get_type.xml @@ -0,0 +1,167 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_get_type" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_get_type</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_get_type</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_get_type</refname> + <refname>sd_bus_message_get_error</refname> + <refname>sd_bus_message_get_errno</refname> + <refname>sd_bus_message_get_creds</refname> + <refname>sd_bus_message_is_signal</refname> + <refname>sd_bus_message_is_method_call</refname> + <refname>sd_bus_message_is_method_error</refname> + + <refpurpose>Query bus message addressing/credentials metadata</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_type</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>uint8_t *<parameter>type</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_error* <function>sd_bus_message_get_error</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_errno</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_creds* <function>sd_bus_message_get_creds</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_is_signal</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_is_method_call</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_is_method_error</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + </funcprototype> + </funcsynopsis> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_get_type()</function> returns the type of a message in the output + parameter <parameter>type</parameter>, one of <constant>SD_BUS_MESSAGE_METHOD_CALL</constant>, + <constant>SD_BUS_MESSAGE_METHOD_RETURN</constant>, <constant>SD_BUS_MESSAGE_METHOD_ERROR</constant>, + <constant>SD_BUS_MESSAGE_SIGNAL</constant>. This type is either specified as a parameter when the message + is created using + <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + or is set automatically when the message is created using + <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and similar functions.</para> + + <para><function>sd_bus_message_get_error()</function> returns the error stored in the message + <parameter>m</parameter>, if there is any. Otherwise, it returns <constant>NULL</constant>. + <function>sd_bus_message_get_errno()</function> returns the error stored in the message + <parameter>m</parameter> as a positive errno-style value, if there is any. Otherwise, it returns zero. + Errors are mapped to errno values according to the default and any additional registered error mappings. + See <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_message_get_creds()</function> returns the message credentials attached to the + message <parameter>m</parameter>. If no credentials are attached to the message, it returns + <constant>NULL</constant>. Ownership of the credentials instance is not transferred to the caller and + hence should not be freed.</para> + + <para><function>sd_bus_message_is_signal()</function> checks if message <parameter>m</parameter> is a + signal message. If <parameter>interface</parameter> is non-null, it also checks if the message has the + same interface set. If <parameter>member</parameter> is non-null, it also checks if the message has the + same member set. Also see + <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + It returns true when all checks pass.</para> + + <para><function>sd_bus_message_is_method_call()</function> checks if message <parameter>m</parameter> + is a method call message. If <parameter>interface</parameter> is non-null, it also checks if the message + has the same interface set. If <parameter>member</parameter> is non-null, it also checks if the message + has the same member set. Also see + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + It returns true when all checks pass.</para> + + <para><function>sd_bus_message_is_method_error()</function> checks if message <parameter>m</parameter> + is an error reply message. If <parameter>name</parameter> is non-null, it also checks if the message has + the same error identifier set. Also see + <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + It returns true when all checks pass.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions (except <function>sd_bus_message_get_error()</function> and + <function>sd_bus_message_get_creds()</function>) return a non-negative integer. On failure, they return a + negative errno-style error code. <function>sd_bus_message_get_errno()</function> always returns a + non-negative integer, even on failure.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The message parameter <parameter>m</parameter> or an output parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_new.xml b/man/sd_bus_message_new.xml new file mode 100644 index 0000000..4907c5a --- /dev/null +++ b/man/sd_bus_message_new.xml @@ -0,0 +1,189 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_new" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_message_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_new</refname> + <refname>sd_bus_message_ref</refname> + <refname>sd_bus_message_unref</refname> + <refname>sd_bus_message_unrefp</refname> + <refname>SD_BUS_MESSAGE_METHOD_CALL</refname> + <refname>SD_BUS_MESSAGE_METHOD_RETURN</refname> + <refname>SD_BUS_MESSAGE_METHOD_ERROR</refname> + <refname>SD_BUS_MESSAGE_SIGNAL</refname> + <refname>sd_bus_message_get_bus</refname> + + <refpurpose>Create a new bus message object and create or destroy references to it</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>enum</token> { + <constant>SD_BUS_MESSAGE_METHOD_CALL</constant>, + <constant>SD_BUS_MESSAGE_METHOD_RETURN</constant>, + <constant>SD_BUS_MESSAGE_METHOD_ERROR</constant>, + <constant>SD_BUS_MESSAGE_SIGNAL</constant>, +};</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_new</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>uint8_t <parameter>type</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_message *<function>sd_bus_message_ref</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_message *<function>sd_bus_message_unref</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_message_unrefp</function></funcdef> + <paramdef>sd_bus_message **<parameter>mp</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_message_get_bus</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_new()</function> creates a new bus message object attached to the + bus <parameter>bus</parameter> and returns it in the output parameter <parameter>m</parameter>. + This object is reference-counted, and will be destroyed when all references are gone. Initially, + the caller of this function owns the sole reference to the message object. Note that the message + object holds a reference to the bus object, so the bus object will not be destroyed as long as + the message exists.</para> + + <para>Note: this is a low-level call. In most cases functions like + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + that create a message of a certain type and initialize various fields are easier to use.</para> + + <para>The <parameter>type</parameter> parameter specifies the type of the message. It must be + one of <constant>SD_BUS_MESSAGE_METHOD_CALL</constant> — a method call, + <constant>SD_BUS_MESSAGE_METHOD_RETURN</constant> — a method call reply, + <constant>SD_BUS_MESSAGE_METHOD_ERROR</constant> — an error reply to a method call, + <constant>SD_BUS_MESSAGE_SIGNAL</constant> — a broadcast message with no reply. + </para> + + <para>The flag to allow interactive authorization is initialized based on the current value set + in the bus object, see + <citerefentry><refentrytitle>sd_bus_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This may be changed using + <citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_message_ref()</function> increases the reference counter of + <parameter>m</parameter> by one.</para> + + <para><function>sd_bus_message_unref()</function> decreases the reference counter of + <parameter>m</parameter> by one. Once the reference count has dropped to zero, message object is + destroyed and cannot be used anymore, so further calls to + <function>sd_bus_message_ref()</function> or <function>sd_bus_message_unref()</function> are + illegal.</para> + + <para><function>sd_bus_message_unrefp()</function> is similar to + <function>sd_bus_message_unref()</function> but takes a pointer to a + pointer to an <type>sd_bus_message</type> object. 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>. See + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for an example how to use the cleanup attribute.</para> + + <para><function>sd_bus_message_ref()</function> and <function>sd_bus_message_unref()</function> + execute no operation if the passed in bus message object address is + <constant>NULL</constant>. <function>sd_bus_message_unrefp()</function> will first dereference + its argument, which must not be <constant>NULL</constant>, and will execute no operation if + <emphasis>that</emphasis> is <constant>NULL</constant>. + </para> + + <para><function>sd_bus_message_get_bus()</function> returns the bus object that message + <parameter>m</parameter> is attached to.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_message_new()</function> returns 0 or a positive integer. On + failure, it returns a negative errno-style error code.</para> + + <para><function>sd_bus_message_ref()</function> always returns the argument. + </para> + + <para><function>sd_bus_message_unref()</function> always returns + <constant>NULL</constant>.</para> + + <para><function>sd_bus_message_get_bus()</function> always returns the bus object.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified <parameter>type</parameter> is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus parameter <parameter>bus</parameter> is <constant>NULL</constant> or + the bus is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_new_method_call.xml b/man/sd_bus_message_new_method_call.xml new file mode 100644 index 0000000..f6278e3 --- /dev/null +++ b/man/sd_bus_message_new_method_call.xml @@ -0,0 +1,172 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_new_method_call" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_new_method_call</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_new_method_call</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_new_method_call</refname> + <refname>sd_bus_message_new_method_return</refname> + + <refpurpose>Create a method call message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_new_method_call</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_new_method_return</function></funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_new_method_call()</function> function creates a new bus + message object that encapsulates a D-Bus method call, and returns it in the + <parameter>m</parameter> output parameter. The call will be made on the destination + <parameter>destination</parameter>, path <parameter>path</parameter>, on the interface + <parameter>interface</parameter>, member <parameter>member</parameter>.</para> + + <para>Briefly, the <emphasis>destination</emphasis> is a dot-separated name that identifies a + service connected to the bus. The <emphasis>path</emphasis> is a slash-separated identifier of + an object within the destination that resembles a file system path. The meaning of this path is + defined by the destination. The <emphasis>interface</emphasis> is a dot-separated name that + resembles a Java interface name that identifies a group of methods and signals supported by the + object identified by path. Methods and signals are collectively called + <emphasis>members</emphasis> and are identified by a simple name composed of ASCII letters, + numbers, and underscores. See the <ulink + url="https://dbus.freedesktop.org/doc/dbus-tutorial.html#concepts">D-Bus Tutorial</ulink> for an + in-depth explanation.</para> + + <para>The <parameter>destination</parameter> parameter may be <constant>NULL</constant>. The + <parameter>interface</parameter> parameter may be <constant>NULL</constant>, if the destination + has only a single member with the given name and there is no ambiguity if the interface name is + omitted.</para> + + <para>Note that this is a low level interface. See + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a more convenient way of calling D-Bus methods.</para> + + <para>The <function>sd_bus_message_new_method_return()</function> function creates a new bus + message object that is a reply to the method call <parameter>call</parameter> and returns it in + the <parameter>m</parameter> output parameter. The <parameter>call</parameter> parameter must be + a method call message. The sender of <parameter>call</parameter> is used as the destination. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The output parameter <parameter>m</parameter> is + <constant>NULL</constant>.</para> + + <para>The <parameter>destination</parameter> parameter is non-null and is not a valid D-Bus + service name (<literal>org.somewhere.Something</literal>), the <parameter>path</parameter> + parameter is not a valid D-Bus path (<literal>/an/object/path</literal>), the + <parameter>interface</parameter> parameter is non-null and is not a valid D-Bus interface + name (<literal>an.interface.name</literal>), or the <parameter>member</parameter> parameter + is not a valid D-Bus member (<literal>Name</literal>).</para> + + <para>The <parameter>call</parameter> parameter is not a method call object.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus parameter <parameter>bus</parameter> is <constant>NULL</constant> or + the bus is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem> + <para>The <parameter>call</parameter> parameter is not sealed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem> + <para>The <parameter>call</parameter> message does not have a cookie.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Make a call to a D-Bus method that takes a single parameter</title> + + <programlisting><xi:include href="print-unit-path.c" parse="text" /></programlisting> + <para>This defines a minimally useful program that will open a connection to the bus, create a + message object, send it, wait for the reply, and finally extract and print the answer. It does + error handling and proper memory management.</para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_path_encode</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_new_method_error.xml b/man/sd_bus_message_new_method_error.xml new file mode 100644 index 0000000..92c4ac6 --- /dev/null +++ b/man/sd_bus_message_new_method_error.xml @@ -0,0 +1,187 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_new_method_error" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_new_method_error</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_new_method_error</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_new_method_error</refname> + <refname>sd_bus_message_new_method_errorf</refname> + <refname>sd_bus_message_new_method_errno</refname> + <refname>sd_bus_message_new_method_errnof</refname> + + <refpurpose>Create an error reply for a method call</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_new_method_error</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_new_method_errorf</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_new_method_errno</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const sd_bus_error *<parameter>p</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_new_method_errnof</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_new_method_error()</function> function creates + a new bus message object that is an error reply to the + <parameter>call</parameter> message, and returns it in the + <parameter>m</parameter> output parameter. The error information from error + <parameter>e</parameter> is appended: the <parameter>name</parameter> field of + <parameter>e</parameter> is used as the error identifier in the reply header (for + example an error name such as + <literal>org.freedesktop.DBus.Error.NotSupported</literal> or the equivalent + symbolic <constant>SD_BUS_ERROR_NOT_SUPPORTED</constant>), and the + <parameter>message</parameter> field is set as the human readable error message + string if present. The error <parameter>e</parameter> must have the + <parameter>name</parameter> field set, see + <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>The <function>sd_bus_message_new_method_errorf()</function> function + creates an error reply similarly to + <function>sd_bus_message_new_method_error()</function>, but instead of a ready + error structure, it takes an error identifier string <parameter>name</parameter>, + plus a <citerefentry + project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> + format string <parameter>format</parameter> and corresponding arguments. An error + reply is sent with the error identifier <parameter>name</parameter> and the + formatted string as the message. <parameter>name</parameter> and + <parameter>format</parameter> must not be <constant>NULL</constant>. + </para> + + <para>The <function>sd_bus_message_new_method_errno()</function> function creates + an error reply similarly to + <function>sd_bus_message_new_method_error()</function>, but in addition to the + error structure <parameter>p</parameter>, it takes an + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + error value in parameter <parameter>error</parameter>. If the error + <parameter>p</parameter> is set (see + <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>), + it is used in the reply. Otherwise, <parameter>error</parameter> is translated to + an error identifier and used to create a new error structure using + <citerefentry><refentrytitle>sd_bus_error_set_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and that is used in the reply. (If <parameter>error</parameter> is zero, no error + is actually set, and an error reply with no information is created.)</para> + + <para>The <function>sd_bus_message_new_method_errnof()</function> function + creates an error reply similarly to + <function>sd_bus_message_new_method_error()</function>. It takes an + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + error value in parameter <parameter>error</parameter>, plus a <citerefentry + 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 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> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>These functions return 0 if the error reply was successfully created, and a + negative errno-style error code otherwise.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The call message <parameter>call</parameter> or the output + parameter <parameter>m</parameter> are <constant>NULL</constant>.</para> + + <para>Message <parameter>call</parameter> is not a method call + message.</para> + + <para>The error <parameter>e</parameter> parameter to + <function>sd_bus_message_new_method_error()</function> is not set, see + <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message <parameter>call</parameter> has been sealed. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus to which message <parameter>call</parameter> is + attached is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_new_signal.xml b/man/sd_bus_message_new_signal.xml new file mode 100644 index 0000000..17862de --- /dev/null +++ b/man/sd_bus_message_new_signal.xml @@ -0,0 +1,121 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_new_signal" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_new_signal</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_new_signal</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_new_signal</refname> + + <refpurpose>Create a signal message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_new_signal</funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_message_new_signal()</function> function creates a new bus message + object that encapsulates a D-Bus signal, and returns it in the <parameter>m</parameter> output + parameter. The signal will be sent to path <parameter>path</parameter>, on the interface + <parameter>interface</parameter>, member <parameter>member</parameter>. When this message is + sent, no reply is expected. See + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for a short description of the meaning of the <parameter>path</parameter>, + <parameter>interface</parameter>, and <parameter>member</parameter> parameters. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>This function returns 0 if the message object was successfully created, and a negative + errno-style error code otherwise.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The output parameter <parameter>m</parameter> is + <constant>NULL</constant>.</para> + + <para>The <parameter>path</parameter> parameter is not a valid D-Bus path + (<literal>/an/object/path</literal>), the <parameter>interface</parameter> parameter is not + a valid D-Bus interface name (<literal>an.interface.name</literal>), or the + <parameter>member</parameter> parameter is not a valid D-Bus member + (<literal>Name</literal>).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus parameter <parameter>bus</parameter> is <constant>NULL</constant> or + the bus is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Send a simple signal</title> + + <programlisting><xi:include href="send-unit-files-changed.c" parse="text" /></programlisting> + + <para>This function in systemd sources is used to emit the + <literal>UnitFilesChanged</literal> signal when the unit files have been changed. + </para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_emit_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_open_container.xml b/man/sd_bus_message_open_container.xml new file mode 100644 index 0000000..27b953e --- /dev/null +++ b/man/sd_bus_message_open_container.xml @@ -0,0 +1,178 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_open_container" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_open_container</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_open_container</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_open_container</refname> + <refname>sd_bus_message_close_container</refname> + <refname>sd_bus_message_enter_container</refname> + <refname>sd_bus_message_exit_container</refname> + + <refpurpose>Create and move between containers in D-Bus messages</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_open_container</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>const char *<parameter>contents</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_close_container</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_enter_container</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>const char *<parameter>contents</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_message_exit_container</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_open_container()</function> appends a new container to the message + <parameter>m</parameter>. After opening a new container, it can be filled with content using + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and similar functions. Containers behave like a stack. To nest containers inside each other, call + <function>sd_bus_message_open_container()</function> multiple times without calling + <function>sd_bus_message_close_container()</function> in between. Each container will be nested inside the + previous container. <parameter>type</parameter> represents the container type and should be one of + <literal>r</literal>, <literal>a</literal>, <literal>v</literal> or <literal>e</literal> as described in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Instead of literals, the corresponding constants <constant>SD_BUS_TYPE_STRUCT</constant>, + <constant>SD_BUS_TYPE_ARRAY</constant>, <constant>SD_BUS_TYPE_VARIANT</constant> or + <constant>SD_BUS_TYPE_DICT_ENTRY</constant> can also be used. <parameter>contents</parameter> describes + the type of the container's elements and should be a D-Bus type string following the rules described in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_message_close_container()</function> closes the last container opened with + <function>sd_bus_message_open_container()</function>. On success, the write pointer of the message + <parameter>m</parameter> is positioned after the closed container in its parent container or in + <parameter>m</parameter> itself if there is no parent container.</para> + + <para><function>sd_bus_message_enter_container()</function> enters the next container of the message + <parameter>m</parameter> for reading. It behaves mostly the same as + <function>sd_bus_message_open_container()</function>. Entering a container allows reading its contents + with + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and similar functions. <parameter>type</parameter> and <parameter>contents</parameter> are the same as in + <function>sd_bus_message_open_container()</function>.</para> + + <para><function>sd_bus_message_exit_container()</function> exits the scope of the last container entered + with <function>sd_bus_message_enter_container()</function>. It behaves mostly the same as + <function>sd_bus_message_close_container()</function>. Note that + <function>sd_bus_message_exit_container()</function> may only be called after iterating through all + members of the container, i.e. reading or skipping them. Use + <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to skip over felds of a container in order to be able to exit the container with + <function>sd_bus_message_exit_container()</function> without reading all members.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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><parameter>m</parameter> or <parameter>contents</parameter> are + <constant>NULL</constant> or <parameter>type</parameter> is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message <parameter>m</parameter> is already sealed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The message <parameter>m</parameter> is in an invalid state.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para><function>sd_bus_message_exit_container()</function> was called but there are + unread members left in the container.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Append an array of strings to a message</title> + + <programlisting><xi:include href="sd-bus-container-append.c" parse="text" /></programlisting> + </example> + + <example> + <title>Read an array of strings from a message</title> + + <programlisting><xi:include href="sd-bus-container-read.c" parse="text" /></programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_read.xml b/man/sd_bus_message_read.xml new file mode 100644 index 0000000..12a2c77 --- /dev/null +++ b/man/sd_bus_message_read.xml @@ -0,0 +1,259 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_read" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_read</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_read</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_read</refname> + <refname>sd_bus_message_readv</refname> + <refname>sd_bus_message_peek_type</refname> + + <refpurpose>Read a sequence of values from a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_read</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_readv</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_peek_type</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char *<parameter>type</parameter></paramdef> + <paramdef>const char **<parameter>contents</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_read()</function> reads a sequence of fields from the D-Bus message object + <parameter>m</parameter> and advances the read position in the message. The type string + <parameter>types</parameter> describes the types of items expected in the message and the field arguments + that follow. The type string may be <constant>NULL</constant> or empty, in which case nothing is read. + </para> + + <para>The type string is composed of the elements described in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + i.e. basic and container types. It must contain zero or more single "complete types". The type string is + <constant>NUL</constant>-terminated.</para> + + <para>For each type specified in the type string, one or more arguments need to be specified after the + <parameter>types</parameter> parameter, in the same order. The arguments must be pointers to appropriate + types (a pointer to <type>int8_t</type> for a <literal>y</literal> in the type string, a pointer to + <type>int32_t</type> for an <literal>i</literal>, a pointer to <type>const char*</type> for an + <literal>s</literal>, ...) which are set based on the values in the message. As an exception, in case of + array and variant types, the first argument is an "input" argument that further specifies how the message + should be read. See the table below for a complete list of allowed arguments and their types. Note that, + if the basic type is a pointer (e.g., <type>const char *</type> in the case of a string), the argument is + a pointer to a pointer, and also the pointer value that is written is only borrowed and the contents must + be copied if they are to be used after the end of the messages lifetime. If the type is + <literal>h</literal> (UNIX file descriptor), the descriptor is not duplicated by this call and the + returned descriptor remains in possession of the message object, and needs to be duplicated by the caller + in order to keep an open reference to it after the message object is freed.</para> + + <para>Each argument may also be <constant>NULL</constant>, in which case the value is read and ignored. + </para> + + <table> + <title>Item type specifiers</title> + + <tgroup cols='5'> + <colspec colname='specifier' /> + <colspec colname='constant' /> + <colspec colname='description' /> + <colspec colname='type1' /> + <colspec colname='type2' /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Constant</entry> + <entry>Description</entry> + <entry>Type of the first argument</entry> + <entry>Types of the subsequent arguments, if any</entry> + </row> + </thead> + + <tbody> + <xi:include href="sd_bus_message_read_basic.xml" xpointer="xpointer(//table[@id='format-specifiers']//tbody/*)" /> + + <row> + <entry><literal>a</literal></entry> + <entry><constant>SD_BUS_TYPE_ARRAY</constant></entry> + <entry>array</entry> + <entry><type>int</type>, which specifies the expected length <parameter>n</parameter> of the array</entry> + <entry><parameter>n</parameter> sets of arguments appropriate for the array element type</entry> + </row> + + <row> + <entry><literal>v</literal></entry> + <entry><constant>SD_BUS_TYPE_VARIANT</constant></entry> + <entry>variant</entry> + <entry>signature string</entry> + <entry>arguments appropriate for the types specified by the signature</entry> + </row> + + <row> + <entry><literal>(</literal></entry> + <entry><constant>SD_BUS_TYPE_STRUCT_BEGIN</constant></entry> + <entry>array start</entry> + <entry morerows="1" namest="type1" nameend="type2">arguments appropriate for the structure elements</entry> + </row> + <row> + <entry><literal>)</literal></entry> + <entry><constant>SD_BUS_TYPE_STRUCT_END</constant></entry> + <entry>array end</entry> + </row> + + <row> + <entry><literal>{</literal></entry> + <entry><constant>SD_BUS_TYPE_DICT_ENTRY_BEGIN</constant></entry> + <entry>dictionary entry start</entry> + <entry morerows="1">arguments appropriate for the first type in the pair</entry> + <entry morerows="1">arguments appropriate for the second type in the pair</entry> + </row> + <row> + <entry><literal>}</literal></entry> + <entry><constant>SD_BUS_TYPE_DICT_ENTRY_END</constant></entry> + <entry>dictionary entry end</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>If objects of the specified types are not present at the current position in the message, an error + is returned.</para> + + <para>The <function>sd_bus_message_readv()</function> is equivalent to the + <function>sd_bus_message_read()</function>, except that it is called with a <literal>va_list</literal> + instead of a variable number of arguments. This function does not call the <function>va_end()</function> + macro. Because it invokes the <function>va_arg()</function> macro, the value of <parameter>ap</parameter> + is undefined after the call.</para> + + <para><function>sd_bus_message_peek_type()</function> determines the type of the next element in + <parameter>m</parameter> to be read by <function>sd_bus_message_read()</function> or similar functions. + On success, the type is stored in <parameter>type</parameter>, if it is not <constant>NULL</constant>. + If the type is a container type, the type of its elements is stored in <parameter>contents</parameter>, + if it is not <constant>NULL</constant>. If this function successfully determines the type of the next + element in <parameter>m</parameter>, it returns a positive integer. If there are no more elements to be + read, it returns zero.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code.</para> + + <xi:include href="sd_bus_message_read_basic.xml" xpointer="errors" /> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <para>Read a single basic type (a 64-bit integer): + </para> + + <programlisting>sd_bus_message *m; +int64_t x; + +sd_bus_message_read(m, "x", &x);</programlisting> + + <para>Read a boolean value:</para> + + <programlisting>sd_bus_message *m; +int x; /* Do not use C99 'bool' type here, it's typically smaller + in memory and would cause memory corruption */ + +sd_bus_message_read(m, "b", &x);</programlisting> + + <para>Read all types of integers:</para> + + <programlisting>uint8_t y; +int16_t n; +uint16_t q; +int32_t i; +uint32_t u; +int32_t x; +uint32_t t; +double d; + +sd_bus_message_read(m, "ynqiuxtd", &y, &n, &q, &i, &u, &x, &t, &d);</programlisting> + + <para>Read a structure composed of a string and a D-Bus path:</para> + + <programlisting>const char *s, *p; + +sd_bus_message_read(m, "(so)", &s, &p); +</programlisting> + + <para>Read a variant, with the real type "gt" (signature, unsigned integer): + </para> + + <programlisting>const char *s; +uint64_t *v; + +sd_bus_message_read(m, "v", "gt", &s, &v);</programlisting> + + <para>Read a dictionary containing three pairs of type {integer=>string}: + </para> + + <programlisting>int i, j, k; +const char *s, *t, *u; + +sd_bus_message_read(m, "a{is}", 3, &i, &s, &j, &t, &k, &u); + </programlisting> + + <para>Read a single file descriptor, and duplicate it in order to keep it open after the message is + freed.</para> + + <programlisting>sd_bus_message *m; +int fd, fd_copy; + +sd_bus_message_read(m, "h", &fd); +fd_copy = fcntl(fd, FD_DUPFD_CLOEXEC, 3);</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_enter_container</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_read_array.xml b/man/sd_bus_message_read_array.xml new file mode 100644 index 0000000..daff909 --- /dev/null +++ b/man/sd_bus_message_read_array.xml @@ -0,0 +1,116 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_read_array"> + + <refentryinfo> + <title>sd_bus_message_read_array</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_read_array</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_read_array</refname> + + <refpurpose>Access an array of elements in a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_read_array</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>const void **<parameter>ptr</parameter></paramdef> + <paramdef>size_t *<parameter>size</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_read_array()</function> provides access to an array elements in the + bus message <parameter>m</parameter>. The "read pointer" in the message must be right before an array of type + <parameter>type</parameter>. As a special case, <parameter>type</parameter> may be + <constant>NUL</constant>, in which case any trivial type is acceptable. A pointer to the array data is returned + in the parameter <parameter>ptr</parameter> and the size of array data (in bytes) is returned in the + parameter <parameter>size</parameter>. If the returned <parameter>size</parameter> parameter is 0, a + valid non-null pointer will be returned as <parameter>ptr</parameter>, but it may not be + dereferenced. The data is aligned as appropriate for the data type. The data is part of the message — it + may not be modified and is valid only as long as the message is referenced. After this function returns, + the "read pointer" points at the next element after the array.</para> + + <para>Note that this function only supports arrays of trivial types, i.e. arrays of booleans, the various + integer types, as well as floating point numbers. In particular it may not be used for arrays of strings, + structures or similar.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para> + On success and when an array was read, <function>sd_bus_message_read_array()</function> returns an + integer greater than zero. If invoked while inside a container element (such as an array, e.g. when + operating on an array of arrays) and the final element of the outer container has been read already and + the read pointer is thus behind the last element of the outer container this call returns 0 (and the + returned pointer will be <constant>NULL</constant> and the size will be 0). On failure, it returns 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>Specified type is invalid or not a trivial type (see above), or the message + parameter or one of the output parameters are <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>The byte order in the message is different than native byte + order.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message is not sealed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADMSG</constant></term> + + <listitem><para>The message cannot be parsed.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_read_basic.xml b/man/sd_bus_message_read_basic.xml new file mode 100644 index 0000000..443fcda --- /dev/null +++ b/man/sd_bus_message_read_basic.xml @@ -0,0 +1,237 @@ +<?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-or-later + + Copyright © 2016 Julian Orth +--> + +<refentry id="sd_bus_message_read_basic"> + + <refentryinfo> + <title>sd_bus_message_read_basic</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_read_basic</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_read_basic</refname> + + <refpurpose>Read a basic type from a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_read_basic</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>void *<parameter>p</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para> + <function>sd_bus_message_read_basic()</function> reads a basic type from a + message and advances the read position in the message. The set of basic + types and their ascii codes passed in <parameter>type</parameter> are + described in the <ulink + url="https://dbus.freedesktop.org/doc/dbus-specification.html">D-Bus + Specification</ulink>. + </para> + + <para> + If <parameter>p</parameter> is not <constant>NULL</constant>, it should contain a pointer to an + appropriate object. For example, if <parameter>type</parameter> is <constant>'y'</constant>, the object + passed in <parameter>p</parameter> should have type <type>uint8_t *</type>. If + <parameter>type</parameter> is <constant>'s'</constant>, the object passed in <parameter>p</parameter> + should have type <type>const char **</type>. Note that, if the basic type is a pointer (e.g., + <type>const char *</type> in the case of a string), the pointer is only borrowed and the contents must + be copied if they are to be used after the end of the messages lifetime. Similarly, during the lifetime + of such a pointer, the message must not be modified. If <parameter>type</parameter> is + <constant>'h'</constant> (UNIX file descriptor), the descriptor is not duplicated by this call and the + returned descriptor remains in possession of the message object, and needs to be duplicated by the caller + in order to keep an open reference to it after the message object is freed (for example by calling + <literal>fcntl(fd, FD_DUPFD_CLOEXEC, 3)</literal>). See the table below for a complete list of + allowed types. + </para> + + <table id='format-specifiers'> + <title>Item type specifiers</title> + + <tgroup cols='4'> + <colspec colname='specifier' /> + <colspec colname='constant' /> + <colspec colname='description' /> + <colspec colname='ctype' /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Constant</entry> + <entry>Description</entry> + <entry>Expected C Type</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>y</literal></entry> + <entry><constant>SD_BUS_TYPE_BYTE</constant></entry> + <entry>8bit unsigned integer</entry> + <entry><type>uint8_t *</type></entry> + </row> + + <row> + <entry><literal>b</literal></entry> + <entry><constant>SD_BUS_TYPE_BOOLEAN</constant></entry> + <entry>boolean</entry> + <entry><type>int *</type> (NB: not <type>bool *</type>)</entry> + </row> + + <row> + <entry><literal>n</literal></entry> + <entry><constant>SD_BUS_TYPE_INT16</constant></entry> + <entry>16bit signed integer</entry> + <entry><type>int16_t *</type></entry> + </row> + + <row> + <entry><literal>q</literal></entry> + <entry><constant>SD_BUS_TYPE_UINT16</constant></entry> + <entry>16bit unsigned integer</entry> + <entry><type>uint16_t *</type></entry> + </row> + + <row> + <entry><literal>i</literal></entry> + <entry><constant>SD_BUS_TYPE_INT32</constant></entry> + <entry>32bit signed integer</entry> + <entry><type>int32_t *</type></entry> + </row> + + <row> + <entry><literal>u</literal></entry> + <entry><constant>SD_BUS_TYPE_UINT32</constant></entry> + <entry>32bit unsigned integer</entry> + <entry><type>uint32_t *</type></entry> + </row> + + <row> + <entry><literal>x</literal></entry> + <entry><constant>SD_BUS_TYPE_INT64</constant></entry> + <entry>64bit signed integer</entry> + <entry><type>int64_t *</type></entry> + </row> + + <row> + <entry><literal>t</literal></entry> + <entry><constant>SD_BUS_TYPE_UINT64</constant></entry> + <entry>64bit unsigned integer</entry> + <entry><type>uint64_t *</type></entry> + </row> + + <row> + <entry><literal>d</literal></entry> + <entry><constant>SD_BUS_TYPE_DOUBLE</constant></entry> + <entry>IEEE 754 double precision floating-point</entry> + <entry><type>double *</type></entry> + </row> + + <row> + <entry><literal>s</literal></entry> + <entry><constant>SD_BUS_TYPE_STRING</constant></entry> + <entry>UTF-8 string</entry> + <entry><type>const char **</type></entry> + </row> + + <row> + <entry><literal>o</literal></entry> + <entry><constant>SD_BUS_TYPE_OBJECT_PATH</constant></entry> + <entry>D-Bus object path string</entry> + <entry><type>const char **</type></entry> + </row> + + <row> + <entry><literal>g</literal></entry> + <entry><constant>SD_BUS_TYPE_SIGNATURE</constant></entry> + <entry>D-Bus signature string</entry> + <entry><type>const char **</type></entry> + </row> + + <row> + <entry><literal>h</literal></entry> + <entry><constant>SD_BUS_TYPE_UNIX_FD</constant></entry> + <entry>UNIX file descriptor</entry> + <entry><type>int *</type></entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + If there is no object of the specified type at the current position in the + message, an error is returned. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para> + On success, <function>sd_bus_message_read_basic()</function> returns a positive integer. + If the end of the currently opened array has been reached, it returns 0. + On failure, it returns a negative errno-style error code. + </para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified type string is invalid or the message parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The message does not contain the specified type at current position. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADMSG</constant></term> + + <listitem><para>The message cannot be parsed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_read_strv.xml b/man/sd_bus_message_read_strv.xml new file mode 100644 index 0000000..a90ae84 --- /dev/null +++ b/man/sd_bus_message_read_strv.xml @@ -0,0 +1,90 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_read_strv"> + + <refentryinfo> + <title>sd_bus_message_read_strv</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_read_strv</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_read_strv</refname> + + <refpurpose>Access an array of strings in a message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_read_strv</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char ***<parameter>l</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_read_strv()</function> gives access to an array of strings in message + <parameter>m</parameter>. The "read pointer" in the message must be right before an array of strings. On + success, a pointer to the <constant>NULL</constant>-terminated array of strings is returned in the output + parameter <parameter>l</parameter>. Note that ownership of this array is transferred to the caller. + Hence, the caller is responsible for freeing this array and its contents.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_message_read_strv()</function> returns a non-negative integer. On + failure, it returns 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><parameter>m</parameter> or <parameter>l</parameter> are <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message is not sealed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADMSG</constant></term> + + <listitem><para>The message cannot be parsed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_rewind.xml b/man/sd_bus_message_rewind.xml new file mode 100644 index 0000000..5640d28 --- /dev/null +++ b/man/sd_bus_message_rewind.xml @@ -0,0 +1,88 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_rewind" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_rewind</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_rewind</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_rewind</refname> + + <refpurpose>Return to beginning of message or current container</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_rewind</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>int <parameter>complete</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_rewind()</function> moves the "read pointer" in the message + <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> + + <refsect1> + <title>Return Value</title> + + <para> + On success, this function returns 0 or a positive integer. The value is zero if the current + container or whole message in case no container is open is empty, and positive otherwise. On + failure, it returns 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>The <parameter>m</parameter> parameter is <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message <parameter>m</parameter> has not been sealed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_seal.xml b/man/sd_bus_message_seal.xml new file mode 100644 index 0000000..53d3a21 --- /dev/null +++ b/man/sd_bus_message_seal.xml @@ -0,0 +1,106 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_seal" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_seal</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_seal</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_seal</refname> + + <refpurpose>Prepare a D-Bus message for transmission</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_seal</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>uint64_t <parameter>cookie</parameter></paramdef> + <paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_seal()</function> finishes the message <parameter>m</parameter> + and prepares it for transmission using + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + <parameter>cookie</parameter> specifies the identifier used to match the message reply to its + corresponding request. <parameter>timeout_usec</parameter> specifies the maximum time in + microseconds to wait for a reply to arrive.</para> + + <para>Note that in most scenarios, it's not necessary to call this function directly. + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry> + will seal any given messages if they have not been sealed yet.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this function returns a non-negative integer. On failure, it returns 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>The <parameter>m</parameter> parameter is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADMSG</constant></term> + + <listitem><para>The D-Bus message <parameter>m</parameter> has open containers. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMSG</constant></term> + + <listitem><para>The D-Bus message <parameter>m</parameter> is a reply but its type + signature does not match the return type signature of its corresponding member in the + object vtable.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_sensitive.xml b/man/sd_bus_message_sensitive.xml new file mode 100644 index 0000000..f953965 --- /dev/null +++ b/man/sd_bus_message_sensitive.xml @@ -0,0 +1,85 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_sensitive" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_sensitive</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_sensitive</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_sensitive</refname> + + <refpurpose>Mark a message object as containing sensitive data</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_sensitive</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_sensitive()</function> marks an allocated bus message as containing + sensitive data. This ensures that the message data is carefully removed from memory (specifically, + overwritten with zero bytes) when released. It is recommended to mark all incoming and outgoing messages + like this that contain security credentials and similar data that should be dealt with carefully. Note + that it is not possible to unmark messages like this, it's a one way operation. If a message is already + marked sensitive and then marked sensitive a second time the message remains marked so and no further + operation is executed.</para> + + <para>As a safety precaution all messages that are created as reply to messages that are marked sensitive + are also implicitly marked so.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this functions return 0 or a positive integer. On failure, it returns 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>The <parameter>message</parameter> parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_set_destination.xml b/man/sd_bus_message_set_destination.xml new file mode 100644 index 0000000..6308b5e --- /dev/null +++ b/man/sd_bus_message_set_destination.xml @@ -0,0 +1,151 @@ +<!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-or-later --> + +<refentry id="sd_bus_message_set_destination" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_message_set_destination</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_set_destination</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_set_destination</refname> + <refname>sd_bus_message_get_destination</refname> + <refname>sd_bus_message_get_path</refname> + <refname>sd_bus_message_get_interface</refname> + <refname>sd_bus_message_get_member</refname> + <refname>sd_bus_message_set_sender</refname> + <refname>sd_bus_message_get_sender</refname> + + <refpurpose>Set and query bus message addressing information</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_set_destination</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_message_get_destination</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_message_get_path</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_message_get_interface</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_message_get_member</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_set_sender</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>const char *<parameter>sender</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_message_get_sender</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_set_destination()</function> sets the destination service name + for the specified bus message object. The specified name must be a valid unique or well-known + service name.</para> + + <para><function>sd_bus_message_get_destination()</function>, + <function>sd_bus_message_get_path()</function>, + <function>sd_bus_message_get_interface()</function>, and + <function>sd_bus_message_get_member()</function> return the destination, path, interface, and + member fields from <parameter>message</parameter> header. The return value will be + <constant>NULL</constant> is <parameter>message</parameter> is <constant>NULL</constant> or the + message is of a type that doesn't use those fields or the message doesn't have them set. See + <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more discussion of those values.</para> + + <para><function>sd_bus_message_set_sender()</function> sets the sender service name for the specified bus message + object. The specified name must be a valid unique or well-known service name. This function is useful only for + messages to send on direct connections as for connections to bus brokers the broker will fill in the destination + field anyway, and the sender field set by original sender is ignored.</para> + + <para><function>sd_bus_message_get_sender()</function> returns the sender field from + <parameter>message</parameter>.</para> + + <para>When a string is returned, it is a pointer to internal storage, and may not be modified or + freed. It is only valid as long as the <parameter>message</parameter> remains referenced and + this field hasn't been changed by a different call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On failure, these calls 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>The <parameter>message</parameter> parameter or the output parameter are + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>For <function>sd_bus_message_set_destination()</function> and + <function>sd_bus_message_set_sender()</function>, the message is already sealed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EEXIST</constant></term> + + <listitem><para>The message already has a destination or sender field set.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_set_expect_reply.xml b/man/sd_bus_message_set_expect_reply.xml new file mode 100644 index 0000000..dccb99a --- /dev/null +++ b/man/sd_bus_message_set_expect_reply.xml @@ -0,0 +1,147 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_set_expect_reply" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_message_set_expect_reply</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_set_expect_reply</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_set_expect_reply</refname> + <refname>sd_bus_message_get_expect_reply</refname> + <refname>sd_bus_message_set_auto_start</refname> + <refname>sd_bus_message_get_auto_start</refname> + <refname>sd_bus_message_set_allow_interactive_authorization</refname> + <refname>sd_bus_message_get_allow_interactive_authorization</refname> + + <refpurpose>Set and query bus message metadata</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_set_expect_reply</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_expect_reply</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_set_auto_start</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_auto_start</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_set_allow_interactive_authorization</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_get_allow_interactive_authorization</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_set_expect_reply()</function> sets or clears the + <constant>NO_REPLY_EXPECTED</constant> flag on the message <parameter>m</parameter>. This flag matters + only for method call messages and is used to specify that no method return or error reply is expected. + It is ignored for other types. Thus, for a method call message, calling + <programlisting>sd_bus_message_set_expect_reply(…, 0)</programlisting> sets the flag and suppresses the + reply.</para> + + <para><function>sd_bus_message_get_expect_reply()</function> checks if the + <constant>NO_REPLY_EXPECTED</constant> flag is set on the message <parameter>m</parameter>. It will + return positive if it is not set, and zero if it is.</para> + + <para><function>sd_bus_message_set_auto_start()</function> sets or clears the + <constant>NO_AUTO_START</constant> flag on the message <parameter>m</parameter>. When the flag is set, + the bus must not launch an owner for the destination name in response to this message. Calling + <programlisting>sd_bus_message_set_auto_start(…, 0)</programlisting> sets the flag.</para> + + <para><function>sd_bus_message_get_auto_start()</function> checks if the + <constant>NO_AUTO_START</constant> flag is set on the message <parameter>m</parameter>. It will return + positive if it is not set, and zero if it is.</para> + + <para><function>sd_bus_message_set_allow_interactive_authorization()</function> sets or clears the + <constant>ALLOW_INTERACTIVE_AUTHORIZATION</constant> flag on the message <parameter>m</parameter>. + Setting this flag informs the receiver that the caller is prepared to wait for interactive authorization + via polkit or a similar framework. Note that setting this flag does not guarantee that the receiver will + actually perform interactive authorization. Also, make sure to set a suitable message timeout when using + this flag since interactive authorization could potentially take a long time as it depends on user input. + If <parameter>b</parameter> is non-zero, the flag is set.</para> + + <para><function>sd_bus_message_get_allow_interactive_authorization()</function> checks if the + <constant>ALLOW_INTERACTIVE_AUTHORIZATION</constant> flag is set on the message <parameter>m</parameter>. + It will return a positive integer if the flag is set. Otherwise, it returns zero.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>The <parameter>message</parameter> parameter is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem> + <para>The message <parameter>message</parameter> is sealed when trying to set a flag.</para> + + <para>The message <parameter>message</parameter> has wrong type.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_message_skip.xml b/man/sd_bus_message_skip.xml new file mode 100644 index 0000000..7a227c4 --- /dev/null +++ b/man/sd_bus_message_skip.xml @@ -0,0 +1,108 @@ +<?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-or-later --> + +<refentry id="sd_bus_message_skip" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_message_skip</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_skip</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_skip</refname> + + <refpurpose>Skip elements in a bus message</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_message_skip</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char* <parameter>types</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_skip()</function> is somewhat similar to + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but instead of reading the contents of the message, it only moves the "read pointer". Subsequent + read operations will read the elements that are after the elements that were skipped.</para> + + <para>The <parameter>types</parameter> argument has the same meaning as in + <function>sd_bus_message_read()</function>. It may also be <constant>NULL</constant>, to skip a + single element of any type.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_message_skip()</function> returns 0 or a positive integer. On + failure, it returns 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>The <parameter>m</parameter> parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADMSG</constant></term> + + <listitem><para>The message cannot be parsed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message is not sealed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The message end has been reached and the requested elements cannot be read. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_message_verify_type.xml b/man/sd_bus_message_verify_type.xml new file mode 100644 index 0000000..9f3a347 --- /dev/null +++ b/man/sd_bus_message_verify_type.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-or-later --> + +<refentry id="sd_bus_message_verify_type" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_message_verify_type</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_message_verify_type</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_message_verify_type</refname> + + <refpurpose>Check if the message has specified type at the current location</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_message_verify_type</funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>const char* <parameter>contents</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_message_verify_type()</function> checks if the complete type at the + current location in the message <parameter>m</parameter> matches the specified + <parameter>type</parameter> and <parameter>contents</parameter>. If non-zero, parameter + <parameter>type</parameter> must be one of the types specified in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + If non-null, parameter <parameter>contents</parameter> must be a valid sequence of complete + types. If both <parameter>type</parameter> and <parameter>contents</parameter> are specified + <parameter>type</parameter> must be a container type.</para> + + <para>If <parameter>type</parameter> is specified, the type in the message must match. If + <parameter>contents</parameter> is specified, the type in the message must be a container type + with this signature.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this call returns true if the type matches and zero if not (the message + <parameter>m</parameter> contains different data or the end of the message has been reached). On + failure, it returns 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><parameter>m</parameter> or both <parameter>type</parameter> and + <parameter>contents</parameter> are <constant>NULL</constant>.</para> + + <para>Arguments do not satisfy other constraints listed above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message <parameter>m</parameter> is not sealed. + </para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_negotiate_fds.xml b/man/sd_bus_negotiate_fds.xml new file mode 100644 index 0000000..a4893b6 --- /dev/null +++ b/man/sd_bus_negotiate_fds.xml @@ -0,0 +1,163 @@ +<?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-or-later --> + +<refentry id="sd_bus_negotiate_fds" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_negotiate_fds</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_negotiate_fds</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_negotiate_fds</refname> + <refname>sd_bus_negotiate_timestamp</refname> + <refname>sd_bus_negotiate_creds</refname> + <refname>sd_bus_get_creds_mask</refname> + + <refpurpose>Control feature negotiation on bus connections</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_negotiate_fds</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_negotiate_timestamp</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_negotiate_creds</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + <paramdef>uint64_t <parameter>mask</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_creds_mask</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t *<parameter>mask</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_negotiate_fds()</function> controls whether file descriptor passing shall be + negotiated for the specified bus connection. It takes a bus object and a boolean, which, when true, + enables file descriptor passing, and, when false, disables it. Note that not all transports and servers + support file descriptor passing. In particular, networked transports generally do not support file + descriptor passing. To find out whether file descriptor passing is available after negotiation, use + <citerefentry><refentrytitle>sd_bus_can_send</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and pass <constant>SD_BUS_TYPE_UNIX_FD</constant>. Note that file descriptor passing is always enabled + for both sending and receiving or for neither, but never only in one direction. By default, file + descriptor passing is negotiated for all connections.</para> + + <para><function>sd_bus_negotiate_timestamp()</function> controls whether implicit sender timestamps shall + be attached automatically to all incoming messages. Takes a bus object and a boolean, which, when true, + enables timestamping, and, when false, disables it. Use + <citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to query the timestamps of incoming messages. If negotiation is disabled or not supported, these calls + will fail with <constant>-ENODATA</constant>. Note that currently no transports support timestamping of + messages. By default, message timestamping is not negotiated for connections.</para> + + <para><function>sd_bus_negotiate_creds()</function> controls whether and which implicit sender + credentials shall be attached automatically to all incoming messages. Takes a bus object and a boolean + indicating whether to enable or disable the credential parts encoded in the bit mask value argument. Note + that not all transports support attaching sender credentials to messages, or do not support all types of + sender credential parameters, or might suppress them under certain circumstances for individual messages. + Specifically, dbus1 only supports <constant>SD_BUS_CREDS_UNIQUE_NAME</constant>. The sender credentials + are suitable for authorization decisions. By default, only + <constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant> and <constant>SD_BUS_CREDS_UNIQUE_NAME</constant> are + enabled. In fact, these two credential fields are always sent along and cannot be turned off.</para> + + <para><function>sd_bus_get_creds_mask()</function> returns the set of sender credentials that was + negotiated to be attached to all incoming messages in <parameter>mask</parameter>. This value is an + upper boundary only. Hence, always make sure to explicitly check which credentials are attached to a + specific message before using it.</para> + + <para>The <function>sd_bus_negotiate_fds()</function> function may be called only before the connection + has been started with + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Both + <function>sd_bus_negotiate_timestamp()</function> and <function>sd_bus_negotiate_creds()</function> may + also be called after a connection has been set up. Note that, when operating on a connection that is + shared between multiple components of the same program (for example via + <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>), it + is highly recommended to only enable additional per message metadata fields, but never disable them + again, in order not to disable functionality needed by other components.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>-EPERM</constant></term> + + <listitem><para>The bus connection has already been started.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An argument is invalid.</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> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_can_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_new.xml b/man/sd_bus_new.xml new file mode 100644 index 0000000..355b34b --- /dev/null +++ b/man/sd_bus_new.xml @@ -0,0 +1,199 @@ +<?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-or-later --> + +<refentry id="sd_bus_new" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_new</refname> + <refname>sd_bus_ref</refname> + <refname>sd_bus_unref</refname> + <refname>sd_bus_unrefp</refname> + <refname>sd_bus_close_unref</refname> + <refname>sd_bus_close_unrefp</refname> + <refname>sd_bus_flush_close_unref</refname> + <refname>sd_bus_flush_close_unrefp</refname> + + <refpurpose>Create a new bus object and create or destroy references to it</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_new</function></funcdef> + <paramdef>sd_bus **<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_ref</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_unref</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_close_unref</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_flush_close_unref</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_unrefp</function></funcdef> + <paramdef>sd_bus **<parameter>busp</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_close_unrefp</function></funcdef> + <paramdef>sd_bus **<parameter>busp</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_flush_close_unrefp</function></funcdef> + <paramdef>sd_bus **<parameter>busp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_new()</function> creates a new bus + object. This object is reference-counted, and will be destroyed + when all references are gone. Initially, the caller of this + function owns the sole reference and the bus object will not be + connected to any bus. To connect it to a bus, make sure + to set an address with + <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or a related call, and then start the connection with + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>In most cases, it is better to use + <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or related calls instead of the more low-level <function>sd_bus_new()</function> and + <function>sd_bus_start()</function>. The higher-level functions not only allocate a bus object but also + start the connection to a well-known bus in a single function call.</para> + + <para><function>sd_bus_ref()</function> increases the reference + counter of <parameter>bus</parameter> by one.</para> + + <para><function>sd_bus_unref()</function> decreases the reference + counter of <parameter>bus</parameter> by one. Once the reference + count has dropped to zero, <parameter>bus</parameter> is destroyed + and cannot be used anymore, so further calls to + <function>sd_bus_ref()</function> or + <function>sd_bus_unref()</function> are illegal.</para> + + <para><function>sd_bus_unrefp()</function> is similar to + <function>sd_bus_unref()</function> but takes a pointer to a + pointer to an <type>sd_bus</type> object. 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. Use a declaration like the following, in order to + allocate a bus object that is freed automatically as the code + block is left:</para> + + <programlisting>{ + __attribute__((cleanup(sd_bus_unrefp))) sd_bus *bus = NULL; + int r; + … + r = sd_bus_default(&bus); + if (r < 0) + fprintf(stderr, "Failed to allocate bus: %s\n", strerror(-r)); + … +}</programlisting> + + <para><function>sd_bus_ref()</function> and <function>sd_bus_unref()</function> + execute no operation if the passed in bus object address is + <constant>NULL</constant>. <function>sd_bus_unrefp()</function> will first + dereference its argument, which must not be <constant>NULL</constant>, and will + execute no operation if <emphasis>that</emphasis> is <constant>NULL</constant>. + </para> + + <para><function>sd_bus_close_unref()</function> is similar to <function>sd_bus_unref()</function>, but + first executes + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + ensuring that the connection is terminated before the reference to the connection is dropped and possibly + the object freed.</para> + + <para><function>sd_bus_flush_close_unref()</function> is similar to <function>sd_bus_unref()</function>, + but first executes + <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry> as well + as <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + ensuring that any pending messages are synchronously flushed out before the reference to the connection + is dropped and possibly the object freed. This call is particularly useful immediately before exiting + from a program as it ensures that any pending outgoing messages are written out, and unprocessed but + queued incoming messages released before the connection is terminated and released.</para> + + <para><function>sd_bus_close_unrefp()</function> is similar to + <function>sd_bus_close_unref()</function>, but may be used in GCC's and LLVM's Clean-up Variable + Attribute, see above. Similarly, <function>sd_bus_flush_close_unrefp()</function> is similar to + <function>sd_bus_flush_close_unref()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_new()</function> returns 0 or a + positive integer. On failure, it returns a negative errno-style + error code.</para> + + <para><function>sd_bus_ref()</function> always returns the argument. + </para> + + <para><function>sd_bus_unref()</function> and <function>sd_bus_flush_close_unref()</function> always return + <constant>NULL</constant>.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_open_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_open_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_path_encode.xml b/man/sd_bus_path_encode.xml new file mode 100644 index 0000000..5cdb1d7 --- /dev/null +++ b/man/sd_bus_path_encode.xml @@ -0,0 +1,153 @@ +<?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-or-later --> + +<refentry id="sd_bus_path_encode" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_path_encode</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_path_encode</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_path_encode</refname> + <refname>sd_bus_path_encode_many</refname> + <refname>sd_bus_path_decode</refname> + <refname>sd_bus_path_decode_many</refname> + + <refpurpose>Convert an external identifier into an object path and back</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_path_encode</function></funcdef> + <paramdef>const char *<parameter>prefix</parameter></paramdef> + <paramdef>const char *<parameter>external_id</parameter></paramdef> + <paramdef>char **<parameter>ret_path</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_path_encode_many</function></funcdef> + <paramdef>char **<parameter>out</parameter></paramdef> + <paramdef>const char *<parameter>path_template</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_path_decode</function></funcdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>prefix</parameter></paramdef> + <paramdef>char **<parameter>ret_external_id</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_path_decode_many</function></funcdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>path_template</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_path_encode()</function> and + <function>sd_bus_path_decode()</function> convert external + identifier strings into object paths and back. These functions are + useful to map application-specific string identifiers of any kind + into bus object paths in a simple, reversible and safe way.</para> + + <para><function>sd_bus_path_encode()</function> takes a bus path + prefix and an external identifier string as arguments, plus a + place to store the returned bus path string. The bus path prefix + must be a valid bus path, starting with a slash + <literal>/</literal>, and not ending in one. The external + identifier string may be in any format, may be the empty string, + and has no restrictions on the charset — however, it must + always be <constant>NUL</constant>-terminated. The returned string + will be the concatenation of the bus path prefix plus an escaped + version of the external identifier string. This operation may be + reversed with <function>sd_bus_path_decode()</function>. It is + recommended to only use external identifiers that generally + require little escaping to be turned into valid bus path + identifiers (for example, by sticking to a 7-bit ASCII character + set), in order to ensure the resulting bus path is still short and + easily processed.</para> + + <para><function>sd_bus_path_decode()</function> reverses the + operation of <function>sd_bus_path_encode()</function> and thus + regenerates an external identifier string from a bus path. It + takes a bus path and a prefix string, plus a place to store the + returned external identifier string. If the bus path does not + start with the specified prefix, 0 is returned and the returned + string is set to <constant>NULL</constant>. Otherwise, the + string following the prefix is unescaped and returned in the + external identifier string.</para> + + <para>The escaping used will replace all characters which are + invalid in a bus object path by <literal>_</literal>, followed by a + hexadecimal value. As a special case, the empty string will be + replaced by a lone <literal>_</literal>.</para> + + <para><function>sd_bus_path_encode_many()</function> works like + its counterpart <function>sd_bus_path_encode()</function>, but + takes a path template as argument and encodes multiple labels + according to its embedded directives. For each + <literal>%</literal> character found in the template, the caller + must provide a string via varargs, which will be encoded and + embedded at the position of the <literal>%</literal> character. + Any other character in the template is copied verbatim into the + encoded path.</para> + + <para><function>sd_bus_path_decode_many()</function> does the + reverse of <function>sd_bus_path_encode_many()</function>. It + decodes the passed object path according to the given + path template. For each <literal>%</literal> character in the + template, the caller must provide an output storage + (<literal>char **</literal>) via varargs. The decoded label + will be stored there. Each <literal>%</literal> character will + only match the current label. It will never match across labels. + Furthermore, only a single directive is allowed per label. + If <constant>NULL</constant> is passed as output storage, the + label is verified but not returned to the caller.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_path_encode()</function> + returns positive or 0, and a valid bus path in the return + argument. On success, <function>sd_bus_path_decode()</function> + returns a positive value if the prefixed matched, or 0 if it + did not. If the prefix matched, the external identifier is returned + in the return parameter. If it did not match, <constant>NULL</constant> is returned in + the return parameter. On failure, a negative errno-style error + number is returned by either function. The returned strings must + be + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>'d + by the caller.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_process.xml b/man/sd_bus_process.xml new file mode 100644 index 0000000..09b3c50 --- /dev/null +++ b/man/sd_bus_process.xml @@ -0,0 +1,133 @@ +<?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-or-later + + Copyright © 2016 Julian Orth +--> + +<refentry id="sd_bus_process" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_process</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_process</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_process</refname> + + <refpurpose>Drive the connection</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_process</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>ret</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_process()</function> drives the connection between the client and the message bus. That is, + it handles connecting, authentication, and message processing. When invoked pending I/O work is executed, and + queued incoming messages are dispatched to registered callbacks. Each time it is invoked a single operation is + executed. It returns zero when no operations were pending and positive if a message was processed. When zero is + returned the caller should synchronously poll for I/O events before calling into + <function>sd_bus_process()</function> again. For that either user the simple, synchronous + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> call, or hook up + the bus connection object to an external or manual event loop using + <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_process()</function> processes at most one incoming message per call. If the parameter + <parameter>ret</parameter> is not <constant>NULL</constant> and the call processed a message, + <parameter>*ret</parameter> is set to this message. The caller owns a reference to this message and should call + <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> when the + message is no longer needed. If <parameter>ret</parameter> is not <constant>NULL</constant>, progress was made, but no message was + processed, <parameter>*ret</parameter> is set to <constant>NULL</constant>.</para> + + <para>If the bus object is connected to an + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> event loop (with + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>), it is not + necessary to call <function>sd_bus_process()</function> directly as it is invoked automatically when + necessary.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>If progress was made, a positive integer is returned. If no progress was made, 0 is returned. If an + error occurs, a negative <varname>errno</varname>-style error code is returned.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid bus object was passed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was allocated in a parent process and is being reused in a child + process after <function>fork()</function>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus connection has been terminated already.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECONNRESET</constant></term> + + <listitem><para>The bus connection has been terminated just now.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para>This function is already being called, i.e. <function>sd_bus_process()</function> + has been called from a callback function that itself was called by + <function>sd_bus_process()</function>.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_query_sender_creds.xml b/man/sd_bus_query_sender_creds.xml new file mode 100644 index 0000000..d0769e8 --- /dev/null +++ b/man/sd_bus_query_sender_creds.xml @@ -0,0 +1,133 @@ +<?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-or-later --> + +<refentry id="sd_bus_query_sender_creds" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_query_sender_creds</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_query_sender_creds</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_query_sender_creds</refname> + <refname>sd_bus_query_sender_privilege</refname> + + <refpurpose>Query bus message sender credentials/privileges</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_query_sender_creds</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>uint64_t <parameter>mask</parameter></paramdef> + <paramdef>sd_bus_creds **<parameter>creds</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_error* <function>sd_bus_query_sender_privilege</function></funcdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>int <parameter>capability</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_query_sender_creds()</function> returns the credentials of the message + <parameter>m</parameter>. The <parameter>mask</parameter> parameter is a combo of + <constant index='false'>SD_BUS_CREDS_*</constant> flags that indicate which credential info the caller is + interested in. See + <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a list of possible flags. First, this message checks if the requested credentials are attached to the + message itself. If not but the message contains the pid of the sender, this function tries to figure out + the missing credentials via other means (starting from the pid). If the pid isn't available but the + message has a sender, this function calls + <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to get the requested credentials. If the message has no sender (when a direct connection is used), this + function calls + <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to get the requested credentials. On success, the requested credentials are stored in + <parameter>creds</parameter>. Ownership of the credentials object in <parameter>creds</parameter> is + transferred to the caller and should be freed by calling + <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_query_sender_privilege()</function> checks if the message <parameter>m</parameter> + has the requested privileges. If <parameter>capability</parameter> is a non-negative integer, this + function checks if the message has the capability with the same value. See + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a list of capabilities. If <parameter>capability</parameter> is a negative integer, this function + returns whether the sender of the message runs as the same user as the receiver of the message, or if the + sender of the message runs as root and the receiver of the message does not run as root. On success and + if the message has the requested privileges, this function returns a positive integer. If the message + does not have the requested privileges, this function returns zero.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>The message <parameter>m</parameter> or an output parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus of <parameter>m</parameter> is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus of <parameter>m</parameter> was created in a different process. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The message <parameter>m</parameter> is not sealed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_reply_method_error.xml b/man/sd_bus_reply_method_error.xml new file mode 100644 index 0000000..c9553a0 --- /dev/null +++ b/man/sd_bus_reply_method_error.xml @@ -0,0 +1,176 @@ +<?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-or-later --> + +<refentry id="sd_bus_reply_method_error" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_reply_method_error</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_reply_method_error</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_reply_method_error</refname> + <refname>sd_bus_reply_method_errorf</refname> + <refname>sd_bus_reply_method_errorfv</refname> + <refname>sd_bus_reply_method_errno</refname> + <refname>sd_bus_reply_method_errnof</refname> + <refname>sd_bus_reply_method_errnofv</refname> + + <refpurpose>Reply with an error to a D-Bus method call</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_reply_method_error</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_reply_method_errorf</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_reply_method_errorfv</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_reply_method_errno</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const sd_bus_error *<parameter>p</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_reply_method_errnof</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_reply_method_errnofv</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>int <parameter>error</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <function>sd_bus_reply_method_error()</function> function sends an error reply to the + <parameter>call</parameter> message. The error structure <parameter>e</parameter> specifies the + error to send, and is used as described in + <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If no reply is expected to <parameter>call</parameter>, this function succeeds without sending a + reply.</para> + + <para>The <function>sd_bus_reply_method_errorf()</function> is to + <function>sd_bus_reply_method_error()</function> what + <function>sd_bus_message_new_method_errorf()</function> is to + <function>sd_bus_message_new_method_error()</function>.</para> + + <para>The <function>sd_bus_reply_method_errno()</function> is to + <function>sd_bus_reply_method_error()</function> what + <function>sd_bus_message_new_method_errno()</function> is to + <function>sd_bus_message_new_method_error()</function>.</para> + + <para>The <function>sd_bus_reply_method_errnof()</function> is to + <function>sd_bus_reply_method_error()</function> what + <function>sd_bus_message_new_method_errnof()</function> is to + <function>sd_bus_message_new_method_error()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>This function returns a non-negative integer if the error reply was successfully sent or + if <parameter>call</parameter> does not expect a reply. On failure, it returns 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>The input parameter <parameter>call</parameter> is + <constant>NULL</constant>.</para> + + <para>Message <parameter>call</parameter> is not a method call message.</para> + + <para>Message <parameter>call</parameter> is not attached to a bus.</para> + + <para>The error parameter <parameter>e</parameter> to + <function>sd_bus_reply_method_error()</function> is not set, see + <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message <parameter>call</parameter> has been sealed. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus to which message <parameter>call</parameter> is attached is not + connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + + <para>In addition, any error returned by + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be returned.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_reply_method_return.xml b/man/sd_bus_reply_method_return.xml new file mode 100644 index 0000000..76e4ade --- /dev/null +++ b/man/sd_bus_reply_method_return.xml @@ -0,0 +1,121 @@ +<?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-or-later --> + +<refentry id="sd_bus_reply_method_return" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_reply_method_return</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_reply_method_return</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_reply_method_return</refname> + <refname>sd_bus_reply_method_returnv</refname> + + <refpurpose>Reply to a D-Bus method call</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int sd_bus_reply_method_return</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int sd_bus_reply_method_returnv</funcdef> + <paramdef>sd_bus_message *<parameter>call</parameter></paramdef> + <paramdef>const char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_reply_method_return()</function> sends a reply to the + <parameter>call</parameter> message. The type string <parameter>types</parameter> and the + arguments that follow it must adhere to the format described in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If no reply is expected to <parameter>call</parameter>, this function succeeds without sending a + reply.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this function returns a non-negative integer. On failure, it returns 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>The input parameter <parameter>call</parameter> is + <constant>NULL</constant>.</para> + + <para>Message <parameter>call</parameter> is not a method call message. + </para> + + <para>Message <parameter>call</parameter> is not attached to a bus.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message <parameter>call</parameter> has been sealed. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus to which message <parameter>call</parameter> is attached is not + connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + + <para>In addition, any error returned by + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be returned.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_request_name.xml b/man/sd_bus_request_name.xml new file mode 100644 index 0000000..ea4ea22 --- /dev/null +++ b/man/sd_bus_request_name.xml @@ -0,0 +1,210 @@ +<?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-or-later --> + +<refentry id="sd_bus_request_name" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_request_name</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_request_name</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_request_name</refname> + <refname>sd_bus_request_name_async</refname> + <refname>sd_bus_release_name</refname> + <refname>sd_bus_release_name_async</refname> + <refpurpose>Request or release a well-known service name on a bus</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/> + + <funcprototype> + <funcdef>int <function>sd_bus_request_name</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>uint64_t <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_request_name_async</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>uint64_t <parameter>flags</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_release_name</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_release_name_async</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <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 zero or + more of the following flags:</para> + + <variablelist> + <varlistentry> + <term><constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant></term> + + <listitem><para>After acquiring the name successfully, permit other peers to take over the name when they try + to acquire it with the <constant>SD_BUS_NAME_REPLACE_EXISTING</constant> flag set. If + <constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant> is not set on the original request, such a request by other + peers will be denied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_BUS_NAME_REPLACE_EXISTING</constant></term> + + <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> + <term><constant>SD_BUS_NAME_QUEUE</constant></term> + + <listitem><para>Queue the acquisition of the name when the name is already taken.</para></listitem> + </varlistentry> + </variablelist> + + <para><function>sd_bus_request_name()</function> operates in a synchronous fashion: a message requesting the name + is sent to the bus broker, and the call waits until the broker responds.</para> + + <para><function>sd_bus_request_name_async()</function> is an asynchronous version of + <function>sd_bus_release_name()</function>. Instead of waiting for the request to complete, the request message is + enqueued. The specified <parameter>callback</parameter> will be called when the broker's response is received. If + the parameter is specified as <constant>NULL</constant> a default implementation is used instead which will + terminate the connection when the name cannot be acquired. The function returns a slot object in its + <parameter>slot</parameter> parameter — if it is passed as non-<constant>NULL</constant> — which may be used as a + reference to the name request operation. Use + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> to destroy + this reference. Note that destroying the reference will not unregister the name, but simply ensure the specified + callback is no longer called.</para> + + <para><function>sd_bus_release_name()</function> releases an acquired well-known name. It takes a bus connection + and a valid bus name as parameters. This function operates synchronously, sending a release request message to the + bus broker and waiting for it to reply.</para> + + <para><function>sd_bus_release_name_async()</function> is an asynchronous version of + <function>sd_bus_release_name()</function>. The specified <parameter>callback</parameter> function is called when + the name has been released successfully. If specified as <constant>NULL</constant> a generic implementation is used + that ignores the result of the operation. As above, the <parameter>slot</parameter> (if + non-<constant>NULL</constant>) is set to an object that may be used to reference the operation.</para> + + <para>These functions are supported only on bus connections, i.e. connections to a bus broker and not on direct + connections.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On failure, these calls return a negative errno-style + error code.</para> + + <para>If <constant>SD_BUS_NAME_QUEUE</constant> is specified, <function>sd_bus_request_name()</function> will return + 0 when the name is already taken by another peer and the client has been added to the queue for the name. In that + case, the caller can subscribe to <literal>NameOwnerChanged</literal> signals to be notified when the name is + successfully acquired. <function>sd_bus_request_name()</function> returns > 0 when the name has immediately + been acquired successfully.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EALREADY</constant></term> + + <listitem><para>The caller already is the owner of the specified name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EEXIST</constant></term> + + <listitem><para>The name has already been acquired by a different peer, and SD_BUS_NAME_REPLACE_EXISTING was + not specified or the other peer did not specify SD_BUS_NAME_ALLOW_REPLACEMENT while acquiring the + name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESRCH</constant></term> + + <listitem><para>It was attempted to release a name that is currently not registered on the + bus.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EADDRINUSE</constant></term> + + <listitem><para>It was attempted to release a name that is owned by a different peer on the + bus.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>A specified parameter is invalid. This is also generated when the requested name is + a special service name reserved by the D-Bus specification, or when the operation is requested on a + connection that does not refer to a bus.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus connection has been disconnected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process than the current + one.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_send.xml b/man/sd_bus_send.xml new file mode 100644 index 0000000..c4c623a --- /dev/null +++ b/man/sd_bus_send.xml @@ -0,0 +1,158 @@ +<?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-or-later --> + +<refentry id="sd_bus_send" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_send</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_send</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_send</refname> + <refname>sd_bus_send_to</refname> + + <refpurpose>Queue a D-Bus message for transfer</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_send</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>uint64_t *<parameter>cookie</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_send_to</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_bus_message *<parameter>m</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>uint64_t *<parameter>cookie</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_send()</function> queues the bus message object <parameter>m</parameter> for + transfer. If <parameter>bus</parameter> is <constant>NULL</constant>, the bus that + <parameter>m</parameter> is attached to is used. <parameter>bus</parameter> only needs to be set when the + message is sent to a different bus than the one it's attached to, for example when forwarding messages. + If the output parameter <parameter>cookie</parameter> is not <constant>NULL</constant>, it is set to the + message identifier. This value can later be used to match incoming replies to their corresponding + messages. If <parameter>cookie</parameter> is set to <constant>NULL</constant> and the message is not + sealed, <function>sd_bus_send()</function> assumes the message <parameter>m</parameter> doesn't expect a + reply and adds the necessary headers to indicate this.</para> + + <para>Note that in most scenarios, <function>sd_bus_send()</function> should not be called + directly. Instead, use higher level functions such as + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + <citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry> + which call <function>sd_bus_send()</function> internally.</para> + + <para><function>sd_bus_send_to()</function> is a shorthand for sending a message to a specific + destination. It's main use case is to simplify sending unicast signal messages (signals that only have a + single receiver). It's behavior is similar to calling + <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry> + followed by calling <function>sd_bus_send()</function>.</para> + + <para><function>sd_bus_send()</function>/<function>sd_bus_send_to()</function> will write the message + directly to the underlying transport (e.g. kernel socket buffer) if possible. If the connection is not + set up fully yet the message is queued locally. If the transport buffers are congested any unwritten + message data is queued locally, too. If the connection has been closed or is currently being closed the + call fails. + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> should + be invoked to write out any queued message data to the transport.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The input parameter <parameter>m</parameter> is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>The bus connection does not support sending file descriptors. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was allocated in a parent process and is being reused in a child + process after <function>fork()</function>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOBUFS</constant></term> + + <listitem><para>The bus connection's write queue is full.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The input parameter <parameter>bus</parameter> is + <constant>NULL</constant> or the bus is not connected.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECONNRESET</constant></term> + + <listitem><para>The bus connection was closed while waiting for the response. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_address.xml b/man/sd_bus_set_address.xml new file mode 100644 index 0000000..21742bd --- /dev/null +++ b/man/sd_bus_set_address.xml @@ -0,0 +1,188 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_address" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_address</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_address</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_address</refname> + <refname>sd_bus_get_address</refname> + <refname>sd_bus_set_exec</refname> + + <refpurpose>Set or query the address of the bus connection</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_address</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>address</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_address</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char **<parameter>address</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_exec</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>char *const *<parameter>argv</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_address()</function> configures a list of addresses of bus brokers to try to + connect to from a subsequent + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry> call. + The argument is a <literal>;</literal>-separated list of addresses to try. Each item must be one of the + following: + </para> + + <itemizedlist> + <listitem> + <para>A unix socket address specified as + <literal>unix:guid=<replaceable>guid</replaceable>,path=<replaceable>path</replaceable></literal> or + <literal>unix:guid=<replaceable>guid</replaceable>,abstract=<replaceable>path</replaceable></literal>. + Exactly one of the <varname>path=</varname> and <varname>abstract=</varname> keys must be present, + while <varname>guid=</varname> is optional.</para> + </listitem> + + <listitem> + <para>A TCP socket address specified as + <literal>tcp:[guid=<replaceable>guid</replaceable>,][host=<replaceable>host</replaceable>][,port=<replaceable>port</replaceable>][,family=<replaceable>family</replaceable>]</literal>. + One or both of the <varname>host=</varname> and <varname>port=</varname> keys must be present, while + the rest is optional. <replaceable>family</replaceable> may be either <option>ipv4</option> or + <option>ipv6</option>.</para> + </listitem> + + <listitem> + <para>An executable to spawn specified as + <literal>unixexec:guid=<replaceable>guid</replaceable>,path=<replaceable>path</replaceable>,argv1=<replaceable>argument</replaceable>,argv2=<replaceable>argument</replaceable>,...</literal>. + The <varname>path=</varname> key must be present, while <varname>guid=</varname> is optional.</para> + </listitem> + + <listitem> + <para>A machine (container) to connect to specified as + <literal>x-machine-unix:guid=<replaceable>guid</replaceable>,machine=<replaceable>machine</replaceable>,pid=<replaceable>pid</replaceable></literal>. + Exactly one of the <varname>machine=</varname> and <varname>pid=</varname> keys must be present, + while <varname>guid=</varname> is optional. <parameter>machine</parameter> is the name of a local + container. See + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + more information about the "machine" concept. <literal>machine=.host</literal> may be used to specify + the host machine. A connection to the standard system bus socket inside of the specified machine will + be created.</para> + </listitem> + </itemizedlist> + + <para>In all cases, parameter <parameter>guid</parameter> is an identifier of the remote peer, in the + syntax accepted by + <citerefentry><refentrytitle>sd_id128_from_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If specified, the identifier returned by the peer after the connection is established will be checked and + the connection will be rejected in case of a mismatch.</para> + + <para>Note that the addresses passed to <function>sd_bus_set_address()</function> may not be verified + immediately. If they are invalid, an error may be returned e.g. from a subsequent call to + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_get_address()</function> returns any previously set addresses. In addition to + being explicitly set by <function>sd_bus_set_address()</function>, the address will also be set + automatically by + <citerefentry><refentrytitle>sd_bus_open</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + similar calls, based on environment variables or built-in defaults.</para> + + <para><function>sd_bus_set_exec()</function> is a shorthand function for setting a + <literal>unixexec</literal> address that spawns the given executable with the given arguments. + If <parameter>argv</parameter> is <constant>NULL</constant>, the given executable is spawned + without any extra arguments.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>The input parameters <parameter>bus</parameter> or <parameter>address</parameter> are <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus object <parameter>bus</parameter> could not be resolved.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The input parameter <parameter>bus</parameter> is in a wrong state + (<function>sd_bus_set_address()</function> may only be called once on a newly-created bus object).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus object <parameter>bus</parameter> was created in a different + process.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENODATA</constant></term> + + <listitem><para>The bus object <parameter>bus</parameter> has no address configured.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_close_on_exit.xml b/man/sd_bus_set_close_on_exit.xml new file mode 100644 index 0000000..cf3bbae --- /dev/null +++ b/man/sd_bus_set_close_on_exit.xml @@ -0,0 +1,108 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_close_on_exit" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_close_on_exit</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_close_on_exit</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_close_on_exit</refname> + <refname>sd_bus_get_close_on_exit</refname> + + <refpurpose>Control whether to close the bus connection during the event loop exit phase + </refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_close_on_exit</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_close_on_exit</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_close_on_exit()</function> may be used to enable or disable whether + the bus connection is automatically flushed (as in + <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + and closed (as in + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + during the exit phase of the event loop. This logic only applies to bus connections that are + attached to an + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + event loop, see + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + By default this mechanism is enabled and makes sure that any pending messages that have not been + written to the bus connection are written out when the event loop is shutting down. In some + cases this behaviour is not desirable, for example when the bus connection shall remain usable + until after the event loop exited. If <parameter>b</parameter> is true, the feature is enabled + (which is the default), otherwise disabled.</para> + + <para><function>sd_bus_get_close_on_exit()</function> may be used to query the current setting + of this feature. It returns zero when the feature is disabled, and positive if enabled.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_set_close_on_exit()</function> returns a non-negative + integer. On failure, it returns a negative errno-style error code.</para> + + <para><function>sd_bus_get_close_on_exit()</function> returns 0 if the feature is currently + disabled or a positive integer if it is enabled. On failure, it returns a negative errno-style + error code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was created in a different process.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_set_connected_signal.xml b/man/sd_bus_set_connected_signal.xml new file mode 100644 index 0000000..b2dfcf0 --- /dev/null +++ b/man/sd_bus_set_connected_signal.xml @@ -0,0 +1,109 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_connected_signal" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_connected_signal</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_connected_signal</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_connected_signal</refname> + <refname>sd_bus_get_connected_signal</refname> + + <refpurpose>Control emission of local connection establishment signal on bus connections</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_connected_signal</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_connected_signal</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_connected_signal()</function> may be used to control whether a local, synthetic + <function>Connected()</function> signal message shall be generated and enqueued for dispatching when the connection + is fully established. If the <parameter>b</parameter> parameter is zero the message is not generated (the default), + otherwise it is generated.</para> + + <para><function>sd_bus_get_connected_signal()</function> may be used to query whether this feature is enabled. It + returns zero if not, positive otherwise.</para> + + <para>The <function>Connected()</function> signal message is generated from the + <literal>org.freedesktop.DBus.Local</literal> service and interface, and + <literal>/org/freedesktop/DBus/Local</literal> object path. Use + <citerefentry><refentrytitle>sd_bus_match_signal_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> to + match on this signal.</para> + + <para>This message is particularly useful on slow transports where connections take a long time to be + established. This is especially the case when + <citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry> is + used. The signal is generated when the + <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns + positive for the first time.</para> + + <para>The <function>Connected()</function> signal corresponds with the <function>Disconnected()</function> signal + that is synthesized locally when the connection is terminated. The latter is generated unconditionally however, + unlike the former which needs to be enabled explicitly before it is generated, with + <function>sd_bus_set_connected_signal()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_match_signal_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_description.xml b/man/sd_bus_set_description.xml new file mode 100644 index 0000000..bbd3835 --- /dev/null +++ b/man/sd_bus_set_description.xml @@ -0,0 +1,246 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_description" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_description</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_description</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_description</refname> + <refname>sd_bus_get_description</refname> + <refname>sd_bus_set_anonymous</refname> + <refname>sd_bus_is_anonymous</refname> + <refname>sd_bus_set_trusted</refname> + <refname>sd_bus_is_trusted</refname> + <refname>sd_bus_set_allow_interactive_authorization</refname> + <refname>sd_bus_get_allow_interactive_authorization</refname> + <refname>sd_bus_get_scope</refname> + <refname>sd_bus_get_tid</refname> + <refname>sd_bus_get_unique_name</refname> + + <refpurpose>Set or query properties of a bus object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_description</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_description</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char **<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_anonymous</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_is_anonymous</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_trusted</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_is_trusted</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_allow_interactive_authorization</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_allow_interactive_authorization</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_scope</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char **<parameter>scope</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_tid</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>pid_t *<parameter>tid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_unique_name</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char **<parameter>unique</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_description()</function> sets the description string that is used in + logging to the specified string. The string is copied internally and freed when the bus object + is deallocated. The <parameter>description</parameter> argument may be + <constant>NULL</constant>, in which case the description is unset. This function must be called + before the bus is started.</para> + + <para><function>sd_bus_get_description()</function> returns a description string in + <parameter>description</parameter>. This string may have been previously set with + <function>sd_bus_set_description()</function> or + <citerefentry><refentrytitle>sd_bus_open_with_description</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or similar. If not set this way, a default string like <literal>system</literal> or + <literal>user</literal> will be returned for the system or user buses, and + <constant>NULL</constant> otherwise.</para> + + <para><function>sd_bus_set_anonymous()</function> enables or disables "anonymous authentication", + i.e. lack of authentication, of the bus peer. This function must be called before the bus is + started. See the + <ulink url="view-source:https://dbus.freedesktop.org/doc/dbus-specification.html#auth-mechanisms"> + Authentication Mechanisms</ulink> section of the D-Bus specification for details.</para> + + <para><function>sd_bus_is_anonymous()</function> returns true if the bus connection allows + anonymous authentication (in the sense described in previous paragraph).</para> + + <para><function>sd_bus_set_trusted()</function> sets the "trusted" state on the + <parameter>bus</parameter> object. If true, all connections on the bus are trusted and access to + all privileged and unprivileged methods is granted. This function must be called before the bus + is started.</para> + + <para><function>sd_bus_is_trusted()</function> returns true if the bus connection is trusted (in + the sense described in previous paragraph).</para> + + <para><function>sd_bus_set_allow_interactive_authorization()</function> enables or disables + interactive authorization for method calls. If true, messages are marked with the + <constant>ALLOW_INTERACTIVE_AUTHORIZATION</constant> flag specified by the + <ulink url="view-source:https://dbus.freedesktop.org/doc/dbus-specification.html">D-Bus</ulink> + specification, informing the receiving side that the caller is prepared to wait for interactive + authorization, which might take a considerable time to complete. If this flag is set, the user + may be queried for passwords or confirmation via + <ulink url="http://www.freedesktop.org/wiki/Software/polkit">polkit</ulink> or a similar + framework.</para> + + <para><function>sd_bus_get_allow_interactive_authorization()</function> returns true if + interactive authorization is allowed and false if not.</para> + + <para><function>sd_bus_get_scope()</function> stores the scope of the given bus object in + <parameter>scope</parameter>. The scope of the system bus is <literal>system</literal>. The + scope of a user session bus is <literal>user</literal>. If the given bus object is not the + system or a user session bus, <function>sd_bus_get_scope()</function> returns an error.</para> + + <para><function>sd_bus_get_tid()</function> stores the kernel thread id of the thread associated + with the given bus object in <parameter>tid</parameter>. If <parameter>bus</parameter> is a + default bus object obtained by calling one of the functions of the + <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry> + family of functions, it stores the thread id of the thread the bus object was created in. + Otherwise, if the bus object is attached to an event loop, it stores the thread id of the + thread the event loop object was created in. If <parameter>bus</parameter> is not a default bus + object and is not attached to an event loop, <function>sd_bus_get_tid()</function> returns an + error.</para> + + <para><function>sd_bus_get_unique_name()</function> stores the unique name of the bus object on + the bus in <parameter>unique</parameter>. See + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus"> + The D-Bus specification</ulink> for more information on bus names. Note that the caller does not + own the string stored in <parameter>unique</parameter> and should not free it.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>An argument is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus cannot be resolved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The bus has already been started.</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>-ENODATA</constant></term> + + <listitem><para>The bus object passed to <function>sd_bus_get_scope()</function> was not a + system or user session bus.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The bus object passed to <function>sd_bus_get_tid()</function> was not a + default bus object and is not attached to an event loop.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_open_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_open_system</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_exit_on_disconnect.xml b/man/sd_bus_set_exit_on_disconnect.xml new file mode 100644 index 0000000..a694aef --- /dev/null +++ b/man/sd_bus_set_exit_on_disconnect.xml @@ -0,0 +1,114 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_exit_on_disconnect" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_exit_on_disconnect</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_exit_on_disconnect</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_exit_on_disconnect</refname> + <refname>sd_bus_get_exit_on_disconnect</refname> + + <refpurpose>Control the exit behavior when the bus object disconnects</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_exit_on_disconnect</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_exit_on_disconnect</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_exit_on_disconnect()</function> may be used to configure the exit + behavior when the given bus object disconnects. If <parameter>b</parameter> is zero, no special + logic is executed when the bus object disconnects. If <parameter>b</parameter> is non-zero, the + behavior on disconnect depends on whether the bus object is attached to an event loop or not. If + the bus object is attached to an event loop (see + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>), + the event loop is closed when the bus object disconnects (as if calling + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + Otherwise, + <citerefentry project='man-pages'><refentrytitle>exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + is called. The exit code passed to <function>sd_event_exit()</function> and + <function>exit()</function> is <constant>EXIT_FAILURE</constant>. If the bus object has already + disconnected when enabling the exit behavior, the exit behavior is executed immediately. By + default, the exit behavior is disabled.</para> + + <para><function>sd_bus_get_exit_on_disconnect()</function> returns whether the exit on + disconnect behavior is enabled for the given bus object.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_set_exit_on_disconnect()</function> returns a non-negative + integer. On failure, it returns a negative errno-style error code.</para> + + <para><function>sd_bus_get_exit_on_disconnect()</function> returns a positive integer if the + exit on disconnect behavior is enabled. Otherwise, it returns zero.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>A required parameter was <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus object could not be resolved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/sd_bus_set_method_call_timeout.xml b/man/sd_bus_set_method_call_timeout.xml new file mode 100644 index 0000000..0db13e2 --- /dev/null +++ b/man/sd_bus_set_method_call_timeout.xml @@ -0,0 +1,103 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_method_call_timeout" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_method_call_timeout</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_method_call_timeout</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_method_call_timeout</refname> + <refname>sd_bus_get_method_call_timeout</refname> + + <refpurpose>Set or query the default D-Bus method call timeout of a bus object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_method_call_timeout</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_method_call_timeout</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t *<parameter>ret</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_method_call_timeout()</function> sets the default D-Bus method call + timeout of <parameter>bus</parameter> to <parameter>usec</parameter> microseconds.</para> + + <para><function>sd_bus_get_method_call_timeout()</function> queries the default D-Bus method + call timeout of <parameter>bus</parameter>. If no method call timeout was set using + <function>sd_bus_set_method_call_timeout()</function>, the timeout is read from the + <varname>$SYSTEMD_BUS_TIMEOUT</varname> environment variable. If this environment variable is + unset or does not contain a valid timeout, the implementation falls back to a predefined method + call timeout of 25 seconds. Note that <varname>$SYSTEMD_BUS_TIMEOUT</varname> is read once and + cached so callers should not rely on being able to change the default method call timeout at + runtime by changing the value of <varname>$SYSTEMD_BUS_TIMEOUT</varname>. Instead, call + <function>sd_bus_set_method_call_timeout()</function> to change the default method call timeout. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative 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>The parameters <parameter>bus</parameter> or <parameter>ret</parameter> + are <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>Bus object <parameter>bus</parameter> could not be resolved.</para> + </listitem> + </varlistentry> + </variablelist> + + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_property.xml b/man/sd_bus_set_property.xml new file mode 100644 index 0000000..66477b3 --- /dev/null +++ b/man/sd_bus_set_property.xml @@ -0,0 +1,176 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_property" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_property</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_property</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_property</refname> + <refname>sd_bus_set_propertyv</refname> + <refname>sd_bus_get_property</refname> + <refname>sd_bus_get_property_trivial</refname> + <refname>sd_bus_get_property_string</refname> + <refname>sd_bus_get_property_strv</refname> + + <refpurpose>Set or query D-Bus service properties</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_property</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef> + <paramdef>const char *<parameter>type</parameter></paramdef> + <paramdef>...</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_propertyv</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef> + <paramdef>const char *<parameter>type</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_property</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef> + <paramdef>const char *<parameter>type</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_property_trivial</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>void *<parameter>ret_ptr</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_property_string</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>char **<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_property_strv</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char *<parameter>destination</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>const char *<parameter>interface</parameter></paramdef> + <paramdef>const char *<parameter>member</parameter></paramdef> + <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef> + <paramdef>char ***<parameter>ret</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These functions set or query D-Bus properties. D-Bus properties are service fields exposed + via the <constant>org.freedesktop.DBus.Properties</constant> interface. Under the hood, these + functions call methods of the <constant>org.freedesktop.DBus.Properties</constant> interface and + as a result their semantics are similar to + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_set_property()</function> sets a D-Bus property. On success, the response + is stored in <parameter>reply</parameter>. If setting the property fails or an internal error + occurs, an error is returned and an extended description of the error is optionally stored in + <parameter>ret_error</parameter> if it is not <constant>NULL</constant>. + <parameter>type</parameter> and the arguments that follow it describe the new value of the + property and must follow the format described in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_set_propertyv()</function> is equivalent to + <function>sd_bus_set_property()</function>, except that it is called with a + <literal>va_list</literal> instead of a variable number of arguments.</para> + + <para><function>sd_bus_get_property()</function> queries a D-Bus property. If retrieving the + property fails or an internal error occurs, an error is returned and an extended description of + the error is optionally stored in <parameter>ret_error</parameter> if it is not + <constant>NULL</constant>. On success, the property is stored in <parameter>reply</parameter>. + <parameter>type</parameter> describes the property type and must follow the format described in + <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para><function>sd_bus_get_property_trivial()</function>, + <function>sd_bus_get_property_string()</function> and + <function>sd_bus_get_property_strv()</function> are shorthands for + <function>sd_bus_get_property()</function> that are used to query basic, string and string + vector properties respectively. The caller is responsible for freeing the string and string + vector results stored in <parameter>ret</parameter> by + <function>sd_bus_get_property_string()</function> and + <function>sd_bus_get_property_strv()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>See the + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> + man page for a list of possible errors.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_sender.xml b/man/sd_bus_set_sender.xml new file mode 100644 index 0000000..c6e07ac --- /dev/null +++ b/man/sd_bus_set_sender.xml @@ -0,0 +1,103 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_sender" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_sender</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_sender</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_sender</refname> + <refname>sd_bus_get_sender</refname> + + <refpurpose>Configure default sender for outgoing messages</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_sender</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char* <parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_sender</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>const char** <parameter>name</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_sender()</function> configures the default sender service name to use for outgoing + messages. The service name specified in the <parameter>name</parameter> parameter is set on all outgoing messages + that are sent on the connection and have no sender set yet, for example through + <citerefentry><refentrytitle>sd_bus_message_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Note + that this function is only supported on direct connections, i.e. not on connections to a bus broker as the broker + will fill in the sender service name automatically anyway. By default no sender name is configured, and hence + messages are sent without sender field set. If the <parameter>name</parameter> parameter is specified as + <constant>NULL</constant> the default sender service name is cleared, returning to the default state if a default + sender service name was set before. If passed as non-<constant>NULL</constant> the specified name must be a valid + unique or well-known service name.</para> + + <para><function>sd_bus_get_sender()</function> may be used to query the current default service name for outgoing + messages.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The specified bus connection object is a not a direct but a brokered + connection.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_server.xml b/man/sd_bus_set_server.xml new file mode 100644 index 0000000..e2cd74d --- /dev/null +++ b/man/sd_bus_set_server.xml @@ -0,0 +1,193 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_server" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_server</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_server</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_server</refname> + <refname>sd_bus_is_server</refname> + <refname>sd_bus_get_bus_id</refname> + <refname>sd_bus_set_bus_client</refname> + <refname>sd_bus_is_bus_client</refname> + <refname>sd_bus_set_monitor</refname> + <refname>sd_bus_is_monitor</refname> + + <refpurpose>Configure connection mode for a bus object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_server</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + <paramdef>sd_id128_t <parameter>id</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_is_server</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_bus_id</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>sd_id128_t *<parameter>id</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_bus_client</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_is_bus_client</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_set_monitor</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_is_monitor</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_server()</function> configures the bus object as a server for direct D-Bus + connections. <parameter>b</parameter> enables/disables the server mode. If zero, the server mode is + disabled. Otherwise, the server mode is enabled. Configuring a bus object as a server is required to + allow establishing direct connections between two peers without going via the D-Bus daemon. + <parameter>id</parameter> must contain a 128-bit integer id for the server. If clients add a guid field + to their D-Bus address string, the server id must match this guid or the D-Bus authentication handshake + will fail. If no specific id is defined for the server, + <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry> + can be used to generate a random id instead.</para> + + <para><function>sd_bus_is_server()</function> returns whether the server mode is enabled for the given + bus object.</para> + + <para><function>sd_bus_get_bus_id()</function> stores the D-Bus server id configured using + <function>sd_bus_set_server()</function> (for server bus objects) or received during D-Bus authentication + (for client bus objects) in <parameter>id</parameter>.</para> + + <para><function>sd_bus_set_bus_client()</function> configures the bus object as a D-Bus daemon client. + <parameter>b</parameter> enables/disables the client mode. If zero, the client mode is disabled and the + bus object should connect directly to a D-Bus server. Otherwise, the client mode is enabled and the bus + object should connect to a D-Bus daemon. When connecting to an existing bus using any of the functions in + the <citerefentry><refentrytitle>sd_bus_open</refentrytitle><manvolnum>3</manvolnum></citerefentry> + family of functions or any of the functions in the + <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry> family + of functions, the bus object is automatically configured as a bus client. However, when connecting to a + D-Bus daemon by calling + <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry> + followed by + <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, the bus + object should be manually configured as a bus client using <function>sd_bus_set_bus_client()</function>. + By default, a bus object is not configured as a D-Bus daemon client.</para> + + <para><function>sd_bus_is_bus_client()</function> returns whether the client mode is enabled/disabled for + the given bus object.</para> + + <para><function>sd_bus_set_monitor()</function> configures the bus object as a D-Bus monitor object. + <parameter>b</parameter> enables/disables the monitor mode. If zero, the monitor mode is disabled. If + non-zero, the monitor mode is enabled. When the monitor mode is enabled, no messages may be sent via the + bus object and it may not expose any objects on the bus. To start monitoring messages, call the + <function>org.freedesktop.DBus.Monitoring.BecomeMonitor</function> method of the D-Bus daemon and pass + a list of matches indicating which messages to intercept. See + <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-become-monitor"> + The D-Bus specification</ulink> for more information.</para> + + <para><function>sd_bus_is_monitor()</function> returns whether the monitor mode is enabled/disabled for + the given bus object.</para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_set_server()</function>, + <function>sd_bus_get_bus_id()</function>, <function>sd_bus_set_bus_client()</function> and + <function>sd_bus_set_monitor()</function> return a non-negative integer. On failure, they return a + negative errno-style error code.</para> + + <para><function>sd_bus_is_server()</function>, <function>sd_bus_is_bus_client()</function> and + <function>sd_bus_is_monitor()</function> return a positive integer when the server or client mode is + enabled, respectively. Otherwise, they return zero.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The bus connection has already been started.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus cannot be resolved.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>A required parameter was <constant>NULL</constant> or + <parameter>b</parameter> was zero and <parameter>id</parameter> did not equal + <constant>SD_ID128_NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus is not connected.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_set_watch_bind.xml b/man/sd_bus_set_watch_bind.xml new file mode 100644 index 0000000..20f6f53 --- /dev/null +++ b/man/sd_bus_set_watch_bind.xml @@ -0,0 +1,118 @@ +<?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-or-later --> + +<refentry id="sd_bus_set_watch_bind" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_set_watch_bind</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_set_watch_bind</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_set_watch_bind</refname> + <refname>sd_bus_get_watch_bind</refname> + + <refpurpose>Control socket binding watching on bus connections</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_set_watch_bind</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_get_watch_bind</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_set_watch_bind()</function> may be used to enable or disable client-side watching of server + socket binding for a bus connection object. If the <parameter>b</parameter> is true, the feature is enabled, + otherwise disabled (which is the default). When enabled, and the selected bus address refers to an + <filename>AF_UNIX</filename> socket in the file system which does not exist while the connection attempt is made an + <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> watch is installed on + it, waiting for the socket to appear. As soon as the socket appears the connection is made. This functionality is + useful in particular in early-boot programs that need to run before the system bus is available, but want to + connect to it the instant it may be connected to.</para> + + <para><function>sd_bus_get_watch_bind()</function> may be used to query the current setting of this feature. It + returns zero when the feature is disabled, and positive if enabled.</para> + + <para>Note that no timeout is applied while we wait for the socket to appear. This means that any + synchronous remote operation (such as + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>), + that is used on a connection with this feature enabled that hasn't been established yet, might block + forever if the socket is never created. However, asynchronous remote operations (such as + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_add_match_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + do not block in this case, and safely enqueue the requested operations to be dispatched the instant the + connection is set up.</para> + + <para>Use <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry> to + determine whether the connection is fully established, i.e. whether the peer socket has been bound, connected to + and authenticated. Use + <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> to + be notified when the connection is fully established.</para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_slot_get_bus.xml b/man/sd_bus_slot_get_bus.xml new file mode 100644 index 0000000..48400ad --- /dev/null +++ b/man/sd_bus_slot_get_bus.xml @@ -0,0 +1,90 @@ +<?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-or-later --> + +<refentry id="sd_bus_slot_get_bus" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_slot_get_bus</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_slot_get_bus</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_slot_get_bus</refname> + <refname>sd_bus_slot_get_current_handler</refname> + <refname>sd_bus_slot_get_current_message</refname> + <refname>sd_bus_slot_get_current_userdata</refname> + + <refpurpose>Query information attached to a bus slot object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_slot_get_bus</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_message_handler_t <function>sd_bus_slot_get_current_handler</function> + </funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_message *<function>sd_bus_slot_get_current_message</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void *<function>sd_bus_slot_get_current_userdata</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_slot_get_bus()</function> returns the bus object that message + <parameter>slot</parameter> is attached to.</para> + + <para><function>sd_bus_slot_get_current_handler()</function>, + <function>sd_bus_slot_get_current_message()</function> and + <function>sd_bus_slot_get_current_userdata()</function> return the current handler, message and + userdata respectively of the bus <parameter>slot</parameter> is attached to if we're currently + executing the callback associated with <parameter>slot</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_bus_slot_get_bus()</function> always returns the bus object.</para> + + <para>On success, <function>sd_bus_slot_get_current_handler()</function>, + <function>sd_bus_slot_get_current_message()</function> and + <function>sd_bus_slot_get_current_userdata()</function> return the requested object. On failure, + they return <constant>NULL</constant>.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_slot_ref.xml b/man/sd_bus_slot_ref.xml new file mode 100644 index 0000000..c200bc4 --- /dev/null +++ b/man/sd_bus_slot_ref.xml @@ -0,0 +1,94 @@ +<?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-or-later --> + +<refentry id="sd_bus_slot_ref" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_slot_ref</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_slot_ref</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_slot_ref</refname> + <refname>sd_bus_slot_unref</refname> + <refname>sd_bus_slot_unrefp</refname> + + <refpurpose>Create and destroy references to a bus slot object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>sd_bus_slot *<function>sd_bus_slot_ref</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_slot *<function>sd_bus_slot_unref</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_slot_unrefp</function></funcdef> + <paramdef>sd_bus_slot **<parameter>slotp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_slot_ref()</function> increases the reference counter of + <parameter>slot</parameter> by one.</para> + + <para><function>sd_bus_slot_unref()</function> decreases the reference counter of + <parameter>slot</parameter> by one. Once the reference count has dropped to zero, slot object is + destroyed and cannot be used anymore, so further calls to <function>sd_bus_slot_ref()</function> + or <function>sd_bus_slot_unref()</function> are illegal.</para> + + <para><function>sd_bus_slot_unrefp()</function> is similar to + <function>sd_bus_slot_unref()</function> but takes a pointer to a pointer to an + <type>sd_bus_slot</type> object. 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>. See + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for an example how to use the cleanup attribute.</para> + + <para><function>sd_bus_slot_ref()</function> and <function>sd_bus_slot_unref()</function> + execute no operation if the passed in bus object address is + <constant>NULL</constant>. <function>sd_bus_slot_unrefp()</function> will first dereference + its argument, which must not be <constant>NULL</constant>, and will execute no operation if + <emphasis>that</emphasis> is <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_bus_slot_ref()</function> always returns the argument.</para> + + <para><function>sd_bus_slot_unref()</function> always returns <constant>NULL</constant>.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_method_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_slot_set_description.xml b/man/sd_bus_slot_set_description.xml new file mode 100644 index 0000000..4a8df0c --- /dev/null +++ b/man/sd_bus_slot_set_description.xml @@ -0,0 +1,105 @@ +<?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-or-later --> + +<refentry id="sd_bus_slot_set_description" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_bus_slot_set_description</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_slot_set_description</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_slot_set_description</refname> + <refname>sd_bus_slot_get_description</refname> + + <refpurpose>Set or query the description of bus slot objects</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_slot_set_description</function></funcdef> + <paramdef>sd_bus_slot* <parameter>slot</parameter></paramdef> + <paramdef>const char *<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_slot_get_description</function></funcdef> + <paramdef>sd_bus_slot* <parameter>bus</parameter></paramdef> + <paramdef>const char **<parameter>description</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_slot_set_description()</function> sets the description string + that is used in logging to the specified string. The string is copied internally + and freed when the bus slot object is deallocated. The + <parameter>description</parameter> argument may be <constant>NULL</constant>, in + which case the description is unset.</para> + + <para><function>sd_bus_slot_get_description()</function> returns a description string in + <parameter>description</parameter>. If the string is not set, e.g. with + <function>sd_bus_slot_set_description()</function>, and the slot is a bus match callback slot, + the match string will be returned. Otherwise, <constant>-ENXIO</constant> is returned. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>An required argument is <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The bus slot object has no description.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + <citerefentry><refentrytitle>sd_bus_slot_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_slot_set_destroy_callback.xml b/man/sd_bus_slot_set_destroy_callback.xml new file mode 100644 index 0000000..4de77d2 --- /dev/null +++ b/man/sd_bus_slot_set_destroy_callback.xml @@ -0,0 +1,130 @@ +<?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-or-later --> + +<refentry id="sd_bus_slot_set_destroy_callback" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_slot_set_destroy_callback</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_slot_set_destroy_callback</refname> + <refname>sd_bus_slot_get_destroy_callback</refname> + <refname>sd_bus_track_set_destroy_callback</refname> + <refname>sd_bus_track_get_destroy_callback</refname> + <refname>sd_bus_destroy_t</refname> + + <refpurpose>Define the callback function for resource cleanup</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_bus_destroy_t</function>)</funcdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_slot_set_destroy_callback</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + <paramdef>sd_bus_destroy_t <parameter>callback</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_slot_get_destroy_callback</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + <paramdef>sd_bus_destroy_t *<parameter>callback</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_set_destroy_callback</function></funcdef> + <paramdef>sd_bus_track *<parameter>track</parameter></paramdef> + <paramdef>sd_bus_destroy_t <parameter>callback</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_get_destroy_callback</function></funcdef> + <paramdef>sd_bus_track *<parameter>track</parameter></paramdef> + <paramdef>sd_bus_destroy_t *<parameter>callback</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_slot_set_destroy_callback()</function> sets <parameter>callback</parameter> as the callback + function to be called right before the bus slot object <parameter>slot</parameter> is deallocated. The + <parameter>userdata</parameter> pointer from the slot object will be passed as the <parameter>userdata</parameter> + parameter. This pointer can be set by an argument to the constructor functions, see + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or directly, + see <citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This callback function is called even if <parameter>userdata</parameter> is <constant>NULL</constant>. Note that + this callback is invoked at a time where the bus slot object itself is already invalidated, and executing + operations or taking new references to the bus slot object is not permissible.</para> + + <para><function>sd_bus_slot_get_destroy_callback()</function> returns the current callback + for <parameter>slot</parameter> in the <parameter>callback</parameter> parameter.</para> + + <para><function>sd_bus_track_set_destroy_callback()</function> and + <function>sd_bus_track_get_destroy_callback()</function> provide equivalent functionality for the + <parameter>userdata</parameter> pointer associated with bus peer tracking objects. For details about bus peer + tracking objects, see + <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_slot_set_destroy_callback()</function> and + <function>sd_bus_track_set_destroy_callback()</function> return 0 or a positive integer. On failure, they + return a negative errno-style error code.</para> + + <para><function>sd_bus_slot_get_destroy_callback()</function> and + <function>sd_bus_track_get_destroy_callback()</function> return positive if the destroy callback function + is set, 0 if not. 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>The <parameter>slot</parameter> or <parameter>track</parameter> parameter is + <constant>NULL</constant>.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_track_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_slot_set_floating.xml b/man/sd_bus_slot_set_floating.xml new file mode 100644 index 0000000..dd3a950 --- /dev/null +++ b/man/sd_bus_slot_set_floating.xml @@ -0,0 +1,117 @@ +<?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-or-later --> + +<refentry id="sd_bus_slot_set_floating" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_slot_set_floating</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_slot_set_floating</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_slot_set_floating</refname> + <refname>sd_bus_slot_get_floating</refname> + + <refpurpose>Control whether a bus slot object is "floating"</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_slot_set_floating</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_slot_get_floating</function></funcdef> + <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_slot_set_floating()</function> controls whether the specified bus slot object + <parameter>slot</parameter> shall be "floating" or not. A floating bus slot object's lifetime is bound to the + lifetime of the bus object it is associated with, meaning that it remains allocated as long as the bus object + itself and is freed automatically when the bus object is freed. Regular (i.e. non-floating) bus slot objects keep + the bus referenced, hence the bus object remains allocated at least as long as there remains at least one + referenced bus slot object around. The floating state hence controls the direction of referencing between the bus + object and the bus slot objects: if floating the bus pins the bus slot, and otherwise the bus slot pins the bus + objects. Use <function>sd_bus_slot_set_floating()</function> to switch between both modes: if the + <parameter>b</parameter> parameter is zero, the slot object is considered floating, otherwise it is made a regular + (non-floating) slot object.</para> + + <para>Bus slot objects may be allocated with calls such as + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If the + <parameter>slot</parameter> of these functions is non-<constant>NULL</constant> the slot object will be of the + regular kind (i.e. non-floating), otherwise it will be created floating. With + <function>sd_bus_slot_set_floating()</function> a bus slot object allocated as regular can be converted into a + floating object and back. This is particularly useful for creating a bus slot object, then changing parameters of + it, and then turning it into a floating object, whose lifecycle is managed by the bus object.</para> + + <para><function>sd_bus_slot_get_floating()</function> returns the current floating state of the specified bus slot + object. It returns negative on error, zero if the bus slot object is a regular (non-floating) object and positive + otherwise.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>The <parameter>slot</parameter> parameter is <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection has been created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The bus object the specified bus slot object is associated with has already been + freed, and hence no change in the floating state can be made anymore.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_slot_set_userdata.xml b/man/sd_bus_slot_set_userdata.xml new file mode 100644 index 0000000..9fa5f3a --- /dev/null +++ b/man/sd_bus_slot_set_userdata.xml @@ -0,0 +1,88 @@ +<?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-or-later --> + +<refentry id="sd_bus_slot_set_userdata" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_slot_set_userdata</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_slot_set_userdata</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_slot_set_userdata</refname> + <refname>sd_bus_slot_get_userdata</refname> + + <refpurpose>Set and query the value in the "userdata" field</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>void* <function>sd_bus_slot_set_userdata</function></funcdef> + <paramdef>sd_bus_slot* <parameter>slot</parameter></paramdef> + <paramdef>void* <parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void* <function>sd_bus_slot_get_userdata</function></funcdef> + <paramdef>sd_bus_slot* <parameter>slot</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The userdata pointer allows data to be passed between the point where a callback is + registered, for example when a filter is added using + <citerefentry><refentrytitle>sd_bus_add_filter</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or an asynchronous function call is made using + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and the point where the callback is called, without having any global state. The pointer has + type <type>void*</type> and is not used by the sd-bus functions in any way, except to pass to + the callback function.</para> + + <para>Usually, the userdata field is set when the slot object is initially + registered. <function>sd_bus_slot_set_userdata()</function> may be used to change it later for + the bus slot object <parameter>slot</parameter>. Previous value of the field is returned. The + argument and returned value may be <constant>NULL</constant>. It will be passed as the + <parameter>userdata</parameter> argument to the callback function attached to the slot.</para> + + <para><function>sd_bus_slot_set_userdata()</function> gets the value of the userdata field in + the bus slot object <parameter>slot</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return the value of the userdata field before the function + call. If the <parameter>slot</parameter> object is <constant>NULL</constant>, + <constant>NULL</constant> will be returned to signify an error, but this is not distinguishable + from the userdata field value being <constant>NULL</constant>.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_slot_get_current_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_start.xml b/man/sd_bus_start.xml new file mode 100644 index 0000000..68fe3e0 --- /dev/null +++ b/man/sd_bus_start.xml @@ -0,0 +1,124 @@ +<?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-or-later --> + +<refentry id="sd_bus_start" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_start</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_start</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_start</refname> + + <refpurpose>Initiate a bus connection to the D-bus broker daemon + </refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_start</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_start()</function> connects an existing bus connection object to the D-Bus + broker daemon, usually + <citerefentry project='die-net'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry> + or + <citerefentry project='mankier'><refentrytitle>dbus-broker</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + The mechanism to use for the connection must be configured before the call to + <function>sd_bus_start()</function>, using one of + <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or + <citerefentry><refentrytitle>sd_bus_set_exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + <function>sd_bus_start()</function> will open the connection socket or spawn the executable as + needed, and asynchronously start a <function>org.freedesktop.DBus.Hello()</function> call. The + answer to the Hello call will be processed later from + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If + opening of the connection or queuing of the asynchronous call fail, the connection will be closed with + <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>In most cases, it is better to use + <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or related calls instead of the more low-level <function>sd_bus_new()</function> and + <function>sd_bus_start()</function>. The higher-level functions not only allocate a bus object but also + start the connection to a well-known bus in a single function call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, this function returns a non-negative integer. On failure, it returns a negative + errno-style error code.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The input parameter <parameter>bus</parameter> is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>Bus object <parameter>bus</parameter> could not be resolved.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The input parameter <parameter>bus</parameter> is in a wrong state + (<function>sd_bus_start()</function> may only be called once on a newly-created bus object).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus object <parameter>bus</parameter> was created in a different + process.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>In addition, other connection-related errors may be returned. See + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_track_add_name.xml b/man/sd_bus_track_add_name.xml new file mode 100644 index 0000000..ae90e44 --- /dev/null +++ b/man/sd_bus_track_add_name.xml @@ -0,0 +1,228 @@ +<?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-or-later --> + +<refentry id="sd_bus_track_add_name" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_track_add_name</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_track_add_name</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_track_add_name</refname> + <refname>sd_bus_track_add_sender</refname> + <refname>sd_bus_track_remove_name</refname> + <refname>sd_bus_track_remove_sender</refname> + <refname>sd_bus_track_count</refname> + <refname>sd_bus_track_count_sender</refname> + <refname>sd_bus_track_count_name</refname> + <refname>sd_bus_track_contains</refname> + <refname>sd_bus_track_first</refname> + <refname>sd_bus_track_next</refname> + + <refpurpose>Add, remove and retrieve bus peers tracked in a bus peer tracking object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_track_add_name</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>const char* <parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_add_sender</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>sd_bus_message* <parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_remove_name</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>const char* <parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_remove_sender</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>sd_bus_message* <parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>unsigned <function>sd_bus_track_count</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_count_name</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>const char* <parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_count_sender</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>sd_bus_message* <parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_contains</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + <paramdef>const char* <parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_track_first</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char* <function>sd_bus_track_next</function></funcdef> + <paramdef>sd_bus_track* <parameter>t</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_track_add_name()</function> adds a peer to track to a bus peer tracking object. The first + argument should refer to a bus peer tracking object created with + <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, the second + name should refer to a D-Bus peer name to track, either in unique or well-known service format. If the name is not + tracked yet it will be added to the list of names to track. If it already is being tracked and non-recursive mode + is enabled, no operation is executed by this call. If recursive mode is enabled a per-name counter is increased by + one each time this call is invoked, and <function>sd_bus_track_remove_name()</function> has to be called as many + times as <function>sd_bus_track_add_name()</function> was invoked before in order to stop tracking of the name. Use + <citerefentry><refentrytitle>sd_bus_track_set_recursive</refentrytitle><manvolnum>3</manvolnum></citerefentry> to + switch from the default non-recursive mode to recursive mode, or back. Note that the specified name is tracked as + it is, well-known names are not resolved to unique names by this call. Note that multiple bus peer tracking objects + may track the same name.</para> + + <para><function>sd_bus_track_remove_name()</function> undoes the effect of + <function>sd_bus_track_add_name()</function> and removes a bus peer name from the list of peers to watch. Depending + on whether non-recursive or recursive mode is enabled for the bus peer tracking object this call will either remove + the name fully from the tracking object, or will simply decrement the per-name counter by one, removing the name + only when the counter reaches zero (see above). Note that a bus peer disconnecting from the bus will implicitly + remove its names fully from the bus peer tracking object, regardless of the current per-name counter.</para> + + <para><function>sd_bus_track_add_sender()</function> and <function>sd_bus_track_remove_sender()</function> are + similar to <function>sd_bus_track_add_name()</function> and <function>sd_bus_track_remove_name()</function> but + take a bus message as argument. The sender of this bus message is determined and added to/removed from the bus peer + tracking object. As messages always originate from unique names, and never from well-known names this means that + this call will effectively only add unique names to the bus peer tracking object.</para> + + <para><function>sd_bus_track_count()</function> returns the number of names currently being tracked by the + specified bus peer tracking object. Note that this function always returns the actual number of names tracked, and + hence if <function>sd_bus_track_add_name()</function> has been invoked multiple times for the same name it is only + counted as one, regardless if recursive mode is used or not.</para> + + <para><function>sd_bus_track_count_name()</function> returns the current per-name counter for the specified + name. If non-recursive mode is used this returns either 1 or 0, depending on whether the specified name has been + added to the tracking object before, or not. If recursive mode has been enabled, values larger than 1 may be + returned too, in case <function>sd_bus_track_add_name()</function> has been called multiple times for the same + name.</para> + + <para><function>sd_bus_track_count_sender()</function> is similar to + <function>sd_bus_track_count_name()</function>, but takes a bus message object and returns the per-name counter + matching the sender of the message.</para> + + <para><function>sd_bus_track_contains()</function> may be used to determine whether the specified name has been + added at least once to the specified bus peer tracking object.</para> + + <para><function>sd_bus_track_first()</function> and <function>sd_bus_track_next()</function> may be used to + enumerate all names currently being tracked by the passed bus peer tracking + object. <function>sd_bus_track_first()</function> returns the first entry in the object, and resets an internally + maintained read index. Each subsequent invocation of <function>sd_bus_track_next()</function> returns the next name + contained in the bus object. If the end is reached <constant>NULL</constant> is returned. If no names have been + added to the object yet <function>sd_bus_track_first()</function> will return <constant>NULL</constant> + immediately. The order in which names are returned is undefined; in particular which name is considered the first + returned is not defined. If recursive mode is enabled and the same name has been added multiple times to the bus + peer tracking object it is only returned once by this enumeration. If new names are added to or existing names + removed from the bus peer tracking object while it is being enumerated the enumeration ends on the next invocation + of <function>sd_bus_track_next()</function> as <constant>NULL</constant> is returned.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_track_add_name()</function> and <function>sd_bus_track_add_sender()</function> + return 0 if the specified name has already been added to the bus peer tracking object before and positive if it + hasn't. On failure, they return a negative errno-style error code.</para> + + <para><function>sd_bus_track_remove_name()</function> and <function>sd_bus_track_remove_sender()</function> return + positive if the specified name was previously tracked by the bus peer tracking object and has now been removed. In + non-recursive mode, 0 is returned if the specified name was not being tracked yet. In recursive mode + <constant>-EUNATCH</constant> is returned in this case. On failure, they return a negative errno-style error + code.</para> + + <para><function>sd_bus_track_count()</function> returns the number of names currently being tracked, or 0 on + failure.</para> + + <para><function>sd_bus_track_count_name()</function> and <function>sd_bus_track_count_sender()</function> return + the current per-name counter for the specified name or the sender of the specified message. Zero is returned for + names that are not being tracked yet, a positive value for names added at least once. Larger values than 1 are only + returned in recursive mode. On failure, a negative errno-style error code is returned.</para> + + <para><function>sd_bus_track_contains()</function> returns the passed name if it exists in the bus peer tracking + object. On failure, and if the name has not been added yet <constant>NULL</constant> is returned.</para> + + <para><function>sd_bus_track_first()</function> and <function>sd_bus_track_next()</function> return the first/next + name contained in the bus peer tracking object, and <constant>NULL</constant> if the end of the enumeration is + reached and on error.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EUNATCH</constant></term> + + <listitem><para><function>sd_bus_track_remove_name()</function> or + <function>sd_bus_track_remove_sender()</function> have been invoked for a name not previously added + to the bus peer object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified parameter is invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_track_new.xml b/man/sd_bus_track_new.xml new file mode 100644 index 0000000..2147ad1 --- /dev/null +++ b/man/sd_bus_track_new.xml @@ -0,0 +1,231 @@ +<?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-or-later --> + +<refentry id="sd_bus_track_new" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_track_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_track_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_track_new</refname> + <refname>sd_bus_track_ref</refname> + <refname>sd_bus_track_unref</refname> + <refname>sd_bus_track_unrefp</refname> + <refname>sd_bus_track_set_recursive</refname> + <refname>sd_bus_track_get_recursive</refname> + <refname>sd_bus_track_get_bus</refname> + <refname>sd_bus_track_get_userdata</refname> + <refname>sd_bus_track_set_userdata</refname> + + <refpurpose>Track bus peers</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_track_new</function></funcdef> + <paramdef>sd_bus* <parameter>bus</parameter></paramdef> + <paramdef>sd_bus_track** <parameter>ret</parameter></paramdef> + <paramdef>sd_bus_track_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void* <parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_track *<function>sd_bus_track_ref</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus_track *<function>sd_bus_track_unref</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_bus_track_unrefp</function></funcdef> + <paramdef>sd_bus_track **<parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_get_recursive</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_track_set_recursive</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_bus* <function>sd_bus_track_get_bus</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void* <function>sd_bus_track_get_userdata</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void* <function>sd_bus_track_set_userdata</function></funcdef> + <paramdef>sd_bus_track *<parameter>t</parameter></paramdef> + <paramdef>void *userdata</paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_track_new()</function> creates a new bus peer tracking object. The object is allocated for + the specified bus, and returned in the <parameter>*ret</parameter> parameter. After use, the object should be freed + again by dropping the acquired reference with <function>sd_bus_track_unref()</function> (see below). A bus peer + tracking object may be used to keep track of peers on a specific IPC bus, for cases where peers are making use of + one or more local objects, in order to control the lifecycle of the local objects and ensure they stay around as + long as the peers needing them are around, and unreferenced (and possibly destroyed) as soon as all relevant peers + have vanished. Each bus peer tracking object may be used to track zero, one or more peers add a time. References to + specific bus peers are added via + <citerefentry><refentrytitle>sd_bus_track_add_name</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <function>sd_bus_track_add_sender()</function>. They may be dropped again via + <function>sd_bus_track_remove_name()</function> and + <function>sd_bus_track_remove_sender()</function>. Alternatively, references on peers are removed automatically + when they disconnect from the bus. If non-<constant>NULL</constant> the <parameter>handler</parameter> may specify + a function that is invoked whenever the last reference is dropped, regardless whether the reference is dropped + explicitly via <function>sd_bus_track_remove_name()</function> or implicitly because the peer disconnected from the + bus. The final argument <parameter>userdata</parameter> may be used to attach a generic user data pointer to the + object. This pointer is passed to the handler callback when it is invoked.</para> + + <para><function>sd_bus_track_ref()</function> creates a new reference to a bus peer tracking object. This object + will not be destroyed until <function>sd_bus_track_unref()</function> has been called as many times plus once + more. Once the reference count has dropped to zero, the specified object cannot be used anymore, further calls to + <function>sd_bus_track_ref()</function> or <function>sd_bus_track_unref()</function> on the same object are + illegal.</para> + + <para><function>sd_bus_track_unref()</function> destroys a reference to a bus peer tracking object.</para> + + <para><function>sd_bus_track_unrefp()</function> is similar to <function>sd_bus_track_unref()</function> but takes + a pointer to a pointer to an <type>sd_bus_track</type> object. 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> + + <para><function>sd_bus_track_ref()</function>, <function>sd_bus_track_unref()</function> and + <function>sd_bus_track_unrefp()</function> execute no operation if the passed in bus peer tracking object is + <constant>NULL</constant>.</para> + + <para>Bus peer tracking objects may exist in two modes: by default they operate in non-recursive mode, but may + optionally be switched into recursive mode. If operating in the default non-recursive mode a peer is either tracked + or not tracked. In this mode invoking <function>sd_bus_track_add_name()</function> multiple times in a row for the + same peer is fully equivalent to calling it just once, as the call adds the peer to the set of tracked peers if + necessary, and executes no operation if the peer is already being tracked. A single invocation of + <function>sd_bus_track_remove_name()</function> removes the reference on the peer again, regardless how many times + <function>sd_bus_track_add_name()</function> was called before. If operating in recursive mode, the number of times + <function>sd_bus_track_add_name()</function> is invoked for the same peer name is counted and + <function>sd_bus_track_remove_name()</function> must be called the same number of times before the peer is not + tracked anymore, with the exception when the tracked peer vanishes from the bus, in which case the count is + irrelevant and the tracking of the specific peer is immediately + removed. <function>sd_bus_track_get_recursive()</function> may be used to determine whether the bus peer tracking + object is operating in recursive mode. <function>sd_bus_track_set_recursive()</function> may be used to enable or + disable recursive mode. By default a bus peer tracking object operates in non-recursive mode, and + <function>sd_bus_track_get_recursive()</function> for a newly allocated object hence returns a value equal to + zero. Use <function>sd_bus_track_set_recursive()</function> to enable recursive mode, right after allocation. It + takes a boolean argument to enable or disable recursive mode. Note that tracking objects for which + <function>sd_bus_track_add_name()</function> was already invoked at least once (and which hence track already one + or more peers) may not be switched from recursive to non-recursive mode anymore.</para> + + <para><function>sd_bus_track_get_bus()</function> returns the bus object the bus peer tracking object belongs + to. It returns the bus object initially passed to <function>sd_bus_track_new()</function> when the object was + allocated.</para> + + <para><function>sd_bus_track_get_userdata()</function> returns the generic user data pointer set on the bus peer + tracking object at the time of creation using <function>sd_bus_track_new()</function> or at a later time, using + <function>sd_bus_track_set_userdata()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_track_new()</function> and <function>sd_bus_track_set_recursive()</function> + return 0 or a positive integer. On failure, they return a negative errno-style error code.</para> + + <para><function>sd_bus_track_ref()</function> always returns the argument.</para> + + <para><function>sd_bus_track_unref()</function> always returns <constant>NULL</constant>.</para> + + <para><function>sd_bus_track_get_recursive()</function> returns 0 if non-recursive mode is selected (default), and + greater than 0 if recursive mode is selected. On failure a negative errno-style error code is returned.</para> + + <para><function>sd_bus_track_get_bus()</function> returns the bus object associated to the bus peer tracking + object.</para> + + <para><function>sd_bus_track_get_userdata()</function> returns the generic user data pointer associated with the + bus peer tracking object. <function>sd_bus_track_set_userdata()</function> returns the previous user data pointer + set.</para> + + </refsect1> + + <refsect1> + <title>Reference ownership</title> + + <para>The <function>sd_bus_track_new()</function> function creates a new object and the caller owns the sole + reference. When not needed anymore, this reference should be destroyed with + <function>sd_bus_track_unref()</function>. + </para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para>Bus peers have already been added to the bus peer tracking object and + <function>sd_bus_track_set_recursive()</function> was called to change tracking mode. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Specified parameter is invalid + (<constant>NULL</constant> in case of output + parameters).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> + <citerefentry><refentrytitle>sd_bus_track_add_name</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_bus_wait.xml b/man/sd_bus_wait.xml new file mode 100644 index 0000000..005602d --- /dev/null +++ b/man/sd_bus_wait.xml @@ -0,0 +1,113 @@ +<?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-or-later + + Copyright © 2016 Julian Orth +--> + +<refentry id="sd_bus_wait" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_bus_wait</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_bus_wait</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_bus_wait</refname> + + <refpurpose>Wait for I/O on a bus connection</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-bus.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_bus_wait</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_bus_wait()</function> synchronously waits for I/O on the specified bus connection object. This + function is supposed to be called whenever + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns zero, + indicating that no work is pending on the connection. Internally, this call invokes <citerefentry + project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>3</manvolnum></citerefentry>, to wait for I/O on + the bus connection. If the <parameter>timeout_sec</parameter> parameter is specified, the call will block at most + for the specified amount of time in µs. Pass <constant>UINT64_MAX</constant> to permit it to sleep + indefinitely.</para> + + <para>After each invocation of <function>sd_bus_wait()</function> the <function>sd_bus_process()</function> call + should be invoked in order to process any now pending I/O work.</para> + + <para>Note that <function>sd_bus_wait()</function> is suitable only for simple programs as it does not permit + waiting for other I/O events. For more complex programs either connect the bus connection object to an external + event loop using <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or to an <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> event loop + using + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>If any I/O was seen, a positive value is returned, zero otherwise. If an error occurs, a negative + <varname>errno</varname>-style error code is returned.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid bus object was passed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus connection was allocated in a parent process and is being reused in a child + process after <function>fork()</function>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOTCONN</constant></term> + + <listitem><para>The bus connection has been terminated already.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_add_child.xml b/man/sd_event_add_child.xml new file mode 100644 index 0000000..2961b3e --- /dev/null +++ b/man/sd_event_add_child.xml @@ -0,0 +1,338 @@ +<?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-or-later --> + +<refentry id="sd_event_add_child" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_add_child</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_add_child</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_add_child</refname> + <refname>sd_event_add_child_pidfd</refname> + <refname>sd_event_source_get_child_pid</refname> + <refname>sd_event_source_get_child_pidfd</refname> + <refname>sd_event_source_get_child_pidfd_own</refname> + <refname>sd_event_source_set_child_pidfd_own</refname> + <refname>sd_event_source_get_child_process_own</refname> + <refname>sd_event_source_set_child_process_own</refname> + <refname>sd_event_source_send_child_signal</refname> + <refname>sd_event_child_handler_t</refname> + + <refpurpose>Add a child process state change event source to an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_child_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>const siginfo_t *<parameter>si</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_child</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>int <parameter>options</parameter></paramdef> + <paramdef>sd_event_child_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_child_pidfd</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>int <parameter>pidfd</parameter></paramdef> + <paramdef>int <parameter>options</parameter></paramdef> + <paramdef>sd_event_child_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_child_pid</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>pid_t *<parameter>pid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_child_pidfd</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_child_pidfd_own</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_child_pidfd_own</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>own</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_child_process_own</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_child_process_own</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>own</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_send_child_signal</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>sig</parameter></paramdef> + <paramdef>const siginfo_t *<parameter>info</parameter></paramdef> + <paramdef>unsigned <parameter>flags</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_add_child()</function> adds a new child process state change event source to an + event loop. The event loop object is specified in the <parameter>event</parameter> parameter, the event + source object is returned in the <parameter>source</parameter> parameter. The <parameter>pid</parameter> + parameter specifies the PID of the process to watch, which must be a direct child process of the invoking + process. The <parameter>handler</parameter> must reference a function to call when the process changes + state. The handler function will be passed the <parameter>userdata</parameter> pointer, which may be + chosen freely by the caller. The handler also receives a pointer to a <structname>siginfo_t</structname> + structure containing information about the child process event. The <parameter>options</parameter> + parameter determines which state changes will be watched for. It must contain an OR-ed mask of + <constant>WEXITED</constant> (watch for the child process terminating), <constant>WSTOPPED</constant> + (watch for the child process being stopped by a signal), and <constant>WCONTINUED</constant> (watch for + the child process being resumed by a signal). See <citerefentry + project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + further information.</para> + + <para>Only a single handler may be installed for a specific + child process. The handler is enabled for a single event + (<constant>SD_EVENT_ONESHOT</constant>), but this may be changed + with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If the handler function returns a negative error code, it will be + disabled after the invocation, even if the + <constant>SD_EVENT_ON</constant> mode was requested before. + </para> + + <para>To destroy an event source object use + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even when there's still a + reference to it kept, consider setting the event source to + <constant>SD_EVENT_OFF</constant> with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>The <constant>SIGCHLD</constant> signal must be blocked in all threads before this function is + called (using <citerefentry + project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or + <citerefentry + project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>).</para> + + <para>If the second parameter of <function>sd_event_add_child()</function> is passed as + <constant>NULL</constant> no reference to the event source object is returned. In this case the event + source is considered "floating", and will be destroyed implicitly when the event loop itself is + destroyed.</para> + + <para>Note that the <parameter>handler</parameter> function is + invoked at a time where the child process is not reaped yet (and + thus still is exposed as a zombie process by the kernel). However, + the child will be reaped automatically after the function + returns. Child processes for which no child process state change + event sources are installed will not be reaped by the event loop + implementation.</para> + + <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_child()</function> is + <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the + event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as + the exit code parameter to + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>If both a child process state change event source and a + <constant>SIGCHLD</constant> signal event source is installed in + the same event loop, the configured event source priorities decide + which event source is dispatched first. If the signal handler is + processed first, it should leave the child processes for which + child process state change event sources are installed unreaped.</para> + + <para><function>sd_event_add_child_pidfd()</function> is similar to + <function>sd_event_add_child()</function> but takes a file descriptor referencing the process ("pidfd") + instead of the numeric PID. A suitable file descriptor may be acquired via <citerefentry + project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and + related calls. The passed file descriptor is not closed when the event source is freed again, unless + <function>sd_event_source_set_child_pidfd_own()</function> is used to turn this behaviour on. Note that + regardless which of <function>sd_event_add_child()</function> and + <function>sd_event_add_child_pidfd()</function> is used for allocating an event source, the watched + process has to be a direct child process of the invoking process. Also in both cases + <constant>SIGCHLD</constant> has to be blocked in the invoking process.</para> + + <para><function>sd_event_source_get_child_pid()</function> + retrieves the configured PID of a child process state change event + source created previously with + <function>sd_event_add_child()</function>. It takes the event + source object as the <parameter>source</parameter> parameter and a + pointer to a <type>pid_t</type> variable to return the process ID + in. + </para> + + <para><function>sd_event_source_get_child_pidfd()</function> retrieves the file descriptor referencing + the watched process ("pidfd") if this functionality is available. On kernels that support the concept the + event loop will make use of pidfds to watch child processes, regardless if the individual event sources + are allocated via <function>sd_event_add_child()</function> or + <function>sd_event_add_child_pidfd()</function>. If the latter call was used to allocate the event + source, this function returns the file descriptor used for allocation. On kernels that do not support the + pidfd concept this function will fail with <constant>EOPNOTSUPP</constant>. This call takes the event + source object as the <parameter>source</parameter> parameter and returns the numeric file descriptor. + </para> + + <para><function>sd_event_source_get_child_pidfd_own()</function> may be used to query whether the pidfd + the event source encapsulates shall be closed when the event source is freed. This function returns zero + if the pidfd shall be left open, and positive if it shall be closed automatically. By default this + setting defaults to on if the event source was allocated via <function>sd_event_add_child()</function> + and off if it was allocated via <function>sd_event_add_child_pidfd()</function>. The + <function>sd_event_source_set_child_pidfd_own()</function> function may be used to change the setting and + takes a boolean parameter with the new setting.</para> + + <para><function>sd_event_source_get_child_process_own()</function> may be used to query whether the + process the event source watches shall be killed (with <constant>SIGKILL</constant>) and reaped when the + event source is freed. This function returns zero if the process shell be left running, and positive if + it shall be killed and reaped automatically. By default this setting defaults to off. The + <function>sd_event_source_set_child_process_own()</function> function may be used to change the setting + and takes a boolean parameter with the new setting. Note that currently if the calling process is + terminated abnormally the watched process might survive even thought the event source ceases to + exist. This behaviour might change eventually.</para> + + <para><function>sd_event_source_send_child_signal()</function> may be used to send a UNIX signal to the + watched process. If the pidfd concept is supported in the kernel, this is implemented via <citerefentry + project='man-pages'><refentrytitle>pidfd_send_signal</refentrytitle><manvolnum>2</manvolnum></citerefentry> + and otherwise via <citerefentry + project='man-pages'><refentrytitle>rt_sigqueueinfo</refentrytitle><manvolnum>2</manvolnum></citerefentry> + (or via <citerefentry + project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> in case + <parameter>info</parameter> is <constant>NULL</constant>). The specified parameters match those of these + underlying system calls, except that the <parameter>info</parameter> is never modified (and is thus + declared constant). Like for the underlying system calls, the <parameter>flags</parameter> parameter + currently must be zero.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate an object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid argument has been passed. This includes + specifying an empty mask in <parameter>options</parameter> or a mask + which contains values different than a combination of + <constant>WEXITED</constant>, <constant>WSTOPPED</constant>, and + <constant>WCONTINUED</constant>. + </para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para>A handler is already installed for this child process, or + <constant>SIGCHLD</constant> is not blocked.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The passed event source is not a child process event source.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>A pidfd was requested but the kernel does not support this concept.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pidfd_send_signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>rt_sigqueueinfo</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_add_defer.xml b/man/sd_event_add_defer.xml new file mode 100644 index 0000000..54e8823 --- /dev/null +++ b/man/sd_event_add_defer.xml @@ -0,0 +1,197 @@ +<?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-or-later --> + +<refentry id="sd_event_add_defer" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_add_defer</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_add_defer</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_add_defer</refname> + <refname>sd_event_add_post</refname> + <refname>sd_event_add_exit</refname> + <refname>sd_event_handler_t</refname> + + <refpurpose>Add static event sources to an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_defer</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_post</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_exit</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These three functions add new static event sources to an + event loop. The event loop object is specified in the + <parameter>event</parameter> parameter, the event source object is + returned in the <parameter>source</parameter> parameter. The event + sources are enabled statically and will "fire" when the event loop + is run and the conditions described below are met. The handler + function will be passed the <parameter>userdata</parameter> + pointer, which may be chosen freely by the caller.</para> + + <para><function>sd_event_add_defer()</function> adds a new event + source that will be dispatched instantly, before the event loop + goes to sleep again and waits for new events. By default, the + handler will be called once + (<constant>SD_EVENT_ONESHOT</constant>). Note that if the event + source is set to <constant>SD_EVENT_ON</constant> the event loop + will never go to sleep again, but continuously call the handler, + possibly interleaved with other event sources.</para> + + <para><function>sd_event_add_post()</function> adds a new event + source that is run before the event loop will sleep and wait + for new events, but only after at least one other non-post event + source was dispatched. By default, the source is enabled + permanently (<constant>SD_EVENT_ON</constant>). Note that this + event source type will still allow the event loop to go to sleep + again, even if set to <constant>SD_EVENT_ON</constant>, as long as + no other event source is ever triggered.</para> + + <para><function>sd_event_add_exit()</function> adds a new event + source that will be dispatched when the event loop is terminated + with <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>The + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + function may be used to enable the event source permanently + (<constant>SD_EVENT_ON</constant>) or to make it fire just once + (<constant>SD_EVENT_ONESHOT</constant>).</para> + + <para>If the handler function returns a negative error code, it + will be disabled after the invocation, even if the + <constant>SD_EVENT_ON</constant> mode was requested before.</para> + + <para>To destroy an event source object use + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even when there's still a + reference to it kept, consider setting the event source to + <constant>SD_EVENT_OFF</constant> with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>If the second parameter of these functions is passed as <constant>NULL</constant> no reference to + the event source object is returned. In this case the event source is considered "floating", and will be + destroyed implicitly when the event loop itself is destroyed.</para> + + <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_defer()</function> or + <function>sd_event_add_post()</function> is <constant>NULL</constant>, and the event source fires, this + will be considered a request to exit the event loop. In this case, the <parameter>userdata</parameter> + parameter, cast to an integer, is passed as the exit code parameter to + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Similar + functionality is not available for <function>sd_event_add_exit()</function>, as these types of event + sources are only dispatched when exiting anyway.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate an object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid argument has been passed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_add_inotify.xml b/man/sd_event_add_inotify.xml new file mode 100644 index 0000000..1681143 --- /dev/null +++ b/man/sd_event_add_inotify.xml @@ -0,0 +1,198 @@ +<?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-or-later --> + +<refentry id="sd_event_add_inotify" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_add_inotify</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_add_inotify</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_add_inotify</refname> + <refname>sd_event_source_get_inotify_mask</refname> + <refname>sd_event_inotify_handler_t</refname> + + <refpurpose>Add an "inotify" file system inode event source to an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_inotify_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>const struct inotify_event *<parameter>event</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_inotify</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>uint32_t <parameter>mask</parameter></paramdef> + <paramdef>sd_event_inotify_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_inotify_mask</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint32_t *<parameter>mask</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_add_inotify()</function> adds a new <citerefentry + project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> file system inode + event source to an event loop. The event loop object is specified in the <parameter>event</parameter> parameter, + the event source object is returned in the <parameter>source</parameter> parameter. The <parameter>path</parameter> + parameter specifies the path of the file system inode to watch. The <parameter>handler</parameter> must reference a + function to call when the inode changes. The handler function will be passed the <parameter>userdata</parameter> + pointer, which may be chosen freely by the caller. The handler also receives a pointer to a <structname>struct + inotify_event</structname> structure containing information about the inode event. The <parameter>mask</parameter> + parameter specifies which types of inode events to watch specifically. It must contain an OR-ed combination of + <constant>IN_ACCESS</constant>, <constant>IN_ATTRIB</constant>, <constant>IN_CLOSE_WRITE</constant>, … flags. See + <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + further information.</para> + + <para>If multiple event sources are installed for the same inode the backing inotify watch descriptor is + automatically shared. The mask parameter may contain any flag defined by the inotify API, with the exception of + <constant>IN_MASK_ADD</constant>.</para> + + <para>The handler is enabled continuously (<constant>SD_EVENT_ON</constant>), but this may be changed with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Alternatively, + the <constant>IN_ONESHOT</constant> mask flag may be used to request <constant>SD_EVENT_ONESHOT</constant> mode. + If the handler function returns a negative error code, it will be disabled after the invocation, even if the + <constant>SD_EVENT_ON</constant> mode was requested before. + </para> + + <para>As a special limitation the priority of inotify event sources may only be altered (see + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + in the time between creation of the event source object with <function>sd_event_add_inotify()</function> and the + beginning of the next event loop iteration. Attempts of changing the priority any later will be refused. Consider + freeing and allocating a new inotify event source to change the priority at that point.</para> + + <para>To destroy an event source object use + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, but note + that the event source is only removed from the event loop when all references to the event source are dropped. To + make sure an event source does not fire anymore, even when there's still a reference to it kept, consider disabling + it with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>If the second parameter of <function>sd_event_add_inotify()</function> is passed as + <constant>NULL</constant> no reference to the event source object is returned. In this case the event + source is considered "floating", and will be destroyed implicitly when the event loop itself is + destroyed.</para> + + <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_inotify()</function> is + <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the + event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as + the exit code parameter to + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para><function>sd_event_source_get_inotify_mask()</function> retrieves the configured inotify watch mask of an + event source created previously with <function>sd_event_add_inotify()</function>. It takes the event source object + as the <parameter>source</parameter> parameter and a pointer to a <type>uint32_t</type> variable to return the mask + in.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate an object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid argument has been passed. This includes specifying a mask with + <constant>IN_MASK_ADD</constant> set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The passed event source is not an inotify process event source.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>A simple program that uses inotify to monitor one or two directories</title> + + <programlisting><xi:include href="inotify-watch-tmp.c" parse="text" /></programlisting> + </example> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_add_io.xml b/man/sd_event_add_io.xml new file mode 100644 index 0000000..323e57c --- /dev/null +++ b/man/sd_event_add_io.xml @@ -0,0 +1,311 @@ +<?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-or-later --> + +<refentry id="sd_event_add_io" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_add_io</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_add_io</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_add_io</refname> + <refname>sd_event_source_get_io_events</refname> + <refname>sd_event_source_set_io_events</refname> + <refname>sd_event_source_get_io_revents</refname> + <refname>sd_event_source_get_io_fd</refname> + <refname>sd_event_source_set_io_fd</refname> + <refname>sd_event_source_get_io_fd_own</refname> + <refname>sd_event_source_set_io_fd_own</refname> + <refname>sd_event_source</refname> + <refname>sd_event_io_handler_t</refname> + + <refpurpose>Add an I/O event source to an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_io_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>uint32_t <parameter>revents</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_io</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>uint32_t <parameter>events</parameter></paramdef> + <paramdef>sd_event_io_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_io_events</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint32_t *<parameter>events</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_io_events</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint32_t <parameter>events</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_io_revents</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint32_t *<parameter>revents</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_io_fd</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_io_fd</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>fd</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_io_fd_own</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_io_fd_own</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_add_io()</function> adds a new I/O event + source to an event loop. The event loop object is specified in the + <parameter>event</parameter> parameter, the event source object is + returned in the <parameter>source</parameter> parameter. The + <parameter>fd</parameter> parameter takes the UNIX file descriptor + to watch, which may refer to a socket, a FIFO, a message queue, a + serial connection, a character device, or any other file descriptor + compatible with Linux + <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The + <parameter>events</parameter> parameter takes a bit mask of events + to watch for, a combination of the following event flags: + <constant>EPOLLIN</constant>, <constant>EPOLLOUT</constant>, + <constant>EPOLLRDHUP</constant>, <constant>EPOLLPRI</constant>, + and <constant>EPOLLET</constant>, see + <citerefentry project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. The <parameter>handler</parameter> shall reference a + function to call when the event source is triggered. The + <parameter>userdata</parameter> pointer will be passed to the + handler function, and may be chosen freely by the caller. The + handler will also be passed the file descriptor the event was seen + on, as well as the actual event flags. It's generally a subset of + the events watched, however may additionally include + <constant>EPOLLERR</constant> and <constant>EPOLLHUP</constant>. + </para> + + <para>By default, an event source will stay enabled + continuously (<constant>SD_EVENT_ON</constant>), but this may be + changed with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If the handler function returns a negative error code, it will be + disabled after the invocation, even if the + <constant>SD_EVENT_ON</constant> mode was requested before. Note + that an event source set to <constant>SD_EVENT_ON</constant> will + fire continuously unless data is read from or written to the file + descriptor to reset the mask of events seen. + </para> + + <para>Setting the I/O event mask to watch for to 0 does not mean + that the event source won't be triggered anymore, as + <constant>EPOLLHUP</constant> and <constant>EPOLLERR</constant> + may be triggered even with a zero event mask. To temporarily + disable an I/O event source use + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with <constant>SD_EVENT_OFF</constant> instead.</para> + + <para>To destroy an event source object use + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even if it is still referenced, + disable the event source using + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with <constant>SD_EVENT_OFF</constant>.</para> + + <para>If the second parameter of + <function>sd_event_add_io()</function> is + <constant>NULL</constant> no reference to the event source object + is returned. In this case the event source is considered + "floating", and will be destroyed implicitly when the event loop + itself is destroyed.</para> + + <para>If the <parameter>handler</parameter> to <function>sd_event_add_io()</function> is + <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the + event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as + the exit code parameter to + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Note that this call does not take possession of the file descriptor passed in, ownership (and thus + the duty to close it when it is no longer needed) remains with the caller. However, with the + <function>sd_event_source_set_io_fd_own()</function> call (see below) the event source may optionally + take ownership of the file descriptor after the event source has been created. In that case the file + descriptor is closed automatically as soon as the event source is released.</para> + + <para>It is recommended to use + <function>sd_event_add_io()</function> only in conjunction with + file descriptors that have <constant>O_NONBLOCK</constant> set, to + ensure that all I/O operations from invoked handlers are properly + asynchronous and non-blocking. Using file descriptors without + <constant>O_NONBLOCK</constant> might result in unexpected + starvation of other event sources. See + <citerefentry project='man-pages'><refentrytitle>fcntl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details on enabling <constant>O_NONBLOCK</constant> mode.</para> + + <para><function>sd_event_source_get_io_events()</function> retrieves + the configured mask of watched I/O events of an event source created + previously with <function>sd_event_add_io()</function>. It takes + the event source object and a pointer to a variable to store the + mask in.</para> + + <para><function>sd_event_source_set_io_events()</function> + configures the mask of watched I/O events of an event source created + previously with <function>sd_event_add_io()</function>. It takes the + event source object and the new event mask.</para> + + <para><function>sd_event_source_get_io_revents()</function> + retrieves the I/O event mask of currently seen but undispatched + events from an event source created previously with + <function>sd_event_add_io()</function>. It takes the event source + object and a pointer to a variable to store the event mask + in. When called from a handler function on the handler's event + source object this will return the same mask as passed to the + handler's <parameter>revents</parameter> parameter. This call is + primarily useful to check for undispatched events of an event + source from the handler of an unrelated (possibly higher priority) + event source. Note the relation between + <function>sd_event_source_get_pending()</function> and + <function>sd_event_source_get_io_revents()</function>: both + functions will report non-zero results when there's an event + pending for the event source, but the former applies to all event + source types, the latter only to I/O event sources.</para> + + <para><function>sd_event_source_get_io_fd()</function> retrieves + the UNIX file descriptor of an event source created previously + with <function>sd_event_add_io()</function>. It takes the event + source object and returns the non-negative file descriptor + or a negative error number on error (see below).</para> + + <para><function>sd_event_source_set_io_fd()</function> + changes the UNIX file descriptor of an I/O event source created + previously with <function>sd_event_add_io()</function>. It takes + the event source object and the new file descriptor.</para> + + <para><function>sd_event_source_set_io_fd_own()</function> controls whether the file descriptor of the event source + shall be closed automatically when the event source is freed, i.e. whether it shall be considered 'owned' by the + event source object. By default it is not closed automatically, and the application has to do this on its own. The + <parameter>b</parameter> parameter is a boolean parameter: if zero, the file descriptor is not closed automatically + when the event source is freed, otherwise it is closed.</para> + + <para><function>sd_event_source_get_io_fd_own()</function> may be used to query the current setting of the file + descriptor ownership boolean flag as set with <function>sd_event_source_set_io_fd_own()</function>. It returns + positive if the file descriptor is closed automatically when the event source is destroyed, zero if not, and + negative on error.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned values may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate an object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid argument has been passed.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The passed event source is not an I/O event source.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_get_pending</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_add_signal.xml b/man/sd_event_add_signal.xml new file mode 100644 index 0000000..1f0854f --- /dev/null +++ b/man/sd_event_add_signal.xml @@ -0,0 +1,201 @@ +<?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-or-later --> + +<refentry id="sd_event_add_signal" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_add_signal</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_add_signal</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_add_signal</refname> + <refname>sd_event_source_get_signal</refname> + <refname>sd_event_signal_handler_t</refname> + + <refpurpose>Add a UNIX process signal event source to an event + loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_signal_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>const struct signalfd_siginfo *<parameter>si</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_signal</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>int <parameter>signal</parameter></paramdef> + <paramdef>sd_event_signal_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_signal</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_add_signal()</function> adds a new UNIX + process signal event source to an event loop. The event loop + object is specified in the <parameter>event</parameter> parameter, + and the event source object is returned in the + <parameter>source</parameter> parameter. The + <parameter>signal</parameter> parameter specifies the numeric + signal to be handled (see <citerefentry + project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>). + The <parameter>handler</parameter> parameter must reference a + function to call when the signal is received or be + <constant>NULL</constant>. The handler function will be passed + the <parameter>userdata</parameter> pointer, which may be chosen + freely by the caller. The handler also receives a pointer to a + <structname>signalfd_siginfo</structname> structure containing + information about the received signal. See <citerefentry + project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for further information.</para> + + <para>Only a single handler may be installed for a specific signal. The signal must be blocked in all + threads before this function is called (using <citerefentry + project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or + <citerefentry + project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>).</para> + + <para>By default, the event source is enabled permanently + (<constant>SD_EVENT_ON</constant>), but this may be changed with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If the handler function returns a negative error code, it will be + disabled after the invocation, even if the + <constant>SD_EVENT_ON</constant> mode was requested before. + </para> + + <para>To destroy an event source object use + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even if it is still referenced, + disable the event source using + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with <constant>SD_EVENT_OFF</constant>.</para> + + <para>If the second parameter of + <function>sd_event_add_signal()</function> is + <constant>NULL</constant> no reference to the event source object + is returned. In this case the event source is considered + "floating", and will be destroyed implicitly when the event loop + itself is destroyed.</para> + + <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_signal()</function> is + <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the + event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as + the exit code parameter to + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para><function>sd_event_source_get_signal()</function> returns + the configured signal number of an event source created previously + with <function>sd_event_add_signal()</function>. It takes the + event source object as the <parameter>source</parameter> + parameter.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions 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>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate an object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid argument has been passed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para>A handler is already installed for this + signal or the signal was not blocked previously.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The passed event source is not a signal event source.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_add_time.xml b/man/sd_event_add_time.xml new file mode 100644 index 0000000..3e8927f --- /dev/null +++ b/man/sd_event_add_time.xml @@ -0,0 +1,321 @@ +<?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-or-later --> + +<refentry id="sd_event_add_time" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_add_time</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_add_time</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_add_time</refname> + <refname>sd_event_add_time_relative</refname> + <refname>sd_event_source_get_time</refname> + <refname>sd_event_source_set_time</refname> + <refname>sd_event_source_set_time_relative</refname> + <refname>sd_event_source_get_time_accuracy</refname> + <refname>sd_event_source_set_time_accuracy</refname> + <refname>sd_event_source_get_time_clock</refname> + <refname>sd_event_time_handler_t</refname> + + <refpurpose>Add a timer event source to an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_time_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_time</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>clockid_t <parameter>clock</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + <paramdef>uint64_t <parameter>accuracy</parameter></paramdef> + <paramdef>sd_event_time_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_add_time_relative</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + <paramdef>clockid_t <parameter>clock</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + <paramdef>uint64_t <parameter>accuracy</parameter></paramdef> + <paramdef>sd_event_time_handler_t <parameter>handler</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_time</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_time</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_time_relative</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_time_accuracy</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_time_accuracy</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_time_clock</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>clockid_t *<parameter>clock</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_add_time()</function> adds a new timer event source to an event loop. The event loop + object is specified in the <parameter>event</parameter> parameter, the event source object is returned in the + <parameter>source</parameter> parameter. The <parameter>clock</parameter> parameter takes a clock identifier, one + of <constant>CLOCK_REALTIME</constant>, <constant>CLOCK_MONOTONIC</constant>, <constant>CLOCK_BOOTTIME</constant>, + <constant>CLOCK_REALTIME_ALARM</constant>, or <constant>CLOCK_BOOTTIME_ALARM</constant>. See + <citerefentry><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> for details + regarding the various types of clocks. The <parameter>usec</parameter> parameter specifies the earliest time, in + microseconds (µs), relative to the clock's epoch, when the timer shall be triggered. If a time already in the past + is specified (including <constant>0</constant>), this timer source "fires" immediately and is ready to be + dispatched. If the parameter is specified as <constant>UINT64_MAX</constant> the timer event will never elapse, + which may be used as an alternative to explicitly disabling a timer event source with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. The + <parameter>accuracy</parameter> parameter specifies an additional accuracy value in µs specifying how much the + timer event may be delayed. Use <constant>0</constant> to select the default accuracy (250ms). Use 1µs for maximum + accuracy. Consider specifying 60000000µs (1min) or larger for long-running events that may be delayed + substantially. Picking higher accuracy values allows the system to coalesce timer events more aggressively, + improving power efficiency. The <parameter>handler</parameter> parameter shall reference a function to call when + the timer elapses. The handler function will be passed the <parameter>userdata</parameter> pointer, which may be + chosen freely by the caller. The handler is also passed the configured trigger time, even if it is actually called + slightly later, subject to the specified accuracy value, the kernel timer slack (see + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>), and additional + scheduling latencies. To query the actual time the handler was called use + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>By default, the timer will elapse once + (<constant>SD_EVENT_ONESHOT</constant>), but this may be changed + with + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If the handler function returns a negative error code, it will be + disabled after the invocation, even if the + <constant>SD_EVENT_ON</constant> mode was requested before. Note + that a timer event set to <constant>SD_EVENT_ON</constant> will + fire continuously unless its configured time is updated using + <function>sd_event_source_set_time()</function>. + </para> + + <para><function>sd_event_add_time_relative()</function> is like <function>sd_event_add_time()</function>, + but takes a relative time specification. It's relative to the current time of the event loop iteration, + as returned by + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>To destroy an event source object use + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even if it is still referenced, + disable the event source using + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with <constant>SD_EVENT_OFF</constant>.</para> + + <para>If the second parameter of + <function>sd_event_add_time()</function> is + <constant>NULL</constant> no reference to the event source object + is returned. In this case the event source is considered + "floating", and will be destroyed implicitly when the event loop + itself is destroyed.</para> + + <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_time()</function> is + <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the + event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as + the exit code parameter to + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Use <constant>CLOCK_BOOTTIME_ALARM</constant> and + <constant>CLOCK_REALTIME_ALARM</constant> to define event sources + that may wake up the system from suspend.</para> + + <para>In order to set up relative timers (that is, relative to the + current time), retrieve the current time via + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + add the desired timespan to it, and use the result as + the <parameter>usec</parameter> parameter to + <function>sd_event_add_time()</function>.</para> + + <para>In order to set up repetitive timers (that is, timers that + are triggered in regular intervals), set up the timer normally, + for the first invocation. Each time the event handler is invoked, + update the timer's trigger time with + <citerefentry><refentrytitle>sd_event_source_set_time</refentrytitle><manvolnum>3</manvolnum></citerefentry> for the next timer + iteration, and reenable the timer using + <function>sd_event_source_set_enabled()</function>. To calculate + the next point in time to pass to + <function>sd_event_source_set_time()</function>, either use as + base the <parameter>usec</parameter> parameter passed to the timer + callback, or the timestamp returned by + <function>sd_event_now()</function>. In the former case timer + events will be regular, while in the latter case the scheduling + latency will keep accumulating on the timer.</para> + + <para><function>sd_event_source_get_time()</function> retrieves the configured time value of an event + source created previously with <function>sd_event_add_time()</function> or + <function>sd_event_add_time_relative()</function>. It takes the event source object and a pointer to a + variable to store the time in, relative to the selected clock's epoch, in µs. The returned value is + relative to the epoch, even if the event source was created with a relative time via + <function>sd_event_add_time_relative()</function>.</para> + + <para><function>sd_event_source_set_time()</function> changes the time of an event source created + previously with <function>sd_event_add_time()</function> or + <function>sd_event_add_time_relative()</function>. It takes the event source object and a time relative + to the selected clock's epoch, in µs.</para> + + <para><function>sd_event_source_set_time_relative()</function> is similar to + <function>sd_event_source_set_time()</function>, but takes a time relative to the current time of the + event loop iteration, as returned by <function>sd_event_now()</function>.</para> + + <para><function>sd_event_source_get_time_accuracy()</function> + retrieves the configured accuracy value of an event source + created previously with <function>sd_event_add_time()</function>. It + takes the event source object and a pointer to a variable to store + the accuracy in. The accuracy is specified in µs.</para> + + <para><function>sd_event_source_set_time_accuracy()</function> + changes the configured accuracy of a timer event source created + previously with <function>sd_event_add_time()</function>. It takes + the event source object and accuracy, in µs.</para> + + <para><function>sd_event_source_get_time_clock()</function> + retrieves the configured clock of an event source created + previously with <function>sd_event_add_time()</function>. It takes + the event source object and a pointer to a variable to store the + clock identifier in.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code. </para> + + <refsect2> + <title>Errors</title> + + <para>Returned values may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate an object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid argument has been passed.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>The selected clock is not supported by the event loop implementation.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The passed event source is not a timer event source.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EOVERFLOW</constant></term> + + <listitem><para>The passed relative time is outside of the allowed range for time values (i.e. the + specified value added to the current time is outside the 64 bit unsigned integer range).</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_exit.xml b/man/sd_event_exit.xml new file mode 100644 index 0000000..e13cbe1 --- /dev/null +++ b/man/sd_event_exit.xml @@ -0,0 +1,150 @@ +<?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-or-later --> + +<refentry id="sd_event_exit" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_exit</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_exit</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_exit</refname> + <refname>sd_event_get_exit_code</refname> + + <refpurpose>Ask the event loop to exit</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_exit</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>int <parameter>code</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_get_exit_code</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>int *<parameter>code</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_exit()</function> requests the event loop + specified in the <parameter>event</parameter> event loop object to + exit. The <parameter>code</parameter> parameter may be any integer + value and is returned as-is by + <citerefentry><refentrytitle>sd_event_loop</refentrytitle><manvolnum>3</manvolnum></citerefentry> + after the last event loop iteration. It may also be queried + using <function>sd_event_get_exit_code()</function>, see + below. </para> + + <para>When exiting is requested the event loop will stop listening + for and dispatching regular event sources. Instead it will proceed + with executing only event sources registered with + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + in the order defined by their priority. After all exit event + sources have been dispatched the event loop is terminated.</para> + + <para>If <function>sd_event_exit()</function> is invoked a second + time while the event loop is still processing exit event sources, + the exit code stored in the event loop object is updated, but + otherwise no further operation is executed.</para> + + <para><function>sd_event_get_exit_code()</function> may be used to + query the exit code passed into + <function>sd_event_exit()</function> earlier.</para> + + <para>While the full positive and negative integer ranges may be used + for the exit code, care should be taken not pick exit codes that + conflict with regular exit codes returned by + <function>sd_event_loop()</function>, if these exit codes shall be + distinguishable.</para> + + <para>Note that for most event source types passing the callback pointer as <constant>NULL</constant> in + the respective constructor call (i.e. in + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + …) has the effect of <function>sd_event_exit()</function> being invoked once the event source triggers, + with the specified userdata pointer cast to an integer as the exit code parameter. This is useful to + automatically terminate an event loop after some condition, such as a time-out or reception of + <constant>SIGTERM</constant> or similar. See the documentation for the respective constructor call for + details.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_exit()</function> and <function>sd_event_get_exit_code()</function> + 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>The event loop object or error code pointer are invalid.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop was created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop has exited already and all exit handlers are already processed. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENODATA</constant></term> + + <listitem><para>The event loop has not been requested to exit yet.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_get_fd.xml b/man/sd_event_get_fd.xml new file mode 100644 index 0000000..a3b11e4 --- /dev/null +++ b/man/sd_event_get_fd.xml @@ -0,0 +1,111 @@ +<?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-or-later --> + +<refentry id="sd_event_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_get_fd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_get_fd</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_get_fd</refname> + + <refpurpose>Obtain a file descriptor to poll for event loop events</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_get_fd</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_get_fd()</function> returns the file + descriptor that an event loop object returned by the + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> + function uses to wait for events. This file descriptor may itself + be polled for + <constant>POLLIN</constant>/<constant>EPOLLIN</constant> + events. This makes it possible to embed an + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + event loop into another, possibly foreign, event loop.</para> + + <para>The returned file descriptor refers to an <citerefentry + project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry> + object. It is recommended not to alter it by invoking + <citerefentry + project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + on it, in order to avoid interference with the event loop's inner + logic and assumptions.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_get_fd()</function> returns a non-negative file descriptor. On + failure, it returns 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><parameter>event</parameter> is not a valid pointer to an + <structname>sd_event</structname> structure.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Integration in the GLib event loop</title> + + <programlisting><xi:include href="glib-event-glue.c" parse="text" /></programlisting> + </example> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_new.xml b/man/sd_event_new.xml new file mode 100644 index 0000000..352137e --- /dev/null +++ b/man/sd_event_new.xml @@ -0,0 +1,216 @@ +<?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-or-later --> + +<refentry id="sd_event_new" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_new</refname> + <refname>sd_event_default</refname> + <refname>sd_event_ref</refname> + <refname>sd_event_unref</refname> + <refname>sd_event_unrefp</refname> + <refname>sd_event_get_tid</refname> + <refname>sd_event</refname> + + <refpurpose>Acquire and release an event loop object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>typedef</token> struct sd_event sd_event;</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_new</function></funcdef> + <paramdef>sd_event **<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_default</function></funcdef> + <paramdef>sd_event **<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_event *<function>sd_event_ref</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_event *<function>sd_event_unref</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_event_unrefp</function></funcdef> + <paramdef>sd_event **<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_get_tid</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>pid_t *<parameter>tid</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_new()</function> allocates a new event + loop object. The event loop object is returned in the + <parameter>event</parameter> parameter. After use, drop + the returned reference with + <function>sd_event_unref()</function>. When the last reference is + dropped, the object is freed.</para> + + <para><function>sd_event_default()</function> acquires a reference + to the default event loop object of the calling thread, possibly + allocating a new object if no default event loop object has been + allocated yet for the thread. After use, drop the returned + reference with <function>sd_event_unref()</function>. When the + last reference is dropped, the event loop is freed. If this + function is called while the object returned from a previous call + from the same thread is still referenced, the same object is + returned again, but the reference is increased by one. It is + recommended to use this call instead of + <function>sd_event_new()</function> in order to share event loop + objects between various components that are dispatched in the same + thread. All threads have exactly either zero or one default event loop + objects associated, but never more.</para> + + <para>After allocating an event loop object, add event sources to + it with + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_post</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and then execute the event loop using + <citerefentry><refentrytitle>sd_event_loop</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para><function>sd_event_ref()</function> increases the reference + count of the specified event loop object by one.</para> + + <para><function>sd_event_unref()</function> decreases the + reference count of the specified event loop object by one. If + the count hits zero, the object is freed. Note that it + is freed regardless of whether it is the default event loop object for a + thread or not. This means that allocating an event loop with + <function>sd_event_default()</function>, then releasing it, and + then acquiring a new one with + <function>sd_event_default()</function> will result in two + distinct objects. Note that, in order to free an event loop object, + all remaining event sources of the event loop also need to be + freed as each keeps a reference to it.</para> + + <para><function>sd_event_unrefp()</function> is similar to + <function>sd_event_unref()</function> but takes a pointer to a + pointer to an <type>sd_event</type> object. 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. Use a declaration like the following, + in order to allocate an event loop object that is freed + automatically as the code block is left:</para> + + <programlisting>{ + __attribute__((cleanup(sd_event_unrefp))) sd_event *event = NULL; + int r; + … + r = sd_event_default(&event); + if (r < 0) + fprintf(stderr, "Failed to allocate event loop: %s\n", strerror(-r)); + … +}</programlisting> + + <para><function>sd_event_ref()</function>, + <function>sd_event_unref()</function> and + <function>sd_event_unrefp()</function> execute no operation if the + passed in event loop object is <constant>NULL</constant>.</para> + + <para><function>sd_event_get_tid()</function> retrieves the thread + identifier ("TID") of the thread the specified event loop object + is associated with. This call is only supported for event loops + allocated with <function>sd_event_default()</function>, and + returns the identifier for the thread the event loop is the + default event loop of. See <citerefentry + project='man-pages'><refentrytitle>gettid</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for more information on thread identifiers.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_new()</function>, <function>sd_event_default()</function> and + <function>sd_event_get_tid()</function> return 0 or a positive integer. On failure, they return a + negative errno-style error code. <function>sd_event_ref()</function> always returns a pointer to the + event loop object passed in. <function>sd_event_unref()</function> always returns + <constant>NULL</constant>.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to allocate the object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EMFILE</constant></term> + + <listitem><para>The maximum number of event loops has been allocated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para><function>sd_event_get_tid()</function> was invoked on an event loop object that + was not allocated with <function>sd_event_default()</function>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>gettid</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_now.xml b/man/sd_event_now.xml new file mode 100644 index 0000000..789b9e0 --- /dev/null +++ b/man/sd_event_now.xml @@ -0,0 +1,114 @@ +<?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-or-later --> + +<refentry id="sd_event_now" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_now</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_now</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_now</refname> + + <refpurpose>Retrieve current event loop iteration timestamp</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_now</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>clockid_t <parameter>clock</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_now()</function> returns the time when + the most recent event loop iteration began. A timestamp + is taken right after returning from the event sleep, and before + dispatching any event sources. The <parameter>event</parameter> + parameter specifies the event loop object to retrieve the timestamp + from. The <parameter>clock</parameter> parameter specifies the clock to + retrieve the timestamp for, and is one of + <constant>CLOCK_REALTIME</constant> (or equivalently + <constant>CLOCK_REALTIME_ALARM</constant>), + <constant>CLOCK_MONOTONIC</constant>, or + <constant>CLOCK_BOOTTIME</constant> (or equivalently + <constant>CLOCK_BOOTTIME_ALARM</constant>), see + <citerefentry project='man-pages'><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for more information on the various clocks. The retrieved + timestamp is stored in the <parameter>usec</parameter> parameter, + in µs since the clock's epoch. If this function is invoked before + the first event loop iteration, the current time is returned, as + reported by <function>clock_gettime()</function>. To distinguish + this case from a regular invocation the return value will be + positive, and zero when the returned timestamp refers to an actual + event loop iteration.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>If the first event loop iteration has not run yet <function>sd_event_now()</function> writes + current time to <parameter>usec</parameter> and returns a positive return value. Otherwise, it will + write the requested timestamp to <parameter>usec</parameter> and return 0. On failure, the call returns a + negative errno-style error code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned values may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An invalid parameter was passed.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>Unsupported clock type.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop object was created in a different process.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_run.xml b/man/sd_event_run.xml new file mode 100644 index 0000000..81c51b7 --- /dev/null +++ b/man/sd_event_run.xml @@ -0,0 +1,164 @@ +<?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-or-later --> + +<refentry id="sd_event_run" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_run</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_run</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_run</refname> + <refname>sd_event_loop</refname> + + <refpurpose>Run an event loop</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_run</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_loop</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_run()</function> may be used to run a single + iteration of the event loop specified in the + <parameter>event</parameter> parameter. The function waits until an event to + process is available, and dispatches the registered handler for + it. The <parameter>usec</parameter> parameter specifies the + maximum time (in microseconds) to wait for an event. Use + <constant>(uint64_t) -1</constant> to specify an infinite + timeout.</para> + + <para><function>sd_event_loop()</function> invokes + <function>sd_event_run()</function> in a loop, thus implementing + the actual event loop. The call returns as soon as exiting was + requested using + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>The event loop object <parameter>event</parameter> is + created with + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Events sources to wait for and their handlers may be registered + with + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_post</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>For low-level control of event loop execution, use + <citerefentry><refentrytitle>sd_event_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_event_dispatch</refentrytitle><manvolnum>3</manvolnum></citerefentry> + which are wrapped by <function>sd_event_run()</function>. Along + with + <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + these functions allow integration of an + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + event loop into foreign event loop implementations.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, these functions return a negative errno-style + error code. <function>sd_event_run()</function> returns a + positive, non-zero integer if an event source was dispatched, and + zero when the specified timeout hit before an event source has + seen any event, and hence no event source was + dispatched. <function>sd_event_loop()</function> returns the exit + code specified when invoking + <function>sd_event_exit()</function>.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The <parameter>event</parameter> parameter is invalid or + <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para>The event loop object is not in the right + state (see + <citerefentry><refentrytitle>sd_event_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for an explanation of possible states).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + </variablelist> + + <para>Other errors are possible, too.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <ulink url="https://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html">GLib Main Event Loop</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_set_watchdog.xml b/man/sd_event_set_watchdog.xml new file mode 100644 index 0000000..28d647c --- /dev/null +++ b/man/sd_event_set_watchdog.xml @@ -0,0 +1,145 @@ +<?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-or-later --> + +<refentry id="sd_event_set_watchdog" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_set_watchdog</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_set_watchdog</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_set_watchdog</refname> + <refname>sd_event_get_watchdog</refname> + + <refpurpose>Enable event loop watchdog support</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_set_watchdog</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>int b</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_get_watchdog</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_set_watchdog()</function> may be used to + enable or disable automatic watchdog notification support in the + event loop object specified in the <parameter>event</parameter> + parameter. Specifically, depending on the <parameter>b</parameter> + boolean argument this will make sure the event loop wakes up in + regular intervals and sends watchdog notification messages to the + service manager, if this was requested by the service + manager. Watchdog support is determined with + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and watchdog messages are sent with + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. See + the <varname>WatchdogSec=</varname> setting in + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details on how to enable watchdog support for a service and + the protocol used. The wake-up interval is chosen as half the + watchdog timeout declared by the service manager via the + <varname>$WATCHDOG_USEC</varname> environment variable. If the + service manager did not request watchdog notifications, or if the + process was not invoked by the service manager this call with a + true <parameter>b</parameter> parameter executes no + operation. Passing a false <parameter>b</parameter> parameter will + disable the automatic sending of watchdog notification messages if + it was enabled before. Newly allocated event loop objects have + this feature disabled.</para> + + <para>The first watchdog notification message is sent immediately + 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 + to automatically detect services that ceased processing of + incoming events, and thus appear "hung". Watchdog notifications + are sent out only at the beginning of each event loop + iteration. If an event source dispatch function blocks for an + excessively long time and does not return execution to the event + loop quickly, this might hence cause the notification message to + be delayed, and possibly result in abnormal program termination, + as configured in the service unit file.</para> + + <para><function>sd_event_get_watchdog()</function> may be used to + determine whether watchdog support was previously requested by a + call to <function>sd_event_set_watchdog()</function> with a true + <parameter>b</parameter> parameter and successfully + enabled.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_set_watchdog()</function> and + <function>sd_event_get_watchdog()</function> return a non-zero positive integer if the service manager + requested watchdog support and watchdog support was successfully enabled. They return zero if the service + manager did not request watchdog support, or if watchdog support was explicitly disabled with a false + <parameter>b</parameter> parameter. 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>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The passed event loop object was invalid.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_get_event.xml b/man/sd_event_source_get_event.xml new file mode 100644 index 0000000..a850583 --- /dev/null +++ b/man/sd_event_source_get_event.xml @@ -0,0 +1,74 @@ +<?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-or-later --> + +<refentry id="sd_event_source_get_event" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_get_event</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_get_event</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_get_event</refname> + + <refpurpose>Retrieve the event loop of an event source</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>sd_event* <function>sd_event_source_get_event</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_get_event()</function> may be used + to retrieve the event loop object the event source object specified + as <parameter>source</parameter> is associated with. The event + loop object is specified when creating an event source object with + calls such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_get_event()</function> + returns the associated event loop object. On failure, it returns + <constant>NULL</constant>.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_get_pending.xml b/man/sd_event_source_get_pending.xml new file mode 100644 index 0000000..5906930 --- /dev/null +++ b/man/sd_event_source_get_pending.xml @@ -0,0 +1,137 @@ +<?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-or-later --> + +<refentry id="sd_event_source_get_pending" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_get_pending</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_get_pending</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_get_pending</refname> + + <refpurpose>Determine pending state of event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_pending</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_get_pending()</function> may be + used to determine whether the event source object specified as + <parameter>source</parameter> has seen events but has not been + dispatched yet (and thus is marked "pending").</para> + + <para>Event source objects initially are not marked pending, when + they are created with calls such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + with the exception of those created with + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry> + which are immediately marked pending, and + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for which the "pending" concept is not defined. For details see + the respective manual pages.</para> + + <para>In each event loop iteration one event source of those + marked pending is dispatched, in the order defined by the event + source priority, as set with + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>For I/O event sources, as created with + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + the call + <citerefentry><refentrytitle>sd_event_source_get_io_revents</refentrytitle><manvolnum>3</manvolnum></citerefentry> + may be used to query the type of event pending in more + detail.</para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_get_pending()</function> returns an integer greater than zero + when the event source is marked pending, and zero when the event source is not marked pending. On + failure, it returns 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para><parameter>source</parameter> refers to an event source object created with + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_description.xml b/man/sd_event_source_set_description.xml new file mode 100644 index 0000000..bea3e71 --- /dev/null +++ b/man/sd_event_source_set_description.xml @@ -0,0 +1,140 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_description" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_description</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_description</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_description</refname> + <refname>sd_event_source_get_description</refname> + + <refpurpose>Set or retrieve descriptive names of event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_description</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>const char *<parameter>description</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_description</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>const char **<parameter>description</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_description()</function> may + be used to set an arbitrary descriptive name for the event source + object specified as <parameter>source</parameter>. This name will + be used in debugging messages generated by + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for this event source, and may be queried using + <function>sd_event_source_get_description()</function> for + debugging purposes. The <parameter>description</parameter> parameter shall + point to a <constant>NUL</constant>-terminated string or be + <constant>NULL</constant>. In the latter case, the descriptive + name will be unset. The string is copied internally, hence the + <parameter>description</parameter> argument is not referenced + after the function returns.</para> + + <para><function>sd_event_source_get_description()</function> may + be used to query the current descriptive name assigned to the + event source object <parameter>source</parameter>. It returns a + pointer to the current name in <parameter>description</parameter>, + stored in memory internal to the event source. The memory is + invalidated when the event source is destroyed or the descriptive + name is changed.</para> + + <para>Event source objects generally have no description set when + they are created, except for UNIX signal event sources created + with + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + whose descriptive name is initialized to the signal's C constant + name (e.g. <literal>SIGINT</literal> or + <literal>SIGTERM</literal>).</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_description()</function> and + <function>sd_event_source_get_description()</function> return a non-negative 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object or the <parameter>description</parameter> argument + for <function>sd_event_source_get_description()</function> is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory to copy the name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>No name was set for the event source.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_destroy_callback.xml b/man/sd_event_source_set_destroy_callback.xml new file mode 100644 index 0000000..4e39f21 --- /dev/null +++ b/man/sd_event_source_set_destroy_callback.xml @@ -0,0 +1,112 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_destroy_callback" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_destroy_callback</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_destroy_callback</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_destroy_callback</refname> + <refname>sd_event_source_get_destroy_callback</refname> + <refname>sd_event_destroy_t</refname> + + <refpurpose>Define the callback function for resource cleanup</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_destroy_t</function>)</funcdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_destroy_callback</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>sd_event_destroy_t <parameter>callback</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_destroy_callback</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>sd_event_destroy_t *<parameter>callback</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_destroy_callback()</function> sets <parameter>callback</parameter> as the + callback function to be called right before the event source object <parameter>source</parameter> is + deallocated. The <parameter>userdata</parameter> pointer from the event source object will be passed as the + <parameter>userdata</parameter> parameter. This pointer can be set by an argument to the constructor functions, see + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or directly, + see + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This callback function is called even if <parameter>userdata</parameter> is <constant>NULL</constant>. Note that + this callback is invoked at a time where the event source object itself is already invalidated, and executing + operations or taking new references to the event source object is not permissible.</para> + + <para><function>sd_event_source_get_destroy_callback()</function> returns the current callback + for <parameter>source</parameter> in the <parameter>callback</parameter> parameter.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_destroy_callback()</function> returns 0 or a positive + integer. On failure, it returns a negative errno-style error code.</para> + + <para><function>sd_event_source_get_destroy_callback()</function> returns positive if the destroy + callback function is set, 0 if not. On failure, returns 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>The <parameter>source</parameter> parameter is <constant>NULL</constant>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_enabled.xml b/man/sd_event_source_set_enabled.xml new file mode 100644 index 0000000..cf00695 --- /dev/null +++ b/man/sd_event_source_set_enabled.xml @@ -0,0 +1,154 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_enabled" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_enabled</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_enabled</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_enabled</refname> + <refname>sd_event_source_get_enabled</refname> + <refname>SD_EVENT_ON</refname> + <refname>SD_EVENT_OFF</refname> + <refname>SD_EVENT_ONESHOT</refname> + + <refpurpose>Enable or disable event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>enum</token> { + <constant>SD_EVENT_OFF</constant> = 0, + <constant>SD_EVENT_ON</constant> = 1, + <constant>SD_EVENT_ONESHOT</constant> = -1, +};</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_enabled</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>enabled</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_enabled</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int *<parameter>enabled</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_enabled()</function> may be + used to enable or disable the event source object specified as + <parameter>source</parameter>. The <parameter>enabled</parameter> + parameter takes one of <constant>SD_EVENT_ON</constant> (to + enable), <constant>SD_EVENT_OFF</constant> (to disable) or + <constant>SD_EVENT_ONESHOT</constant>. If invoked with + <constant>SD_EVENT_ONESHOT</constant> the event source will be + enabled but automatically reset to + <constant>SD_EVENT_OFF</constant> after the event source was + dispatched once.</para> + + <para>Event sources that are disabled will not result in event + loop wakeups and will not be dispatched, until they are enabled + again.</para> + + <para><function>sd_event_source_get_enabled()</function> may be + used to query whether the event source object + <parameter>source</parameter> is currently enabled or not. It + returns the enablement state (one of <constant>SD_EVENT_ON</constant>, + <constant>SD_EVENT_OFF</constant>, <constant>SD_EVENT_ONESHOT</constant>) + in <parameter>enabled</parameter>, if it is not <constant>NULL</constant>. + It also returns true if the event source is not disabled.</para> + + <para>Event source objects are enabled when they are first created + with calls such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>. However, + depending on the event source type they are enabled continuously + (<constant>SD_EVENT_ON</constant>) or only for a single invocation + of the event source handler + (<constant>SD_EVENT_ONESHOT</constant>). For details see the + respective manual pages.</para> + + <para>As event source objects stay active and may be dispatched as + long as there is at least one reference to them, in many cases it + is a good idea to combine a call to + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with a prior call to + <function>sd_event_source_set_enabled()</function> with + <constant>SD_EVENT_OFF</constant>, to ensure the event source is + not dispatched again until all other remaining references are dropped.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_enabled()</function> returns a non-negative + integer. <function>sd_event_source_get_enabled()</function> returns zero if the source is disabled + (<constant>SD_EVENT_OFF</constant>) and a positive integer otherwise. 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_exit_on_failure.xml b/man/sd_event_source_set_exit_on_failure.xml new file mode 100644 index 0000000..6f839cd --- /dev/null +++ b/man/sd_event_source_set_exit_on_failure.xml @@ -0,0 +1,108 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_exit_on_failure" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_exit_on_failure</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_exit_on_failure</refname> + <refname>sd_event_source_get_exit_on_failure</refname> + + <refpurpose>Set or retrieve the exit-on-failure feature of event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_exit_on_failure</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>b</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_exit_on_failure</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_exit_on_failure()</function> may be used to set/unset the + exit-on-failure flag of the event source object specified as <parameter>source</parameter>. The flag + defaults to off. If on and the callback function set for the event source returns a failure code (i.e. a + negative value) the event loop is exited too, using the callback return code as the exit code for + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If + off, the event source is disabled but the event loop continues to run. Setting this flag is useful for + "dominant" event sources that define the purpose and reason for the event loop, and whose failure hence + should propagate to the event loop itself — as opposed to "auxiliary" event sources whose failures should + remain local and affect the event source, but not propagate further.</para> + + <para><function>sd_event_source_get_exit_on_failure()</function> may be used to query the flag currently + set for the event source object <parameter>source</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_exit_on_failure()</function> returns a non-negative + integer. <function>sd_event_source_get_exit_on_failure()</function> returns 0 if the flag is off, > 0 + if the flag is on. On failure, both 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The event source refers to an exit event source (as created with + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>), + for which this functionality is not supported.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_floating.xml b/man/sd_event_source_set_floating.xml new file mode 100644 index 0000000..7f3ed86 --- /dev/null +++ b/man/sd_event_source_set_floating.xml @@ -0,0 +1,118 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_floating" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_floating</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_floating</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_floating</refname> + <refname>sd_event_source_get_floating</refname> + + <refpurpose>Set or retrieve 'floating' state of event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_floating</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int <parameter>floating</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_floating</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_floating()</function> takes a boolean and sets the 'floating' state + of the specified event source object. This is used to change the direction of reference counts for the + object and the event loop it is associated with. In non-floating mode, the event source object holds a + reference to the event loop object, but not vice versa. The creator of the event source object must hold + a reference to it as long as the source should exist. In floating mode, the event loop holds a reference + to the source object, and will decrease the reference count when being freed. This means that a reference + to the event loop should be held to prevent both from being destroyed.</para> + + <para>Various calls that allocate event source objects (i.e. + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry> and + similar) will automatically set an event source object to 'floating' mode if the caller passed + <constant>NULL</constant> in the parameter used to return a reference to the event source object. + Nevertheless, it may be necessary to gain temporary access to the source object, for example to adjust + event source properties after allocation (e.g. its priority or description string). In those cases the + object may be created in non-floating mode, and the returned reference used to adjust the properties, and + the object marked as floating afterwards, and the reference in the caller dropped.</para> + + <para><function>sd_event_source_get_floating()</function> may be used to query the current 'floating' + state of the event source object <parameter>source</parameter>. It returns zero if 'floating' mode is + off, positive if it is on.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_floating()</function> and + <function>sd_event_source_get_floating()</function> return a non-negative 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_prepare.xml b/man/sd_event_source_set_prepare.xml new file mode 100644 index 0000000..d52c55b --- /dev/null +++ b/man/sd_event_source_set_prepare.xml @@ -0,0 +1,142 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_prepare" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_prepare</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_prepare</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_prepare</refname> + + <refpurpose>Set a preparation callback for event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_prepare</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>sd_event_handler_t <parameter>callback</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>typedef int (*<function>sd_event_handler_t</function>)</funcdef> + <paramdef>sd_event_source *<parameter>s</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_prepare()</function> may be + used to set a preparation callback for the event source object + specified as <parameter>source</parameter>. The callback function + specified as <parameter>callback</parameter> will be invoked + immediately before the event loop goes to sleep to wait for + incoming events. It is invoked with the user data pointer passed + when the event source was created. The event source will be disabled + if the callback function returns a negative error code. The callback + function may be used to reconfigure the precise events to wait for. + If the <parameter>callback</parameter> parameter is passed as <constant>NULL</constant> + the callback function is reset. </para> + + <para>Event source objects have no preparation callback associated + when they are first created with calls such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Preparation + callback functions are supported for all event source types with + the exception of those created with + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Preparation + callback functions are dispatched in the order indicated by the + event source's priority field, as set with + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Preparation + callbacks of disabled event sources (see + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + are not invoked.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_prepare()</function> returns a non-negative integer. On + failure, it returns 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-EDOM</constant></term> + + <listitem><para>The specified event source has been created with + <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_priority.xml b/man/sd_event_source_set_priority.xml new file mode 100644 index 0000000..2616c12 --- /dev/null +++ b/man/sd_event_source_set_priority.xml @@ -0,0 +1,166 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_priority" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_priority</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_priority</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_priority</refname> + <refname>sd_event_source_get_priority</refname> + <refname>SD_EVENT_PRIORITY_IMPORTANT</refname> + <refname>SD_EVENT_PRIORITY_NORMAL</refname> + <refname>SD_EVENT_PRIORITY_IDLE</refname> + + <refpurpose>Set or retrieve the priority of event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>enum</token> { + <constant>SD_EVENT_PRIORITY_IMPORTANT</constant> = -100, + <constant>SD_EVENT_PRIORITY_NORMAL</constant> = 0, + <constant>SD_EVENT_PRIORITY_IDLE</constant> = 100, +};</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_source_set_priority</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int64_t <parameter>priority</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_source_get_priority</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>int64_t *<parameter>priority</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_priority()</function> may be + used to set the priority for the event source object specified as + <parameter>source</parameter>. The priority is specified as an + arbitrary signed 64bit integer. The priority is initialized to + <constant>SD_EVENT_PRIORITY_NORMAL</constant> (0) when the event + source is allocated with a call such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and may be changed with this call. If multiple event sources have seen events at the same time, they are dispatched in the order indicated by the + event sources' priorities. Event sources with smaller priority + values are dispatched first. As well-known points of reference, + the constants <constant>SD_EVENT_PRIORITY_IMPORTANT</constant> + (-100), <constant>SD_EVENT_PRIORITY_NORMAL</constant> (0) and + <constant>SD_EVENT_PRIORITY_IDLE</constant> (100) may be used to + indicate event sources that shall be dispatched early, normally or + late. It is recommended to specify priorities based on these + definitions, and relative to them — however, the full 64bit + signed integer range is available for ordering event + sources.</para> + + <para>Priorities define the order in which event sources that have + seen events are dispatched. Care should be taken to ensure that + high-priority event sources (those with negative priority values + assigned) do not cause starvation of low-priority event sources + (those with positive priority values assigned).</para> + + <para>The order in which event sources with the same priority are + dispatched is undefined, but the event loop generally tries to + dispatch them in the order it learnt about events on them. As the + backing kernel primitives do not provide accurate information + about the order in which events occurred this is not necessarily + reliable. However, it is guaranteed that if events are seen on + multiple same-priority event sources at the same time, each one is + not dispatched again until all others have been dispatched + once. This behavior guarantees that within each priority + particular event sources do not starve or dominate the event + loop.</para> + + <para>The priority of event sources may be changed at any time of their lifetime, with the exception of inotify + event sources (i.e. those created with + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>) whose + priority may only be changed in the time between their initial creation and the first subsequent event loop + iteration.</para> + + <para><function>sd_event_source_get_priority()</function> may be + used to query the current priority assigned to the event source + object <parameter>source</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_event_source_set_priority()</function> and + <function>sd_event_source_get_priority()</function> return a non-negative 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><parameter>source</parameter> is not a valid pointer to an + <structname>sd_event_source</structname> object.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Not enough memory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_set_userdata.xml b/man/sd_event_source_set_userdata.xml new file mode 100644 index 0000000..e8e5dc1 --- /dev/null +++ b/man/sd_event_source_set_userdata.xml @@ -0,0 +1,93 @@ +<?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-or-later --> + +<refentry id="sd_event_source_set_userdata" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_set_userdata</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_set_userdata</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_source_set_userdata</refname> + <refname>sd_event_source_get_userdata</refname> + + <refpurpose>Set or retrieve user data pointer of event sources</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>void* <function>sd_event_source_set_userdata</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>void *<parameter>userdata</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void* <function>sd_event_source_get_userdata</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_set_userdata()</function> may be + used to set an arbitrary user data pointer for the event source + object specified as <parameter>source</parameter>. The user data + pointer is usually specified when creating an event source object + with calls such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + and may be updated with this call. The user data pointer is also + passed to all handler callback functions associated with the event + source. The <parameter>userdata</parameter> parameter specifies + the new user data pointer to set, the function returns the + previous user data pointer. Note that <constant>NULL</constant> is + a valid user data pointer.</para> + + <para><function>sd_event_source_get_userdata()</function> may be + used to query the current user data pointer assigned to the event + source object <parameter>source</parameter>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>sd_event_source_set_userdata()</function> and + <function>sd_event_source_get_userdata()</function> return the + previously set user data pointer. On failure, they return + <constant>NULL</constant>.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_source_unref.xml b/man/sd_event_source_unref.xml new file mode 100644 index 0000000..a7699e3 --- /dev/null +++ b/man/sd_event_source_unref.xml @@ -0,0 +1,136 @@ +<?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-or-later --> + +<refentry id="sd_event_source_unref" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_source_unref</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_source_unref</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <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> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>sd_event_source* <function>sd_event_source_unref</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_event_source_unrefp</function></funcdef> + <paramdef>sd_event_source **<parameter>source</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_event_source* <function>sd_event_source_ref</function></funcdef> + <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> + + <refsect1> + <title>Description</title> + + <para><function>sd_event_source_unref()</function> may be used to + decrement by one the reference counter of the event source object + specified as <parameter>source</parameter>. The reference counter + is initially set to one, when the event source is created with calls + such as + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>. When + the reference counter reaches zero it is removed from its event loop + object and destroyed.</para> + + <para><function>sd_event_source_unrefp()</function> is similar to + <function>sd_event_source_unref()</function> but takes a pointer to a + pointer to an <type>sd_event_source</type> object. 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> + + <para><function>sd_event_source_ref()</function> may be used + to increase by one the reference counter of the event source object + specified as <parameter>source</parameter>.</para> + + <para><function>sd_event_source_unref()</function>, + <function>sd_bus_creds_unrefp()</function> and + <function>sd_bus_creds_ref()</function> execute no operation if + 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 + <function>sd_event_source_unref()</function> with a prior call to + <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> 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" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_event_wait.xml b/man/sd_event_wait.xml new file mode 100644 index 0000000..25e21b9 --- /dev/null +++ b/man/sd_event_wait.xml @@ -0,0 +1,324 @@ +<?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-or-later --> + +<refentry id="sd_event_wait" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_event_wait</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_event_wait</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_event_wait</refname> + <refname>sd_event_prepare</refname> + <refname>sd_event_dispatch</refname> + <refname>sd_event_get_state</refname> + <refname>sd_event_get_iteration</refname> + <refname>SD_EVENT_INITIAL</refname> + <refname>SD_EVENT_PREPARING</refname> + <refname>SD_EVENT_ARMED</refname> + <refname>SD_EVENT_PENDING</refname> + <refname>SD_EVENT_RUNNING</refname> + <refname>SD_EVENT_EXITING</refname> + <refname>SD_EVENT_FINISHED</refname> + + <refpurpose>Low-level event loop operations</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-event.h></funcsynopsisinfo> + + <funcsynopsisinfo><token>enum</token> { + <constant>SD_EVENT_INITIAL</constant>, + <constant>SD_EVENT_PREPARING</constant>, + <constant>SD_EVENT_ARMED</constant>, + <constant>SD_EVENT_PENDING</constant>, + <constant>SD_EVENT_RUNNING</constant>, + <constant>SD_EVENT_EXITING</constant>, + <constant>SD_EVENT_FINISHED</constant>, +};</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_event_prepare</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_wait</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_dispatch</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_get_state</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_event_get_iteration</function></funcdef> + <paramdef>sd_event *<parameter>event</parameter></paramdef> + <paramdef>uint64_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The low-level <function>sd_event_prepare()</function>, + <function>sd_event_wait()</function> and + <function>sd_event_dispatch()</function> functions may be used to + execute specific phases of an event loop. See + <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_event_loop</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for higher-level functions that execute individual but complete + iterations of an event loop or run it continuously.</para> + + <para><function>sd_event_prepare()</function> checks for pending + events and arms necessary timers. If any events are ready to be + processed ("pending"), it returns a positive, non-zero value, and the caller + should process these events with + <function>sd_event_dispatch()</function>.</para> + + <para><function>sd_event_dispatch()</function> dispatches the + highest priority event source that has a pending event. On + success, <function>sd_event_dispatch()</function> returns either + zero, which indicates that no further event sources may be + dispatched and exiting of the event loop was requested via + <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>; + or a positive non-zero value, which means that an event source was + dispatched and the loop returned to its initial state, and the + caller should initiate the next event loop iteration by invoking + <function>sd_event_prepare()</function> again.</para> + + <para>In case <function>sd_event_prepare()</function> returned + zero, <function>sd_event_wait()</function> should be called to + wait for further events or a timeout. If any events are ready to + be processed, it returns a positive, non-zero value, and the + events should be dispatched with + <function>sd_event_dispatch()</function>. Otherwise, the event + loop returned to its initial state and the next event loop + iteration should be initiated by invoking + <function>sd_event_prepare()</function> again.</para> + + <para><function>sd_event_get_state()</function> may be used to + determine the state the event loop is currently in. It returns one + of the states described below.</para> + + <para><function>sd_event_get_iteration()</function> may be used to determine the current iteration of the event + loop. It returns an unsigned 64bit integer containing a counter that increases monotonically with each iteration of + the event loop, starting with 0. The counter is increased at the time of the + <function>sd_event_prepare()</function> invocation.</para> + + <para>All five functions take, as the first argument, the event loop object <parameter>event</parameter> that has + been created with <function>sd_event_new()</function>. The timeout for <function>sd_event_wait()</function> is + specified in <parameter>usec</parameter> in microseconds. <constant>(uint64_t) -1</constant> may be used to + specify an infinite timeout.</para> +</refsect1> + + <refsect1> + <title>State Machine</title> + + <para>The event loop knows the following states, that may be + queried with <function>sd_event_get_state()</function>.</para> + + <variablelist> + <varlistentry> + <term><constant>SD_EVENT_INITIAL</constant></term> + + <listitem><para>The initial state the event loop is in, + before each event loop iteration. Use + <function>sd_event_prepare()</function> to transition the + event loop into the <constant>SD_EVENT_ARMED</constant> or + <constant>SD_EVENT_PENDING</constant> states.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_EVENT_PREPARING</constant></term> + + <listitem><para>An event source is currently being prepared, + i.e. the preparation handler is currently being executed, as + set with + <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This + state is only seen in the event source preparation handler + that is invoked from the + <function>sd_event_prepare()</function> call and is + immediately followed by <constant>SD_EVENT_ARMED</constant> or + <constant>SD_EVENT_PENDING</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_EVENT_ARMED</constant></term> + + <listitem><para><function>sd_event_prepare()</function> has + been called and no event sources were ready to be + dispatched. Use <function>sd_event_wait()</function> to wait + for new events, and transition into + <constant>SD_EVENT_PENDING</constant> or back into + <constant>SD_EVENT_INITIAL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_EVENT_PENDING</constant></term> + + <listitem><para><function>sd_event_prepare()</function> or + <function>sd_event_wait()</function> have been called and + there were event sources with events pending. Use + <function>sd_event_dispatch()</function> to dispatch the + highest priority event source and transition back to + <constant>SD_EVENT_INITIAL</constant>, or + <constant>SD_EVENT_FINISHED</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_EVENT_RUNNING</constant></term> + + <listitem><para>A regular event source is currently being + dispatched. This state is only seen in the event source + handler that is invoked from the + <function>sd_event_dispatch()</function> call, and is + immediately followed by <constant>SD_EVENT_INITIAL</constant> + or <constant>SD_EVENT_FINISHED</constant> as soon the event + source handler returns. Note that during dispatching of exit + event sources the <constant>SD_EVENT_EXITING</constant> state + is seen instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_EVENT_EXITING</constant></term> + + <listitem><para>Similar to + <constant>SD_EVENT_RUNNING</constant> but is the state in + effect while dispatching exit event sources. It is followed by + <constant>SD_EVENT_INITIAL</constant> or + <constant>SD_EVENT_FINISHED</constant> as soon as the event + handler returns.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SD_EVENT_FINISHED</constant></term> + + <listitem><para>The event loop has exited. All exit event + sources have run. If the event loop is in this state it serves + no purpose anymore, and should be freed.</para></listitem> + </varlistentry> + + </variablelist> + + <para>A simplified flow chart of the states and the calls to + transition between them is shown below. Note that + <constant>SD_EVENT_PREPARING</constant>, + <constant>SD_EVENT_RUNNING</constant> and + <constant>SD_EVENT_EXITING</constant> are not shown here.</para> + + <programlisting> + INITIAL -<---<---<---<---<---<---<---<---<---<---<---<---\ + | | + | ^ + | | + v ret == 0 | + sd_event_prepare() >--->--->--->--->- ARMED | + | | ^ + | ret > 0 | | + | | | + v v ret == 0 | + PENDING <---<---<---<---<---< sd_event_wait() >--->--->--+ + | ret > 0 ^ + | | + | | + v | + sd_event_dispatch() >--->--->--->--->--->--->--->--->--->--->/ + | ret > 0 + | ret == 0 + | + v + FINISHED + </programlisting> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return 0 or a positive integer. On failure, they return a negative + errno-style error code. In case of <function>sd_event_prepare()</function> and + <function>sd_event_wait()</function>, a positive, non-zero return code indicates that events are ready to + be processed and zero indicates that no events are ready. In case of + <function>sd_event_dispatch()</function>, a positive, non-zero return code indicates that the event loop + returned to its initial state and zero indicates the event loop has + exited. <function>sd_event_get_state()</function> returns a positive or zero state on success.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The <parameter>event</parameter> parameter is invalid or <constant>NULL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBUSY</constant></term> + + <listitem><para>The event loop object is not in the right state.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ESTALE</constant></term> + + <listitem><para>The event loop is already terminated.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The event loop has been created in a different process.</para></listitem> + + </varlistentry> + + </variablelist> + + <para>Other errors are possible, too.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_get_seats.xml b/man/sd_get_seats.xml new file mode 100644 index 0000000..818f968 --- /dev/null +++ b/man/sd_get_seats.xml @@ -0,0 +1,118 @@ +<?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-or-later --> + +<refentry id="sd_get_seats" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_get_seats</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_get_seats</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_get_seats</refname> + <refname>sd_get_sessions</refname> + <refname>sd_get_uids</refname> + <refname>sd_get_machine_names</refname> + <refpurpose>Determine available seats, sessions, logged in users and virtual machines/containers</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_get_seats</function></funcdef> + <paramdef>char ***<parameter>seats</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_get_sessions</function></funcdef> + <paramdef>char ***<parameter>sessions</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_get_uids</function></funcdef> + <paramdef>uid_t **<parameter>users</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_get_machine_names</function></funcdef> + <paramdef>char ***<parameter>machines</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_get_seats()</function> may be used to determine + all currently available local seats. Returns the number of seat + identifiers and if the input pointer is non-<constant>NULL</constant>, a + <constant>NULL</constant>-terminated array of seat identifiers + is stored at the address. + The returned array and all strings it references need to be freed + with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use. Note that instead of an empty array + <constant>NULL</constant> may be returned and should be considered + equivalent to an empty array.</para> + + <para>Similarly, <function>sd_get_sessions()</function> may be + used to determine all current login sessions.</para> + + <para>Similarly, <function>sd_get_uids()</function> may be used to + determine all Unix users who currently have login sessions.</para> + + <para>Similarly, <function>sd_get_machine_names()</function> may + be used to determine all current virtual machines and containers + on the system.</para> + + <para>Note that the returned lists are not sorted and in an + undefined order.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_get_seats()</function>, <function>sd_get_sessions()</function>, + <function>sd_get_uids()</function> and <function>sd_get_machine_names()</function> return the number of + entries in the arrays. On failure, these calls 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>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_session_get_seat</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_hwdb_get.xml b/man/sd_hwdb_get.xml new file mode 100644 index 0000000..6a6594f --- /dev/null +++ b/man/sd_hwdb_get.xml @@ -0,0 +1,157 @@ +<?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-or-later --> + +<refentry id="sd_hwdb_get" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_hwdb_get</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_hwdb_get</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_hwdb_get</refname> + <refname>sd_hwdb_seek</refname> + <refname>sd_hwdb_enumerate</refname> + <refname>SD_HWDB_FOREACH_PROPERTY</refname> + + <refpurpose>Seek to a location in hwdb or access entries</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-hwdb.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_hwdb_get</function></funcdef> + <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef> + <paramdef>const char *<parameter>modalias</parameter></paramdef> + <paramdef>const char *<parameter>key</parameter></paramdef> + <paramdef>const char **<parameter>value</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_hwdb_seek</function></funcdef> + <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef> + <paramdef>const char *<parameter>modalias</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_hwdb_enumerate</function></funcdef> + <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef> + <paramdef>const char **<parameter>key</parameter></paramdef> + <paramdef>const char **<parameter>value</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef><function>SD_HWDB_FOREACH_PROPERTY</function></funcdef> + <paramdef>hwdb</paramdef> + <paramdef>modalias</paramdef> + <paramdef>key</paramdef> + <paramdef>value</paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_hwdb_get()</function> queries the <parameter>hwdb</parameter> object created earlier + with <citerefentry><refentrytitle>sd_hwdb_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + entries matching the specified string <parameter>modalias</parameter>, and returns the value + corresponding to the key <parameter>key</parameter>. The value is returned as a + <constant>NUL</constant>-terminated string in <parameter>value</parameter>. It must not be modified by + the caller and is valid as long as a reference to <parameter>hwdb</parameter> is kept. When multiple + patterns in the database match <parameter>modalias</parameter>, the one with the highest priority is + used. See <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.</para> + + <para><function>sd_hwdb_seek()</function> selects entries matching the specified string + <parameter>modalias</parameter>. Subsequent queries with <function>sd_hwdb_enumerate()</function> will + access the key-value pairs for that string.</para> + + <para><function>sd_hwdb_enumerate()</function> returns (in turn) all the key-value pairs defined for the + string used with <function>sd_hwdb_seek()</function>. Each pair is returned as + <constant>NUL</constant>-terminated strings in <parameter>key</parameter> and + <parameter>value</parameter>. The strings must not be modified by the caller and are valid as long as a + reference to <parameter>hwdb</parameter> is kept. When multiple patterns in the database match + <parameter>modalias</parameter>, the combination of all matching key-value pairs is used. See + <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.</para> + + <para>The <function>SD_HWDB_FOREACH_PROPERTY()</function> macro combines + <function>sd_hwdb_seek()</function> and <function>sd_hwdb_enumerate()</function>. No error handling is + performed and iteration simply stops on error. See the example below.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_hwdb_get()</function> and <function>sd_hwdb_seek()</function> return a + non-negative integer. On failure, they return a negative errno-style error code.</para> + + <para><function>sd_hwdb_enumerate()</function> returns a positive integer if another key-value pair was found or zero if + all entries have already been enumerated. On failure, it returns 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>A parameter is <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOENT</constant></term> + + <listitem><para>An entry for the specified <parameter>modalias</parameter> was not found. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EAGAIN</constant></term> + + <listitem><para><function>sd_hwdb_seek()</function> was not called before + <function>sd_hwdb_enumerate()</function>.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Look up hwdb entries for a USB device</title> + + <programlisting><xi:include href="hwdb-usb-device.c" parse="text" /></programlisting> + + <para>The effect is similar to calling <command>systemd-hwdb query usb:v046DpC534</command>. + </para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_hwdb_new.xml b/man/sd_hwdb_new.xml new file mode 100644 index 0000000..c071599 --- /dev/null +++ b/man/sd_hwdb_new.xml @@ -0,0 +1,121 @@ +<?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-or-later --> + +<refentry id="sd_hwdb_new" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>sd_hwdb_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_hwdb_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_hwdb_new</refname> + <refname>sd_hwdb_ref</refname> + <refname>sd_hwdb_unref</refname> + + <refpurpose>Create a new hwdb object and create or destroy references to it</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-hwdb.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_hwdb_new</function></funcdef> + <paramdef>sd_hwdb **<parameter>hwdb</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_hwdb* <function>sd_hwdb_ref</function></funcdef> + <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_hwdb* <function>sd_hwdb_unref</function></funcdef> + <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_hwdb_new()</function> creates a new hwdb object to access the binary hwdb + database. Upon initialization, the file containing the binary representation of the hardware database is + located and opened. The new object is returned in <parameter>hwdb</parameter>.</para> + + <para>The <parameter>hwdb</parameter> object is reference counted. <function>sd_hwdb_ref()</function> and + <function>sd_hwdb_unref()</function> may be used to get a new reference or destroy an existing reference + to an object. The caller must dispose of the reference acquired with <function>sd_hwdb_new()</function> + by calling <function>sd_hwdb_unref()</function> when done with the object.</para> + + <para>Use + <citerefentry><refentrytitle>sd_hwdb_seek</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_hwdb_get</refentrytitle><manvolnum>3</manvolnum></citerefentry>, and + <citerefentry><refentrytitle>sd_hwdb_enumerate</refentrytitle><manvolnum>3</manvolnum></citerefentry> to + access entries.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_hwdb_new()</function> returns a non-negative integer. On + failure, it returns a negative errno-style error code.</para> + + <para><function>sd_hwdb_ref()</function> always returns the argument. + </para> + + <para><function>sd_hwdb_unref()</function> always returns <constant>NULL</constant>. + </para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOENT</constant></term> + + <listitem><para>The binary hardware database file could not be located. See + <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for more information.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>The located binary hardware database file is in an incompatible format. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_id128_get_machine.xml b/man/sd_id128_get_machine.xml new file mode 100644 index 0000000..2df4496 --- /dev/null +++ b/man/sd_id128_get_machine.xml @@ -0,0 +1,208 @@ +<?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-or-later --> + +<refentry id="sd_id128_get_machine" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_id128_get_machine</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_id128_get_machine</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_id128_get_machine</refname> + <refname>sd_id128_get_machine_app_specific</refname> + <refname>sd_id128_get_boot</refname> + <refname>sd_id128_get_boot_app_specific</refname> + <refname>sd_id128_get_invocation</refname> + <refpurpose>Retrieve 128-bit IDs</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-id128.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_id128_get_machine</function></funcdef> + <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_id128_get_machine_app_specific</function></funcdef> + <paramdef>sd_id128_t <parameter>app_id</parameter></paramdef> + <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_id128_get_boot</function></funcdef> + <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_id128_get_boot_app_specific</function></funcdef> + <paramdef>sd_id128_t <parameter>app_id</parameter></paramdef> + <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_id128_get_invocation</function></funcdef> + <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_id128_get_machine()</function> returns the machine ID of the executing host. This reads and + parses the <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + file. This function caches the machine ID internally to make retrieving the machine ID a cheap operation. This ID + may be used wherever a unique identifier for the local system is needed. However, it is recommended to use this ID + as-is only in trusted environments. In untrusted environments it is recommended to derive an application specific + ID from this machine ID, in an irreversible (cryptographically secure) way. To make this easy + <function>sd_id128_get_machine_app_specific()</function> is provided, see below.</para> + + <para><function>sd_id128_get_machine_app_specific()</function> is similar to + <function>sd_id128_get_machine()</function>, but retrieves a machine ID that is specific to the application that is + identified by the indicated application ID. It is recommended to use this function instead of + <function>sd_id128_get_machine()</function> when passing an ID to untrusted environments, in order to make sure + that the original machine ID may not be determined externally. This way, the ID used by the application remains + stable on a given machine, but cannot be easily correlated with IDs used in other applications on the same + machine. The application-specific ID should be generated via a tool like <command>systemd-id128 new</command>, + and may be compiled into the application. This function will return the same application-specific ID for each + combination of machine ID and application ID. Internally, this function calculates HMAC-SHA256 of the application + ID, keyed by the machine ID.</para> + + <para><function>sd_id128_get_boot()</function> returns the boot ID of the executing kernel. This reads and parses + the <filename>/proc/sys/kernel/random/boot_id</filename> file exposed by the kernel. It is randomly generated early + at boot and is unique for every running kernel instance. See <citerefentry + project='man-pages'><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more + information. This function also internally caches the returned ID to make this call a cheap operation. It is + recommended to use this ID as-is only in trusted environments. In untrusted environments it is recommended to + derive an application specific ID using <function>sd_id128_get_machine_app_specific()</function>, see below.</para> + + <para><function>sd_id128_get_boot_app_specific()</function> is analogous to + <function>sd_id128_get_machine_app_specific()</function> but returns an ID that changes between boots. Some + machines may be used for a long time without rebooting, hence the boot ID may remain constant for a long time, and + has properties similar to the machine ID during that time.</para> + + <para><function>sd_id128_get_invocation()</function> returns the invocation ID of the currently executed + service. In its current implementation, this reads and parses the <varname>$INVOCATION_ID</varname> environment + variable that the service manager sets when activating a service, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. The + ID is cached internally. In future a different mechanism to determine the invocation ID may be added.</para> + + <para>Note that <function>sd_id128_get_machine_app_specific()</function>, <function>sd_id128_get_boot()</function>, + <function>sd_id128_get_boot_app_specific()</function>, and <function>sd_id128_get_invocation()</function> always + return UUID v4 compatible IDs. <function>sd_id128_get_machine()</function> will also return a UUID v4-compatible + ID on new installations but might not on older. It is possible to convert the machine ID into a UUID v4-compatible + one. For more information, see + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>For more information about the <literal>sd_id128_t</literal> + type see + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>Those calls return 0 on success (in which case <parameter>ret</parameter> is filled in), + or a negative errno-style error code.</para> + + <refsect2> + <title>Errors</title> + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-ENOENT</constant></term> + + <listitem><para>Returned by <function>sd_id128_get_machine()</function>, + <function>sd_id128_get_machine_app_specific()</function>, and + <function>sd_id128_get_boot_app_specific()</function> when <filename>/etc/machine-id</filename> is + missing.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEDIUM</constant></term> + + <listitem><para>Returned by <function>sd_id128_get_machine()</function>, + <function>sd_id128_get_machine_app_specific()</function>, and + <function>sd_id128_get_boot_app_specific()</function> when <filename>/etc/machine-id</filename> is + empty or all zeros.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>Returned by <function>sd_id128_get_invocation()</function> if no invocation ID is + set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EIO</constant></term> + + <listitem><para>Returned by any of the functions described here when the configured value has + invalid format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Requested information could not be retrieved because of insufficient permissions. + </para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Application-specific machine ID</title> + + <para>First, generate the application ID:</para> + <programlisting>$ systemd-id128 -p new +As string: +c273277323db454ea63bb96e79b53e97 + +As UUID: +c2732773-23db-454e-a63b-b96e79b53e97 + +As man:sd-id128(3) macro: +#define MESSAGE_XYZ SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97) +... +</programlisting> + + <para>Then use the new identifier in an example application:</para> + + <programlisting><xi:include href="id128-app-specific.c" parse="text" /></programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_id128_randomize.xml b/man/sd_id128_randomize.xml new file mode 100644 index 0000000..cf6ca77 --- /dev/null +++ b/man/sd_id128_randomize.xml @@ -0,0 +1,79 @@ +<?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-or-later --> + +<refentry id="sd_id128_randomize" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_id128_randomize</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_id128_randomize</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_id128_randomize</refname> + <refpurpose>Generate 128-bit IDs</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-id128.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_id128_randomize</function></funcdef> + <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_id128_randomize()</function> generates a new + randomized 128-bit ID and returns it in + <parameter>ret</parameter>. Every invocation returns a new + randomly generated ID. This uses the + <filename>/dev/urandom</filename> kernel random number + generator.</para> + + <para>Note that <function>sd_id128_randomize()</function> always + returns a UUID v4-compatible ID.</para> + + <para>For more information about the <literal>sd_id128_t</literal> + type, see + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para><citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>new</command> command may be used as a command line front-end for + <function>sd_id128_randomize()</function>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The call returns 0 on success (in which case + <parameter>ret</parameter> is filled in), or a negative + errno-style error code.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_id128_to_string.xml b/man/sd_id128_to_string.xml new file mode 100644 index 0000000..54cab1a --- /dev/null +++ b/man/sd_id128_to_string.xml @@ -0,0 +1,94 @@ +<?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-or-later --> + +<refentry id="sd_id128_to_string" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_id128_to_string</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_id128_to_string</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_id128_to_string</refname> + <refname>sd_id128_from_string</refname> + <refpurpose>Format or parse 128-bit IDs as strings</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-id128.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>char *<function>sd_id128_to_string</function></funcdef> + <paramdef>sd_id128_t <parameter>id</parameter>, char <parameter>s</parameter>[33]</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_id128_from_string</function></funcdef> + <paramdef>const char *<parameter>s</parameter>, sd_id128_t *<parameter>ret</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_id128_to_string()</function> formats a 128-bit + ID as a character string. It expects the ID and a string array + capable of storing 33 characters. The ID will be formatted as 32 + lowercase hexadecimal digits and be terminated by a + <constant>NUL</constant> byte.</para> + + <para><function>sd_id128_from_string()</function> implements the reverse operation: it takes a 33 character string + with 32 hexadecimal digits (either lowercase or uppercase, terminated by <constant>NUL</constant>) and parses them + back into a 128-bit ID returned in <parameter>ret</parameter>. Alternatively, this call can also parse a + 37-character string with a 128-bit ID formatted as RFC UUID. If <parameter>ret</parameter> is passed as + <constant>NULL</constant> the function will validate the passed ID string, but not actually return it in parsed + form.</para> + + <para>For more information about the <literal>sd_id128_t</literal> + type see + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Note that these calls operate the same way on all architectures, + i.e. the results do not depend on endianness.</para> + + <para>When formatting a 128-bit ID into a string, it is often + easier to use a format string for + <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This is easily done using the + <constant>SD_ID128_FORMAT_STR</constant> and <function>SD_ID128_FORMAT_VAL()</function> macros. For + more information see + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_id128_to_string()</function> always succeeds + and returns a pointer to the string array passed in. + <function>sd_id128_from_string()</function> returns 0 on success, in + which case <parameter>ret</parameter> is filled in, or a negative + errno-style error code.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_is_fifo.xml b/man/sd_is_fifo.xml new file mode 100644 index 0000000..99f1524 --- /dev/null +++ b/man/sd_is_fifo.xml @@ -0,0 +1,201 @@ +<?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-or-later --> + +<refentry id="sd_is_fifo" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_is_fifo</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_is_fifo</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_is_fifo</refname> + <refname>sd_is_socket</refname> + <refname>sd_is_socket_inet</refname> + <refname>sd_is_socket_unix</refname> + <refname>sd_is_socket_sockaddr</refname> + <refname>sd_is_mq</refname> + <refname>sd_is_special</refname> + <refpurpose>Check the type of a file descriptor</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-daemon.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_is_fifo</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_is_socket</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>family</parameter></paramdef> + <paramdef>int <parameter>type</parameter></paramdef> + <paramdef>int <parameter>listening</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_is_socket_inet</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>family</parameter></paramdef> + <paramdef>int <parameter>type</parameter></paramdef> + <paramdef>int <parameter>listening</parameter></paramdef> + <paramdef>uint16_t <parameter>port</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_is_socket_sockaddr</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>type</parameter></paramdef> + <paramdef>const struct sockaddr *<parameter>addr</parameter></paramdef> + <paramdef>unsigned <parameter>addr_len</parameter></paramdef> + <paramdef>int <parameter>listening</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_is_socket_unix</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>type</parameter></paramdef> + <paramdef>int <parameter>listening</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>size_t <parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_is_mq</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_is_special</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_is_fifo()</function> may be called to check + whether the specified file descriptor refers to a FIFO or pipe. If + the <parameter>path</parameter> parameter is not + <constant>NULL</constant>, it is checked whether the FIFO is bound + to the specified file system path.</para> + + <para><function>sd_is_socket()</function> may be called to check + whether the specified file descriptor refers to a socket. If the + <parameter>family</parameter> parameter is not + <constant>AF_UNSPEC</constant>, it is checked whether the socket + is of the specified family (<constant>AF_UNIX</constant>, + <constant>AF_INET</constant>, …). If the <parameter>type</parameter> + parameter is not 0, it is checked whether the socket is of the + specified type (<constant>SOCK_STREAM</constant>, + <constant>SOCK_DGRAM</constant>, …). If the + <parameter>listening</parameter> parameter is positive, it is + checked whether the socket is in accepting mode, i.e. + <function>listen()</function> has been called for it. If + <parameter>listening</parameter> is 0, it is checked whether the + socket is not in this mode. If the parameter is negative, no such + check is made. The <parameter>listening</parameter> parameter + should only be used for stream sockets and should be set to a + negative value otherwise.</para> + + <para><function>sd_is_socket_inet()</function> is similar to + <function>sd_is_socket()</function>, but optionally checks the + IPv4 or IPv6 port number the socket is bound to, unless + <parameter>port</parameter> is zero. For this call + <parameter>family</parameter> must be passed as either + <constant>AF_UNSPEC</constant>, <constant>AF_INET</constant>, or + <constant>AF_INET6</constant>.</para> + + <para><function>sd_is_socket_sockaddr()</function> is similar to + <function>sd_is_socket_inet()</function>, but checks if the socket is bound to the + address specified by <parameter>addr</parameter>. The + <structfield>family</structfield> specified by <parameter>addr</parameter> must be + either <constant>AF_INET</constant> or <constant>AF_INET6</constant> and + <parameter>addr_len</parameter> must be large enough for that family. If + <parameter>addr</parameter> specifies a non-zero port, it is also checked if the + socket is bound to this port. In addition, for IPv6, if <parameter>addr</parameter> + specifies non-zero <structfield>sin6_flowinfo</structfield> or + <structfield>sin6_scope_id</structfield>, it is checked if the socket has the same + values.</para> + + <para><function>sd_is_socket_unix()</function> is similar to + <function>sd_is_socket()</function> but optionally checks the + <constant>AF_UNIX</constant> path the socket is bound to, unless + the <parameter>path</parameter> parameter is + <constant>NULL</constant>. For normal file system + <constant>AF_UNIX</constant> sockets, set the + <parameter>length</parameter> parameter to 0. For Linux abstract + namespace sockets, set the <parameter>length</parameter> to the + size of the address, including the initial 0 byte, and set the + <parameter>path</parameter> to the initial 0 byte of the socket + address.</para> + + <para><function>sd_is_mq()</function> may be called to check + whether the specified file descriptor refers to a POSIX message + queue. If the <parameter>path</parameter> parameter is not + <constant>NULL</constant>, it is checked whether the message queue + is bound to the specified name.</para> + + <para><function>sd_is_special()</function> may be called to check + whether the specified file descriptor refers to a special file. If + the <parameter>path</parameter> parameter is not + <constant>NULL</constant>, it is checked whether the file + descriptor is bound to the specified filename. Special files in + this context are character device nodes and files in + <filename>/proc/</filename> or <filename>/sys/</filename>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, these calls return a negative errno-style error + code. If the file descriptor is of the specified type and bound to + the specified address, a positive return value is returned, + otherwise zero.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + + <para>Internally, these function use a combination of + <filename>fstat()</filename> and + <filename>getsockname()</filename> to check the file descriptor + type and where it is bound to.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fifo</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_add_match.xml b/man/sd_journal_add_match.xml new file mode 100644 index 0000000..f7f5ee3 --- /dev/null +++ b/man/sd_journal_add_match.xml @@ -0,0 +1,177 @@ +<?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-or-later --> + +<refentry id="sd_journal_add_match" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_add_match</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_add_match</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_add_match</refname> + <refname>sd_journal_add_disjunction</refname> + <refname>sd_journal_add_conjunction</refname> + <refname>sd_journal_flush_matches</refname> + <refpurpose>Add or remove entry matches</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_add_match</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void *<parameter>data</parameter></paramdef> + <paramdef>size_t <parameter>size</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_add_disjunction</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_add_conjunction</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_journal_flush_matches</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_add_match()</function> adds a match by + which to filter the entries of the journal file. Matches applied + with this call will filter what can be iterated through and read + from the journal file via calls like + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Parameter <parameter>data</parameter> must be of the form + <literal><replaceable>FIELD</replaceable>=<replaceable>value</replaceable></literal>, + where the <replaceable>FIELD</replaceable> part is a short uppercase string consisting only + of 0–9, A–Z and the underscore; it may not begin with two underscores or be the empty + string. The <replaceable>value</replaceable> part may be anything, including binary. Parameter + <parameter>size</parameter> specifies the number of bytes in <parameter>data</parameter> + (i.e. the length of <replaceable>FIELD</replaceable>, plus one, plus the length of + <replaceable>value</replaceable>). Parameter <parameter>size</parameter> may also be + specified as <constant>0</constant>, in which case <parameter>data</parameter> + must be a <constant>NUL</constant>-terminated string, and the bytes before the terminating + zero are used as the match.</para> + + <para>If a match is applied, only entries with this field set + will be iterated. Multiple matches may be active at the same time: + If they apply to different fields, only entries with both fields + set like this will be iterated. If they apply to the same fields, + only entries where the field takes one of the specified values + will be iterated. Well known fields are documented in + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + Whenever a new match is added the current entry position is reset, + and + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + (or a similar call) needs to be called before entries can be read + again.</para> + + <para><function>sd_journal_add_disjunction()</function> may be + used to insert a disjunction (i.e. logical OR) in the match list. + If this call is invoked, all previously added matches since the + last invocation of + <function>sd_journal_add_disjunction()</function> or + <function>sd_journal_add_conjunction()</function> are combined in + an OR with all matches added afterwards, until + <function>sd_journal_add_disjunction()</function> or + <function>sd_journal_add_conjunction()</function> is invoked again + to begin the next OR or AND term. </para> + + <para><function>sd_journal_add_conjunction()</function> may be + used to insert a conjunction (i.e. logical AND) in the match list. + If this call is invoked, all previously added matches since the + last invocation of + <function>sd_journal_add_conjunction()</function> are combined in + an AND with all matches added afterwards, until + <function>sd_journal_add_conjunction()</function> is invoked again + to begin the next AND term. The combination of + <function>sd_journal_add_match()</function>, + <function>sd_journal_add_disjunction()</function> and + <function>sd_journal_add_conjunction()</function> may be used to + build complex search terms, even though full logical expressions + are not available. Note that + <function>sd_journal_add_conjunction()</function> operates one + level 'higher' than + <function>sd_journal_add_disjunction()</function>. It is hence + possible to build an expression of AND terms, consisting of OR + terms, consisting of AND terms, consisting of OR terms of matches + (the latter OR expression is implicitly created for matches with + the same field name, see above).</para> + + <para><function>sd_journal_flush_matches()</function> may be used + to flush all matches, disjunction and conjunction terms again. + After this call all filtering is removed and all entries in the + journal will be iterated again.</para> + + <para>Note that filtering via matches only applies to the way the + journal is read, it has no effect on storage on disk.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_add_match()</function>, + <function>sd_journal_add_disjunction()</function> and + <function>sd_journal_add_conjunction()</function> + return 0 on success or a negative errno-style error + code. <function>sd_journal_flush_matches()</function> + returns nothing.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>Examples</title> + + <para>The following example adds matches to a journal context + object to iterate only through messages generated by the Avahi + service at the four error log levels, plus all messages of the + message ID 03bb1dab98ab4ecfbf6fff2738bdd964 coming from any + service (this example lacks the necessary error checking):</para> + + <programlisting>… +int add_matches(sd_journal *j) { + sd_journal_add_match(j, "_SYSTEMD_UNIT=avahi-daemon.service", 0); + sd_journal_add_match(j, "PRIORITY=0", 0); + sd_journal_add_match(j, "PRIORITY=1", 0); + sd_journal_add_match(j, "PRIORITY=2", 0); + sd_journal_add_match(j, "PRIORITY=3", 0); + sd_journal_add_disjunction(j); + sd_journal_add_match(j, "MESSAGE_ID=03bb1dab98ab4ecfbf6fff2738bdd964", 0); +}</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_enumerate_fields.xml b/man/sd_journal_enumerate_fields.xml new file mode 100644 index 0000000..e074906 --- /dev/null +++ b/man/sd_journal_enumerate_fields.xml @@ -0,0 +1,133 @@ +<?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-or-later --> + +<refentry id="sd_journal_enumerate_fields" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_enumerate_fields</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_enumerate_fields</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_enumerate_fields</refname> + <refname>sd_journal_restart_fields</refname> + <refname>SD_JOURNAL_FOREACH_FIELD</refname> + <refpurpose>Read used field names from the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_enumerate_fields</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const char **<parameter>field</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_journal_restart_fields</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef><function>SD_JOURNAL_FOREACH_FIELD</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const char *<parameter>field</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_enumerate_fields()</function> may be used to iterate through all field names used in the + opened journal files. On each invocation the next field name is returned. The order of the returned field names is + not defined. It takes two arguments: the journal context object, plus a pointer to a constant string pointer where + the field name is stored in. The returned data is in a read-only memory map and is only valid until the next + invocation of <function>sd_journal_enumerate_fields()</function>. Note that this call is subject to the data field + size threshold as controlled by <function>sd_journal_set_data_threshold()</function>.</para> + + <para><function>sd_journal_restart_fields()</function> resets the field name enumeration index to the beginning of + the list. The next invocation of <function>sd_journal_enumerate_fields()</function> will return the first field + name again.</para> + + <para>The <function>SD_JOURNAL_FOREACH_FIELD()</function> macro may be used as a handy wrapper around + <function>sd_journal_restart_fields()</function> and <function>sd_journal_enumerate_fields()</function>.</para> + + <para>These functions currently are not influenced by matches set with <function>sd_journal_add_match()</function> + but this might change in a later version of this software.</para> + + <para>To retrieve the possible values a specific field can take use + <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_enumerate_fields()</function> returns a + positive integer if the next field name has been read, 0 when no + more field names are known, or a negative errno-style error code. + <function>sd_journal_restart_fields()</function> returns + nothing.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict" /> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Use the <function>SD_JOURNAL_FOREACH_FIELD()</function> macro to iterate through all field names in use in the + current journal.</para> + + <programlisting>#include <stdio.h> +#include <string.h> +#include <systemd/sd-journal.h> + +int main(int argc, char *argv[]) { + sd_journal *j; + const char *field; + int r; + + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); + return 1; + } + SD_JOURNAL_FOREACH_FIELD(j, field) + printf("%s\n", field); + sd_journal_close(j); + return 0; +}</programlisting> + + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_catalog.xml b/man/sd_journal_get_catalog.xml new file mode 100644 index 0000000..ad5992f --- /dev/null +++ b/man/sd_journal_get_catalog.xml @@ -0,0 +1,113 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_catalog" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_catalog</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_catalog</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_catalog</refname> + <refname>sd_journal_get_catalog_for_message_id</refname> + <refpurpose>Retrieve message catalog entry</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_catalog</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>char **<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_get_catalog_for_message_id</function></funcdef> + <paramdef>sd_id128_t <parameter>id</parameter></paramdef> + <paramdef>char **<parameter>ret</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_catalog()</function> retrieves a + message catalog entry for the current journal entry. This will + look up an entry in the message catalog by using the + <literal>MESSAGE_ID=</literal> field of the current journal entry. + Before returning the entry all journal field names in the catalog + entry text enclosed in "@" will be replaced by the respective + field values of the current entry. If a field name referenced in + the message catalog entry does not exist, in the current journal + entry, the "@" will be removed, but the field name otherwise left + untouched.</para> + + <para><function>sd_journal_get_catalog_for_message_id()</function> + works similar to <function>sd_journal_get_catalog()</function> but + the entry is looked up by the specified message ID (no open + journal context is necessary for this), and no field substitution + is performed.</para> + + <para>For more information about the journal message catalog + please refer to the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/catalog">Journal + Message Catalogs</ulink> documentation page.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_catalog()</function> and + <function>sd_journal_get_catalog_for_message_id()</function> + return 0 on success or a negative errno-style error code. If no + matching message catalog entry is found, -ENOENT is + returned.</para> + + <para>On successful return, <parameter>ret</parameter> points to a + new string, which must be freed with + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <para>Function <function>sd_journal_get_catalog()</function> is thread-agnostic and only + a single specific thread may operate on a given object during its entire lifetime. It's safe to allocate multiple + independent objects and use each from a specific thread in parallel. However, it's not safe to allocate such an + object in one thread, and operate or free it from any other, even if locking is used to ensure these threads don't + operate on it at the very same time.</para> + + <para>Function <function>sd_journal_get_catalog_for_message_id()</function> is are thread-safe and may be called in + parallel from multiple threads.</para> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>malloc</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_cursor.xml b/man/sd_journal_get_cursor.xml new file mode 100644 index 0000000..acaba06 --- /dev/null +++ b/man/sd_journal_get_cursor.xml @@ -0,0 +1,114 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_cursor" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_cursor</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_cursor</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_cursor</refname> + <refname>sd_journal_test_cursor</refname> + <refpurpose>Get cursor string for or test cursor string against the current journal entry</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_cursor</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>char **<parameter>cursor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_test_cursor</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const char *<parameter>cursor</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_cursor()</function> returns a + cursor string for the current journal entry. A cursor is a + serialization of the current journal position formatted as text. + The string only contains printable characters and can be passed + around in text form. The cursor identifies a journal entry + globally and in a stable way and may be used to later seek to it + via + <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + The cursor string should be considered opaque and not be parsed by + clients. Seeking to a cursor position without the specific entry + being available locally will seek to the next closest (in terms of + time) available entry. The call takes two arguments: a journal + context object and a pointer to a string pointer where the cursor + string will be placed. The string is allocated via libc + <citerefentry project='man-pages'><refentrytitle>malloc</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and should be freed after use with + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Note that <function>sd_journal_get_cursor()</function> will + not work before + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + (or related call) has been called at least once, in order to + position the read pointer at a valid entry.</para> + + <para><function>sd_journal_test_cursor()</function> + may be used to check whether the current position in + the journal matches the specified cursor. This is + useful since cursor strings do not uniquely identify + an entry: the same entry might be referred to by + multiple different cursor strings, and hence string + comparing cursors is not possible. Use this call to + verify after an invocation of + <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry> + whether the entry being sought to was actually found + in the journal or the next closest entry was used + instead.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_cursor()</function> returns 0 on + success or a negative errno-style error code. + <function>sd_journal_test_cursor()</function> returns positive if + the current entry matches the specified cursor, 0 if it does not + match the specified cursor or a negative errno-style error code on + failure.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict" /> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_cutoff_realtime_usec.xml b/man/sd_journal_get_cutoff_realtime_usec.xml new file mode 100644 index 0000000..445130e --- /dev/null +++ b/man/sd_journal_get_cutoff_realtime_usec.xml @@ -0,0 +1,114 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_cutoff_realtime_usec" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_cutoff_realtime_usec</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_cutoff_realtime_usec</refname> + <refname>sd_journal_get_cutoff_monotonic_usec</refname> + <refpurpose>Read cut-off timestamps from the current journal entry</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_cutoff_realtime_usec</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t *<parameter>from</parameter></paramdef> + <paramdef>uint64_t *<parameter>to</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_get_cutoff_monotonic_usec</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>sd_id128_t <parameter>boot_id</parameter></paramdef> + <paramdef>uint64_t *<parameter>from</parameter></paramdef> + <paramdef>uint64_t *<parameter>to</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_cutoff_realtime_usec()</function> + retrieves the realtime (wallclock) timestamps of the first and + last entries accessible in the journal. It takes three arguments: + the journal context object <parameter>j</parameter> and two + pointers <parameter>from</parameter> and <parameter>to</parameter> + pointing at 64-bit unsigned integers to store the timestamps in. + The timestamps are in microseconds since the epoch, i.e. + <constant>CLOCK_REALTIME</constant>. Either one of the two + timestamp arguments may be passed as <constant>NULL</constant> in + case the timestamp is not needed, but not both.</para> + + <para><function>sd_journal_get_cutoff_monotonic_usec()</function> + retrieves the monotonic timestamps of the first and last entries + accessible in the journal. It takes three arguments: the journal + context object <parameter>j</parameter>, a 128-bit identifier for + the boot <parameter>boot_id</parameter>, and two pointers to + 64-bit unsigned integers to store the timestamps, + <parameter>from</parameter> and <parameter>to</parameter>. The + timestamps are in microseconds since boot-up of the specific boot, + i.e. <constant>CLOCK_MONOTONIC</constant>. Since the monotonic + clock begins new with every reboot it only defines a well-defined + point in time when used together with an identifier identifying + the boot, see + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information. The function will return the timestamps for + the boot identified by the passed boot ID. Either one of the two + timestamp arguments may be passed as <constant>NULL</constant> in + case the timestamp is not needed, but not both.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_cutoff_realtime_usec()</function> + and <function>sd_journal_get_cutoff_monotonic_usec()</function> + return 1 on success, 0 if not suitable entries are in the journal + or a negative errno-style error code.</para> + + <para>Locations pointed to by parameters + <parameter>from</parameter> and <parameter>to</parameter> will be + set only if the return value is positive, and obviously, the + parameters are non-null.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict" /> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_data.xml b/man/sd_journal_get_data.xml new file mode 100644 index 0000000..2955cd2 --- /dev/null +++ b/man/sd_journal_get_data.xml @@ -0,0 +1,276 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_data" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_data</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_data</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_data</refname> + <refname>sd_journal_enumerate_data</refname> + <refname>sd_journal_enumerate_available_data</refname> + <refname>sd_journal_restart_data</refname> + <refname>SD_JOURNAL_FOREACH_DATA</refname> + <refname>sd_journal_set_data_threshold</refname> + <refname>sd_journal_get_data_threshold</refname> + <refpurpose>Read data fields from the current journal entry</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_data</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const char *<parameter>field</parameter></paramdef> + <paramdef>const void **<parameter>data</parameter></paramdef> + <paramdef>size_t *<parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_enumerate_data</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void **<parameter>data</parameter></paramdef> + <paramdef>size_t *<parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_enumerate_available_data</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void **<parameter>data</parameter></paramdef> + <paramdef>size_t *<parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_journal_restart_data</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef><function>SD_JOURNAL_FOREACH_DATA</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void *<parameter>data</parameter></paramdef> + <paramdef>size_t <parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_set_data_threshold</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>size_t <parameter>sz</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_get_data_threshold</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>size_t *<parameter>sz</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_data()</function> gets the data object associated with a specific field + from the current journal entry. It takes four arguments: the journal context object, a string with the + field name to request, plus a pair of pointers to pointer/size variables where the data object and its + size shall be stored in. The field name should be an entry field name. Well-known field names are listed in + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + but any field can be specified. The returned data is in a read-only memory map and is only valid until + the next invocation of <function>sd_journal_get_data()</function>, + <function>sd_journal_enumerate_data()</function>, + <function>sd_journal_enumerate_available_data()</function>, or when the read pointer is altered. Note + that the data returned will be prefixed with the field name and <literal>=</literal>. Also note that, by + default, data fields larger than 64K might get truncated to 64K. This threshold may be changed and turned + off with <function>sd_journal_set_data_threshold()</function> (see below).</para> + + <para><function>sd_journal_enumerate_data()</function> may be used + to iterate through all fields of the current entry. On each + invocation the data for the next field is returned. The order of + these fields is not defined. The data returned is in the same + format as with <function>sd_journal_get_data()</function> and also + follows the same life-time semantics.</para> + + <para><function>sd_journal_enumerate_available_data()</function> is similar to + <function>sd_journal_enumerate_data()</function>, but silently skips any fields which may be valid, but + are too large or not supported by current implementation.</para> + + <para><function>sd_journal_restart_data()</function> resets the + data enumeration index to the beginning of the entry. The next + invocation of <function>sd_journal_enumerate_data()</function> + will return the first field of the entry again.</para> + + <para>Note that the <function>SD_JOURNAL_FOREACH_DATA()</function> macro may be used as a handy wrapper + around <function>sd_journal_restart_data()</function> and + <function>sd_journal_enumerate_available_data()</function>.</para> + + <para>Note that these functions will not work before + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + (or related call) has been called at least once, in order to + position the read pointer at a valid entry.</para> + + <para><function>sd_journal_set_data_threshold()</function> may be + used to change the data field size threshold for data returned by + <function>sd_journal_get_data()</function>, + <function>sd_journal_enumerate_data()</function> and + <function>sd_journal_enumerate_unique()</function>. This threshold + is a hint only: it indicates that the client program is interested + only in the initial parts of the data fields, up to the threshold + in size — but the library might still return larger data objects. + That means applications should not rely exclusively on this + setting to limit the size of the data fields returned, but need to + apply an explicit size limit on the returned data as well. This + threshold defaults to 64K by default. To retrieve the complete + data fields this threshold should be turned off by setting it to + 0, so that the library always returns the complete data objects. + It is recommended to set this threshold as low as possible since + this relieves the library from having to decompress large + compressed data objects in full.</para> + + <para><function>sd_journal_get_data_threshold()</function> returns + the currently configured data field size threshold.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_data()</function> returns 0 on success or a negative errno-style error + code. <function>sd_journal_enumerate_data()</function> and + <function>sd_journal_enumerate_available_data()</function> return a positive integer if the next field + has been read, 0 when no more fields remain, or a negative errno-style error code. + <function>sd_journal_restart_data()</function> doesn't return anything. + <function>sd_journal_set_data_threshold()</function> and <function>sd_journal_get_threshold()</function> + return 0 on success or a negative errno-style error code.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry id='EINVAL'> + <term><constant>-EINVAL</constant></term> + + <listitem><para>One of the required parameters is <constant>NULL</constant> or invalid. + </para></listitem> + </varlistentry> + + <varlistentry id='ECHILD'> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The journal object was created in a different process.</para></listitem> + </varlistentry> + + <varlistentry id='EADDRNOTAVAIL'> + <term><constant>-EADDRNOTAVAIL</constant></term> + + <listitem><para>The read pointer is not positioned at a valid entry; + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or a related call has not been called at least once.</para></listitem> + </varlistentry> + + <varlistentry id='ENOENT'> + <term><constant>-ENOENT</constant></term> + + <listitem><para>The current entry does not include the specified field.</para> + </listitem> + </varlistentry> + + <varlistentry id='ENOMEM'> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + + <varlistentry id='ENOBUFS'> + <term><constant>-ENOBUFS</constant></term> + + <listitem><para>A compressed entry is too large.</para></listitem> + </varlistentry> + + <varlistentry id='E2BIG'> + <term><constant>-E2BIG</constant></term> + + <listitem><para>The data field is too large for this computer architecture (e.g. above 4 GB on a + 32-bit architecture).</para></listitem> + </varlistentry> + + <varlistentry id='EPROTONOSUPPORT'> + <term><constant>-EPROTONOSUPPORT</constant></term> + + <listitem><para>The journal is compressed with an unsupported method or the journal uses an + unsupported feature.</para></listitem> + </varlistentry> + + <varlistentry id='EBADMSG'> + <term><constant>-EBADMSG</constant></term> + + <listitem><para>The journal is corrupted (possibly just the entry being iterated over). + </para></listitem> + </varlistentry> + + <varlistentry id='EIO'> + <term><constant>-EIO</constant></term> + + <listitem><para>An I/O error was reported by the kernel.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>See + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for a complete example how to use + <function>sd_journal_get_data()</function>.</para> + + <para>Use the + <function>SD_JOURNAL_FOREACH_DATA()</function> macro to + iterate through all fields of the current journal + entry:</para> + + <programlisting>… +int print_fields(sd_journal *j) { + const void *data; + size_t length; + SD_JOURNAL_FOREACH_DATA(j, data, length) + printf("%.*s\n", (int) length, data); +} +…</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_fd.xml b/man/sd_journal_get_fd.xml new file mode 100644 index 0000000..52360c7 --- /dev/null +++ b/man/sd_journal_get_fd.xml @@ -0,0 +1,259 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_fd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_fd</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_fd</refname> + <refname>sd_journal_get_events</refname> + <refname>sd_journal_get_timeout</refname> + <refname>sd_journal_process</refname> + <refname>sd_journal_wait</refname> + <refname>sd_journal_reliable_fd</refname> + <refname>SD_JOURNAL_NOP</refname> + <refname>SD_JOURNAL_APPEND</refname> + <refname>SD_JOURNAL_INVALIDATE</refname> + <refpurpose>Journal change notification + interface</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_fd</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_get_events</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_get_timeout</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_process</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_wait</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_reliable_fd</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_fd()</function> returns a file + descriptor that may be asynchronously polled in an external event + loop and is signaled as soon as the journal changes, because new + entries or files were added, rotation took place, or files have + been deleted, and similar. The file descriptor is suitable for + usage in + <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>. + Use <function>sd_journal_get_events()</function> for an events + mask to watch for. The call takes one argument: the journal + context object. Note that not all file systems are capable of + generating the necessary events for wakeups from this file + descriptor for changes to be noticed immediately. In particular + network files systems do not generate suitable file change events + in all cases. Cases like this can be detected with + <function>sd_journal_reliable_fd()</function>, below. + <function>sd_journal_get_timeout()</function> will ensure in these + cases that wake-ups happen frequently enough for changes to be + noticed, although with a certain latency.</para> + + <para><function>sd_journal_get_events()</function> will return the + <function>poll()</function> mask to wait for. This function will + return a combination of <constant>POLLIN</constant> and + <constant>POLLOUT</constant> and similar to fill into the + <literal>.events</literal> field of <varname>struct + pollfd</varname>.</para> + + <para><function>sd_journal_get_timeout()</function> will return a + timeout value for usage in <function>poll()</function>. This + returns a value in microseconds since the epoch of + <constant>CLOCK_MONOTONIC</constant> for timing out + <function>poll()</function> in <varname>timeout_usec</varname>. + See + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details about <constant>CLOCK_MONOTONIC</constant>. If there + is no timeout to wait for, this will fill in <constant>(uint64_t) + -1</constant> instead. Note that <function>poll()</function> takes + a relative timeout in milliseconds rather than an absolute timeout + in microseconds. To convert the absolute 'us' timeout into + relative 'ms', use code like the following:</para> + + <programlisting>uint64_t t; +int msec; +sd_journal_get_timeout(m, &t); +if (t == (uint64_t) -1) + msec = -1; +else { + struct timespec ts; + uint64_t n; + clock_gettime(CLOCK_MONOTONIC, &ts); + n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000; + msec = t > n ? (int) ((t - n + 999) / 1000) : 0; +}</programlisting> + + <para>The code above does not do any error checking for brevity's + sake. The calculated <varname>msec</varname> integer can be passed + directly as <function>poll()</function>'s timeout + parameter.</para> + + <para>After each <function>poll()</function> wake-up + <function>sd_journal_process()</function> needs to be called to + process events. This call will also indicate what kind of change + has been detected (see below; note that spurious wake-ups are + possible).</para> + + <para>A synchronous alternative for using + <function>sd_journal_get_fd()</function>, + <function>sd_journal_get_events()</function>, + <function>sd_journal_get_timeout()</function> and + <function>sd_journal_process()</function> is + <function>sd_journal_wait()</function>. It will synchronously wait + until the journal gets changed. The maximum time this call sleeps + may be controlled with the <parameter>timeout_usec</parameter> + parameter. Pass <constant>(uint64_t) -1</constant> to wait + indefinitely. Internally this call simply combines + <function>sd_journal_get_fd()</function>, + <function>sd_journal_get_events()</function>, + <function>sd_journal_get_timeout()</function>, + <function>poll()</function> and + <function>sd_journal_process()</function> into one.</para> + + <para><function>sd_journal_reliable_fd()</function> may be used to + check whether the wakeup events from the file descriptor returned + by <function>sd_journal_get_fd()</function> are known to be + immediately triggered. On certain file systems where file change + events from the OS are not available (such as NFS) changes need to + be polled for repeatedly, and hence are detected only with a + certain latency. This call will return a positive value if the + journal changes are detected immediately and zero when they need + to be polled for and hence might be noticed only with a certain + latency. Note that there is usually no need to invoke this function + directly as <function>sd_journal_get_timeout()</function> on these + file systems will ask for timeouts explicitly anyway.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_fd()</function> returns a valid + file descriptor on success or a negative errno-style error + code.</para> + + <para><function>sd_journal_get_events()</function> returns a + combination of <constant>POLLIN</constant>, + <constant>POLLOUT</constant> and suchlike on success or a negative + errno-style error code.</para> + + <para><function>sd_journal_reliable_fd()</function> returns a + positive integer if the file descriptor returned by + <function>sd_journal_get_fd()</function> will generate wake-ups + immediately for all journal changes. Returns 0 if there might be a + latency involved.</para> + + <para><function>sd_journal_process()</function> and <function>sd_journal_wait()</function> return a negative + errno-style error code, or one of <constant>SD_JOURNAL_NOP</constant>, <constant>SD_JOURNAL_APPEND</constant> or + <constant>SD_JOURNAL_INVALIDATE</constant> on success:</para> + + <itemizedlist> + <listitem><para>If <constant>SD_JOURNAL_NOP</constant> is returned, the journal did not change since the last + invocation.</para></listitem> + + <listitem><para>If <constant>SD_JOURNAL_APPEND</constant> is returned, new entries have been appended to the end + of the journal. In this case it is sufficient to simply continue reading at the previous end location of the + journal, to read the newly added entries.</para></listitem> + + <listitem><para>If <constant>SD_JOURNAL_INVALIDATE</constant>, journal files were added to or removed from the + set of journal files watched (e.g. due to rotation or vacuuming), and thus entries might have appeared or + disappeared at arbitrary places in the log stream, possibly before or after the previous end of the log + stream. If <constant>SD_JOURNAL_INVALIDATE</constant> is returned, live-view UIs that want to reflect on screen + the precise state of the log data on disk should probably refresh their entire display (relative to the cursor of + the log entry on the top of the screen). Programs only interested in a strictly sequential stream of log data may + treat <constant>SD_JOURNAL_INVALIDATE</constant> the same way as <constant>SD_JOURNAL_APPEND</constant>, thus + ignoring any changes to the log view earlier than the old end of the log stream.</para></listitem> + </itemizedlist> + </refsect1> + + <refsect1> + <title>Signal safety</title> + + <para>In general, <function>sd_journal_get_fd()</function>, <function>sd_journal_get_events()</function>, and + <function>sd_journal_get_timeout()</function> are <emphasis>not</emphasis> "async signal safe" in the meaning of + <citerefentry + project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + Nevertheless, only the first call to any of those three functions performs unsafe operations, so subsequent calls + <emphasis>are</emphasis> safe.</para> + + <para><function>sd_journal_process()</function> and <function>sd_journal_wait()</function> are not + safe. <function>sd_journal_reliable_fd()</function> is safe.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Iterating through the journal, in a live view tracking all + changes:</para> + + <programlisting><xi:include href="journal-iterate-wait.c" parse="text" /></programlisting> + + <para>Waiting with <function>poll()</function> (this + example lacks all error checking for the sake of + simplicity):</para> + + <programlisting><xi:include href="journal-iterate-poll.c" parse="text" /></programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_realtime_usec.xml b/man/sd_journal_get_realtime_usec.xml new file mode 100644 index 0000000..025b6a1 --- /dev/null +++ b/man/sd_journal_get_realtime_usec.xml @@ -0,0 +1,112 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_realtime_usec" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_realtime_usec</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_realtime_usec</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_realtime_usec</refname> + <refname>sd_journal_get_monotonic_usec</refname> + <refpurpose>Read timestamps from the current journal entry</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_realtime_usec</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_get_monotonic_usec</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + <paramdef>sd_id128_t *<parameter>boot_id</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_realtime_usec()</function> gets the + realtime (wallclock) timestamp of the current journal entry. It + takes two arguments: the journal context object and a pointer to a + 64-bit unsigned integer to store the timestamp in. The timestamp + is in microseconds since the epoch, i.e. + <constant>CLOCK_REALTIME</constant>.</para> + + <para><function>sd_journal_get_monotonic_usec()</function> gets + the monotonic timestamp of the current journal entry. It takes + three arguments: the journal context object, a pointer to a 64-bit + unsigned integer to store the timestamp in, as well as a 128-bit + ID buffer to store the boot ID of the monotonic timestamp. The + timestamp is in microseconds since boot-up of the specific boot, + i.e. <constant>CLOCK_MONOTONIC</constant>. Since the monotonic + clock begins new with every reboot, it only defines a well-defined + point in time when used together with an identifier identifying + the boot. See + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information. If the boot ID parameter is passed + <constant>NULL</constant>, the function will fail if the monotonic + timestamp of the current entry is not of the current system + boot.</para> + + <para>Note that these functions will not work before + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + (or related call) has been called at least + once, in order to position the read pointer at a valid entry.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_realtime_usec()</function> and + <function>sd_journal_get_monotonic_usec()</function> returns 0 on + success or a negative errno-style error code. If the boot ID + parameter was passed <constant>NULL</constant> and the monotonic + timestamp of the current journal entry is not of the current + system boot, <constant>-ESTALE</constant> is returned by + <function>sd_journal_get_monotonic_usec()</function>.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_get_usage.xml b/man/sd_journal_get_usage.xml new file mode 100644 index 0000000..e6fcd67 --- /dev/null +++ b/man/sd_journal_get_usage.xml @@ -0,0 +1,71 @@ +<?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-or-later --> + +<refentry id="sd_journal_get_usage" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_get_usage</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_get_usage</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_get_usage</refname> + <refpurpose>Journal disk usage</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_get_usage</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t *<parameter>bytes</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_get_usage()</function> determines the + total disk space currently used by journal files (in bytes). If + <constant>SD_JOURNAL_LOCAL_ONLY</constant> was passed when opening + the journal, this value will only reflect the size of journal + files of the local host, otherwise of all hosts.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_get_usage()</function> returns 0 on + success or a negative errno-style error code.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_has_runtime_files.xml b/man/sd_journal_has_runtime_files.xml new file mode 100644 index 0000000..e452b49 --- /dev/null +++ b/man/sd_journal_has_runtime_files.xml @@ -0,0 +1,79 @@ +<?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-or-later +--> + +<refentry id="sd_journal_has_runtime_files" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_has_runtime_files</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_has_runtime_files</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_has_runtime_files</refname> + <refname>sd_journal_has_persistent_files</refname> + <refpurpose>Query availability of runtime or persistent journal files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_has_runtime_files</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_has_persistent_files</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_has_runtime_files()</function> returns a positive value + if runtime journal files (present in /run/systemd/journal/) have been found. + Otherwise returns 0.</para> + + <para><function>sd_journal_has_persistent_files()</function> returns a positive value + if persistent journal files (present in /var/log/journal/) have been found. + Otherwise returns 0.</para> + </refsect1> + + <refsect1> + <title>Return value</title> + <para>Both <function>sd_journal_has_runtime_files()</function> + and <function>sd_journal_has_persistent_files()</function> return -EINVAL + if their argument is <constant>NULL</constant>. + </para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_next.xml b/man/sd_journal_next.xml new file mode 100644 index 0000000..5608331 --- /dev/null +++ b/man/sd_journal_next.xml @@ -0,0 +1,175 @@ +<?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-or-later --> + +<refentry id="sd_journal_next" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_next</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_next</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_next</refname> + <refname>sd_journal_previous</refname> + <refname>sd_journal_next_skip</refname> + <refname>sd_journal_previous_skip</refname> + <refname>SD_JOURNAL_FOREACH</refname> + <refname>SD_JOURNAL_FOREACH_BACKWARDS</refname> + <refpurpose>Advance or set back the read pointer in the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_next</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_previous</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_next_skip</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t <parameter>skip</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_previous_skip</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t <parameter>skip</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef><function>SD_JOURNAL_FOREACH</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef><function>SD_JOURNAL_FOREACH_BACKWARDS</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_next()</function> advances the read + pointer into the journal by one entry. The only argument taken is + a journal context object as allocated via + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + After successful invocation the entry may be read with functions + such as + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Similarly, <function>sd_journal_previous()</function> sets + the read pointer back one entry.</para> + + <para><function>sd_journal_next_skip()</function> and + <function>sd_journal_previous_skip()</function> advance/set back the read pointer by multiple + entries at once, as specified in the <varname>skip</varname> parameter. The <varname>skip</varname> + parameter must be less than or equal to 2147483647 (2^31-1).</para> + + <para>The journal is strictly ordered by reception time, and hence + advancing to the next entry guarantees that the entry then + pointing to is later in time than then previous one, or has the + same timestamp.</para> + + <para>Note that + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and related calls will fail unless + <function>sd_journal_next()</function> has been invoked at least + once in order to position the read pointer on a journal + entry.</para> + + <para>Note that the <function>SD_JOURNAL_FOREACH()</function> + macro may be used as a wrapper around + <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and <function>sd_journal_next()</function> in order to make + iterating through the journal easier. See below for an example. + Similarly, <function>SD_JOURNAL_FOREACH_BACKWARDS()</function> may + be used for iterating the journal in reverse order.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The four calls return the number of entries advanced/set + back on success or a negative errno-style error code. When the end + or beginning of the journal is reached, a number smaller than + requested is returned. More specifically, if + <function>sd_journal_next()</function> or + <function>sd_journal_previous()</function> reach the end/beginning + of the journal they will return 0, instead of 1 when they are + successful. This should be considered an EOF marker.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Iterating through the journal:</para> + + <programlisting>#include <stdio.h> +#include <string.h> +#include <systemd/sd-journal.h> + +int main(int argc, char *argv[]) { + int r; + sd_journal *j; + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + fprintf(stderr, "Failed to open journal: %s\n", strerror(-r)); + return 1; + } + SD_JOURNAL_FOREACH(j) { + const char *d; + size_t l; + + r = sd_journal_get_data(j, "MESSAGE", (const void **)&d, &l); + if (r < 0) { + fprintf(stderr, "Failed to read message field: %s\n", strerror(-r)); + continue; + } + + printf("%.*s\n", (int) l, d); + } + sd_journal_close(j); + return 0; +}</programlisting> + + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_open.xml b/man/sd_journal_open.xml new file mode 100644 index 0000000..8f62c96 --- /dev/null +++ b/man/sd_journal_open.xml @@ -0,0 +1,225 @@ +<?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-or-later --> + +<refentry id="sd_journal_open" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_open</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_open</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_open</refname> + <refname>sd_journal_open_directory</refname> + <refname>sd_journal_open_directory_fd</refname> + <refname>sd_journal_open_files</refname> + <refname>sd_journal_open_files_fd</refname> + <refname>sd_journal_open_namespace</refname> + <refname>sd_journal_close</refname> + <refname>sd_journal</refname> + <refname>SD_JOURNAL_LOCAL_ONLY</refname> + <refname>SD_JOURNAL_RUNTIME_ONLY</refname> + <refname>SD_JOURNAL_SYSTEM</refname> + <refname>SD_JOURNAL_CURRENT_USER</refname> + <refname>SD_JOURNAL_OS_ROOT</refname> + <refname>SD_JOURNAL_ALL_NAMESPACES</refname> + <refname>SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE</refname> + <refpurpose>Open the system journal for reading</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_open</function></funcdef> + <paramdef>sd_journal **<parameter>ret</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_open_namespace</function></funcdef> + <paramdef>sd_journal **<parameter>ret</parameter></paramdef> + <paramdef>const char *<parameter>namespace</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_open_directory</function></funcdef> + <paramdef>sd_journal **<parameter>ret</parameter></paramdef> + <paramdef>const char *<parameter>path</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_open_directory_fd</function></funcdef> + <paramdef>sd_journal **<parameter>ret</parameter></paramdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_open_files</function></funcdef> + <paramdef>sd_journal **<parameter>ret</parameter></paramdef> + <paramdef>const char **<parameter>paths</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_open_files_fd</function></funcdef> + <paramdef>sd_journal **<parameter>ret</parameter></paramdef> + <paramdef>int <parameter>fds[]</parameter></paramdef> + <paramdef>unsigned <parameter>n_fds</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_journal_close</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_open()</function> opens the log journal + for reading. It will find all journal files automatically and + interleave them automatically when reading. As first argument it + takes a pointer to a <varname>sd_journal</varname> pointer, which, + on success, will contain a journal context object. The second + argument is a flags field, which may consist of the following + flags ORed together: <constant>SD_JOURNAL_LOCAL_ONLY</constant> + makes sure only journal files generated on the local machine will + be opened. <constant>SD_JOURNAL_RUNTIME_ONLY</constant> makes sure + only volatile journal files will be opened, excluding those which + are stored on persistent storage. + <constant>SD_JOURNAL_SYSTEM</constant> will cause journal files of + system services and the kernel (in opposition to user session + processes) to be opened. + <constant>SD_JOURNAL_CURRENT_USER</constant> will cause journal + files of the current user to be opened. If neither + <constant>SD_JOURNAL_SYSTEM</constant> nor + <constant>SD_JOURNAL_CURRENT_USER</constant> are specified, all + journal file types will be opened.</para> + + <para><function>sd_journal_open_namespace()</function> is similar to + <function>sd_journal_open()</function> but takes an additional <parameter>namespace</parameter> parameter + that specifies which journal namespace to operate on. If specified as <constant>NULL</constant> the call + is identical to <function>sd_journal_open()</function>. If non-<constant>NULL</constant> only data from + the namespace identified by the specified parameter is accessed. This call understands two additional + flags: if <constant>SD_JOURNAL_ALL_NAMESPACES</constant> is specified the + <parameter>namespace</parameter> parameter is ignored and all defined namespaces are accessed + simultaneously; if <constant>SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE</constant> the specified namespace and + the default namespace are accessed but no others (this flag has no effect when + <parameter>namespace</parameter> is passed as <constant>NULL</constant>). For details about journal + namespaces see + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para><function>sd_journal_open_directory()</function> is similar to <function>sd_journal_open()</function> but + takes an absolute directory path as argument. All journal files in this directory will be opened and interleaved + automatically. This call also takes a flags argument. The flags parameters accepted by this call are + <constant>SD_JOURNAL_OS_ROOT</constant>, <constant>SD_JOURNAL_SYSTEM</constant>, and + <constant>SD_JOURNAL_CURRENT_USER</constant>. If <constant>SD_JOURNAL_OS_ROOT</constant> is specified, journal + files are searched for below the usual <filename>/var/log/journal</filename> and + <filename>/run/log/journal</filename> relative to the specified path, instead of directly beneath it. + The other two flags limit which files are opened, the same as for <function>sd_journal_open()</function>. + </para> + + <para><function>sd_journal_open_directory_fd()</function> is similar to + <function>sd_journal_open_directory()</function>, but takes a file descriptor referencing a directory in the file + system instead of an absolute file system path.</para> + + <para><function>sd_journal_open_files()</function> is similar to <function>sd_journal_open()</function> but takes a + <constant>NULL</constant>-terminated list of file paths to open. All files will be opened and interleaved + automatically. This call also takes a flags argument, but it must be passed as 0 as no flags are currently + understood for this call. Please note that in the case of a live journal, this function is only useful for + debugging, because individual journal files can be rotated at any moment, and the opening of specific files is + inherently racy.</para> + + <para><function>sd_journal_open_files_fd()</function> is similar to <function>sd_journal_open_files()</function> + but takes an array of open file descriptors that must reference journal files, instead of an array of file system + paths. Pass the array of file descriptors as second argument, and the number of array entries in the third. The + flags parameter must be passed as 0.</para> + + <para><varname>sd_journal</varname> objects cannot be used in the + child after a fork. Functions which take a journal object as an + argument (<function>sd_journal_next()</function> and others) will + return <constant>-ECHILD</constant> after a fork. + </para> + + <para><function>sd_journal_close()</function> will close the + journal context allocated with + <function>sd_journal_open()</function> or + <function>sd_journal_open_directory()</function> and free its + resources.</para> + + <para>When opening the journal only journal files accessible to + the calling user will be opened. If journal files are not + accessible to the caller, this will be silently ignored.</para> + + <para>See + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for an example of how to iterate through the journal after opening + it with <function>sd_journal_open()</function>.</para> + + <para>A journal context object returned by + <function>sd_journal_open()</function> references a specific + journal entry as <emphasis>current</emphasis> entry, similar to a + file seek index in a classic file system file, but without + absolute positions. It may be altered with + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and related calls. The current entry position may be exported in + <emphasis>cursor</emphasis> strings, as accessible via + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Cursor strings may be used to globally identify a specific journal + entry in a stable way and then later to seek to it (or if the + specific entry is not available locally, to its closest entry in + time) + <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Notification of journal changes is available via + <function>sd_journal_get_fd()</function> and related calls.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The <function>sd_journal_open()</function>, + <function>sd_journal_open_directory()</function>, and + <function>sd_journal_open_files()</function> calls return 0 on + success or a negative errno-style error code. + <function>sd_journal_close()</function> returns nothing.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_print.xml b/man/sd_journal_print.xml new file mode 100644 index 0000000..68a4a0a --- /dev/null +++ b/man/sd_journal_print.xml @@ -0,0 +1,272 @@ +<?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-or-later --> + +<refentry id="sd_journal_print" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_print</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_print</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_print</refname> + <refname>sd_journal_printv</refname> + <refname>sd_journal_send</refname> + <refname>sd_journal_sendv</refname> + <refname>sd_journal_perror</refname> + <refname>SD_JOURNAL_SUPPRESS_LOCATION</refname> + <refname>sd_journal_print_with_location</refname> + <refname>sd_journal_printv_with_location</refname> + <refname>sd_journal_send_with_location</refname> + <refname>sd_journal_sendv_with_location</refname> + <refname>sd_journal_perror_with_location</refname> + + <refpurpose>Submit log entries to the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_print</function></funcdef> + <paramdef>int <parameter>priority</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_printv</function></funcdef> + <paramdef>int <parameter>priority</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_send</function></funcdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_sendv</function></funcdef> + <paramdef>const struct iovec *<parameter>iov</parameter></paramdef> + <paramdef>int <parameter>n</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_perror</function></funcdef> + <paramdef>const char *<parameter>message</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_print_with_location</function></funcdef> + <paramdef>const char *<parameter>file</parameter></paramdef> + <paramdef>const char *<parameter>line</parameter></paramdef> + <paramdef>const char *<parameter>func</parameter></paramdef> + <paramdef>int <parameter>priority</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_printv_with_location</function></funcdef> + <paramdef>int <parameter>priority</parameter></paramdef> + <paramdef>const char *<parameter>file</parameter></paramdef> + <paramdef>const char *<parameter>line</parameter></paramdef> + <paramdef>const char *<parameter>func</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>va_list <parameter>ap</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_send_with_location</function></funcdef> + <paramdef>const char *<parameter>file</parameter></paramdef> + <paramdef>const char *<parameter>line</parameter></paramdef> + <paramdef>const char *<parameter>func</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_sendv_with_location</function></funcdef> + <paramdef>const char *<parameter>file</parameter></paramdef> + <paramdef>const char *<parameter>line</parameter></paramdef> + <paramdef>const char *<parameter>func</parameter></paramdef> + <paramdef>const struct iovec *<parameter>iov</parameter></paramdef> + <paramdef>int <parameter>n</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_perror_with_location</function></funcdef> + <paramdef>const char *<parameter>file</parameter></paramdef> + <paramdef>const char *<parameter>line</parameter></paramdef> + <paramdef>const char *<parameter>func</parameter></paramdef> + <paramdef>const char *<parameter>message</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_print()</function> may be used to submit simple, plain text log entries to the system + journal. The first argument is a priority value. This is followed by a format string and its parameters, similar to + <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Note that currently the resulting message will be truncated to <constant>LINE_MAX - 8</constant>. + The priority value is one of <constant>LOG_EMERG</constant>, <constant>LOG_ALERT</constant>, + <constant>LOG_CRIT</constant>, <constant>LOG_ERR</constant>, <constant>LOG_WARNING</constant>, + <constant>LOG_NOTICE</constant>, <constant>LOG_INFO</constant>, <constant>LOG_DEBUG</constant>, as defined in + <filename>syslog.h</filename>, see <citerefentry + project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for details. It is + recommended to use this call to submit log messages in the application locale or system locale and in UTF-8 format, + but no such restrictions are enforced. Note that log messages written using this function are generally not + expected to end in a new-line character. However, as all trailing whitespace (including spaces, new-lines, + tabulators and carriage returns) are automatically stripped from the logged string, it is acceptable to specify one + (or more). Empty lines (after trailing whitespace removal) are suppressed. On non-empty lines, leading whitespace + (as well as inner whitespace) is left unmodified. </para> + + <para><function>sd_journal_printv()</function> is similar to + <function>sd_journal_print()</function> but takes a variable + argument list encapsulated in an object of type + <varname>va_list</varname> (see + <citerefentry project='man-pages'><refentrytitle>stdarg</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information) instead of the format string. It is + otherwise equivalent in behavior.</para> + + <para><function>sd_journal_send()</function> may be used to submit structured log entries to the system journal. It + takes a series of format strings, each immediately followed by their associated parameters, terminated by + <constant>NULL</constant>. The strings passed should be of the format <literal>VARIABLE=value</literal>. The + variable name must be in uppercase and consist only of characters, numbers and underscores, and may not begin with + an underscore. (All assignments that do not follow this syntax will be ignored.) The value can be of any size and + format. It is highly recommended to submit text strings formatted in the UTF-8 character encoding only, and submit + binary fields only when formatting in UTF-8 strings is not sensible. A number of well-known fields are defined, see + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details, but additional application defined fields may be used. A variable may be assigned more than one value per + entry. If this function is used, trailing whitespace is automatically removed from each formatted field.</para> + + <para><function>sd_journal_sendv()</function> is similar to <function>sd_journal_send()</function> but takes an + array of <varname>struct iovec</varname> (as defined in <filename>uio.h</filename>, see <citerefentry + project='man-pages'><refentrytitle>readv</refentrytitle><manvolnum>3</manvolnum></citerefentry> for details) + instead of the format string. Each structure should reference one field of the entry to submit. The second argument + specifies the number of structures in the array. <function>sd_journal_sendv()</function> is particularly useful to + submit binary objects to the journal where that is necessary. Note that this function will not strip trailing + whitespace of the passed fields, but passes the specified data along unmodified. This is different from both + <function>sd_journal_print()</function> and <function>sd_journal_send()</function> described above, which are based + on format strings, and do strip trailing whitespace.</para> + + <para><function>sd_journal_perror()</function> is a similar to + <citerefentry project='die-net'><refentrytitle>perror</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and writes a message to the journal that consists of the passed + string, suffixed with ": " and a human-readable representation of + the current error code stored in + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If the message string is passed as <constant>NULL</constant> or + empty string, only the error string representation will be + written, prefixed with nothing. An additional journal field ERRNO= + is included in the entry containing the numeric error code + formatted as decimal string. The log priority used is + <constant>LOG_ERR</constant> (3).</para> + + <para>Note that <function>sd_journal_send()</function> is a + wrapper around <function>sd_journal_sendv()</function> to make it + easier to use when only text strings shall be submitted. Also, the + following two calls are mostly equivalent:</para> + + <programlisting>sd_journal_print(LOG_INFO, "Hello World, this is PID %lu!", (unsigned long) getpid()); + +sd_journal_send("MESSAGE=Hello World, this is PID %lu!", (unsigned long) getpid(), + "PRIORITY=%i", LOG_INFO, + NULL);</programlisting> + + <para>Note that these calls implicitly add fields for the source file, function name and code line where + invoked. This is implemented with macros. If this is not desired, it can be turned off by defining + <constant>SD_JOURNAL_SUPPRESS_LOCATION</constant> before including <filename>sd-journal.h</filename>. + </para> + + <para><function>sd_journal_print_with_location()</function>, + <function>sd_journal_printv_with_location()</function>, <function>sd_journal_send_with_location()</function>, + <function>sd_journal_sendv_with_location()</function>, and + <function>sd_journal_perror_with_location()</function> are similar to their counterparts without + <literal>_with_location</literal>, but accept additional parameters to explicitly set the source file + name, function, and line. Those arguments must contain valid journal entries including the variable name, + e.g. <literal>CODE_FILE=src/foo.c</literal>, <literal>CODE_LINE=666</literal>, + <literal>CODE_FUNC=myfunc</literal>. These variants are primarily useful when writing custom wrappers, + for example in bindings for a different language.</para> + + <para><citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and <function>sd_journal_print()</function> may + largely be used interchangeably + functionality-wise. However, note that log messages + logged via the former take a different path to the + journal server than the later, and hence global + chronological ordering between the two streams cannot + be guaranteed. Using + <function>sd_journal_print()</function> has the + benefit of logging source code line, filenames, and + functions as metadata along all entries, and + guaranteeing chronological ordering with structured + log entries that are generated via + <function>sd_journal_send()</function>. Using + <function>syslog()</function> has the benefit of being + more portable.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The ten functions return 0 on success or a negative errno-style error code. The + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + variable itself is not altered.</para> + + <para>If + <citerefentry><refentrytitle>systemd-journald</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is not running (the socket is not present), those functions do + nothing, and also return 0.</para> + </refsect1> + + <refsect1> + <title>Thread safety</title> + + <xi:include href="threads-aware.xml" xpointer="safe"/> + + <para><function>sd_journal_sendv()</function> and <function>sd_journal_sendv_with_location()</function> + are "async signal safe" in the meaning of + <citerefentry project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + + <para><function>sd_journal_print()</function>, + <function>sd_journal_printv()</function>, + <function>sd_journal_send()</function>, + <function>sd_journal_perror()</function>, + and their counterparts with <literal>_with_location</literal> + are not async signal safe.</para> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>perror</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_query_unique.xml b/man/sd_journal_query_unique.xml new file mode 100644 index 0000000..26188f9 --- /dev/null +++ b/man/sd_journal_query_unique.xml @@ -0,0 +1,175 @@ +<?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-or-later --> + +<refentry id="sd_journal_query_unique" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_query_unique</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_query_unique</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_query_unique</refname> + <refname>sd_journal_enumerate_unique</refname> + <refname>sd_journal_enumerate_available_unique</refname> + <refname>sd_journal_restart_unique</refname> + <refname>SD_JOURNAL_FOREACH_UNIQUE</refname> + <refpurpose>Read unique data fields from the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_query_unique</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const char *<parameter>field</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_enumerate_available_unique</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void **<parameter>data</parameter></paramdef> + <paramdef>size_t *<parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_enumerate_unique</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void **<parameter>data</parameter></paramdef> + <paramdef>size_t *<parameter>length</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_journal_restart_unique</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef><function>SD_JOURNAL_FOREACH_UNIQUE</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const void *<parameter>data</parameter></paramdef> + <paramdef>size_t <parameter>length</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_query_unique()</function> queries the journal for all unique values the + specified field can take. It takes two arguments: the journal to query and the field name to look + for. Well-known field names are listed on + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + but any field can be specified. Field names must be specified without a trailing + <literal>=</literal>. After this function has been executed successfully the field values may be queried + using <function>sd_journal_enumerate_unique()</function> and + <function>sd_journal_enumerate_available_unique()</function>. Invoking one of those calls will change the + field name being queried and reset the enumeration index to the first field value that matches.</para> + + <para><function>sd_journal_enumerate_unique()</function> may be used to iterate through all data fields + which match the previously selected field name as set with + <function>sd_journal_query_unique()</function>. On each invocation the next field data matching the field + name is returned. The order of the returned data fields is not defined. It takes three arguments: the + journal object, plus a pair of pointers to pointer/size variables where the data object and its size + shall be stored. The returned data is in a read-only memory map and is only valid until the next + invocation of <function>sd_journal_enumerate_unique()</function>. Note that the data returned will be + prefixed with the field name and <literal>=</literal>. Note that this call is subject to the data field + size threshold as controlled by <function>sd_journal_set_data_threshold()</function> and only the initial + part of the field up to the threshold is returned. An error is returned for fields which cannot be + retrieved. See the error list below for details.</para> + + <para><function>sd_journal_enumerate_available_unique()</function> is similar to + <function>sd_journal_enumerate_unique()</function>, but silently skips any fields which may be valid, but + are too large or not supported by current implementation.</para> + + <para><function>sd_journal_restart_unique()</function> resets the + data enumeration index to the beginning of the list. The next + invocation of <function>sd_journal_enumerate_unique()</function> + will return the first field data matching the field name + again.</para> + + <para>Note that the <function>SD_JOURNAL_FOREACH_UNIQUE()</function> macro may be used as a handy wrapper + around <function>sd_journal_restart_unique()</function> and + <function>sd_journal_enumerate_available_unique()</function>.</para> + + <para>Note that these functions currently are not influenced by + matches set with <function>sd_journal_add_match()</function> but + this might change in a later version of this software.</para> + + <para>To enumerate all field names currently in use (and thus all suitable field parameters for + <function>sd_journal_query_unique()</function>), use the + <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_journal_query_unique()</function> returns 0 on success or a negative errno-style error + code. <function>sd_journal_enumerate_unique()</function> and and + <function>sd_journal_query_available_unique()</function> return a positive integer if the next field data + has been read, 0 when no more fields remain, or a negative errno-style error code. + <function>sd_journal_restart_unique()</function> doesn't return anything.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <xi:include href="sd_journal_get_data.xml" xpointer="EINVAL"/> + <xi:include href="sd_journal_get_data.xml" xpointer="ECHILD"/> + <xi:include href="sd_journal_get_data.xml" xpointer="EADDRNOTAVAIL"/> + <xi:include href="sd_journal_get_data.xml" xpointer="ENOENT"/> + <xi:include href="sd_journal_get_data.xml" xpointer="ENOBUFS"/> + <xi:include href="sd_journal_get_data.xml" xpointer="E2BIG"/> + <xi:include href="sd_journal_get_data.xml" xpointer="EPROTONOSUPPORT"/> + <xi:include href="sd_journal_get_data.xml" xpointer="EBADMSG"/> + <xi:include href="sd_journal_get_data.xml" xpointer="EIO"/> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Use the <function>SD_JOURNAL_FOREACH_UNIQUE()</function> macro to iterate through all values a field + of the journal can take (and which can be accessed on the given architecture and are not compressed with + an unsupported mechanism). The following example lists all unit names referenced in the journal:</para> + + <programlisting><xi:include href="journal-iterate-unique.c" parse="text" /></programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_seek_head.xml b/man/sd_journal_seek_head.xml new file mode 100644 index 0000000..869889a --- /dev/null +++ b/man/sd_journal_seek_head.xml @@ -0,0 +1,131 @@ +<?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-or-later --> + +<refentry id="sd_journal_seek_head" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_seek_head</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_seek_head</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_seek_head</refname> + <refname>sd_journal_seek_tail</refname> + <refname>sd_journal_seek_monotonic_usec</refname> + <refname>sd_journal_seek_realtime_usec</refname> + <refname>sd_journal_seek_cursor</refname> + <refpurpose>Seek to a position in the + journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_seek_head</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_seek_tail</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_seek_monotonic_usec</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>sd_id128_t <parameter>boot_id</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_seek_realtime_usec</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>uint64_t <parameter>usec</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_journal_seek_cursor</function></funcdef> + <paramdef>sd_journal *<parameter>j</parameter></paramdef> + <paramdef>const char *<parameter>cursor</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_seek_head()</function> seeks to the beginning of the journal, i.e. to the + position before the oldest available entry.</para> + + <para>Similarly, <function>sd_journal_seek_tail()</function> may be used to seek to the end of the + journal, i.e. the position after the most recent available entry.</para> + + <para><function>sd_journal_seek_monotonic_usec()</function> seeks to a position with the specified + monotonic timestamp, i.e. <constant>CLOCK_MONOTONIC</constant>. Since monotonic time restarts on every + reboot a boot ID needs to be specified as well.</para> + + <para><function>sd_journal_seek_realtime_usec()</function> seeks to a position with the specified + realtime (wallclock) timestamp, i.e. <constant>CLOCK_REALTIME</constant>. Note that the realtime clock is + not necessarily monotonic. If a realtime timestamp is ambiguous, it is not defined which position is + sought to.</para> + + <para><function>sd_journal_seek_cursor()</function> seeks to the position at the specified cursor + string. For details on cursors, see + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If no entry matching the specified cursor is found the call will seek to the next closest entry (in terms + of time) instead. To verify whether the newly selected entry actually matches the cursor, use + <citerefentry><refentrytitle>sd_journal_test_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + + <para>Note that these calls do not actually make any entry the new current entry, this needs to be done + in a separate step with a subsequent + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + invocation (or a similar call). Only then, entry data may be retrieved via + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or an entry cursor be retrieved via + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If no entry exists that matches exactly the specified seek address, the next closest is sought to. If + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> is + used, the closest following entry will be sought to, if + <citerefentry><refentrytitle>sd_journal_previous</refentrytitle><manvolnum>3</manvolnum></citerefentry> + is used the closest preceding entry is sought to.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The functions return 0 on success or a negative errno-style + error code.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="strict"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_journal_stream_fd.xml b/man/sd_journal_stream_fd.xml new file mode 100644 index 0000000..af2234e --- /dev/null +++ b/man/sd_journal_stream_fd.xml @@ -0,0 +1,146 @@ +<?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-or-later --> + +<refentry id="sd_journal_stream_fd" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_journal_stream_fd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_journal_stream_fd</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_journal_stream_fd</refname> + <refpurpose>Create log stream file descriptor to the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-journal.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_journal_stream_fd</function></funcdef> + <paramdef>const char *<parameter>identifier</parameter></paramdef> + <paramdef>int <parameter>priority</parameter></paramdef> + <paramdef>int <parameter>level_prefix</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_journal_stream_fd()</function> may be used to + create a log stream file descriptor. Log messages written to this + file descriptor as simple newline-separated text strings are + written to the journal. This file descriptor can be used + internally by applications or be made standard output or standard + error of other processes executed.</para> + + <para><function>sd_journal_stream_fd()</function> takes a short + program identifier string as first argument, which will be written + to the journal as SYSLOG_IDENTIFIER= field for each log entry + (see + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information). The second argument shall be the default + priority level for all messages. The priority level is one of + <constant>LOG_EMERG</constant>, <constant>LOG_ALERT</constant>, + <constant>LOG_CRIT</constant>, <constant>LOG_ERR</constant>, + <constant>LOG_WARNING</constant>, <constant>LOG_NOTICE</constant>, + <constant>LOG_INFO</constant>, <constant>LOG_DEBUG</constant>, as + defined in <filename>syslog.h</filename>, see + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for details. The third argument is a boolean: if true kernel-style + log level prefixes (such as <constant>SD_WARNING</constant>) are + interpreted, see + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information.</para> + + <para>It is recommended that applications log UTF-8 messages only + with this API, but this is not enforced.</para> + + <para>Each invocation of <function>sd_journal_stream_fd()</function> allocates a new log stream file descriptor, + that is not shared with prior or later invocations. The file descriptor is write-only (its reading direction is + shut down), and <constant>O_NONBLOCK</constant> is turned off initially.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The call returns a valid write-only file descriptor on + success or a negative errno-style error code.</para> + </refsect1> + + <refsect1> + <title>Signal safety</title> + + <para><function>sd_journal_stream_fd()</function> is "async signal safe" in the meaning of <citerefentry + project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="threads-aware.xml" xpointer="safe"/> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>Creating a log stream suitable for + <citerefentry project='man-pages'><refentrytitle>fprintf</refentrytitle><manvolnum>3</manvolnum></citerefentry>:</para> + + <programlisting>#include <syslog.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> +#include <systemd/sd-journal.h> +#include <systemd/sd-daemon.h> + +int main(int argc, char *argv[]) { + int fd; + FILE *log; + fd = sd_journal_stream_fd("test", LOG_INFO, 1); + if (fd < 0) { + fprintf(stderr, "Failed to create stream fd: %s\n", strerror(-fd)); + return 1; + } + log = fdopen(fd, "w"); + if (!log) { + fprintf(stderr, "Failed to create file object: %m\n"); + close(fd); + return 1; + } + fprintf(log, "Hello World!\n"); + fprintf(log, SD_WARNING "This is a warning!\n"); + fclose(log); + return 0; +}</programlisting> + + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fprintf</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_listen_fds.xml b/man/sd_listen_fds.xml new file mode 100644 index 0000000..9ddd129 --- /dev/null +++ b/man/sd_listen_fds.xml @@ -0,0 +1,225 @@ +<?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-or-later --> + +<refentry id="sd_listen_fds" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_listen_fds</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_listen_fds</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_listen_fds</refname> + <refname>sd_listen_fds_with_names</refname> + <refname>SD_LISTEN_FDS_START</refname> + <refpurpose>Check for file descriptors passed by the system manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-daemon.h></funcsynopsisinfo> + + <funcsynopsisinfo>#define SD_LISTEN_FDS_START 3</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_listen_fds</function></funcdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_listen_fds_with_names</function></funcdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>char*** <parameter>names</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_listen_fds()</function> may be invoked by a + daemon to check for file descriptors passed by the service manager as + part of the socket-based activation logic. It returns the number + of received file descriptors. If no file descriptors have been + received, zero is returned. The first file descriptor may be found + at file descriptor number 3 + (i.e. <constant>SD_LISTEN_FDS_START</constant>), the remaining + descriptors follow at 4, 5, 6, …, if any.</para> + + <para>If a daemon receives more than one file descriptor, they will be passed in the same order as + configured in the systemd socket unit file (see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details) — if there's only one such file (see below). Nonetheless, it is recommended to verify the + correct socket types before using them. To simplify this checking, the functions + <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_socket</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_socket_inet</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_socket_unix</refentrytitle><manvolnum>3</manvolnum></citerefentry> are + provided. In order to maximize flexibility, it is recommended to make these checks as loose as possible + without allowing incorrect setups. i.e. often, the actual port number a socket is bound to matters little + for the service to work, hence it should not be verified. On the other hand, whether a socket is a + datagram or stream socket matters a lot for the most common program logics and should be checked.</para> + + <para>This function call will set the FD_CLOEXEC flag for all + passed file descriptors to avoid further inheritance to children + of the calling process.</para> + + <para>If multiple socket units activate the same service, the order + of the file descriptors passed to its main process is undefined. + If additional file descriptors have been passed to the service + manager using + <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s + <literal>FDSTORE=1</literal> messages, these file descriptors are + passed last, in arbitrary order, and with duplicates + removed.</para> + + <para>If the <parameter>unset_environment</parameter> parameter is + non-zero, <function>sd_listen_fds()</function> will unset the + <varname>$LISTEN_FDS</varname>, <varname>$LISTEN_PID</varname> and + <varname>$LISTEN_FDNAMES</varname> environment variables before + returning (regardless of whether the function call itself + succeeded or not). Further calls to + <function>sd_listen_fds()</function> will then return zero, but the + variables are no longer inherited by child processes.</para> + + <para><function>sd_listen_fds_with_names()</function> is like + <function>sd_listen_fds()</function>, but optionally also returns + an array of strings with identification names for the passed file + descriptors, if that is available and the + <parameter>names</parameter> parameter is non-<constant>NULL</constant>. This + information is read from the <varname>$LISTEN_FDNAMES</varname> + variable, which may contain a colon-separated list of names. For + socket-activated services, these names may be configured with the + <varname>FileDescriptorName=</varname> setting in socket unit + files, see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. For file descriptors pushed into the file descriptor + store (see above), the name is set via the + <varname>FDNAME=</varname> field transmitted via + <function>sd_pid_notify_with_fds()</function>. The primary usecase + for these names are services which accept a variety of file + descriptors which are not recognizable with functions like + <function>sd_is_socket()</function> alone, and thus require + identification via a name. It is recommended to rely on named file + descriptors only if identification via + <function>sd_is_socket()</function> and related calls is not + sufficient. Note that the names used are not unique in any + way. The returned array of strings has as many entries as file + descriptors have been received, plus a final <constant>NULL</constant> pointer + terminating the array. The caller needs to free the array itself + and each of its elements with libc's <function>free()</function> + call after use. If the <parameter>names</parameter> parameter is + <constant>NULL</constant>, the call is entirely equivalent to + <function>sd_listen_fds()</function>.</para> + + <para>Under specific conditions, the following automatic file + descriptor names are returned: + + <table> + <title> + <command>Special names</command> + </title> + + <tgroup cols='2'> + <thead> + <row> + <entry>Name</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>unknown</literal></entry> + <entry>The process received no name for the specific file descriptor from the service manager.</entry> + </row> + + <row> + <entry><literal>stored</literal></entry> + <entry>The file descriptor originates in the service manager's per-service file descriptor store, and the <varname>FDNAME=</varname> field was absent when the file descriptor was submitted to the service manager.</entry> + </row> + + <row> + <entry><literal>connection</literal></entry> + <entry>The service was activated in per-connection style using <varname>Accept=yes</varname> in the socket unit file, and the file descriptor is the connection socket.</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, these calls returns a negative errno-style error + code. If + <varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname> was + not set or was not correctly set for this daemon and hence no file + descriptors were received, 0 is returned. Otherwise, the number of + file descriptors passed is returned. The application may find them + starting with file descriptor SD_LISTEN_FDS_START, i.e. file + descriptor 3.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + + <para>Internally, <function>sd_listen_fds()</function> checks + whether the <varname>$LISTEN_PID</varname> environment variable + equals the daemon PID. If not, it returns immediately. Otherwise, + it parses the number passed in the <varname>$LISTEN_FDS</varname> + environment variable, then sets the FD_CLOEXEC flag for the parsed + number of file descriptors starting from SD_LISTEN_FDS_START. + Finally, it returns the parsed + number. <function>sd_listen_fds_with_names()</function> does the + same but also parses <varname>$LISTEN_FDNAMES</varname> if + set.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$LISTEN_PID</varname></term> + <term><varname>$LISTEN_FDS</varname></term> + <term><varname>$LISTEN_FDNAMES</varname></term> + + <listitem><para>Set by the service manager for supervised + processes that use socket-based activation. This environment + variable specifies the data + <function>sd_listen_fds()</function> and + <function>sd_listen_fds_with_names()</function> parses. See + above for details.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_socket</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_socket_inet</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_is_socket_unix</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_login_monitor_new.xml b/man/sd_login_monitor_new.xml new file mode 100644 index 0000000..57d22f9 --- /dev/null +++ b/man/sd_login_monitor_new.xml @@ -0,0 +1,247 @@ +<?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-or-later --> + +<refentry id="sd_login_monitor_new" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_login_monitor_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_login_monitor_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_login_monitor_new</refname> + <refname>sd_login_monitor_unref</refname> + <refname>sd_login_monitor_unrefp</refname> + <refname>sd_login_monitor_flush</refname> + <refname>sd_login_monitor_get_fd</refname> + <refname>sd_login_monitor_get_events</refname> + <refname>sd_login_monitor_get_timeout</refname> + <refname>sd_login_monitor</refname> + <refpurpose>Monitor login sessions, seats, users and virtual machines/containers</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_login_monitor_new</function></funcdef> + <paramdef>const char *<parameter>category</parameter></paramdef> + <paramdef>sd_login_monitor **<parameter>ret</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>sd_login_monitor *<function>sd_login_monitor_unref</function></funcdef> + <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>void <function>sd_login_monitor_unrefp</function></funcdef> + <paramdef>sd_login_monitor **<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_login_monitor_flush</function></funcdef> + <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_login_monitor_get_fd</function></funcdef> + <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_login_monitor_get_events</function></funcdef> + <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_login_monitor_get_timeout</function></funcdef> + <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef> + <paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_login_monitor_new()</function> may be used to + monitor login sessions, users, seats, and virtual + machines/containers. Via a monitor object a file descriptor can be + integrated into an application defined event loop which is woken + up each time a user logs in, logs out or a seat is added or + removed, or a session, user, seat or virtual machine/container + changes state otherwise. The first parameter takes a string which + can be <literal>seat</literal> (to get only notifications about + seats being added, removed or changed), <literal>session</literal> + (to get only notifications about sessions being created or removed + or changed), <literal>uid</literal> (to get only notifications + when a user changes state in respect to logins) or + <literal>machine</literal> (to get only notifications when a + virtual machine or container is started or stopped). If + notifications shall be generated in all these conditions, + <constant>NULL</constant> may be passed. Note that in the future + additional categories may be defined. The second parameter returns + a monitor object and needs to be freed with the + <function>sd_login_monitor_unref()</function> call after + use.</para> + + <para><function>sd_login_monitor_unref()</function> may be used to + destroy a monitor object. Note that this will invalidate any file + descriptor returned by + <function>sd_login_monitor_get_fd()</function>.</para> + + <para><function>sd_login_monitor_unrefp()</function> is similar to + <function>sd_login_monitor_unref()</function> but takes a pointer + to a pointer to an <type>sd_login_monitor</type> object. 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. Use a declaration like the following, in order to + allocate a login monitor object that is freed automatically as the + code block is left:</para> + + <programlisting>{ + __attribute__((cleanup(sd_login_monitor_unrefp))) sd_login_monitor *m = NULL; + int r; + … + r = sd_login_monitor_default(&m); + if (r < 0) + fprintf(stderr, "Failed to allocate login monitor object: %s\n", strerror(-r)); + … +}</programlisting> + + <para><function>sd_login_monitor_flush()</function> may be used to + reset the wakeup state of the monitor object. Whenever an event + causes the monitor to wake up the event loop via the file + descriptor this function needs to be called to reset the wake-up + state. If this call is not invoked, the file descriptor will + immediately wake up the event loop again.</para> + + <para><function>sd_login_monitor_unref()</function> and + <function>sd_login_monitor_unrefp()</function> execute no + operation if the passed in monitor object is + <constant>NULL</constant>.</para> + + <para><function>sd_login_monitor_get_fd()</function> may be used + to retrieve the file descriptor of the monitor object that may be + integrated in an application defined event loop, based around + <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry> + or a similar interface. The application should include the + returned file descriptor as wake-up source for the events mask + returned by <function>sd_login_monitor_get_events()</function>. It + should pass a timeout value as returned by + <function>sd_login_monitor_get_timeout()</function>. Whenever a + wake-up is triggered the file descriptor needs to be reset via + <function>sd_login_monitor_flush()</function>. An application + needs to reread the login state with a function like + <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or similar to determine what changed.</para> + + <para><function>sd_login_monitor_get_events()</function> will + return the <function>poll()</function> mask to wait for. This + function will return a combination of <constant>POLLIN</constant>, + <constant>POLLOUT</constant> and similar to fill into the + <literal>.events</literal> field of <varname>struct + pollfd</varname>.</para> + + <para><function>sd_login_monitor_get_timeout()</function> will + return a timeout value for usage in <function>poll()</function>. + This returns a value in microseconds since the epoch of + <constant>CLOCK_MONOTONIC</constant> for timing out + <function>poll()</function> in <varname>timeout_usec</varname>. + See + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details about <constant>CLOCK_MONOTONIC</constant>. If there + is no timeout to wait for this will fill in <constant>(uint64_t) + -1</constant> instead. Note that <function>poll()</function> takes + a relative timeout in milliseconds rather than an absolute timeout + in microseconds. To convert the absolute 'µs' timeout into + relative 'ms', use code like the following:</para> + + <programlisting>uint64_t t; +int msec; +sd_login_monitor_get_timeout(m, &t); +if (t == (uint64_t) -1) + msec = -1; +else { + struct timespec ts; + uint64_t n; + clock_gettime(CLOCK_MONOTONIC, &ts); + n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000; + msec = t > n ? (int) ((t - n + 999) / 1000) : 0; +}</programlisting> + + <para>The code above does not do any error checking for brevity's + sake. The calculated <varname>msec</varname> integer can be passed + directly as <function>poll()</function>'s timeout + parameter.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>sd_login_monitor_new()</function>, + <function>sd_login_monitor_flush()</function> and + <function>sd_login_monitor_get_timeout()</function> + return 0 or a positive integer. On success, + <function>sd_login_monitor_get_fd()</function> returns + a Unix file descriptor. On success, + <function>sd_login_monitor_get_events()</function> + returns a combination of <constant>POLLIN</constant>, + <constant>POLLOUT</constant> and suchlike. On failure, + these calls return a negative errno-style error + code.</para> + + <para><function>sd_login_monitor_unref()</function> + always returns <constant>NULL</constant>.</para> + + <refsect2> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where + that is not accepted). The specified category to watch is not known.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_machine_get_class.xml b/man/sd_machine_get_class.xml new file mode 100644 index 0000000..6e5fe9e --- /dev/null +++ b/man/sd_machine_get_class.xml @@ -0,0 +1,116 @@ +<?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-or-later --> + +<refentry id="sd_machine_get_class" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_machine_get_class</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_machine_get_class</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_machine_get_class</refname> + <refname>sd_machine_get_ifindices</refname> + <refpurpose>Determine the class and network interface indices of a + locally running virtual machine or container</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_machine_get_class</function></funcdef> + <paramdef>const char* <parameter>machine</parameter></paramdef> + <paramdef>char **<parameter>class</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_machine_get_ifindices</function></funcdef> + <paramdef>const char* <parameter>machine</parameter></paramdef> + <paramdef>int **<parameter>ret_ifindices</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_machine_get_class()</function> may be used to + determine the class of a locally running virtual machine or + container that is registered with + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + The string returned is either <literal>vm</literal> or + <literal>container</literal>. The returned string needs to be + freed with the libc <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_machine_get_ifindices()</function> may be used to determine the numeric indices of the + network interfaces on the host that are pointing towards the specified locally running virtual machine or + container. The vm or container must be registered with + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + The output parameter <parameter>ret_ifindices</parameter> may be passed as <constant>NULL</constant> when + the output value is not needed. The returned array needs to be freed with the libc <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> call after + use.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these functions return a non-negative integer. + <function>sd_machine_get_ifindices()</function> returns the number of the relevant network interfaces. + On failure, these calls 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>-ENXIO</constant></term> + + <listitem><para>The specified machine does not exist or is currently not running.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where + that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_pid_get_machine_name</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_notify.xml b/man/sd_notify.xml new file mode 100644 index 0000000..69e1b02 --- /dev/null +++ b/man/sd_notify.xml @@ -0,0 +1,469 @@ +<?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-or-later --> + +<refentry id="sd_notify" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_notify</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_notify</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_notify</refname> + <refname>sd_notifyf</refname> + <refname>sd_pid_notify</refname> + <refname>sd_pid_notifyf</refname> + <refname>sd_pid_notify_with_fds</refname> + <refname>sd_notify_barrier</refname> + <refpurpose>Notify service manager about start-up completion and other service status changes</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-daemon.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_notify</function></funcdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>const char *<parameter>state</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_notifyf</function></funcdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_notify</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>const char *<parameter>state</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_notifyf</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>const char *<parameter>format</parameter></paramdef> + <paramdef>…</paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_notify_with_fds</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>const char *<parameter>state</parameter></paramdef> + <paramdef>const int *<parameter>fds</parameter></paramdef> + <paramdef>unsigned <parameter>n_fds</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_notify_barrier</function></funcdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>uint64_t <parameter>timeout</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para><function>sd_notify()</function> may be called by a service + to notify the service manager about state changes. It can be used + to send arbitrary information, encoded in an + environment-block-like string. Most importantly, it can be used for + start-up completion notification.</para> + + <para>If the <parameter>unset_environment</parameter> parameter is + non-zero, <function>sd_notify()</function> will unset the + <varname>$NOTIFY_SOCKET</varname> environment variable before + returning (regardless of whether the function call itself + succeeded or not). Further calls to + <function>sd_notify()</function> will then fail, but the variable + is no longer inherited by child processes.</para> + + <para>The <parameter>state</parameter> parameter should contain a + newline-separated list of variable assignments, similar in style + to an environment block. A trailing newline is implied if none is + specified. The string may contain any kind of variable + assignments, but the following shall be considered + well-known:</para> + + <variablelist> + <varlistentry> + <term>READY=1</term> + + <listitem><para>Tells the service manager that service startup is finished, or the service finished loading its + configuration. This is only used by systemd if the service definition file has <varname>Type=notify</varname> + set. Since there is little value in signaling non-readiness, the only value services should send is + <literal>READY=1</literal> (i.e. <literal>READY=0</literal> is not defined).</para></listitem> + </varlistentry> + + <varlistentry> + <term>RELOADING=1</term> + + <listitem><para>Tells the service manager that the service is + reloading its configuration. This is useful to allow the + service manager to track the service's internal state, and + present it to the user. Note that a service that sends this + notification must also send a <literal>READY=1</literal> + notification when it completed reloading its + configuration. Reloads are propagated in the same way as they + are when initiated by the user.</para></listitem> + </varlistentry> + + <varlistentry> + <term>STOPPING=1</term> + + <listitem><para>Tells the service manager that the service is + beginning its shutdown. This is useful to allow the service + manager to track the service's internal state, and present it + to the user.</para></listitem> + </varlistentry> + + <varlistentry> + <term>STATUS=…</term> + + <listitem><para>Passes a single-line UTF-8 status string back + to the service manager that describes the service state. This + is free-form and can be used for various purposes: general + state feedback, fsck-like programs could pass completion + percentages and failing programs could pass a human-readable + error message. Example: <literal>STATUS=Completed 66% of file + system check…</literal></para></listitem> + </varlistentry> + + <varlistentry> + <term>ERRNO=…</term> + + <listitem><para>If a service fails, the errno-style error + code, formatted as string. Example: <literal>ERRNO=2</literal> + for ENOENT.</para></listitem> + </varlistentry> + + <varlistentry> + <term>BUSERROR=…</term> + + <listitem><para>If a service fails, the D-Bus error-style + error code. Example: + <literal>BUSERROR=org.freedesktop.DBus.Error.TimedOut</literal></para></listitem> + </varlistentry> + + <varlistentry> + <term>MAINPID=…</term> + + <listitem><para>The main process ID (PID) of the service, in + case the service manager did not fork off the process itself. + Example: <literal>MAINPID=4711</literal></para></listitem> + </varlistentry> + + <varlistentry> + <term>WATCHDOG=1</term> + + <listitem><para>Tells the service manager to update the + watchdog timestamp. This is the keep-alive ping that services + need to issue in regular intervals if + <varname>WatchdogSec=</varname> is enabled for it. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information how to enable this functionality and + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for the details of how the service can check whether the + watchdog is enabled. </para></listitem> + </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. + Notice that this is not available when using <function>sd_event_set_watchdog()</function> + or <function>sd_watchdog_enabled()</function>. + Example : <literal>WATCHDOG_USEC=20000000</literal></para></listitem> + </varlistentry> + + <varlistentry> + <term>EXTEND_TIMEOUT_USEC=…</term> + + <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 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> + </varlistentry> + + <varlistentry> + <term>FDSTORE=1</term> + + <listitem><para>Stores additional file descriptors in the service manager. File descriptors sent this way will + be maintained per-service by the service manager and will later be handed back using the usual file descriptor + passing logic at the next invocation of the service, see + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This is + useful for implementing services that can restart after an explicit request or a crash without losing + state. Any open sockets and other file descriptors which should not be closed during the restart may be stored + this way. Application state can either be serialized to a file in <filename>/run/</filename>, or better, stored + in a <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> memory + file descriptor. Note that the service manager will accept messages for a service only if its + <varname>FileDescriptorStoreMax=</varname> setting is non-zero (defaults to zero, see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If + <varname>FDPOLL=0</varname> is not set and the file descriptors sent are pollable (see + <citerefentry><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>), then any + <constant>EPOLLHUP</constant> or <constant>EPOLLERR</constant> event seen on them will result in their + automatic removal from the store. Multiple arrays of file descriptors may be sent in separate messages, in + which case the arrays are combined. Note that the service manager removes duplicate (pointing to the same + object) file descriptors before passing them to the service. Use <function>sd_pid_notify_with_fds()</function> + to send messages with <literal>FDSTORE=1</literal>, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term>FDSTOREREMOVE=1</term> + + <listitem><para>Removes file descriptors from the file descriptor store. This field needs to be combined with + <varname>FDNAME=</varname> to specify the name of the file descriptors to remove.</para></listitem> + </varlistentry> + + <varlistentry> + <term>FDNAME=…</term> + + <listitem><para>When used in combination with <varname>FDSTORE=1</varname>, specifies a name for the submitted + file descriptors. When used with <varname>FDSTOREREMOVE=1</varname>, specifies the name for the file + descriptors to remove. This name is passed to the service during activation, and may be queried using + <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>. File + descriptors submitted without this field set, will implicitly get the name <literal>stored</literal> + assigned. Note that, if multiple file descriptors are submitted at once, the specified name will be assigned to + all of them. In order to assign different names to submitted file descriptors, submit them in separate + invocations of <function>sd_pid_notify_with_fds()</function>. The name may consist of arbitrary ASCII + characters except control characters or <literal>:</literal>. It may not be longer than 255 characters. If a + submitted name does not follow these restrictions, it is ignored.</para></listitem> + </varlistentry> + + <varlistentry> + <term>FDPOLL=0</term> + + <listitem><para>When used in combination with <varname>FDSTORE=1</varname>, disables polling of the stored + file descriptors regardless of whether or not they are pollable. As this option disables automatic cleanup + of the stored file descriptors on EPOLLERR and EPOLLHUP, care must be taken to ensure proper manual cleanup. + Use of this option is not generally recommended except for when automatic cleanup has unwanted behavior such + as prematurely discarding file descriptors from the store.</para></listitem> + </varlistentry> + + <varlistentry> + <term>BARRIER=1</term> + + <listitem><para>Tells the service manager that the client is explicitly requesting synchronization by means of + closing the file descriptor sent with this command. The service manager guarantees that the processing of a <varname> + BARRIER=1</varname> command will only happen after all previous notification messages sent before this command + have been processed. Hence, this command accompanied with a single file descriptor can be used to synchronize + against reception of all previous status messages. Note that this command cannot be mixed with other notifications, + and has to be sent in a separate message to the service manager, otherwise all assignments will be ignored. Note that + sending 0 or more than 1 file descriptor with this command is a violation of the protocol.</para></listitem> + </varlistentry> + </variablelist> + + <para>It is recommended to prefix variable names that are not + listed above with <varname>X_</varname> to avoid namespace + clashes.</para> + + <para>Note that systemd will accept status data sent from a + service only if the <varname>NotifyAccess=</varname> option is + correctly set in the service definition file. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if either + the sending process is still around at the time PID 1 processes the message, or if the sending process is + explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally forked + off the process, i.e. on all processes that match <varname>NotifyAccess=</varname><option>main</option> or + <varname>NotifyAccess=</varname><option>exec</option>. Conversely, if an auxiliary process of the unit sends an + <function>sd_notify()</function> message and immediately exits, the service manager might not be able to properly + attribute the message to the unit, and thus will ignore it, even if + <varname>NotifyAccess=</varname><option>all</option> is set for it.</para> + + <para>Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications + to units correctly, <function>sd_notify_barrier()</function> may be used. This call acts as a synchronization point + and ensures all notifications sent before this call have been picked up by the service manager when it returns + successfully. Use of <function>sd_notify_barrier()</function> is needed for clients which are not invoked by the + service manager, otherwise this synchronization mechanism is unnecessary for attribution of notifications to the + unit.</para> + + <para><function>sd_notifyf()</function> is similar to + <function>sd_notify()</function> but takes a + <function>printf()</function>-like format string plus + arguments.</para> + + <para><function>sd_pid_notify()</function> and + <function>sd_pid_notifyf()</function> are similar to + <function>sd_notify()</function> and + <function>sd_notifyf()</function> but take a process ID (PID) to + use as originating PID for the message as first argument. This is + useful to send notification messages on behalf of other processes, + provided the appropriate privileges are available. If the PID + argument is specified as 0, the process ID of the calling process + is used, in which case the calls are fully equivalent to + <function>sd_notify()</function> and + <function>sd_notifyf()</function>.</para> + + <para><function>sd_pid_notify_with_fds()</function> is similar to + <function>sd_pid_notify()</function> but takes an additional array + of file descriptors. These file descriptors are sent along the + notification message to the service manager. This is particularly + useful for sending <literal>FDSTORE=1</literal> messages, as + described above. The additional arguments are a pointer to the + file descriptor array plus the number of file descriptors in the + array. If the number of file descriptors is passed as 0, the call + is fully equivalent to <function>sd_pid_notify()</function>, i.e. + no file descriptors are passed. Note that sending file descriptors + to the service manager on messages that do not expect them (i.e. + without <literal>FDSTORE=1</literal>) they are immediately closed + on reception.</para> + + <para><function>sd_notify_barrier()</function> allows the caller to + synchronize against reception of previously sent notification messages + and uses the <literal>BARRIER=1</literal> command. It takes a relative + <varname>timeout</varname> value in microseconds which is passed to + <citerefentry><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum> + </citerefentry>. A value of UINT64_MAX is interpreted as infinite timeout. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, these calls return a negative errno-style error code. If <varname>$NOTIFY_SOCKET</varname> was + not set and hence no status message could be sent, 0 is returned. If the status was sent, these functions return a + positive value. In order to support both service managers that implement this scheme and those which do not, it is + generally recommended to ignore the return value of this call. Note that the return value simply indicates whether + the notification message was enqueued properly, it does not reflect whether the message could be processed + successfully. Specifically, no error is returned when a file descriptor is attempted to be stored using + <varname>FDSTORE=1</varname> but the service is not actually configured to permit storing of file descriptors (see + above).</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + + <para>These functions send a single datagram with the + state string as payload to the <constant>AF_UNIX</constant> socket + referenced in the <varname>$NOTIFY_SOCKET</varname> environment + variable. If the first character of + <varname>$NOTIFY_SOCKET</varname> is <literal>@</literal>, the + string is understood as Linux abstract namespace socket. The + datagram is accompanied by the process credentials of the sending + service, using SCM_CREDENTIALS.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$NOTIFY_SOCKET</varname></term> + + <listitem><para>Set by the service manager for supervised + processes for status and start-up completion notification. + This environment variable specifies the socket + <function>sd_notify()</function> talks to. See above for + details.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Start-up Notification</title> + + <para>When a service finished starting up, it might issue the + following call to notify the service manager:</para> + + <programlisting>sd_notify(0, "READY=1");</programlisting> + </example> + + <example> + <title>Extended Start-up Notification</title> + + <para>A service could send the following after completing + initialization:</para> + + <programlisting>sd_notifyf(0, "READY=1\n" + "STATUS=Processing requests…\n" + "MAINPID=%lu", + (unsigned long) getpid());</programlisting> + </example> + + <example> + <title>Error Cause Notification</title> + + <para>A service could send the following shortly before exiting, on failure:</para> + + <programlisting>sd_notifyf(0, "STATUS=Failed to start up: %s\n" + "ERRNO=%i", + strerror(errno), + errno);</programlisting> + </example> + + <example> + <title>Store a File Descriptor in the Service Manager</title> + + <para>To store an open file descriptor in the service manager, + in order to continue operation after a service restart without + losing state, use <literal>FDSTORE=1</literal>:</para> + + <programlisting>sd_pid_notify_with_fds(0, 0, "FDSTORE=1\nFDNAME=foobar", &fd, 1);</programlisting> + </example> + + <example> + <title>Eliminating race conditions</title> + + <para>When the client sending the notifications is not spawned + by the service manager, it may exit too quickly and the service + manager may fail to attribute them correctly to the unit. To + prevent such races, use <function>sd_notify_barrier()</function> + to synchronize against reception of all notifications sent before + this call is made.</para> + + <programlisting>sd_notify(0, "READY=1"); + /* set timeout to 5 seconds */ + sd_notify_barrier(0, 5 * 1000000); + </programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_path_lookup.xml b/man/sd_path_lookup.xml new file mode 100644 index 0000000..01fb1ed --- /dev/null +++ b/man/sd_path_lookup.xml @@ -0,0 +1,215 @@ +<?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-or-later --> + +<refentry id="sd_path_lookup" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_path_lookup</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_path_lookup</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_path_lookup</refname> + <refname>sd_path_lookup_strv</refname> + + <refpurpose>Query well-known file system paths</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-path.h></funcsynopsisinfo> + + <!-- note: individual constants are not added as <refname>s, there's just too many --> + + <funcsynopsisinfo><token>enum</token> { + <constant>SD_PATH_TEMPORARY</constant>, + <constant>SD_PATH_TEMPORARY_LARGE</constant>, + + <constant>SD_PATH_SYSTEM_BINARIES</constant>, + <constant>SD_PATH_SYSTEM_INCLUDE</constant>, + <constant>SD_PATH_SYSTEM_LIBRARY_PRIVATE</constant>, + <constant>SD_PATH_SYSTEM_LIBRARY_ARCH</constant>, + <constant>SD_PATH_SYSTEM_SHARED</constant>, + <constant>SD_PATH_SYSTEM_CONFIGURATION_FACTORY</constant>, + <constant>SD_PATH_SYSTEM_STATE_FACTORY</constant>, + + <constant>SD_PATH_SYSTEM_CONFIGURATION</constant>, + <constant>SD_PATH_SYSTEM_RUNTIME</constant>, + <constant>SD_PATH_SYSTEM_RUNTIME_LOGS</constant>, + <constant>SD_PATH_SYSTEM_STATE_PRIVATE</constant>, + <constant>SD_PATH_SYSTEM_STATE_LOGS</constant>, + <constant>SD_PATH_SYSTEM_STATE_CACHE</constant>, + <constant>SD_PATH_SYSTEM_STATE_SPOOL</constant>, + + <constant>SD_PATH_USER_BINARIES</constant>, + <constant>SD_PATH_USER_LIBRARY_PRIVATE</constant>, + <constant>SD_PATH_USER_LIBRARY_ARCH</constant>, + <constant>SD_PATH_USER_SHARED</constant>, + + <constant>SD_PATH_USER_CONFIGURATION</constant>, + <constant>SD_PATH_USER_RUNTIME</constant>, + <constant>SD_PATH_USER_STATE_CACHE</constant>, + + <constant>SD_PATH_USER</constant>, + <constant>SD_PATH_USER_DOCUMENTS</constant>, + <constant>SD_PATH_USER_MUSIC</constant>, + <constant>SD_PATH_USER_PICTURES</constant>, + <constant>SD_PATH_USER_VIDEOS</constant>, + <constant>SD_PATH_USER_DOWNLOAD</constant>, + <constant>SD_PATH_USER_PUBLIC</constant>, + <constant>SD_PATH_USER_TEMPLATES</constant>, + <constant>SD_PATH_USER_DESKTOP</constant>, + + <constant>SD_PATH_SEARCH_BINARIES</constant>, + <constant>SD_PATH_SEARCH_BINARIES_DEFAULT</constant>, + <constant>SD_PATH_SEARCH_LIBRARY_PRIVATE</constant>, + <constant>SD_PATH_SEARCH_LIBRARY_ARCH</constant>, + <constant>SD_PATH_SEARCH_SHARED</constant>, + <constant>SD_PATH_SEARCH_CONFIGURATION_FACTORY</constant>, + <constant>SD_PATH_SEARCH_STATE_FACTORY</constant>, + <constant>SD_PATH_SEARCH_CONFIGURATION</constant>, + + <constant>SD_PATH_SYSTEMD_UTIL</constant>, + <constant>SD_PATH_SYSTEMD_SYSTEM_UNIT</constant>, + <constant>SD_PATH_SYSTEMD_SYSTEM_PRESET</constant>, + <constant>SD_PATH_SYSTEMD_USER_UNIT</constant>, + <constant>SD_PATH_SYSTEMD_USER_PRESET</constant>, + <constant>SD_PATH_SYSTEMD_SYSTEM_CONF</constant>, + <constant>SD_PATH_SYSTEMD_USER_CONF</constant>, + <constant>SD_PATH_SYSTEMD_SEARCH_SYSTEM_UNIT</constant>, + <constant>SD_PATH_SYSTEMD_SEARCH_USER_UNIT</constant>, + <constant>SD_PATH_SYSTEMD_SYSTEM_GENERATOR</constant>, + <constant>SD_PATH_SYSTEMD_USER_GENERATOR</constant>, + <constant>SD_PATH_SYSTEMD_SEARCH_SYSTEM_GENERATOR</constant>, + <constant>SD_PATH_SYSTEMD_SEARCH_USER_GENERATOR</constant>, + <constant>SD_PATH_SYSTEMD_SLEEP</constant>, + <constant>SD_PATH_SYSTEMD_SHUTDOWN</constant>, + + <constant>SD_PATH_TMPFILES</constant>, + <constant>SD_PATH_SYSUSERS</constant>, + <constant>SD_PATH_SYSCTL</constant>, + <constant>SD_PATH_BINFMT</constant>, + <constant>SD_PATH_MODULES_LOAD</constant>, + <constant>SD_PATH_CATALOG</constant>, + + <constant>SD_PATH_SYSTEMD_SEARCH_NETWORK</constant>, +};</funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_path_lookup</function></funcdef> + <paramdef>uint64_t <parameter>type</parameter></paramdef> + <paramdef>const char *<parameter>suffix</parameter></paramdef> + <paramdef>char **<parameter>paths</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_path_lookup_strv</function></funcdef> + <paramdef>uint64_t <parameter>type</parameter></paramdef> + <paramdef>const char *<parameter>suffix</parameter></paramdef> + <paramdef>char ***<parameter>paths</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_path_lookup()</function> and <function>sd_bus_path_lookup_strv()</function> return a + single path or set of file system paths specified by the argument <parameter>type</parameter>. In case of + <function>sd_path_lookup()</function> a single <constant>NUL</constant>-terminated string is returned. + When <parameter>type</parameter> specifies a set of paths, they are concatenated using + <literal>:</literal> as a separator (as is traditionally done for e.g. <varname>$PATH</varname> or + <varname>$LD_LIBRARY_PATH</varname>). In case of <function>sd_path_lookup_strv()</function> a + <constant>NULL</constant>-terminated array of strings is returned (strv). If suffix + <parameter>suffix</parameter> is given, it is concatenated to each of the paths after a slash + (<literal>/</literal>). All returned paths are absolute.</para> + + <para>For paths which refer to user directories, the relevant XDG standard is followed, with support for + environment variables like <varname>$XDG_DOCUMENTS_DIR</varname>, <varname>$XDG_DESKTOP_DIR</varname>, + ..., and explicit configuration in <filename>/etc/xdg/user-dirs.conf</filename> or + <filename>${XDG_CONFIG_HOME}/user-dirs.dirs</filename>. See + <ulink url="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html"> + XDG Base Directory Specification</ulink> for details.</para> + + <para><citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry> is + a wrapper around <function>sd_path_lookup()</function> and allows the same set of paths to be queried. + </para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_path_lookup()</function> and <function>sd_path_lookup_strv()</function> + return a non-negative integer. On failure, a negative errno-style error number is returned by either + function.</para> + + <para>The returned string or string array (strv) must be + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>'d by the + caller.</para> + + <refsect2 id='errors'> + <title>Errors</title> + + <para>Returned errors may indicate the following problems:</para> + + <variablelist> + <varlistentry> + <term><constant>-EOPNOTSUPP</constant></term> + + <listitem><para>Unknown identifier <parameter>type</parameter>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>Output argument is <constant>NULL</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>Query failed because of an undefined environment variable (e.g. for + <constant>SD_PATH_USER_RUNTIME</constant> when <varname>$XDG_RUNTIME_DIR</varname> is not + defined).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Examples</title> + + <refsect2> + <title>Look up the location of ~/Documents</title> + + <programlisting><xi:include href="path-documents.c" parse="text" /></programlisting> + <para>Note that the default answer of <filename index='false'>$HOME/Documents</filename> may be + overridden by <filename index='false'>user-dirs.conf</filename> or + <varname>$XDG_DOCUMENTS_DIR</varname>.</para> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_pid_get_owner_uid.xml b/man/sd_pid_get_owner_uid.xml new file mode 100644 index 0000000..3e30aca --- /dev/null +++ b/man/sd_pid_get_owner_uid.xml @@ -0,0 +1,314 @@ +<?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-or-later --> + +<refentry id="sd_pid_get_owner_uid" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_pid_get_owner_uid</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_pid_get_owner_uid</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_pid_get_owner_uid</refname> + <refname>sd_pid_get_session</refname> + <refname>sd_pid_get_user_unit</refname> + <refname>sd_pid_get_unit</refname> + <refname>sd_pid_get_machine_name</refname> + <refname>sd_pid_get_slice</refname> + <refname>sd_pid_get_user_slice</refname> + <refname>sd_pid_get_cgroup</refname> + <refname>sd_peer_get_owner_uid</refname> + <refname>sd_peer_get_session</refname> + <refname>sd_peer_get_user_unit</refname> + <refname>sd_peer_get_unit</refname> + <refname>sd_peer_get_machine_name</refname> + <refname>sd_peer_get_slice</refname> + <refname>sd_peer_get_user_slice</refname> + <refname>sd_peer_get_cgroup</refname> + <refpurpose>Determine the owner uid of the user unit or session, + or the session, user unit, system unit, container/VM or slice that + a specific PID or socket peer belongs to</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_pid_get_owner_uid</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_session</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>session</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_user_unit</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>unit</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_unit</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>unit</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_machine_name</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_slice</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_user_slice</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_pid_get_cgroup</function></funcdef> + <paramdef>pid_t <parameter>pid</parameter></paramdef> + <paramdef>char **<parameter>cgroup</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_owner_uid</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_session</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>session</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_user_unit</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>unit</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_unit</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>unit</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_machine_name</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_slice</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_user_slice</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>slice</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_peer_get_cgroup</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>char **<parameter>cgroup</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_pid_get_owner_uid()</function> may be used to + determine the Unix UID (user identifier) which owns the login + session or systemd user unit of a process identified by the + specified PID. For processes which are not part of a login session + and not managed by a user manager, this function will fail with + <constant>-ENODATA</constant>.</para> + + <para><function>sd_pid_get_session()</function> may be used to + determine the login session identifier of a process identified by + the specified process identifier. The session identifier is a + short string, suitable for usage in file system paths. Please + note the login session may be limited to a stub process or two. + User processes may instead be started from their systemd user + manager, e.g. GUI applications started using DBus activation, as + well as service processes which are shared between multiple logins + of the same user. For processes which are not part of a login + session, this function will fail with <constant>-ENODATA</constant>. + The returned string needs to be freed with the libc <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_pid_get_user_unit()</function> may be used to + determine the systemd user unit (i.e. user service or scope unit) + identifier of a process identified by the specified PID. The + unit name is a short string, suitable for usage in file system + paths. For processes which are not managed by a user manager, this + function will fail with <constant>-ENODATA</constant>. The + returned string needs to be freed with the libc <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_pid_get_unit()</function> may be used to + determine the systemd system unit (i.e. system service or scope + unit) identifier of a process identified by the specified PID. The + unit name is a short string, suitable for usage in file system + paths. Note that not all processes are part of a system + unit/service. For processes not being part of a systemd system + unit, this function will fail with <constant>-ENODATA</constant>. + (More specifically, this call will not work for kernel threads.) + The returned string needs to be freed with the libc <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_pid_get_machine_name()</function> may be used + to determine the name of the VM or container is a member of. The + machine name is a short string, suitable for usage in file system + paths. The returned string needs to be freed with the libc + <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use. For processes not part of a VM or container, this + function fails with <constant>-ENODATA</constant>.</para> + + <para><function>sd_pid_get_slice()</function> may be used to + determine the slice unit the process is a member of. See + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details about slices. The returned string needs to be freed + with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para>Similarly, <function>sd_pid_get_user_slice()</function> + returns the user slice (as managed by the user's systemd instance) + of a process.</para> + + <para><function>sd_pid_get_cgroup()</function> returns the control + group path of the specified process, relative to the root of the + hierarchy. Returns the path without trailing slash, except for + processes located in the root control group, where "/" is + returned. To find the actual control group path in the file system, + the returned path needs to be prefixed with + <filename>/sys/fs/cgroup/</filename> (if the unified control group + setup is used), or + <filename>/sys/fs/cgroup/<replaceable>HIERARCHY</replaceable>/</filename> + (if the legacy multi-hierarchy control group setup is used).</para> + + <para>If the <varname>pid</varname> parameter of any of these + functions is passed as 0, the operation is executed for the + calling process.</para> + + <para>The <function>sd_peer_get_owner_uid()</function>, + <function>sd_peer_get_session()</function>, + <function>sd_peer_get_user_unit()</function>, + <function>sd_peer_get_unit()</function>, + <function>sd_peer_get_machine_name()</function>, + <function>sd_peer_get_slice()</function>, + <function>sd_peer_get_user_slice()</function> and + <function>sd_peer_get_cgroup()</function> calls operate similar to + their PID counterparts, but operate on a connected AF_UNIX socket + and retrieve information about the connected peer process. Note + that these fields are retrieved via <filename>/proc/</filename>, + and hence are not suitable for authorization purposes, as they are + subject to races.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, these calls return 0 or a positive integer. On failure, these calls 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>-ESRCH</constant></term> + + <listitem><para>The specified PID does not refer to a running process.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EBADF</constant></term> + + <listitem><para>The specified socket file descriptor was invalid.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENODATA</constant></term> + + <listitem><para>The given field is not specified for the described process or peer.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where + that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + + <para>Note that the login session identifier as + returned by <function>sd_pid_get_session()</function> + is completely unrelated to the process session + identifier as returned by + <citerefentry><refentrytitle>getsid</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>getsid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_seat_get_active.xml b/man/sd_seat_get_active.xml new file mode 100644 index 0000000..110862c --- /dev/null +++ b/man/sd_seat_get_active.xml @@ -0,0 +1,162 @@ +<?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-or-later --> + +<refentry id="sd_seat_get_active" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_seat_get_active</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_seat_get_active</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_seat_get_active</refname> + <refname>sd_seat_get_sessions</refname> + <refname>sd_seat_can_tty</refname> + <refname>sd_seat_can_graphical</refname> + <refpurpose>Determine state of a specific seat</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_seat_get_active</function></funcdef> + <paramdef>const char *<parameter>seat</parameter></paramdef> + <paramdef>char **<parameter>session</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_seat_get_sessions</function></funcdef> + <paramdef>const char *<parameter>seat</parameter></paramdef> + <paramdef>char ***<parameter>ret_sessions</parameter></paramdef> + <paramdef>uid_t **<parameter>ret_uids</parameter></paramdef> + <paramdef>unsigned int *<parameter>ret_n_uids</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_seat_can_tty</function></funcdef> + <paramdef>const char *<parameter>seat</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_seat_can_graphical</function></funcdef> + <paramdef>const char *<parameter>seat</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_seat_get_active()</function> may be used to + determine which session is currently active on a seat, if there is + any. Returns the session identifier and the user identifier of the + Unix user the session is belonging to. Either the session or the + user identifier parameter can be passed <constant>NULL</constant>, + in case only one of the parameters shall be queried. The returned + string needs to be freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_seat_get_sessions()</function> may be used to determine all sessions on the specified + seat. Returns two arrays, one (<constant>NULL</constant> terminated) with the session identifiers of the + sessions and one with the user identifiers of the Unix users the sessions belong to. An additional + parameter may be used to return the number of entries in the latter array. This value is the same as the + return value if the return value is nonnegative. The output parameters may be passed as + <constant>NULL</constant> in case these output values are not needed. The arrays and the strings + referenced by them need to be freed with the libc <citerefentry + project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> call after + use. Note that instead of an empty array <constant>NULL</constant> may be returned and should be + considered equivalent to an empty array.</para> + + <para><function>sd_seat_can_tty()</function> may be used to + determine whether a specific seat provides TTY functionality, i.e. + is useful as a text console.</para> + + <para><function>sd_seat_can_graphical()</function> may be used to + determine whether a specific seat provides graphics functionality, + i.e. is useful as a graphics display.</para> + + <para>If the <varname>seat</varname> parameter of any of these + functions is passed as <constant>NULL</constant>, the operation is + executed for the seat of the session of the calling process, if + there is any.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para> On success, <function>sd_seat_get_active()</function> returns 0 or a positive integer. On success, + <function>sd_seat_get_sessions()</function> returns the number of entries in the session identifier + array. If the test succeeds, + <function>sd_seat_can_tty()</function> and <function>sd_seat_can_graphical()</function> return a positive + integer, if it fails 0. On failure, these calls 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>-ENODATA</constant></term> + + <listitem><para>The given field is not specified for the described seat.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The specified seat is unknown.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where + that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>History</title> + + <para>In the past, <function>sd_seat_can_multi_session()</function> was used to check whether the seat + supports multiple sessions. All seats support that now, so that function has been deprecated and always + returns true.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_session_get_seat</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml new file mode 100644 index 0000000..9941a05 --- /dev/null +++ b/man/sd_session_is_active.xml @@ -0,0 +1,315 @@ +<?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-or-later --> + +<refentry id="sd_session_is_active" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_session_is_active</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_session_is_active</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_session_is_active</refname> + <refname>sd_session_is_remote</refname> + <refname>sd_session_get_state</refname> + <refname>sd_session_get_uid</refname> + <refname>sd_session_get_seat</refname> + <refname>sd_session_get_service</refname> + <refname>sd_session_get_type</refname> + <refname>sd_session_get_class</refname> + <refname>sd_session_get_desktop</refname> + <refname>sd_session_get_display</refname> + <refname>sd_session_get_tty</refname> + <refname>sd_session_get_vt</refname> + <refname>sd_session_get_remote_host</refname> + <refname>sd_session_get_remote_user</refname> + <refpurpose>Determine state of a specific session</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_session_is_active</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_is_remote</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_state</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>state</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_uid</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>uid_t *<parameter>uid</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_seat</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>seat</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_service</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>service</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_type</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>type</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_class</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>class</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_desktop</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>desktop</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_display</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>display</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_remote_host</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>remote_host</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_remote_user</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>remote_user</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_tty</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>char **<parameter>tty</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_session_get_vt</function></funcdef> + <paramdef>const char *<parameter>session</parameter></paramdef> + <paramdef>unsigned int *<parameter>vt</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_session_is_active()</function> may be used to + determine whether the session identified by the specified session + identifier is currently active (i.e. currently in the foreground + and available for user input) or not.</para> + + <para><function>sd_session_is_remote()</function> may be used to + determine whether the session identified by the specified session + identifier is a remote session (i.e. its remote host is known) or + not.</para> + + <para><function>sd_session_get_state()</function> may be used to + determine the state of the session identified by the specified + session identifier. The following states are currently known: + <literal>online</literal> (session logged in, but session not + active, i.e. not in the foreground), <literal>active</literal> + (session logged in and active, i.e. in the foreground), + <literal>closing</literal> (session nominally logged out, but some + processes belonging to it are still around). In the future + additional states might be defined, client code should be written + to be robust in regards to additional state strings being + returned. This function is a more generic version of + <function>sd_session_is_active()</function>. The returned string + needs to be freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_uid()</function> may be used to + determine the user identifier of the Unix user the session + identified by the specified session identifier belongs to.</para> + + <para><function>sd_session_get_seat()</function> may be used to + determine the seat identifier of the seat the session identified + by the specified session identifier belongs to. Note that not all + sessions are attached to a seat, this call will fail (returning + <constant>-ENODATA</constant>) for them. The returned string needs + to be freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_service()</function> may be used to + determine the name of the service (as passed during PAM session + setup) that registered the session identified by the specified + session identifier. The returned string needs to be freed with the + libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_type()</function> may be used to + determine the type of the session identified by the specified + session identifier. The returned string is one of + <literal>x11</literal>, <literal>wayland</literal>, + <literal>tty</literal>, <literal>mir</literal> or + <literal>unspecified</literal> and needs to be freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_class()</function> may be used to + determine the class of the session identified by the specified + session identifier. The returned string is one of + <literal>user</literal>, <literal>greeter</literal>, + <literal>lock-screen</literal>, or <literal>background</literal> + and needs to be freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_desktop()</function> may be used to + determine the brand of the desktop running on the session + identified by the specified session identifier. This field can be + set freely by desktop environments and does not follow any special + formatting. However, desktops are strongly recommended to use the + same identifiers and capitalization as for + <varname>$XDG_CURRENT_DESKTOP</varname>, as defined by the <ulink + url="http://standards.freedesktop.org/desktop-entry-spec/latest/">Desktop + Entry Specification</ulink>. The returned string needs to be freed + with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_display()</function> may be used to + determine the X11 display of the session identified by the + specified session identifier. The returned string needs to be + freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_remote_host()</function> may be + used to determine the remote hostname of the session identified by + the specified session identifier. The returned string needs to be + freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_remote_user()</function> may be + used to determine the remote username of the session identified by + the specified session identifier. The returned string needs to be + freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use. Note that this value is rarely known to the + system, and even then should not be relied on.</para> + + <para><function>sd_session_get_tty()</function> may be used to + determine the TTY device of the session identified by the + specified session identifier. The returned string needs to be + freed with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_session_get_vt()</function> may be used to + determine the VT number of the session identified by the specified + session identifier. This function will return an error if the seat + does not support VTs.</para> + + <para>If the <varname>session</varname> parameter of any of these + functions is passed as <constant>NULL</constant>, the operation is + executed for the session the calling process is a member of, if + there is any.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>If the test succeeds, + <function>sd_session_is_active()</function> and + <function>sd_session_is_remote()</function> return a + positive integer; if it fails, 0. On success, + <function>sd_session_get_state()</function>, + <function>sd_session_get_uid()</function>, + <function>sd_session_get_seat()</function>, + <function>sd_session_get_service()</function>, + <function>sd_session_get_type()</function>, + <function>sd_session_get_class()</function>, + <function>sd_session_get_display()</function>, + <function>sd_session_get_remote_user()</function>, + <function>sd_session_get_remote_host()</function> and + <function>sd_session_get_tty()</function> return 0 or + a positive integer. On failure, these calls 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>-ENXIO</constant></term> + + <listitem><para>The specified session does not exist.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENODATA</constant></term> + + <listitem><para>The given field is not specified for the described session.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where + that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_uid_get_state.xml b/man/sd_uid_get_state.xml new file mode 100644 index 0000000..2d6fb0c --- /dev/null +++ b/man/sd_uid_get_state.xml @@ -0,0 +1,191 @@ +<?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-or-later --> + +<refentry id="sd_uid_get_state" conditional='HAVE_PAM' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_uid_get_state</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_uid_get_state</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_uid_get_state</refname> + <refname>sd_uid_is_on_seat</refname> + <refname>sd_uid_get_sessions</refname> + <refname>sd_uid_get_seats</refname> + <refname>sd_uid_get_display</refname> + <refpurpose>Determine login state of a specific Unix user ID</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-login.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_uid_get_state</function></funcdef> + <paramdef>uid_t <parameter>uid</parameter></paramdef> + <paramdef>char **<parameter>state</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_uid_is_on_seat</function></funcdef> + <paramdef>uid_t <parameter>uid</parameter></paramdef> + <paramdef>int <parameter>require_active</parameter></paramdef> + <paramdef>const char *<parameter>seat</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_uid_get_sessions</function></funcdef> + <paramdef>uid_t <parameter>uid</parameter></paramdef> + <paramdef>int <parameter>require_active</parameter></paramdef> + <paramdef>char ***<parameter>sessions</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_uid_get_seats</function></funcdef> + <paramdef>uid_t <parameter>uid</parameter></paramdef> + <paramdef>int <parameter>require_active</parameter></paramdef> + <paramdef>char ***<parameter>seats</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_uid_get_display</function></funcdef> + <paramdef>uid_t <parameter>uid</parameter></paramdef> + <paramdef>char **<parameter>session</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>sd_uid_get_state()</function> may be used to + determine the login state of a specific Unix user identifier. The + following states are currently known: <literal>offline</literal> + (user not logged in at all), <literal>lingering</literal> (user + not logged in, but some user services running), + <literal>online</literal> (user logged in, but not active, i.e. + has no session in the foreground), <literal>active</literal> (user + logged in, and has at least one active session, i.e. one session + in the foreground), <literal>closing</literal> (user not logged + in, and not lingering, but some processes are still around). In + the future additional states might be defined, client code should + be written to be robust in regards to additional state strings + being returned. The returned string needs to be freed with the + libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use.</para> + + <para><function>sd_uid_is_on_seat()</function> may be used to + determine whether a specific user is logged in or active on a + specific seat. Accepts a Unix user identifier and a seat + identifier string as parameters. The + <parameter>require_active</parameter> parameter is a boolean + value. If non-zero (true), this function will test if the user is + active (i.e. has a session that is in the foreground and accepting + user input) on the specified seat, otherwise (false) only if the + user is logged in (and possibly inactive) on the specified + seat.</para> + + <para><function>sd_uid_get_sessions()</function> may be used to + determine the current sessions of the specified user. Accepts a + Unix user identifier as parameter. The + <parameter>require_active</parameter> parameter controls whether + the returned list shall consist of only those sessions where the + user is currently active (> 0), where the user is currently + online but possibly inactive (= 0), or logged in at all but + possibly closing the session (< 0). The call returns a + <constant>NULL</constant> terminated string array of session + identifiers in <parameter>sessions</parameter> which needs to be + freed by the caller with the libc + <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call after use, including all the strings referenced. If the + string array parameter is passed as <constant>NULL</constant>, the + array will not be filled in, but the return code still indicates + the number of current sessions. Note that instead of an empty + array <constant>NULL</constant> may be returned and should be + considered equivalent to an empty array.</para> + + <para>Similarly, <function>sd_uid_get_seats()</function> may be + used to determine the list of seats on which the user currently + has sessions. Similar semantics apply, however note that the user + may have multiple sessions on the same seat as well as sessions + with no attached seat and hence the number of entries in the + returned array may differ from the one returned by + <function>sd_uid_get_sessions()</function>.</para> + + <para><function>sd_uid_get_display()</function> returns the name + of the "primary" session of a user. If the user has graphical + sessions, it will be the oldest graphical session. Otherwise, it + will be the oldest open session.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_uid_get_state()</function> returns 0 or a positive integer. If the test + succeeds, <function>sd_uid_is_on_seat()</function> returns a positive integer; if it fails, 0. + <function>sd_uid_get_sessions()</function> and <function>sd_uid_get_seats()</function> return the number + of entries in the returned arrays. <function>sd_uid_get_display()</function> returns a non-negative code + on success. On failure, these calls 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>-ENODATA</constant></term> + + <listitem><para>The given field is not specified for the described user.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The specified seat is unknown.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EINVAL</constant></term> + + <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, + where that is not accepted). This is also returned if the passed user ID is + <constant>0xFFFF</constant> or <constant>0xFFFFFFFF</constant>, which are undefined on Linux. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_pid_get_owner_uid</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sd_watchdog_enabled.xml b/man/sd_watchdog_enabled.xml new file mode 100644 index 0000000..1abc2f8 --- /dev/null +++ b/man/sd_watchdog_enabled.xml @@ -0,0 +1,142 @@ +<?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-or-later --> + +<refentry id="sd_watchdog_enabled" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sd_watchdog_enabled</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sd_watchdog_enabled</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>sd_watchdog_enabled</refname> + <refpurpose>Check whether the service manager expects watchdog keep-alive notifications from a service</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <systemd/sd-daemon.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>sd_watchdog_enabled</function></funcdef> + <paramdef>int <parameter>unset_environment</parameter></paramdef> + <paramdef>uint64_t *<parameter>usec</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para><function>sd_watchdog_enabled()</function> may be called by + a service to detect whether the service manager expects regular + keep-alive watchdog notification events from it, and the timeout + after which the manager will act on the service if it did not get + such a notification.</para> + + <para>If the <varname>$WATCHDOG_USEC</varname> environment + variable is set, and the <varname>$WATCHDOG_PID</varname> variable + is unset or set to the PID of the current process, the service + manager expects notifications from this process. The manager will + usually terminate a service when it does not get a notification + message within the specified time after startup and after each + previous message. It is recommended that a daemon sends a + keep-alive notification message to the service manager every half + of the time returned here. Notification messages may be sent with + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> + with a message string of <literal>WATCHDOG=1</literal>.</para> + + <para>If the <parameter>unset_environment</parameter> parameter is + non-zero, <function>sd_watchdog_enabled()</function> will unset + the <varname>$WATCHDOG_USEC</varname> and + <varname>$WATCHDOG_PID</varname> environment variables before + returning (regardless of whether the function call itself + succeeded or not). Those variables are no longer inherited by + child processes. Further calls to + <function>sd_watchdog_enabled()</function> will also return with + zero.</para> + + <para>If the <parameter>usec</parameter> parameter is non-<constant>NULL</constant>, + <function>sd_watchdog_enabled()</function> will write the timeout + in µs for the watchdog logic to it.</para> + + <para>To enable service supervision with the watchdog logic, use + <varname>WatchdogSec=</varname> in service files. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>Use + <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + to enable automatic watchdog support in + <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>-based event loops.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On failure, this call returns a negative errno-style error + code. If the service manager expects watchdog keep-alive + notification messages to be sent, > 0 is returned, otherwise 0 + is returned. Only if the return value is > 0, the + <parameter>usec</parameter> parameter is valid after the + call.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/> + + <para>Internally, this function parses the + <varname>$WATCHDOG_PID</varname> and + <varname>$WATCHDOG_USEC</varname> environment variable. The call + will ignore these variables if <varname>$WATCHDOG_PID</varname> + does not contain the PID of the current process, under the + assumption that in that case, the variables were set for a + different process further up the process tree.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$WATCHDOG_PID</varname></term> + + <listitem><para>Set by the system manager for supervised + process for which watchdog support is enabled, and contains + the PID of that process. See above for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$WATCHDOG_USEC</varname></term> + + <listitem><para>Set by the system manager for supervised + process for which watchdog support is enabled, and contains + the watchdog timeout in µs. See above for + details.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/send-unit-files-changed.c b/man/send-unit-files-changed.c new file mode 100644 index 0000000..aecfbcb --- /dev/null +++ b/man/send-unit-files-changed.c @@ -0,0 +1,16 @@ +#include <systemd/sd-bus.h> +#define _cleanup_(f) __attribute__((cleanup(f))) + +int send_unit_files_changed(sd_bus *bus) { + _cleanup_(sd_bus_message_unrefp) sd_bus_message *message = NULL; + int r; + + r = sd_bus_message_new_signal(bus, &message, + "/org/freedesktop/systemd1", + "org.freedesktop.systemd1.Manager", + "UnitFilesChanged"); + if (r < 0) + return r; + + return sd_bus_send(bus, message, NULL); +} diff --git a/man/shutdown.xml b/man/shutdown.xml new file mode 100644 index 0000000..f29010f --- /dev/null +++ b/man/shutdown.xml @@ -0,0 +1,148 @@ +<?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-or-later --> + +<refentry id="shutdown" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>shutdown</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>shutdown</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>shutdown</refname> + <refpurpose>Halt, power-off or reboot the machine</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>shutdown</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt">TIME</arg> + <arg choice="opt" rep="repeat">WALL</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>shutdown</command> may be used to halt, power-off + or reboot the machine.</para> + + <para>The first argument may be a time string (which is usually + <literal>now</literal>). Optionally, this may be followed by a + wall message to be sent to all logged-in users before going + down.</para> + + <para>The time string may either be in the format + <literal>hh:mm</literal> for hour/minutes specifying the time to + execute the shutdown at, specified in 24h clock format. + Alternatively it may be in the syntax <literal>+m</literal> + referring to the specified number of minutes m from now. + <literal>now</literal> is an alias for <literal>+0</literal>, i.e. + for triggering an immediate shutdown. If no time argument is + specified, <literal>+1</literal> is implied.</para> + + <para>Note that to specify a wall message you must specify a time + argument, too.</para> + + <para>If the time argument is used, 5 minutes before the system + goes down the <filename>/run/nologin</filename> file is created to + ensure that further logins shall not be allowed.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--help</option></term> + + <xi:include href="standard-options.xml" xpointer="help-text" /> + </varlistentry> + + <varlistentry> + <term><option>-H</option></term> + <term><option>--halt</option></term> + + <listitem><para>Halt the machine.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-P</option></term> + <term><option>--poweroff</option></term> + + <listitem><para>Power-off the machine (the + default).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--reboot</option></term> + + <listitem><para>Reboot the + machine.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-h</option></term> + + <listitem><para>Equivalent to <option>--poweroff</option>, + unless <option>--halt</option> is specified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-k</option></term> + + <listitem><para>Do not halt, power-off, reboot, just write + wall message.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-wall</option></term> + + <listitem><para>Do not send wall + message before + halt, power-off, reboot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-c</option></term> + + <listitem><para>Cancel a pending shutdown. This may be used + to cancel the effect of an invocation of + <command>shutdown</command> with a time argument that is not + <literal>+0</literal> or + <literal>now</literal>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>halt</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/standard-conf.xml b/man/standard-conf.xml new file mode 100644 index 0000000..69cd7b0 --- /dev/null +++ b/man/standard-conf.xml @@ -0,0 +1,73 @@ +<?xml version="1.0"?> +<!DOCTYPE refsection PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1-or-later + Copyright © 2014 Josh Triplett +--> + +<refsection> + <refsection id='confd'> + <title>Configuration Directories and Precedence</title> + + <para>Configuration files are read from directories in <filename>/etc/</filename>, + <filename>/run/</filename>, <filename>/usr/local/lib/</filename>, and <filename>/usr/lib/</filename>, in + order of precedence, as listed in the SYNOPSIS section above. Files must have the + <literal>.conf</literal> extension. 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>.</para> + + <para>All configuration files are sorted by their filename in lexicographic order, regardless of which of + the directories they reside in. If multiple files specify the same option, the entry in the file with the + lexicographically latest name will take precedence. Thus, the configuration in a certain file may either + be replaced completely (by placing a file with the same name in a directory with higher priority), or + individual settings might be changed (by specifying additional settings in a file with a different name + that is ordered later).</para> + + <para>Packages should install their configuration files in <filename>/usr/lib/</filename> (distribution + packages) or <filename>/usr/local/lib/</filename> (local installs). Files in <filename>/etc/</filename> + are reserved for the local administrator, who may use this logic to override the configuration files + installed by vendor packages. It is recommended to prefix all filenames with a two-digit number and a + dash, to simplify the ordering of the files.</para> + + <para>If the administrator wants to disable a configuration file supplied by the vendor, the recommended + way is to place a symlink to <filename>/dev/null</filename> in the configuration directory in + <filename>/etc/</filename>, with the same filename as the vendor configuration file. If the vendor + configuration file is included in the initrd image, the image has to be regenerated.</para> + </refsection> + + <refsection id='main-conf'> + <title>Configuration Directories and Precedence</title> + + <para>The default configuration is defined during compilation, so a + configuration file is only needed when it is necessary to deviate + from those defaults. By default, the configuration file in + <filename>/etc/systemd/</filename> contains commented out entries + showing the defaults as a guide to the administrator. This file + can be edited to create local overrides. + </para> + + <para>When packages need to customize the configuration, they can install configuration snippets in + <filename>/usr/lib/systemd/*.conf.d/</filename> or <filename>/usr/local/lib/systemd/*.conf.d/</filename>. + The main configuration file is read before any of the configuration directories, and has the lowest + precedence; entries in a file in any configuration directory override entries in the single configuration + file. Files in the <filename>*.conf.d/</filename> configuration subdirectories are sorted by their + filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple + files specify the same option, for options which accept just a single value, the entry in the file with + the lexicographically latest name takes precedence. For options which accept a list of values, entries + are collected as they occur in files sorted lexicographically.</para> + + <para>Files in <filename>/etc/</filename> are reserved for the local administrator, who may use this + logic to override the configuration files installed by vendor packages. It is recommended to prefix all + filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the + files.</para> + + <para>To disable a configuration file supplied by the vendor, the + recommended way is to place a symlink to + <filename>/dev/null</filename> in the configuration directory in + <filename>/etc/</filename>, with the same filename as the vendor + configuration file.</para> + </refsection> +</refsection> diff --git a/man/standard-options.xml b/man/standard-options.xml new file mode 100644 index 0000000..64274ce --- /dev/null +++ b/man/standard-options.xml @@ -0,0 +1,55 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<variablelist> + <varlistentry id='help'> + <term><option>-h</option></term> + <term><option>--help</option></term> + + <listitem id='help-text'> + <para>Print a short help text and exit. + </para></listitem> + </varlistentry> + + <varlistentry id='version'> + <term><option>--version</option></term> + + <listitem id='version-text'> + <para>Print a short version string and exit.</para> + </listitem> + </varlistentry> + + <varlistentry id='no-pager'> + <term><option>--no-pager</option></term> + + <listitem> + <para>Do not pipe output into a pager.</para> + </listitem> + </varlistentry> + + <varlistentry id='no-ask-password'> + <term><option>--no-ask-password</option></term> + + <listitem><para>Do not query the user for authentication for privileged operations.</para></listitem> + </varlistentry> + + <varlistentry id='no-legend'> + <term><option>--no-legend</option></term> + + <listitem> + <para>Do not print the legend, i.e. column headers and the + footer with hints.</para> + </listitem> + </varlistentry> + + <varlistentry id='cat-config'> + <term><option>--cat-config</option></term> + + <listitem> + <para>Copy the contents of config files to standard output. + Before each file, the filename is printed as a comment.</para> + </listitem> + </varlistentry> +</variablelist> diff --git a/man/standard-specifiers.xml b/man/standard-specifiers.xml new file mode 100644 index 0000000..40bb6cc --- /dev/null +++ b/man/standard-specifiers.xml @@ -0,0 +1,72 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<tbody> + <row id='b'> + <entry><literal>%b</literal></entry> + <entry>Boot ID</entry> + <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry> + </row> + <row id='a'> + <entry><literal>%a</literal></entry> + <entry>Architecture</entry> + <entry>A short string identifying the architecture of the local system. A string such as <constant>x86</constant>, <constant>x86-64</constant> or <constant>arm64</constant>. See the architectures defined for <varname>ConditionArchitecture=</varname> in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a full list.</entry> + </row> + <row id='B'> + <entry><literal>%B</literal></entry> + <entry>Operating system build ID</entry> + <entry>The operating system build identifier of the running system, as read from the <varname>BUILD_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry> + </row> + <row id='H'> + <entry><literal>%H</literal></entry> + <entry>Host name</entry> + <entry>The hostname of the running system.</entry> + </row> + <row id='l'> + <entry><literal>%l</literal></entry> + <entry>Short host name</entry> + <entry>The hostname of the running system, truncated at the first dot to remove any domain component.</entry> + </row> + <row id='m'> + <entry><literal>%m</literal></entry> + <entry>Machine ID</entry> + <entry>The machine ID of the running system, formatted as string. See <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry> + </row> + <row id='o'> + <entry><literal>%o</literal></entry> + <entry>Operating system ID</entry> + <entry>The operating system identifier of the running system, as read from the <varname>ID=</varname> field of <filename>/etc/os-release</filename>. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry> + </row> + <row id='T'> + <entry><literal>%T</literal></entry> + <entry>Directory for temporary files</entry> + <entry>This is either <filename>/tmp<!-- no / --></filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to. (Note that the directory may be specified without a trailing slash.)</entry> + </row> + <row id='v'> + <entry><literal>%v</literal></entry> + <entry>Kernel release</entry> + <entry>Identical to <command>uname -r</command> output.</entry> + </row> + <row id='V'> + <entry><literal>%V</literal></entry> + <entry>Directory for larger and persistent temporary files</entry> + <entry>This is either <filename>/var/tmp<!-- no / --></filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to. (Note that the directory may be specified without a trailing slash.)</entry> + </row> + <row id='w'> + <entry><literal>%w</literal></entry> + <entry>Operating system version ID</entry> + <entry>The operating system version identifier of the running system, as read from the <varname>VERSION_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry> + </row> + <row id='W'> + <entry><literal>%W</literal></entry> + <entry>Operating system variant ID</entry> + <entry>The operating system variant identifier of the running system, as read from the <varname>VARIANT_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry> + </row> + <row id='percent'> + <entry><literal>%%</literal></entry> + <entry>Single percent sign</entry> + <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry> + </row> +</tbody> diff --git a/man/supported-controllers.xml b/man/supported-controllers.xml new file mode 100644 index 0000000..61cdf46 --- /dev/null +++ b/man/supported-controllers.xml @@ -0,0 +1,14 @@ +<?xml version="1.0"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1-or-later +--> + +<refsect1> + +<para id="controllers-text">The following controller names may be specified: <option>cpu</option>, <option>cpuacct</option>, +<option>cpuset</option>, <option>io</option>, <option>blkio</option>, <option>memory</option>, <option>devices</option>, +<option>pids</option>, <option>bpf-firewall</option>, and <option>bpf-devices</option>.</para> + +</refsect1> diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml new file mode 100644 index 0000000..4d810e6 --- /dev/null +++ b/man/sysctl.d.xml @@ -0,0 +1,193 @@ +<?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-or-later --> +<refentry id="sysctl.d" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sysctl.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sysctl.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>sysctl.d</refname> + <refpurpose>Configure kernel parameters at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/sysctl.d/*.conf</filename></para> + <para><filename>/run/sysctl.d/*.conf</filename></para> + <para><filename>/usr/lib/sysctl.d/*.conf</filename></para> + + <programlisting>key.name.under.proc.sys = some value +key/name/under/proc/sys = some value +key/middle.part.with.dots/foo = 123 +key.middle/part/with/dots.foo = 123 +-key.that.will.not.fail = value +key.pattern.*.with.glob = whatever +-key.pattern.excluded.with.glob +key.pattern.overridden.with.glob = custom +</programlisting> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>At boot, + <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + reads configuration files from the above directories to configure + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + kernel parameters.</para> + </refsect1> + + <refsect1> + <title>Configuration Format</title> + + <para>The configuration files contain a list of variable + assignments, separated by newlines. Empty lines and lines whose + first non-whitespace character is <literal>#</literal> or + <literal>;</literal> are ignored.</para> + + <para>Note that either <literal>/</literal> or <literal>.</literal> may be used as separators within + sysctl variable names. If the first separator is a slash, remaining slashes and dots are left intact. If + the first separator is a dot, dots and slashes are interchanged. + <literal>kernel.domainname=foo</literal> and <literal>kernel/domainname=foo</literal> are equivalent and + will cause <literal>foo</literal> to be written to + <filename>/proc/sys/kernel/domainname</filename>. Either + <literal>net.ipv4.conf.enp3s0/200.forwarding</literal> or + <literal>net/ipv4/conf/enp3s0.200/forwarding</literal> may be used to refer to + <filename>/proc/sys/net/ipv4/conf/enp3s0.200/forwarding</filename>. A glob + <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry> pattern may be + used to write the same value to all matching keys. Keys for which an explicit pattern exists will be + excluded from any glob matching. In addition, a key may be explicitly excluded from being set by any + matching glob patterns by specifying the key name prefixed with a <literal>-</literal> character and not + followed by <literal>=</literal>, see SYNOPSIS.</para> + + <para>Any access permission errors and attempts to write variables not present on the local system are + logged at debug level and do not cause the service to fail. Other types of errors when setting variables + are logged with higher priority and cause the service to return failure at the end (after processing + other variables). As an exception, if a variable assignment is prefixed with a single + <literal>-</literal> character, failure to set the variable for any reason will be logged at debug level + and will not cause the service to fail.</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 each network interface as it + shows up in the system. (More specifically, <filename>net.ipv4.conf.*</filename>, + <filename>net.ipv6.conf.*</filename>, <filename>net.ipv4.neigh.*</filename> and + <filename>net.ipv6.neigh.*</filename>).</para> + + <para>Many sysctl parameters only become available when certain + kernel modules are loaded. Modules are usually loaded on demand, + e.g. when certain hardware is plugged in or network brought up. + This means that + <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + which runs during early boot will not configure such parameters if + they become available after it has run. To set such parameters, it + is recommended to add an + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> + rule to set those parameters when they become available. + Alternatively, a slightly simpler and less efficient option is to + add the module to + <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + causing it to be loaded statically before sysctl settings are + applied (see example below).</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="confd" /> + + <refsect1> + <title>Examples</title> + <example> + <title>Set kernel YP domain name</title> + <para><filename>/etc/sysctl.d/domain-name.conf</filename>: + </para> + + <programlisting>kernel.domainname=example.com</programlisting> + </example> + + <example> + <title>Apply settings available only when a certain module is loaded (method one)</title> + <para><filename>/etc/udev/rules.d/99-bridge.rules</filename>: + </para> + + <programlisting>ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", \ + RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/net/bridge" +</programlisting> + + <para><filename>/etc/sysctl.d/bridge.conf</filename>: + </para> + + <programlisting>net.bridge.bridge-nf-call-ip6tables = 0 +net.bridge.bridge-nf-call-iptables = 0 +net.bridge.bridge-nf-call-arptables = 0 +</programlisting> + + <para>This method applies settings when the module is + loaded. Please note that, unless the <filename>br_netfilter</filename> + module is loaded, bridged packets will not be filtered by + Netfilter (starting with kernel 3.18), so simply not loading the + module is sufficient to avoid filtering.</para> + </example> + + <example> + <title>Apply settings available only when a certain module is loaded (method two)</title> + <para><filename>/etc/modules-load.d/bridge.conf</filename>: + </para> + + <programlisting>br_netfilter</programlisting> + + <para><filename>/etc/sysctl.d/bridge.conf</filename>: + </para> + + <programlisting>net.bridge.bridge-nf-call-ip6tables = 0 +net.bridge.bridge-nf-call-iptables = 0 +net.bridge.bridge-nf-call-arptables = 0 +</programlisting> + + <para>This method forces the module to be always loaded. Please + note that, unless the <filename>br_netfilter</filename> module is + loaded, bridged packets will not be filtered with Netfilter + (starting with kernel 3.18), so simply not loading the module is + sufficient to avoid filtering.</para> + </example> + + <example> + <title>Set network routing properties for all interfaces</title> + <para><filename>/etc/sysctl.d/20-rp_filter.conf</filename>:</para> + + <programlisting>net.ipv4.conf.default.rp_filter = 2 +net.ipv4.conf.*.rp_filter = 2 +-net.ipv4.conf.all.rp_filter +net.ipv4.conf.hub0.rp_filter = 1 +</programlisting> + + <para>The <option>rp_filter</option> key will be set to "2" for all interfaces, except "hub0". We set + <filename>net.ipv4.conf.default.rp_filter</filename> first, so any interfaces which are added + <emphasis>later</emphasis> will get this value (this also covers any interfaces detected while we're + running). The glob matches any interfaces which were detected <emphasis>earlier</emphasis>. The glob + will also match <filename>net.ipv4.conf.all.rp_filter</filename>, which we don't want to set at all, so + it is explicitly excluded. And "hub0" is excluded from the glob because it has an explicit setting. + </para> + </example> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>sysctl.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>modprobe</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/system-only.xml b/man/system-only.xml new file mode 100644 index 0000000..afd3d32 --- /dev/null +++ b/man/system-only.xml @@ -0,0 +1,16 @@ +<?xml version="1.0"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1-or-later +--> + +<refsect1> + +<para id="singular">This option is only available for system services and is not supported for services +running in per-user instances of the service manager.</para> + +<para id="plural">These options are only available for system services and are not supported for services +running in per-user instances of the service manager.</para> + +</refsect1> diff --git a/man/systemctl.xml b/man/systemctl.xml new file mode 100644 index 0000000..0b8d0e3 --- /dev/null +++ b/man/systemctl.xml @@ -0,0 +1,2339 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemctl" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemctl</refname> + <refpurpose>Control the systemd system and service manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">COMMAND</arg> + <arg choice="opt" rep="repeat">UNIT</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemctl</command> may be used to introspect and + control the state of the <literal>systemd</literal> system and + service manager. Please refer to + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for an introduction into the basic concepts and functionality this + tool manages.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <refsect2> + <title>Unit Commands (Introspection and Modification)</title> + + <variablelist> + <varlistentry> + <term><command>list-units</command> <optional><replaceable>PATTERN</replaceable>…</optional></term> + + <listitem> + <para>List units that <command>systemd</command> currently has in memory. This includes units that are + either referenced directly or through a dependency, units that are pinned by applications programmatically, + or units that were active in the past and have failed. By default only units which are active, have pending + jobs, or have failed are shown; this can be changed with option <option>--all</option>. If one or more + <replaceable>PATTERN</replaceable>s are specified, only units matching one of them are shown. The units + that are shown are additionally filtered by <option>--type=</option> and <option>--state=</option> if those + options are specified.</para> + + <para>Produces output similar to + <programlisting> UNIT LOAD ACTIVE SUB DESCRIPTION + sys-module-fuse.device loaded active plugged /sys/module/fuse + -.mount loaded active mounted Root Mount + boot-efi.mount loaded active mounted /boot/efi + systemd-journald.service loaded active running Journal Service + systemd-logind.service loaded active running Login Service +● user@1000.service loaded failed failed User Manager for UID 1000 + … + systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories + +LOAD = Reflects whether the unit definition was properly loaded. +ACTIVE = The high-level unit activation state, i.e. generalization of SUB. +SUB = The low-level unit activation state, values depend on unit type. + +123 loaded units listed. Pass --all to see loaded but inactive units, too. +To show all installed unit files use 'systemctl list-unit-files'. + </programlisting> + The header and the last unit of a given type are underlined if the + terminal supports that. A colored dot is shown next to services which + were masked, not found, or otherwise failed.</para> + + <para>The LOAD column shows the load state, one of <constant>loaded</constant>, + <constant>not-found</constant>, <constant>bad-setting</constant>, <constant>error</constant>, + <constant>masked</constant>. The ACTIVE columns shows the general unit state, one of + <constant>active</constant>, <constant>reloading</constant>, <constant>inactive</constant>, + <constant>failed</constant>, <constant>activating</constant>, <constant>deactivating</constant>. The SUB + column shows the unit-type-specific detailed state of the unit, possible values vary by unit type. The list + of possible LOAD, ACTIVE, and SUB states is not constant and new systemd releases may both add and remove + values. <programlisting>systemctl --state=help</programlisting> command maybe be used to display the + current set of possible values.</para> + + <para>This is the default command.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>list-sockets</command> <optional><replaceable>PATTERN</replaceable>…</optional></term> + + <listitem> + <para>List socket units currently in memory, ordered by listening address. If one or more + <replaceable>PATTERN</replaceable>s are specified, only socket units matching one of them are + shown. Produces output similar to + <programlisting> +LISTEN UNIT ACTIVATES +/dev/initctl systemd-initctl.socket systemd-initctl.service +… +[::]:22 sshd.socket sshd.service +kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service + +5 sockets listed.</programlisting> + Note: because the addresses might contains spaces, this output + is not suitable for programmatic consumption. + </para> + + <para>Also see <option>--show-types</option>, <option>--all</option>, and <option>--state=</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>list-timers</command> <optional><replaceable>PATTERN</replaceable>…</optional></term> + + <listitem> + <para>List timer units currently in memory, ordered by the time they elapse next. If one or more + <replaceable>PATTERN</replaceable>s are specified, only units matching one of them are shown. + Produces output similar to + <programlisting> +NEXT LEFT LAST PASSED UNIT ACTIVATES +n/a n/a Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service +Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service +Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service +Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service + </programlisting> + </para> + + <para><emphasis>NEXT</emphasis> shows the next time the timer will run.</para> + <para><emphasis>LEFT</emphasis> shows how long till the next time the timer runs.</para> + <para><emphasis>LAST</emphasis> shows the last time the timer ran.</para> + <para><emphasis>PASSED</emphasis> shows how long has passed since the timer last ran.</para> + <para><emphasis>UNIT</emphasis> shows the name of the timer</para> + <para><emphasis>ACTIVATES</emphasis> shows the name the service the timer activates when it runs.</para> + + <para>Also see <option>--all</option> and <option>--state=</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>is-active <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Check whether any of the specified units are active + (i.e. running). Returns an exit code + <constant>0</constant> if at least one is active, or + non-zero otherwise. Unless <option>--quiet</option> is + specified, this will also print the current unit state to + standard output.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>is-failed <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Check whether any of the specified units are in a + "failed" state. Returns an exit code + <constant>0</constant> if at least one has failed, + non-zero otherwise. Unless <option>--quiet</option> is + specified, this will also print the current unit state to + standard output.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>status</command> <optional><replaceable>PATTERN</replaceable>…|<replaceable>PID</replaceable>…]</optional></term> + + <listitem> + <para>Show terse runtime status information about one or + more units, followed by most recent log data from the + journal. If no units are specified, show system status. If + combined with <option>--all</option>, also show the status of + all units (subject to limitations specified with + <option>-t</option>). If a PID is passed, show information + about the unit the process belongs to.</para> + + <para>This function is intended to generate human-readable + output. If you are looking for computer-parsable output, + use <command>show</command> instead. By default, this + function only shows 10 lines of output and ellipsizes + lines to fit in the terminal window. This can be changed + with <option>--lines</option> and <option>--full</option>, + see above. In addition, <command>journalctl + --unit=<replaceable>NAME</replaceable></command> or + <command>journalctl + --user-unit=<replaceable>NAME</replaceable></command> use + a similar filter for messages and might be more + convenient. + </para> + + <para>systemd implicitly loads units as necessary, so just running the <command>status</command> will + attempt to load a file. The command is thus not useful for determining if something was already loaded or + not. The units may possibly also be quickly unloaded after the operation is completed if there's no reason + to keep it in memory thereafter. + </para> + + <example> + <title>Example output from systemctl status </title> + + <programlisting>$ systemctl status bluetooth +● bluetooth.service - Bluetooth service + Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) + Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago + Docs: man:bluetoothd(8) + Main PID: 930 (bluetoothd) + Status: "Running" + Tasks: 1 + Memory: 648.0K + CPU: 435ms + CGroup: /system.slice/bluetooth.service + └─930 /usr/lib/bluetooth/bluetoothd + +Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service +Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered +Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5) +</programlisting> + + <para>The dot ("●") uses color on supported terminals to summarize the unit state at a glance. White + indicates an <literal>inactive</literal> or <literal>deactivating</literal> state. Red indicates a + <literal>failed</literal> or <literal>error</literal> state and green indicates an + <literal>active</literal>, <literal>reloading</literal> or <literal>activating</literal> state. + </para> + + <para>The "Loaded:" line in the output will show <literal>loaded</literal> if the unit has been loaded into + memory. Other possible values for "Loaded:" include: <literal>error</literal> if there was a problem + loading it, <literal>not-found</literal> if no unit file was found for this unit, + <literal>bad-setting</literal> if an essential unit file setting could not be parsed and + <literal>masked</literal> if the unit file has been masked. Along with showing the path to the unit file, + this line will also show the enablement state. Enabled commands start at boot. See the full table of + possible enablement states — including the definition of <literal>masked</literal> — in the documentation + for the <command>is-enabled</command> command. + </para> + + <para>The "Active:" line shows active state. The value is usually <literal>active</literal> or + <literal>inactive</literal>. Active could mean started, bound, plugged in, etc depending on the unit type. + The unit could also be in process of changing states, reporting a state of <literal>activating</literal> or + <literal>deactivating</literal>. A special <literal>failed</literal> state is entered when the service + failed in some way, such as a crash, exiting with an error code or timing out. If the failed state is + entered the cause will be logged for later reference.</para> + </example> + + </listitem> + </varlistentry> + + <varlistentry> + <term><command>show</command> <optional><replaceable>PATTERN</replaceable>…|<replaceable>JOB</replaceable>…</optional></term> + + <listitem> + <para>Show properties of one or more units, jobs, or the manager itself. If no argument is specified, + properties of the manager will be shown. If a unit name is specified, properties of the unit are shown, and + if a job ID is specified, properties of the job are shown. By default, empty properties are suppressed. Use + <option>--all</option> to show those too. To select specific properties to show, use + <option>--property=</option>. This command is intended to be used whenever computer-parsable output is + required. Use <command>status</command> if you are looking for formatted human-readable output.</para> + + <para>Many properties shown by <command>systemctl show</command> map directly to configuration settings of + the system and service manager and its unit files. Note that the properties shown by the command are + generally more low-level, normalized versions of the original configuration settings and expose runtime + state in addition to configuration. For example, properties shown for service units include the service's + current main process identifier as <literal>MainPID</literal> (which is runtime state), and time settings + are always exposed as properties ending in the <literal>…USec</literal> suffix even if a matching + configuration options end in <literal>…Sec</literal>, because microseconds is the normalized time unit used + internally by the system and service manager.</para> + + <para>For details about many of these properties, see the documentation of the D-Bus interface + backing these properties, see + <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>cat <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Show backing files of one or more units. Prints the + "fragment" and "drop-ins" (source files) of units. Each + file is preceded by a comment which includes the file + name. Note that this shows the contents of the backing files + on disk, which may not match the system manager's + understanding of these units if any unit files were + updated on disk and the <command>daemon-reload</command> + command wasn't issued since.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>help <replaceable>PATTERN</replaceable>…|<replaceable>PID</replaceable>…</command></term> + + <listitem> + <para>Show manual pages for one or more units, if + available. If a PID is given, the manual pages for the unit + the process belongs to are shown.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <command>list-dependencies</command> + <optional><replaceable>UNIT</replaceable>...</optional> + </term> + + <listitem> + <para>Shows units required and wanted by the specified + units. This recursively lists units following the + <varname>Requires=</varname>, + <varname>Requisite=</varname>, + <varname>ConsistsOf=</varname>, + <varname>Wants=</varname>, <varname>BindsTo=</varname> + dependencies. If no units are specified, + <filename>default.target</filename> is implied.</para> + + <para>By default, only target units are recursively + expanded. When <option>--all</option> is passed, all other + units are recursively expanded as well.</para> + + <para>Options <option>--reverse</option>, + <option>--after</option>, <option>--before</option> + may be used to change what types of dependencies + are shown.</para> + + <para>Note that this command only lists units currently loaded into memory by the service manager. In + particular, this command is not suitable to get a comprehensive list at all reverse dependencies on a + specific unit, as it won't list the dependencies declared by units currently not loaded.</para> + </listitem> + </varlistentry> + + <!-- Commands that modify unit state start here --> + + <varlistentry> + <term><command>start <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Start (activate) one or more units specified on the command line.</para> + + <para>Note that unit glob patterns expand to names of units currently in memory. Units which are + not active and are not in a failed state usually are not in memory, and will not be matched by + any pattern. In addition, in case of instantiated units, systemd is often unaware of the instance + name until the instance has been started. Therefore, using glob patterns with + <command>start</command> has limited usefulness. Also, secondary alias names of units are not + considered.</para> + + <para>Option <option>--all</option> may be used to also operate on inactive units which are + referenced by other loaded units. Note that this is not the same as operating on "all" possible + units, because as the previous paragraph describes, such a list is ill-defined. Nevertheless, + <command>systemctl start --all <replaceable>GLOB</replaceable></command> may be useful if all the + units that should match the pattern are pulled in by some target which is known to be loaded. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>stop <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Stop (deactivate) one or more units specified on the command line.</para> + + <para>This command will fail if the unit does not 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> + <term><command>reload <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Asks all units listed on the command line to reload + their configuration. Note that this will reload the + service-specific configuration, not the unit configuration + file of systemd. If you want systemd to reload the + configuration file of a unit, use the + <command>daemon-reload</command> command. In other words: + for the example case of Apache, this will reload Apache's + <filename>httpd.conf</filename> in the web server, not the + <filename>apache.service</filename> systemd unit + file.</para> + + <para>This command should not be confused with the + <command>daemon-reload</command> command.</para> + </listitem> + + </varlistentry> + <varlistentry> + <term><command>restart <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Stop and then start one or more units specified on the command line. If the units are not running + yet, they will be started.</para> + + <para>Note that restarting a unit with this command does not necessarily flush out all of the unit's + resources before it is started again. For example, the per-service file descriptor storage facility (see + <varname>FileDescriptorStoreMax=</varname> in + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>) will + remain intact as long as the unit has a job pending, and is only cleared when the unit is fully stopped and + no jobs are pending anymore. If it is intended that the file descriptor store is flushed out, too, during a + restart operation an explicit <command>systemctl stop</command> command followed by <command>systemctl + start</command> should be issued.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>try-restart <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Stop and then start one or more units specified on the + command line if the units are running. This does nothing + if units are not running.</para> + <!-- Note that we don't document condrestart here, as that is just compatibility support, and we generally + don't document that. --> + </listitem> + </varlistentry> + <varlistentry> + <term><command>reload-or-restart <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Reload one or more units if they support it. If not, stop and then start them instead. If the units + are not running yet, they will be started.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>try-reload-or-restart <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Reload one or more units if they support it. If not, stop and then start them instead. This does + nothing if the units are not running.</para> + <!-- Note that we don't document force-reload here, as that is just compatibility support, and we generally + don't document that. --> + </listitem> + </varlistentry> + <varlistentry> + <term><command>isolate <replaceable>UNIT</replaceable></command></term> + + <listitem> + <para>Start the unit specified on the command line and its dependencies + and stop all others, unless they have + <option>IgnoreOnIsolate=yes</option> (see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + If a unit name with no extension is given, an extension of + <literal>.target</literal> will be assumed.</para> + + <para>This command is dangerous, since it will immediately stop processes that are not enabled in + the new target, possibly including the graphical environment or terminal you are currently using. + </para> + + <para>Note that this is allowed only on units where + <option>AllowIsolate=</option> is enabled. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>kill <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Send a signal to one or more processes of the + unit. Use <option>--kill-who=</option> to select which + process to kill. Use <option>--signal=</option> to select + the signal to send.</para> + </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>freeze <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Freeze one or more units specified on the + command line using cgroup freezer</para> + + <para>Freezing the unit will cause all processes contained within the cgroup corresponding to the unit + to be suspended. Being suspended means that unit's processes won't be scheduled to run on CPU until thawed. + Note that this command is supported only on systems that use unified cgroup hierarchy. Unit is automatically + thawed just before we execute a job against the unit, e.g. before the unit is stopped.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>thaw <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Thaw (unfreeze) one or more units specified on the + command line.</para> + + <para>This is the inverse operation to the <command>freeze</command> command and resumes the execution of + processes in the unit's cgroup.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>set-property <replaceable>UNIT</replaceable> <replaceable>PROPERTY</replaceable>=<replaceable>VALUE</replaceable>…</command></term> + + <listitem> + <para>Set the specified unit properties at runtime where + this is supported. This allows changing configuration + parameter properties such as resource control settings at + runtime. Not all properties may be changed at runtime, but + many resource control settings (primarily those in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>) + may. The changes are applied immediately, and stored on disk + for future boots, unless <option>--runtime</option> is + passed, in which case the settings only apply until the + 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 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.</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> + + <varlistentry> + <term><command>service-log-level</command> <replaceable>SERVICE</replaceable> [<replaceable>LEVEL</replaceable>]</term> + + <listitem><para>If the <replaceable>LEVEL</replaceable> argument is not given, print the current + log level as reported by service <replaceable>SERVICE</replaceable>.</para> + + <para>If the optional argument <replaceable>LEVEL</replaceable> is provided, then change the + current log level of the service to <replaceable>LEVEL</replaceable>. The log level should be a + typical syslog log level, i.e. a value in the range 0…7 or one of the strings + <constant>emerg</constant>, <constant>alert</constant>, <constant>crit</constant>, + <constant>err</constant>, <constant>warning</constant>, <constant>notice</constant>, + <constant>info</constant>, <constant>debug</constant>; see <citerefentry + project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for details.</para> + + <para>The service must have the appropriate + <varname>BusName=<replaceable>destination</replaceable></varname> property and also implement the + generic + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + interface. (<filename>systemctl</filename> will use the generic D-Bus protocol to access the + <interfacename>org.freedesktop.LogControl1.LogLevel</interfacename> interface for the D-Bus name + <replaceable>destination</replaceable>.)</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>service-log-target</command> <replaceable>SERVICE</replaceable> [<replaceable>TARGET</replaceable>]</term> + + <listitem><para>If the <replaceable>TARGET</replaceable> argument is not given, print the current + log target as reported by service <replaceable>SERVICE</replaceable>.</para> + + <para>If the optional argument <replaceable>TARGET</replaceable> is provided, then change the + current log target of the service to <replaceable>TARGET</replaceable>. The log target should be + one of the strings <constant>console</constant> (for log output to the service's standard error + stream), <constant>kmsg</constant> (for log output to the kernel log buffer), + <constant>journal</constant> (for log output to + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + using the native journal protocol), <constant>syslog</constant> (for log output to the classic + syslog socket <filename>/dev/log</filename>), <constant>null</constant> (for no log output + whatsoever) or <constant>auto</constant> (for an automatically determined choice, typically + equivalent to <constant>console</constant> if the service is invoked interactively, and + <constant>journal</constant> or <constant>syslog</constant> otherwise).</para> + + <para>For most services, only a small subset of log targets make sense. In particular, most + "normal" services should only implement <constant>console</constant>, <constant>journal</constant>, + and <constant>null</constant>. Anything else is only appropriate for low-level services that + are active in very early boot before proper logging is established.</para> + + <para>The service must have the appropriate + <varname>BusName=<replaceable>destination</replaceable></varname> property and also implement the + generic + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + interface. (<filename>systemctl</filename> will use the generic D-Bus protocol to access the + <interfacename>org.freedesktop.LogControl1.LogLevel</interfacename> interface for the D-Bus name + <replaceable>destination</replaceable>.)</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>reset-failed [<replaceable>PATTERN</replaceable>…]</command></term> + + <listitem> + <para>Reset the <literal>failed</literal> state of the specified units, or if no unit name is passed, reset + the state of all units. When a unit fails in some way (i.e. process exiting with non-zero error code, + terminating abnormally or timing out), it will automatically enter the <literal>failed</literal> state and + its exit code and status is recorded for introspection by the administrator until the service is + stopped/re-started or reset with this command.</para> + + <para>In addition to resetting the <literal>failed</literal> state of a unit it also resets various other + per-unit properties: the start rate limit counter of all unit types is reset to zero, as is the restart + counter of service units. Thus, if a unit's start limit (as configured with + <varname>StartLimitIntervalSec=</varname>/<varname>StartLimitBurst=</varname>) is hit and the unit refuses + to be started again, use this command to make it startable again.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Unit File Commands</title> + + <variablelist> + <varlistentry> + <term><command>list-unit-files</command> <optional><replaceable>PATTERN…</replaceable></optional></term> + + <listitem> + <para>List unit files installed on the system, in combination with their enablement state (as reported by + <command>is-enabled</command>). If one or more <replaceable>PATTERN</replaceable>s are specified, only unit + files whose name matches one of them are shown (patterns matching unit file system paths are not + supported).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>enable <replaceable>UNIT</replaceable>…</command></term> + <term><command>enable <replaceable>PATH</replaceable>…</command></term> + + <listitem> + <para>Enable one or more units or unit instances. This will create a set of symlinks, as encoded in the + [Install] sections of the indicated unit files. After the symlinks have been created, + the system manager configuration is reloaded (in a way equivalent to <command>daemon-reload</command>), in + order to ensure the changes are taken into account immediately. Note that this does + <emphasis>not</emphasis> have the effect of also starting any of the units being enabled. If this is + desired, combine this command with the <option>--now</option> switch, or invoke <command>start</command> + with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of + the form <filename>foo@bar.service</filename>), symlinks named the same as instances are created in the + unit configuration directory, however they point to the single template unit file they are instantiated + from.</para> + + <para>This command expects either valid unit names (in which case various unit file directories are + automatically searched for unit files with appropriate names), or absolute paths to unit files (in which + case these files are read directly). If a specified unit file is located outside of the usual unit file + directories, an additional symlink is created, linking it into the unit configuration path, thus ensuring + it is found when requested by commands such as <command>start</command>. The file system where the linked + unit files are located must be accessible when systemd is started (e.g. anything underneath + <filename>/home/</filename> or <filename>/var/</filename> is not allowed, unless those directories are + located on the root file system).</para> + + <para>This command will print the file system operations executed. This output may be suppressed by passing + <option>--quiet</option>. + </para> + + <para>Note that this operation creates only the symlinks suggested in the [Install] + section of the unit files. While this command is the recommended way to manipulate the unit configuration + directory, the administrator is free to make additional changes manually by placing or removing symlinks + below this directory. This is particularly useful to create configurations that deviate from the suggested + default installation. In this case, the administrator must make sure to invoke + <command>daemon-reload</command> manually as necessary, in order to ensure the changes are taken into + account. + </para> + + <para>Enabling units should not be confused with starting (activating) units, as done by the + <command>start</command> command. Enabling and starting units is orthogonal: units may be enabled without + being started and started without being enabled. Enabling simply hooks the unit into various suggested + places (for example, so that the unit is automatically started on boot or when a particular kind of + hardware is plugged in). Starting actually spawns the daemon process (in case of service units), or binds + the socket (in case of socket units), and so on.</para> + + <para>Depending on whether <option>--system</option>, <option>--user</option>, <option>--runtime</option>, + or <option>--global</option> is specified, this enables the unit for the system, for the calling user only, + for only this boot of the system, or for all future logins of all users. Note that in the last case, no + systemd daemon configuration is reloaded.</para> + + <para>Using <command>enable</command> on masked units is not supported and results in an error.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>disable <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Disables one or more units. This removes all symlinks to the unit files backing the specified units + from the unit configuration directory, and hence undoes any changes made by <command>enable</command> or + <command>link</command>. Note that this removes <emphasis>all</emphasis> symlinks to matching unit files, + including manually created symlinks, and not just those actually created by <command>enable</command> or + <command>link</command>. Note that while <command>disable</command> undoes the effect of + <command>enable</command>, the two commands are otherwise not symmetric, as <command>disable</command> may + remove more symlinks than a prior <command>enable</command> invocation of the same unit created.</para> + + <para>This command expects valid unit names only, it does not accept paths to unit files.</para> + + <para>In addition to the units specified as arguments, all units are disabled that are listed in the + <varname>Also=</varname> setting contained in the [Install] section of any of the unit + files being operated on.</para> + + <para>This command implicitly reloads the system manager configuration after completing the operation. Note + that this command does not implicitly stop the units that are being disabled. If this is desired, either + combine this command with the <option>--now</option> switch, or invoke the <command>stop</command> command + with appropriate arguments later.</para> + + <para>This command will print information about the file system operations (symlink removals) + executed. This output may be suppressed by passing <option>--quiet</option>. + </para> + + <para>This command honors <option>--system</option>, <option>--user</option>, <option>--runtime</option> + and <option>--global</option> in a similar way as <command>enable</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>reenable <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Reenable one or more units, as specified on the command line. This is a combination of + <command>disable</command> and <command>enable</command> and is useful to reset the symlinks a unit file is + enabled with to the defaults configured in its [Install] section. This command expects + a unit name only, it does not accept paths to unit files.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>preset <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Reset the enable/disable status one or more unit files, as specified on + the command line, to the defaults configured in the preset policy files. This + has the same effect as <command>disable</command> or + <command>enable</command>, depending how the unit is listed in the preset + files.</para> + + <para>Use <option>--preset-mode=</option> to control whether units shall be + enabled and disabled, or only enabled, or only disabled.</para> + + <para>If the unit carries no install information, it will be silently ignored + by this command. <replaceable>UNIT</replaceable> must be the real unit name, + any alias names are ignored silently.</para> + + <para>For more information on the preset policy format, see + <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + For more information on the concept of presets, please consult the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/Preset">Preset</ulink> + document.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>preset-all</command></term> + + <listitem> + <para>Resets all installed unit files to the defaults + configured in the preset policy file (see above).</para> + + <para>Use <option>--preset-mode=</option> to control + whether units shall be enabled and disabled, or only + enabled, or only disabled.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>is-enabled <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Checks whether any of the specified unit files are + enabled (as with <command>enable</command>). Returns an + exit code of 0 if at least one is enabled, non-zero + otherwise. Prints the current enable status (see table). + To suppress this output, use <option>--quiet</option>. + To show installation targets, use <option>--full</option>. + </para> + + <table> + <title> + <command>is-enabled</command> output + </title> + + <tgroup cols='3'> + <thead> + <row> + <entry>Name</entry> + <entry>Description</entry> + <entry>Exit Code</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>enabled</literal></entry> + <entry morerows='1'>Enabled via <filename>.wants/</filename>, <filename>.requires/</filename> or <varname>Alias=</varname> symlinks (permanently in <filename>/etc/systemd/system/</filename>, or transiently in <filename>/run/systemd/system/</filename>).</entry> + <entry morerows='1'>0</entry> + </row> + <row> + <entry><literal>enabled-runtime</literal></entry> + </row> + <row> + <entry><literal>linked</literal></entry> + <entry morerows='1'>Made available through one or more symlinks to the unit file (permanently in <filename>/etc/systemd/system/</filename> or transiently in <filename>/run/systemd/system/</filename>), even though the unit file might reside outside of the unit file search path.</entry> + <entry morerows='1'>> 0</entry> + </row> + <row> + <entry><literal>linked-runtime</literal></entry> + </row> + <row> + <entry><literal>alias</literal></entry> + <entry>The name is an alias (symlink to another unit file).</entry> + <entry>0</entry> + </row> + <row> + <entry><literal>masked</literal></entry> + <entry morerows='1'>Completely disabled, so that any start operation on it fails (permanently in <filename>/etc/systemd/system/</filename> or transiently in <filename>/run/systemd/systemd/</filename>).</entry> + <entry morerows='1'>> 0</entry> + </row> + <row> + <entry><literal>masked-runtime</literal></entry> + </row> + <row> + <entry><literal>static</literal></entry> + <entry>The unit file is not enabled, and has no provisions for enabling in the [Install] unit file section.</entry> + <entry>0</entry> + </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 [Install] 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 files, an instance different than the one specified in <varname>DefaultInstance=</varname> is enabled.</entry> + <entry>0</entry> + </row> + <row> + <entry><literal>disabled</literal></entry> + <entry>The unit file is not enabled, but contains an [Install] section with installation instructions.</entry> + <entry>> 0</entry> + </row> + <row> + <entry><literal>generated</literal></entry> + <entry>The unit file was generated dynamically via a generator tool. See <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Generated unit files may not be enabled, they are enabled implicitly by their generator.</entry> + <entry>0</entry> + </row> + <row> + <entry><literal>transient</literal></entry> + <entry>The unit file has been created dynamically with the runtime API. Transient units may not be enabled.</entry> + <entry>0</entry> + </row> + <row> + <entry><literal>bad</literal></entry> + <entry>The unit file is invalid or another error occurred. Note that <command>is-enabled</command> will not actually return this state, but print an error message instead. However the unit file listing printed by <command>list-unit-files</command> might show it.</entry> + <entry>> 0</entry> + </row> + </tbody> + </tgroup> + </table> + + </listitem> + </varlistentry> + + <varlistentry> + <term><command>mask <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Mask one or more units, as specified on the command line. This will link these unit files to + <filename>/dev/null</filename>, making it impossible to start them. This is a stronger version of + <command>disable</command>, since it prohibits all kinds of activation of the unit, including enablement + and manual activation. Use this option with care. This honors the <option>--runtime</option> option to only + mask temporarily until the next reboot of the system. The <option>--now</option> option may be used to + ensure that the units are also stopped. This command expects valid unit names only, it does not accept unit + file paths.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>unmask <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Unmask one or more unit files, as specified on the command line. This will undo the effect of + <command>mask</command>. This command expects valid unit names only, it does not accept unit file + paths.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>link <replaceable>PATH</replaceable>…</command></term> + + <listitem> + <para>Link a unit file that is not in the unit file search paths into the unit file search path. This + command expects an absolute path to a unit file. The effect of this may be undone with + <command>disable</command>. The effect of this command is that a unit file is made available for commands + such as <command>start</command>, even though it is not installed directly in the unit search path. The + file system where the linked unit files are located must be accessible when systemd is started + (e.g. anything underneath <filename>/home/</filename> or <filename>/var/</filename> is not allowed, unless + those directories are located on the root file system).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>revert <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Revert one or more unit files to their vendor versions. This command removes drop-in configuration + files that modify the specified units, as well as any user-configured unit file that overrides a matching + vendor supplied unit file. Specifically, for a unit <literal>foo.service</literal> the matching directories + <literal>foo.service.d/</literal> with all their contained files are removed, both below the persistent and + runtime configuration directories (i.e. below <filename>/etc/systemd/system</filename> and + <filename>/run/systemd/system</filename>); if the unit file has a vendor-supplied version (i.e. a unit file + located below <filename>/usr/</filename>) any matching persistent or runtime unit file that overrides it is + removed, too. Note that if a unit file has no vendor-supplied version (i.e. is only defined below + <filename>/etc/systemd/system</filename> or <filename>/run/systemd/system</filename>, but not in a unit + file stored below <filename>/usr/</filename>), then it is not removed. Also, if a unit is masked, it is + unmasked.</para> + + <para>Effectively, this command may be used to undo all changes made with <command>systemctl + edit</command>, <command>systemctl set-property</command> and <command>systemctl mask</command> and puts + the original unit file with its settings back in effect.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>add-wants <replaceable>TARGET</replaceable> + <replaceable>UNIT</replaceable>…</command></term> + <term><command>add-requires <replaceable>TARGET</replaceable> + <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Adds <literal>Wants=</literal> or <literal>Requires=</literal> + dependencies, respectively, to the specified + <replaceable>TARGET</replaceable> for one or more units. </para> + + <para>This command honors <option>--system</option>, + <option>--user</option>, <option>--runtime</option> and + <option>--global</option> in a way similar to + <command>enable</command>.</para> + + </listitem> + </varlistentry> + + <varlistentry> + <term><command>edit <replaceable>UNIT</replaceable>…</command></term> + + <listitem> + <para>Edit a drop-in snippet or a whole replacement file if + <option>--full</option> is specified, to extend or override the + specified unit.</para> + + <para>Depending on whether <option>--system</option> (the default), + <option>--user</option>, or <option>--global</option> is specified, + this command creates a drop-in file for each unit either for the system, + for the calling user, or for all futures logins of all users. Then, + the editor (see the "Environment" section below) is invoked on + temporary files which will be written to the real location if the + editor exits successfully.</para> + + <para>If <option>--full</option> is specified, this will copy the + original units instead of creating drop-in files.</para> + + <para>If <option>--force</option> is specified and any units do + not already exist, new unit files will be opened for editing.</para> + + <para>If <option>--runtime</option> is specified, the changes will + be made temporarily in <filename>/run/</filename> and they will be + lost on the next reboot.</para> + + <para>If the temporary file is empty upon exit, the modification of + the related unit is canceled.</para> + + <para>After the units have been edited, systemd configuration is + reloaded (in a way that is equivalent to <command>daemon-reload</command>). + </para> + + <para>Note that this command cannot be used to remotely edit units + and that you cannot temporarily edit units which are in + <filename>/etc/</filename>, since they take precedence over + <filename>/run/</filename>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>get-default</command></term> + + <listitem> + <para>Return the default target to boot into. This returns + the target unit name <filename>default.target</filename> + is aliased (symlinked) to.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>set-default <replaceable>TARGET</replaceable></command></term> + + <listitem> + <para>Set the default target to boot into. This sets + (symlinks) the <filename>default.target</filename> alias + to the given target unit.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect2> + + <refsect2> + <title>Machine Commands</title> + + <variablelist> + <varlistentry> + <term><command>list-machines</command> <optional><replaceable>PATTERN</replaceable>…</optional></term> + + <listitem> + <para>List the host and all running local containers with + their state. If one or more + <replaceable>PATTERN</replaceable>s are specified, only + containers matching one of them are shown. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Job Commands</title> + + <variablelist> + <varlistentry> + <term><command>list-jobs <optional><replaceable>PATTERN…</replaceable></optional></command></term> + + <listitem> + <para>List jobs that are in progress. If one or more + <replaceable>PATTERN</replaceable>s are specified, only + jobs for units matching one of them are shown.</para> + + <para>When combined with <option>--after</option> or <option>--before</option> the list is augmented with + information on which other job each job is waiting for, and which other jobs are waiting for it, see + above.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>cancel <replaceable>JOB</replaceable>…</command></term> + + <listitem> + <para>Cancel one or more jobs specified on the command line + by their numeric job IDs. If no job ID is specified, cancel + all pending jobs.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Environment Commands</title> + + <para><command>systemd</command> supports an environment block that is passed to processes the manager + spawns. The names of the variables can contain ASCII letters, digits, and the underscore + character. Variable names cannot be empty or start with a digit. In variable values, most characters + are allowed, but the whole sequence must be valid UTF-8. (Note that control characters like newline + (<constant>NL</constant>), tab (<constant>TAB</constant>), or the escape character + (<constant>ESC</constant>), <emphasis>are</emphasis> valid ASCII and thus valid UTF-8). The total + length of the environment block is limited to <constant>_SC_ARG_MAX</constant> value defined by + <citerefentry project='man-pages'><refentrytitle>sysconf</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <variablelist> + <varlistentry> + <term><command>show-environment</command></term> + + <listitem> + <para>Dump the systemd manager environment block. This is the environment + block that is passed to all processes the manager spawns. The environment + block will be dumped in straight-forward form suitable for sourcing into + most shells. If no special characters or whitespace is present in the variable + values, no escaping is performed, and the assignments have the form + <literal>VARIABLE=value</literal>. If whitespace or characters which have + special meaning to the shell are present, dollar-single-quote escaping is + used, and assignments have the form <literal>VARIABLE=$'value'</literal>. + This syntax is known to be supported by + <citerefentry project='die-net'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>zsh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>ksh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + and + <citerefentry project='die-net'><refentrytitle>busybox</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <citerefentry project='die-net'><refentrytitle>ash</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + but not + <citerefentry project='die-net'><refentrytitle>dash</refentrytitle><manvolnum>1</manvolnum></citerefentry> + or + <citerefentry project='die-net'><refentrytitle>fish</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>set-environment <replaceable>VARIABLE=VALUE</replaceable>…</command></term> + + <listitem> + <para>Set one or more systemd manager environment variables, as specified on the command + line. This command will fail if variable names and values do not conform to the rules listed + above.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>unset-environment <replaceable>VARIABLE</replaceable>…</command></term> + + <listitem> + <para>Unset one or more systemd manager environment + variables. If only a variable name is specified, it will be + removed regardless of its value. If a variable and a value + are specified, the variable is only removed if it has the + specified value.</para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <command>import-environment</command> + <optional><replaceable>VARIABLE…</replaceable></optional> + </term> + + <listitem> + <para>Import all, one or more environment variables set on the client into the systemd manager + environment block. If a list of environment variable names is passed, client-side values are then + imported into the manager's environment block. If any names are not valid environment variable + names or have invalid values according to the rules described above, an error is raised. If no + arguments are passed, the entire environment block inherited by the <command>systemctl</command> + process is imported. In this mode, any inherited invalid environment variables are quietly + ignored.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Manager State Commands</title> + + <variablelist> + <varlistentry> + <term><command>daemon-reload</command></term> + + <listitem> + <para>Reload the systemd manager configuration. This will + rerun all generators (see + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>), + reload all unit files, and recreate the entire dependency + tree. While the daemon is being reloaded, all sockets + systemd listens on behalf of user configuration will stay + accessible.</para> + + <para>This command should not be confused with the + <command>reload</command> command.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>daemon-reexec</command></term> + + <listitem> + <para>Reexecute the systemd manager. This will serialize the + manager state, reexecute the process and deserialize the + state again. This command is of little use except for + debugging and package upgrades. Sometimes, it might be + helpful as a heavy-weight <command>daemon-reload</command>. + While the daemon is being reexecuted, all sockets systemd listening + on behalf of user configuration will stay accessible. + </para> + </listitem> + </varlistentry> + + <varlistentry id='log-level'> + <term><command>log-level</command> [<replaceable>LEVEL</replaceable>]</term> + + <listitem><para>If no argument is given, print the current log level of the manager. If an + optional argument <replaceable>LEVEL</replaceable> is provided, then the command changes the + current log level of the manager to <replaceable>LEVEL</replaceable> (accepts the same values as + <option>--log-level=</option> described in + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>log-target</command> [<replaceable>TARGET</replaceable>]</term> + + <listitem><para>If no argument is given, print the current log target of the manager. If an + optional argument <replaceable>TARGET</replaceable> is provided, then the command changes the + current log target of the manager to <replaceable>TARGET</replaceable> (accepts the same values as + <option>--log-target=</option>, described in + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><command>service-watchdogs</command> [yes|no]</term> + + <listitem><para>If no argument is given, print the current state of service runtime watchdogs of + the manager. If an optional boolean argument is provided, then globally enables or disables the + service runtime watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g. + <option>OnFailure=</option> or <option>StartLimitAction=</option>); see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The hardware watchdog is not affected by this setting.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>System Commands</title> + + <variablelist> + <varlistentry> + <term><command>is-system-running</command></term> + + <listitem> + <para>Checks whether the system is operational. This + returns success (exit code 0) when the system is fully up + and running, specifically not in startup, shutdown or + maintenance mode, and with no failed services. Failure is + returned otherwise (exit code non-zero). In addition, the + current state is printed in a short string to standard + output, see the table below. Use <option>--quiet</option> to + suppress this output.</para> + + <para>Use <option>--wait</option> to wait until the boot + process is completed before printing the current state and + returning the appropriate error status. If <option>--wait</option> + is in use, states <varname>initializing</varname> or + <varname>starting</varname> will not be reported, instead + the command will block until a later state (such as + <varname>running</varname> or <varname>degraded</varname>) + is reached.</para> + + <table> + <title><command>is-system-running</command> output</title> + <tgroup cols='3'> + <colspec colname='name'/> + <colspec colname='description'/> + <colspec colname='exit-code'/> + <thead> + <row> + <entry>Name</entry> + <entry>Description</entry> + <entry>Exit Code</entry> + </row> + </thead> + <tbody> + <row> + <entry><varname>initializing</varname></entry> + <entry><para>Early bootup, before + <filename>basic.target</filename> is reached + or the <varname>maintenance</varname> state entered. + </para></entry> + <entry>> 0</entry> + </row> + <row> + <entry><varname>starting</varname></entry> + <entry><para>Late bootup, before the job queue + becomes idle for the first time, or one of the + rescue targets are reached.</para></entry> + <entry>> 0</entry> + </row> + <row> + <entry><varname>running</varname></entry> + <entry><para>The system is fully + operational.</para></entry> + <entry>0</entry> + </row> + <row> + <entry><varname>degraded</varname></entry> + <entry><para>The system is operational but one or more + units failed.</para></entry> + <entry>> 0</entry> + </row> + <row> + <entry><varname>maintenance</varname></entry> + <entry><para>The rescue or emergency target is + active.</para></entry> + <entry>> 0</entry> + </row> + <row> + <entry><varname>stopping</varname></entry> + <entry><para>The manager is shutting + down.</para></entry> + <entry>> 0</entry> + </row> + <row> + <entry><varname>offline</varname></entry> + <entry><para>The manager is not + running. Specifically, this is the operational + state if an incompatible program is running as + system manager (PID 1).</para></entry> + <entry>> 0</entry> + </row> + <row> + <entry><varname>unknown</varname></entry> + <entry><para>The operational state could not be + determined, due to lack of resources or another + error cause.</para></entry> + <entry>> 0</entry> + </row> + </tbody> + </tgroup> + </table> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>default</command></term> + + <listitem> + <para>Enter default mode. This is equivalent to <command>systemctl isolate default.target</command>. This + operation is blocking by default, use <option>--no-block</option> to request asynchronous behavior.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>rescue</command></term> + + <listitem> + <para>Enter rescue mode. This is equivalent to <command>systemctl isolate rescue.target</command>. This + operation is blocking by default, use <option>--no-block</option> to request asynchronous behavior.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>emergency</command></term> + + <listitem> + <para>Enter emergency mode. This is equivalent to <command>systemctl isolate + emergency.target</command>. This operation is blocking by default, use <option>--no-block</option> to + request asynchronous behavior.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>halt</command></term> + + <listitem> + <para>Shut down and halt the system. This is mostly equivalent to <command>systemctl start halt.target + --job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all users. This command is + asynchronous; it will return after the halt operation is enqueued, without waiting for it to complete. Note + that this operation will simply halt the OS kernel after shutting down, leaving the hardware powered + on. Use <command>systemctl poweroff</command> for powering off the system (see below).</para> + + <para>If combined with <option>--force</option>, shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + system halt. If <option>--force</option> is specified twice, the operation is immediately executed without + terminating any processes or unmounting any file systems. This may result in data loss. Note that when + <option>--force</option> is specified twice the halt operation is executed by <command>systemctl</command> + itself, and the system manager is not contacted. This means the command should succeed even when the system + manager has crashed.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>poweroff</command></term> + + <listitem> + <para>Shut down and power-off the system. This is mostly equivalent to <command>systemctl start + poweroff.target --job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all + users. This command is asynchronous; it will return after the power-off operation is enqueued, without + waiting for it to complete.</para> + + <para>If combined with <option>--force</option>, shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + powering off. If <option>--force</option> is specified twice, the operation is immediately executed without + terminating any processes or unmounting any file systems. This may result in data loss. Note that when + <option>--force</option> is specified twice the power-off operation is executed by + <command>systemctl</command> itself, and the system manager is not contacted. This means the command should + succeed even when the system manager has crashed.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><command>reboot</command></term> + + <listitem> + <para>Shut down and reboot the system. This is mostly equivalent to <command>systemctl start reboot.target + --job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all users. This + command is asynchronous; it will return after the reboot operation is enqueued, without waiting for it to + complete.</para> + + <para>If combined with <option>--force</option>, shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + reboot. If <option>--force</option> is specified twice, the operation is immediately executed without + terminating any processes or unmounting any file systems. This may result in data loss. Note that when + <option>--force</option> is specified twice the reboot operation is executed by + <command>systemctl</command> itself, and the system manager is not contacted. This means the command should + succeed even when the system manager has crashed.</para> + + <para>If the switch <option>--reboot-argument=</option> is given, it will be passed as the optional + argument to the <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> + system call.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>kexec</command></term> + + <listitem> + <para>Shut down and reboot the system via <command>kexec</command>. This is equivalent to + <command>systemctl start kexec.target --job-mode=replace-irreversibly --no-block</command>. This command is + asynchronous; it will return after the reboot operation is enqueued, without waiting for it to + complete.</para> + + <para>If combined with <option>--force</option>, shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + reboot.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>exit</command> <optional><replaceable>EXIT_CODE</replaceable></optional></term> + + <listitem> + <para>Ask the service manager to quit. This is only supported for user service managers (i.e. in + conjunction with the <option>--user</option> option) or in containers and is equivalent to + <command>poweroff</command> otherwise. This command is asynchronous; it will return after the exit + operation is enqueued, without waiting for it to complete.</para> + + <para>The service manager will exit with the specified exit code, if + <replaceable>EXIT_CODE</replaceable> is passed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>switch-root</command> <replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></term> + + <listitem> + <para>Switches to a different root directory and executes a new system manager process below it. This is + intended for usage in initial RAM disks ("initrd"), and will transition from the initrd's system manager + process (a.k.a. "init" process) to the main system manager process which is loaded from the actual host + volume. This call takes two arguments: the directory that is to become the new root directory, and the path + to the new system manager binary below it to execute as PID 1. If the latter is omitted or the empty + string, a systemd binary will automatically be searched for and used as init. If the system manager path is + omitted, equal to the empty string or identical to the path to the systemd binary, the state of the + initrd's system manager process is passed to the main system manager, which allows later introspection of + the state of the services involved in the initrd boot phase.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>suspend</command></term> + + <listitem> + <para>Suspend the system. This will trigger activation of the special target unit + <filename>suspend.target</filename>. This command is asynchronous, and will return after the suspend + operation is successfully enqueued. It will not wait for the suspend/resume cycle to complete.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>hibernate</command></term> + + <listitem> + <para>Hibernate the system. This will trigger activation of the special target unit + <filename>hibernate.target</filename>. This command is asynchronous, and will return after the hibernation + operation is successfully enqueued. It will not wait for the hibernate/thaw cycle to complete.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>hybrid-sleep</command></term> + + <listitem> + <para>Hibernate and suspend the system. This will trigger activation of the special target unit + <filename>hybrid-sleep.target</filename>. This command is asynchronous, and will return after the hybrid + sleep operation is successfully enqueued. It will not wait for the sleep/wake-up cycle to complete.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>suspend-then-hibernate</command></term> + + <listitem> + <para>Suspend the system and hibernate it after the delay specified in <filename>systemd-sleep.conf</filename>. + This will trigger activation of the special target unit <filename>suspend-then-hibernate.target</filename>. + This command is asynchronous, and will return after the hybrid sleep operation is successfully enqueued. + It will not wait for the sleep/wake-up or hibernate/thaw cycle to complete.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Parameter Syntax</title> + + <para>Unit commands listed above take either a single unit name (designated as <replaceable>UNIT</replaceable>), + or multiple unit specifications (designated as <replaceable>PATTERN</replaceable>…). In the first case, the + unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"), + systemctl will append a suitable suffix, <literal>.service</literal> by default, and a type-specific suffix in + case of commands which operate only on specific unit types. For example, + <programlisting># systemctl start sshd</programlisting> and + <programlisting># systemctl start sshd.service</programlisting> + are equivalent, as are + <programlisting># systemctl isolate default</programlisting> + and + <programlisting># systemctl isolate default.target</programlisting> + Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute) + paths to mount unit names. + <programlisting># systemctl status /dev/sda +# systemctl status /home</programlisting> + are equivalent to: + <programlisting># systemctl status dev-sda.device +# systemctl status home.mount</programlisting> + In the second case, shell-style globs will be matched against the primary names of all units currently in memory; + literal unit names, with or without a suffix, will be treated as in the first case. This means that literal unit + names always refer to exactly one unit, but globs may match zero units and this is not considered an + error.</para> + + <para>Glob patterns use + <citerefentry project='man-pages'><refentrytitle>fnmatch</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + so normal shell-style globbing rules are used, and + <literal>*</literal>, <literal>?</literal>, + <literal>[]</literal> may be used. See + <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more details. The patterns are matched against the primary names of + units currently in memory, and patterns which do not match anything + are silently skipped. For example: + <programlisting># systemctl stop sshd@*.service</programlisting> + will stop all <filename>sshd@.service</filename> instances. Note that alias names of units, and units that aren't + in memory are not considered for glob expansion. + </para> + + <para>For unit file commands, the specified <replaceable>UNIT</replaceable> should be the name of the unit file + (possibly abbreviated, see above), or the absolute path to the unit file: + <programlisting># systemctl enable foo.service</programlisting> + or + <programlisting># systemctl link /path/to/foo.service</programlisting> + </para> + </refsect2> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-t</option></term> + <term><option>--type=</option></term> + + <listitem> + <para>The argument should be a comma-separated list of unit + types such as <option>service</option> and + <option>socket</option>. + </para> + + <para>If one of the arguments is a unit type, when listing + units, limit display to certain unit types. Otherwise, units + of all types will be shown.</para> + + <para>As a special case, if one of the arguments is + <option>help</option>, a list of allowed values will be + printed and the program will exit.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--state=</option></term> + + <listitem> + <para>The argument should be a comma-separated list of unit + LOAD, SUB, or ACTIVE states. When listing units, show only + those in the specified states. Use <option>--state=failed</option> + to show only failed units.</para> + + <para>As a special case, if one of the arguments is + <option>help</option>, a list of allowed values will be + printed and the program will exit.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--property=</option></term> + + <listitem> + <para>When showing unit/job/manager properties with the + <command>show</command> command, limit display to properties + specified in the argument. The argument should be a + comma-separated list of property names, such as + <literal>MainPID</literal>. Unless specified, all known + properties are shown. If specified more than once, all + properties with the specified names are shown. Shell + completion is implemented for property names.</para> + + <para>For the manager itself, + <command>systemctl show</command> will show all available + properties. Those properties are documented in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>Properties for units vary by unit type, so showing any + unit (even a non-existent one) is a way to list properties + pertaining to this type. Similarly, showing any job will list + properties pertaining to all jobs. Properties for units are + documented in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + and the pages for individual unit types + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + etc.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-P</option></term> + + <listitem> + <para>Equivalent to <option>--value</option> <option>--property=</option>, i.e. shows the + value of the property without the property name or <literal>=</literal>. Note that using + <option>-P</option> once will also affect all properties listed with + <option>-p</option>/<option>--property=</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-a</option></term> + <term><option>--all</option></term> + + <listitem> + <para>When listing units with <command>list-units</command>, also show inactive units and + units which are following other units. When showing unit/job/manager properties, show all + properties regardless whether they are set or not.</para> + + <para>To list all units installed in the file system, use the + <command>list-unit-files</command> command instead.</para> + + <para>When listing units with <command>list-dependencies</command>, recursively show + dependencies of all dependent units (by default only dependencies of target units are + shown).</para> + + <para>When used with <command>status</command>, show journal messages in full, even if they include + unprintable characters or are very long. By default, fields with unprintable characters are + abbreviated as "blob data". (Note that the pager may escape unprintable characters again.)</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--recursive</option></term> + + <listitem> + <para>When listing units, also show units of local + containers. Units of local containers will be prefixed with + the container name, separated by a single colon character + (<literal>:</literal>).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--reverse</option></term> + + <listitem> + <para>Show reverse dependencies between units with + <command>list-dependencies</command>, i.e. follow + dependencies of type <varname>WantedBy=</varname>, + <varname>RequiredBy=</varname>, + <varname>PartOf=</varname>, <varname>BoundBy=</varname>, + instead of <varname>Wants=</varname> and similar. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--after</option></term> + + <listitem> + <para>With <command>list-dependencies</command>, show the + units that are ordered before the specified unit. In other + words, recursively list units following the + <varname>After=</varname> dependency.</para> + + <para>Note that any <varname>After=</varname> dependency is + automatically mirrored to create a + <varname>Before=</varname> dependency. Temporal dependencies + may be specified explicitly, but are also created implicitly + for units which are <varname>WantedBy=</varname> targets + (see + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>), + and as a result of other directives (for example + <varname>RequiresMountsFor=</varname>). Both explicitly + and implicitly introduced dependencies are shown with + <command>list-dependencies</command>.</para> + + <para>When passed to the <command>list-jobs</command> command, for each printed job show which other jobs are + waiting for it. May be combined with <option>--before</option> to show both the jobs waiting for each job as + well as all jobs each job is waiting for.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--before</option></term> + + <listitem> + <para>With <command>list-dependencies</command>, show the + units that are ordered after the specified unit. In other + words, recursively list units following the + <varname>Before=</varname> dependency.</para> + + <para>When passed to the <command>list-jobs</command> command, for each printed job show which other jobs it + is waiting for. May be combined with <option>--after</option> to show both the jobs waiting for each job as + well as all jobs each job is waiting for.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-dependencies</option></term> + + <listitem> + <para>When used with <command>status</command>, + <command>cat</command>, <command>list-units</command>, and + <command>list-unit-files</command>, those commands print all + specified units and the dependencies of those units.</para> + + <para>Options <option>--reverse</option>, + <option>--after</option>, <option>--before</option> + may be used to change what types of dependencies + are shown.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem> + <para>Do not ellipsize unit names, process tree entries, + journal output, or truncate unit descriptions in the output + of <command>status</command>, <command>list-units</command>, + <command>list-jobs</command>, and + <command>list-timers</command>.</para> + <para>Also, show installation targets in the output of + <command>is-enabled</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--value</option></term> + + <listitem> + <para>When printing properties with <command>show</command>, only print the value, and skip the + property name and <literal>=</literal>. Also see option <option>-P</option> above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--show-types</option></term> + + <listitem> + <para>When showing sockets, show the type of the socket.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--job-mode=</option></term> + + <listitem> + <para>When queuing a new job, this option controls how to deal with + already queued jobs. It takes one of <literal>fail</literal>, + <literal>replace</literal>, + <literal>replace-irreversibly</literal>, + <literal>isolate</literal>, + <literal>ignore-dependencies</literal>, + <literal>ignore-requirements</literal>, + <literal>flush</literal>, or + <literal>triggering</literal>. Defaults to + <literal>replace</literal>, except when the + <command>isolate</command> command is used which implies the + <literal>isolate</literal> job mode.</para> + + <para>If <literal>fail</literal> is specified and a requested + operation conflicts with a pending job (more specifically: + causes an already pending start job to be reversed into a stop + job or vice versa), cause the operation to fail.</para> + + <para>If <literal>replace</literal> (the default) is + specified, any conflicting pending job will be replaced, as + necessary.</para> + + <para>If <literal>replace-irreversibly</literal> is specified, + operate like <literal>replace</literal>, but also mark the new + jobs as irreversible. This prevents future conflicting + transactions from replacing these jobs (or even being enqueued + while the irreversible jobs are still pending). Irreversible + jobs can still be cancelled using the <command>cancel</command> + command. This job mode should be used on any transaction which + pulls in <filename>shutdown.target</filename>.</para> + + <para><literal>isolate</literal> is only valid for start + operations and causes all other units to be stopped when the + specified unit is started. This mode is always used when the + <command>isolate</command> command is used.</para> + + <para><literal>flush</literal> will cause all queued jobs to + be canceled when the new job is enqueued.</para> + + <para>If <literal>ignore-dependencies</literal> is specified, + then all unit dependencies are ignored for this new job and + the operation is executed immediately. If passed, no required + units of the unit passed will be pulled in, and no ordering + dependencies will be honored. This is mostly a debugging and + rescue tool for the administrator and should not be used by + applications.</para> + + <para><literal>ignore-requirements</literal> is similar to + <literal>ignore-dependencies</literal>, but only causes the + requirement dependencies to be ignored, the ordering + dependencies will still be honored.</para> + </listitem> + + <para><literal>triggering</literal> may only be used with + <command>systemctl stop</command>. In this mode, the specified + unit and any active units that trigger it are stopped. See the + discussion of + <varname>Triggers=</varname> in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information about triggering units.</para> + + </varlistentry> + + <varlistentry> + <term><option>-T</option></term> + <term><option>--show-transaction</option></term> + + <listitem> + <para>When enqueuing a unit job (for example as effect of a <command>systemctl start</command> + invocation or similar), show brief information about all jobs enqueued, covering both the requested + job and any added because of unit dependencies. Note that the output will only include jobs + immediately part of the transaction requested. It is possible that service start-up program code + run as effect of the enqueued jobs might request further jobs to be pulled in. This means that + completion of the listed jobs might ultimately entail more jobs than the listed ones.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--fail</option></term> + + <listitem> + <para>Shorthand for <option>--job-mode=</option>fail.</para> + <para>When used with the <command>kill</command> command, + if no units were killed, the operation results in an error. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-i</option></term> + <term><option>--ignore-inhibitors</option></term> + + <listitem> + <para>When system shutdown or a sleep state is requested, ignore inhibitor locks. Applications can establish + inhibitor locks to avoid that certain important operations (such as CD burning or suchlike) are interrupted + by system shutdown or a sleep state. Any user may take these locks and privileged users may override these + locks. If any locks are taken, shutdown and sleep state requests will normally fail (unless privileged) and a + list of active locks is printed. However, if <option>--ignore-inhibitors</option> is specified, the + established locks are ignored and not shown, and the operation attempted anyway, possibly requiring + additional privileges.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--dry-run</option></term> + + <listitem> + <para>Just print what would be done. Currently supported by verbs + <command>halt</command>, <command>poweroff</command>, <command>reboot</command>, + <command>kexec</command>, <command>suspend</command>, <command>hibernate</command>, + <command>hybrid-sleep</command>, <command>suspend-then-hibernate</command>, + <command>default</command>, <command>rescue</command>, + <command>emergency</command>, and <command>exit</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem> + <para>Suppress printing of the results of various commands + and also the hints about truncated log lines. This does not + suppress output of commands for which the printed output is + the only result (like <command>show</command>). Errors are + always printed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-block</option></term> + + <listitem> + <para>Do not synchronously wait for the requested operation + to finish. If this is not specified, the job will be + verified, enqueued and <command>systemctl</command> will + wait until the unit's start-up is completed. By passing this + argument, it is only verified and enqueued. This option may not be + combined with <option>--wait</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--wait</option></term> + + <listitem> + <para>Synchronously wait for started units to terminate again. + This option may not be combined with <option>--no-block</option>. + Note that this will wait forever if any given unit never terminates + (by itself or by getting stopped explicitly); particularly services + which use <literal>RemainAfterExit=yes</literal>.</para> + + <para>When used with <command>is-system-running</command>, wait + until the boot process is completed before returning.</para> + </listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="user" /> + <xi:include href="user-system-options.xml" xpointer="system" /> + + <varlistentry> + <term><option>--failed</option></term> + + <listitem> + <para>List units in failed state. This is equivalent to + <option>--state=failed</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-wall</option></term> + + <listitem> + <para>Do not send wall message before halt, power-off and reboot.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--global</option></term> + + <listitem> + <para>When used with <command>enable</command> and + <command>disable</command>, operate on the global user + configuration directory, thus enabling or disabling a unit + file globally for all future logins of all users.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-reload</option></term> + + <listitem> + <para>When used with <command>enable</command> and + <command>disable</command>, do not implicitly reload daemon + configuration after executing the changes.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-ask-password</option></term> + + <listitem> + <para>When used with <command>start</command> and related + commands, disables asking for passwords. Background services + may require input of a password or passphrase string, for + example to unlock system hard disks or cryptographic + certificates. Unless this option is specified and the + command is invoked from a terminal, + <command>systemctl</command> will query the user on the + terminal for the necessary secrets. Use this option to + switch this behavior off. In this case, the password must be + supplied by some other means (for example graphical password + agents) or the service might fail. This also disables + querying the user for authentication for privileged + operations.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--kill-who=</option></term> + + <listitem> + <para>When used with <command>kill</command>, choose which + processes to send a signal to. Must be one of + <option>main</option>, <option>control</option> or + <option>all</option> to select whether to kill only the main + process, the control process or all processes of the + unit. The main process of the unit is the one that defines + the life-time of it. A control process of a unit is one that + is invoked by the manager to induce state changes of it. For + example, all processes started due to the + <varname>ExecStartPre=</varname>, + <varname>ExecStop=</varname> or + <varname>ExecReload=</varname> settings of service units are + control processes. Note that there is only one control + process per unit at a time, as only one state change is + executed at a time. For services of type + <varname>Type=forking</varname>, the initial process started + by the manager for <varname>ExecStart=</varname> is a + control process, while the process ultimately forked off by + that one is then considered the main process of the unit (if + it can be determined). This is different for service units + of other types, where the process forked off by the manager + for <varname>ExecStart=</varname> is always the main process + itself. A service unit consists of zero or one main process, + zero or one control process plus any number of additional + processes. Not all unit types manage processes of these + types however. For example, for mount units, control processes + are defined (which are the invocations of + <filename>&MOUNT_PATH;</filename> and + <filename>&UMOUNT_PATH;</filename>), but no main process + is defined. If omitted, defaults to + <option>all</option>.</para> + </listitem> + + </varlistentry> + + <varlistentry> + <term><option>-s</option></term> + <term><option>--signal=</option></term> + + <listitem> + <para>When used with <command>kill</command>, choose which + signal to send to selected processes. Must be one of the + well-known signal specifiers such as <constant>SIGTERM</constant>, <constant>SIGINT</constant> or + <constant>SIGSTOP</constant>. If omitted, defaults to + <option>SIGTERM</option>.</para> + </listitem> + </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 + specifying 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> + + <listitem> + <para>When used with <command>enable</command>, overwrite + any existing conflicting symlinks.</para> + + <para>When used with <command>edit</command>, create all of the + specified units which do not already exist.</para> + + <para>When used with <command>halt</command>, <command>poweroff</command>, <command>reboot</command> or + <command>kexec</command>, execute the selected operation without shutting down all units. However, all + processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a + drastic but relatively safe option to request an immediate reboot. If <option>--force</option> is specified + twice for these operations (with the exception of <command>kexec</command>), they will be executed + immediately, without terminating any processes or unmounting any file systems. Warning: specifying + <option>--force</option> twice with any of these operations might result in data loss. Note that when + <option>--force</option> is specified twice the selected operation is executed by + <command>systemctl</command> itself, and the system manager is not contacted. This means the command should + succeed even when the system manager has crashed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--message=</option></term> + + <listitem> + <para>When used with <command>halt</command>, <command>poweroff</command> or <command>reboot</command>, set a + short message explaining the reason for the operation. The message will be logged together with the default + shutdown message.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--now</option></term> + + <listitem> + <para>When used with <command>enable</command>, the units + will also be started. When used with <command>disable</command> or + <command>mask</command>, the units will also be stopped. The start + or stop operation is only carried out when the respective enable or + disable operation has been successful.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--root=</option></term> + + <listitem> + <para>When used with + <command>enable</command>/<command>disable</command>/<command>is-enabled</command> + (and related commands), use the specified root path when looking for unit + files. If this option is present, <command>systemctl</command> will operate on + the file system directly, instead of communicating with the <command>systemd</command> + daemon to carry out changes.</para> + </listitem> + + </varlistentry> + + <varlistentry> + <term><option>--runtime</option></term> + + <listitem> + <para>When used with <command>enable</command>, + <command>disable</command>, <command>edit</command>, + (and related commands), make changes only temporarily, so + that they are lost on the next reboot. This will have the + effect that changes are not made in subdirectories of + <filename>/etc/</filename> but in <filename>/run/</filename>, + with identical immediate effects, however, since the latter + is lost on reboot, the changes are lost too.</para> + + <para>Similarly, when used with + <command>set-property</command>, make changes only + temporarily, so that they are lost on the next + reboot.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--preset-mode=</option></term> + + <listitem> + <para>Takes one of <literal>full</literal> (the default), + <literal>enable-only</literal>, + <literal>disable-only</literal>. When used with the + <command>preset</command> or <command>preset-all</command> + commands, controls whether units shall be disabled and + enabled according to the preset rules, or only enabled, or + only disabled.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--lines=</option></term> + + <listitem> + <para>When used with <command>status</command>, controls the number of journal lines to show, counting from + the most recent ones. Takes a positive integer argument, or 0 to disable journal output. Defaults to + 10.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-o</option></term> + <term><option>--output=</option></term> + + <listitem> + <para>When used with <command>status</command>, controls the + formatting of the journal entries that are shown. For the + available choices, see + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + Defaults to <literal>short</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--firmware-setup</option></term> + + <listitem> + <para>When used with the <command>reboot</command> command, indicate to the system's firmware to reboot into + the firmware setup interface. Note that this functionality is not available on all systems.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--boot-loader-menu=</option></term> + + <listitem> + <para>When used with the <command>reboot</command> command, indicate to the system's boot loader to show the + boot loader menu on the following boot. Takes a time value as parameter — indicating the menu timeout. Pass + zero in order to disable the menu timeout. Note that not all boot loaders support this + functionality.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--boot-loader-entry=</option></term> + + <listitem> + <para>When used with the <command>reboot</command> command, indicate to the system's boot loader to boot into + a specific boot loader entry on the following boot. Takes a boot loader entry identifier as argument, or + <literal>help</literal> in order to list available entries. Note that not all boot loaders support this + functionality.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--reboot-argument=</option></term> + + <listitem> + <para>This switch is used with <command>reboot</command>. The value is architecture and firmware specific. As an example, <literal>recovery</literal> + might be used to trigger system recovery, and <literal>fota</literal> might be used to trigger a + <quote>firmware over the air</quote> update.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--plain</option></term> + + <listitem> + <para>When used with <command>list-dependencies</command>, + <command>list-units</command> or <command>list-machines</command>, + the output is printed as a list instead of a tree, and the bullet + circles are omitted.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--timestamp=</option></term> + + <listitem> + <para>Takes one of <literal>pretty</literal> (the default), + <literal>us</literal>, <literal>µs</literal>, <literal>utc</literal>. + Changes the format of printed timestamps. + <literal>pretty</literal>: <literal>Day YYYY-MM-DD HH:MM:SS TZ</literal> + <literal>us</literal> or <literal>µs</literal>: <literal>Day YYYY-MM-DD HH:MM:SS.UUUUUU TZ</literal> + <literal>utc</literal>: <literal>Day YYYY-MM-DD HH:MM:SS UTC</literal></para> + <literal>us+utc</literal> or <literal>µs+utc</literal>: <literal>Day YYYY-MM-DD HH:MM:SS.UUUUUU UTC</literal> + </listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + + <para><command>systemctl</command> uses the return codes defined by LSB, as defined in + <ulink url="http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html">LSB 3.0.0</ulink>. + </para> + + <table> + <title>LSB return codes</title> + + <tgroup cols='3'> + <thead> + <row> + <entry>Value</entry> + <entry>Description in LSB</entry> + <entry>Use in systemd</entry> + </row> + </thead> + <tbody> + <row> + <entry><constant>0</constant></entry> + <entry>"program is running or service is OK"</entry> + <entry>unit is active</entry> + </row> + <row> + <entry><constant>1</constant></entry> + <entry>"program is dead and <filename>/var/run</filename> pid file exists"</entry> + <entry>unit <emphasis>not</emphasis> failed (used by <command>is-failed</command>)</entry> + </row> + <row> + <entry><constant>2</constant></entry> + <entry>"program is dead and <filename>/var/lock</filename> lock file exists"</entry> + <entry>unused</entry> + </row> + <row> + <entry><constant>3</constant></entry> + <entry>"program is not running"</entry> + <entry>unit is not active</entry> + </row> + <row> + <entry><constant>4</constant></entry> + <entry>"program or service status is unknown"</entry> + <entry>no such unit</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The mapping of LSB service states to systemd unit states is imperfect, so it is better to + not rely on those return values but to look for specific unit states and substates instead. + </para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$SYSTEMD_EDITOR</varname></term> + + <listitem><para>Editor to use when editing units; overrides + <varname>$EDITOR</varname> and <varname>$VISUAL</varname>. If neither + <varname>$SYSTEMD_EDITOR</varname> nor <varname>$EDITOR</varname> nor + <varname>$VISUAL</varname> are present or if it is set to an empty + string or if their execution failed, systemctl will try to execute well + known editors in this order: + <citerefentry project='die-net'><refentrytitle>editor</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>nano</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>vim</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>vi</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + <xi:include href="less-variables.xml" xpointer="pager"/> + <xi:include href="less-variables.xml" xpointer="less"/> + <xi:include href="less-variables.xml" xpointer="lesscharset"/> + <xi:include href="less-variables.xml" xpointer="lesssecure"/> + <xi:include href="less-variables.xml" xpointer="colors"/> + <xi:include href="less-variables.xml" xpointer="urlify"/> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml new file mode 100644 index 0000000..01df7da --- /dev/null +++ b/man/systemd-analyze.xml @@ -0,0 +1,795 @@ +<?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-or-later --> + +<refentry id="systemd-analyze" conditional='ENABLE_ANALYZE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-analyze</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-analyze</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-analyze</refname> + <refpurpose>Analyze and debug system manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg>time</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">blame</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">critical-chain</arg> + <arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg> + </cmdsynopsis> + + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">dump</arg> + </cmdsynopsis> + + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">plot</arg> + <arg choice="opt">>file.svg</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">dot</arg> + <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg> + <arg choice="opt">>file.dot</arg> + </cmdsynopsis> + + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">unit-paths</arg> + </cmdsynopsis> + <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">capability</arg> + <arg choice="opt" rep="repeat"><replaceable>CAPABILITY</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> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">calendar</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> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">timespan</arg> + <arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">cat-config</arg> + <arg choice="plain" rep="repeat"><replaceable>NAME</replaceable>|<replaceable>PATH</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">verify</arg> + <arg choice="opt" rep="repeat"><replaceable>FILE</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">security</arg> + <arg choice="plain" rep="repeat"><replaceable>UNIT</replaceable></arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-analyze</command> may be used to determine + system boot-up performance statistics and retrieve other state and + tracing information from the system and service manager, and to + verify the correctness of unit files. It is also used to access + special functions useful for advanced system manager debugging.</para> + + <para>If no command is passed, <command>systemd-analyze + time</command> is implied.</para> + + <refsect2> + <title><command>systemd-analyze time</command></title> + + <para>This command prints the time spent in the kernel before userspace has been reached, the time + spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time + normal system userspace took to initialize. Note that these measurements simply measure the time passed + up to the point where all system services have been spawned, but not necessarily until they fully + finished initialization or the disk is idle.</para> + + <example> + <title><command>Show how long the boot took</command></title> + + <programlisting># in a container +$ systemd-analyze time +Startup finished in 296ms (userspace) +multi-user.target reached after 275ms in userspace + +# on a real machine +$ systemd-analyze time +Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s +multi-user.target reached after 47.820s in userspace +</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze blame</command></title> + + <para>This command prints a list of all running units, ordered by the time they took to initialize. + This information may be used to optimize boot-up times. Note that the output might be misleading as the + 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. 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> + + <programlisting>$ systemd-analyze blame + 32.875s pmlogger.service + 20.905s systemd-networkd-wait-online.service + 13.299s dev-vda1.device + ... + 23ms sysroot.mount + 11ms initrd-udevadm-cleanup-db.service + 3ms sys-kernel-config.mount + </programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze critical-chain <optional><replaceable>UNIT</replaceable>...</optional></command></title> + + <para>This command prints a tree of the time-critical chain of units (for each of the specified + <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. 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 critical-chain</command></title> + + <programlisting>$ systemd-analyze critical-chain +multi-user.target @47.820s +└─pmie.service @35.968s +548ms + └─pmcd.service @33.715s +2.247s + └─network-online.target @33.712s + └─systemd-networkd-wait-online.service @12.804s +20.905s + └─systemd-networkd.service @11.109s +1.690s + └─systemd-udevd.service @9.201s +1.904s + └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s + └─kmod-static-nodes.service @6.976s +177ms + └─systemd-journald.socket + └─system.slice + └─-.slice +</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze dump</command></title> + + <para>This command outputs a (usually very long) human-readable serialization of the complete server + state. Its format is subject to change without notice and should not be parsed by applications.</para> + + <example> + <title>Show the internal state of user manager</title> + + <programlisting>$ systemd-analyze --user dump +Timestamp userspace: Thu 2019-03-14 23:28:07 CET +Timestamp finish: Thu 2019-03-14 23:28:07 CET +Timestamp generators-start: Thu 2019-03-14 23:28:07 CET +Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET +Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET +Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET +-> Unit proc-timer_list.mount: + Description: /proc/timer_list + ... +-> Unit default.target: + Description: Main user target +... +</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze plot</command></title> + + <para>This command prints an SVG graphic detailing which system services have been started at what + time, highlighting the time they spent on initialization.</para> + + <example> + <title><command>Plot a bootchart</command></title> + + <programlisting>$ systemd-analyze plot >bootup.svg +$ eog bootup.svg& +</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze dot [<replaceable>pattern</replaceable>...]</command></title> + + <para>This command generates textual dependency graph description in dot format for further processing + with the GraphViz + <citerefentry project='die-net'><refentrytitle>dot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool. Use a command line like <command>systemd-analyze dot | dot -Tsvg >systemd.svg</command> to + generate a graphical dependency tree. Unless <option>--order</option> or <option>--require</option> is + passed, the generated graph will show both ordering and requirement dependencies. Optional pattern + globbing style specifications (e.g. <filename>*.target</filename>) may be given at the end. A unit + dependency is included in the graph if any of these patterns match either the origin or destination + node.</para> + + <example> + <title>Plot all dependencies of any unit whose name starts with <literal>avahi-daemon</literal> + </title> + + <programlisting>$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg +$ eog avahi.svg</programlisting> + </example> + + <example> + <title>Plot the dependencies between all known target units</title> + + <programlisting>$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \ + | dot -Tsvg >targets.svg +$ eog targets.svg</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze unit-paths</command></title> + + <para>This command outputs a list of all directories from which unit files, <filename>.d</filename> + overrides, and <filename>.wants</filename>, <filename>.requires</filename> symlinks may be + loaded. Combine with <option>--user</option> to retrieve the list for the user manager instance, and + <option>--global</option> for the global configuration of user manager instances.</para> + + <example> + <title><command>Show all paths for generated units</command></title> + + <programlisting>$ systemd-analyze unit-paths | grep '^/run' +/run/systemd/system.control +/run/systemd/transient +/run/systemd/generator.early +/run/systemd/system +/run/systemd/system.attached +/run/systemd/generator +/run/systemd/generator.late +</programlisting> + </example> + + <para>Note that this verb prints the list that is compiled into <command>systemd-analyze</command> + 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 capability <optional><replaceable>CAPABILITY</replaceable>...</optional></command></title> + + <para>This command prints a list of Linux capabilities along with their numeric IDs. See <citerefentry + project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details. If no argument is specified the full list of capabilities known to the service manager and + the kernel is shown. Capabilities defined by the kernel but not known to the service manager are shown + as <literal>cap_???</literal>. Optionally, if arguments are specified they may refer to specific + cabilities by name or numeric ID, in which case only the indicated capabilities are shown in the + table.</para> + + <example> + <title><command>Show some example capability names</command></title> + + <programlisting>$ systemd-analyze capability 0 1 {30..32} +NAME NUMBER +cap_chown 0 +cap_dac_override 1 +cap_audit_control 30 +cap_setfcap 31 +cap_mac_override 32</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze condition <replaceable>CONDITION</replaceable>...</command></title> + + <para>This command will evaluate <varname index="false">Condition*=...</varname> and + <varname index="false">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 + <replaceable>SET</replaceable>, or all known sets if no sets are specified. Argument + <replaceable>SET</replaceable> must include the <literal>@</literal> prefix.</para> + </refsect2> + + <refsect2> + <title><command>systemd-analyze calendar <replaceable>EXPRESSION</replaceable>...</command></title> + + <para>This command will parse and normalize repetitive calendar time events, and will calculate when + they elapse next. This takes the same input as the <varname>OnCalendar=</varname> setting in + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + following the syntax described in + <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. 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> + + <programlisting>$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0' + Original form: *-2-29 0:0:0 +Normalized form: *-02-29 00:00:00 + Next elapse: Sat 2020-02-29 00:00:00 UTC + From now: 11 months 15 days left + Iter. #2: Thu 2024-02-29 00:00:00 UTC + From now: 4 years 11 months left + Iter. #3: Tue 2028-02-29 00:00:00 UTC + From now: 8 years 11 months left + Iter. #4: Sun 2032-02-29 00:00:00 UTC + From now: 12 years 11 months left + Iter. #5: Fri 2036-02-29 00:00:00 UTC + From now: 16 years 11 months left +</programlisting> + </example> + </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 (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> + + <programlisting>$ systemd-analyze timespan 1s 300s '1year 0.000001s' +Original: 1s + μs: 1000000 + Human: 1s + +Original: 300s + μs: 300000000 + Human: 5min + +Original: 1year 0.000001s + μs: 31557600000001 + Human: 1y 1us +</programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze cat-config</command> + <replaceable>NAME</replaceable>|<replaceable>PATH</replaceable>...</title> + + <para>This command is similar to <command>systemctl cat</command>, but operates on config files. It + will copy the contents of a config file and any drop-ins to standard output, using the usual systemd + set of directories and rules for precedence. Each argument must be either an absolute path including + the prefix (such as <filename>/etc/systemd/logind.conf</filename> or + <filename>/usr/lib/systemd/logind.conf</filename>), or a name relative to the prefix (such as + <filename>systemd/logind.conf</filename>).</para> + + <example> + <title>Showing logind configuration</title> + <programlisting>$ systemd-analyze cat-config systemd/logind.conf +# /etc/systemd/logind.conf +... +[Login] +NAutoVTs=8 +... + +# /usr/lib/systemd/logind.conf.d/20-test.conf +... some override from another package + +# /etc/systemd/logind.conf.d/50-override.conf +... some administrator override + </programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze verify <replaceable>FILE</replaceable>...</command></title> + + <para>This command will load unit files and print warnings if any errors are detected. Files specified + on the command line will be loaded, but also any other units referenced by them. The full unit search + path is formed by combining the directories for all command line arguments, and the usual unit load + paths. The variable <varname>$SYSTEMD_UNIT_PATH</varname> is supported, and may be used to replace or + augment the compiled in set of unit load paths; see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. All + units files present in the directories containing the command line arguments will be used in preference + to the other paths.</para> + + <para>The following errors are currently detected:</para> + <itemizedlist> + <listitem><para>unknown sections and directives,</para></listitem> + + <listitem><para>missing dependencies which are required to start the given unit,</para></listitem> + + <listitem><para>man pages listed in <varname>Documentation=</varname> which are not found in the + system,</para></listitem> + + <listitem><para>commands listed in <varname>ExecStart=</varname> and similar which are not found in + the system or not executable.</para></listitem> + </itemizedlist> + + <example> + <title>Misspelt directives</title> + + <programlisting>$ cat ./user.slice +[Unit] +WhatIsThis=11 +Documentation=man:nosuchfile(1) +Requires=different.service + +[Service] +Description=x + +$ systemd-analyze verify ./user.slice +[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit' +[./user.slice:13] Unknown section 'Service'. Ignoring. +Error: org.freedesktop.systemd1.LoadFailed: + Unit different.service failed to load: + No such file or directory. +Failed to create user.slice/start: Invalid argument +user.slice: man nosuchfile(1) command failed with code 16 + </programlisting> + </example> + + <example> + <title>Missing service units</title> + + <programlisting>$ tail ./a.socket ./b.socket +==> ./a.socket <== +[Socket] +ListenStream=100 + +==> ./b.socket <== +[Socket] +ListenStream=100 +Accept=yes + +$ systemd-analyze verify ./a.socket ./b.socket +Service a.service not loaded, a.socket cannot be started. +Service b@0.service not loaded, b.socket cannot be started. + </programlisting> + </example> + </refsect2> + + <refsect2> + <title><command>systemd-analyze security <optional><replaceable>UNIT</replaceable>...</optional></command></title> + + <para>This command analyzes the security and sandboxing settings of one or more specified service + units. If at least one unit name is specified the security settings of the specified service units are + inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded, + long-running service units are inspected and a terse table with results shown. The command checks for + various security-related service settings, assigning each a numeric "exposure level" value, depending + on how important a setting is. It then calculates an overall exposure level for the whole unit, which + is an estimation in the range 0.0…10.0 indicating how exposed a service is security-wise. High exposure + levels indicate very little applied sandboxing. Low exposure levels indicate tight sandboxing and + strongest security restrictions. Note that this only analyzes the per-service security features systemd + itself implements. This means that any additional security mechanisms applied by the service code + itself are not accounted for. The exposure level determined this way should not be misunderstood: a + high exposure level neither means that there is no effective sandboxing applied by the service code + itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels do + indicate however that most likely the service might benefit from additional settings applied to + them.</para> + + <para>Please note that many of the security and sandboxing settings individually can be circumvented — + unless combined with others. For example, if a service retains the privilege to establish or undo mount + points many of the sandboxing options can be undone by the service code itself. Due to that is + essential that each service uses the most comprehensive and strict sandboxing and security settings + possible. The tool will take into account some of these combinations and relationships between the + settings, but not all. Also note that the security and sandboxing settings analyzed here only apply to + the operations executed by the service code itself. If a service has access to an IPC system (such as + D-Bus) it might request operations from other services that are not subject to the same + restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access + policy is not validated too.</para> + + <example> + <title>Analyze <filename index="false">systemd-logind.service</filename></title> + + <programlisting>$ systemd-analyze security --no-pager systemd-logind.service + NAME DESCRIPTION EXPOSURE +✗ PrivateNetwork= Service has access to the host's network 0.5 +✗ User=/DynamicUser= Service runs as root user 0.4 +✗ DeviceAllow= Service has no device ACL 0.2 +✓ IPAddressDeny= Service blocks all IP address ranges +... +→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂 +</programlisting> + </example> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--system</option></term> + + <listitem><para>Operates on the system systemd instance. This + is the implied default.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--user</option></term> + + <listitem><para>Operates on the user systemd + instance.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--global</option></term> + + <listitem><para>Operates on the system-wide configuration for + user systemd instance.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--order</option></term> + <term><option>--require</option></term> + + <listitem><para>When used in conjunction with the + <command>dot</command> command (see above), selects which + dependencies are shown in the dependency graph. If + <option>--order</option> is passed, only dependencies of type + <varname>After=</varname> or <varname>Before=</varname> are + shown. If <option>--require</option> is passed, only + dependencies of type <varname>Requires=</varname>, + <varname>Requisite=</varname>, + <varname>Wants=</varname> and <varname>Conflicts=</varname> + are shown. If neither is passed, this shows dependencies of + all these types.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--from-pattern=</option></term> + <term><option>--to-pattern=</option></term> + + <listitem><para>When used in conjunction with the + <command>dot</command> command (see above), this selects which + relationships are shown in the dependency graph. Both options + require a + <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry> + pattern as an argument, which will be matched against the + left-hand and the right-hand, respectively, nodes of a + relationship.</para> + + <para>Each of these can be used more than once, in which case + the unit name must match one of the values. When tests for + both sides of the relation are present, a relation must pass + both tests to be shown. When patterns are also specified as + positional arguments, they must match at least one side of the + relation. In other words, patterns specified with those two + options will trim the list of edges matched by the positional + arguments, if any are given, and fully determine the list of + edges shown otherwise.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--fuzz=</option><replaceable>timespan</replaceable></term> + + <listitem><para>When used in conjunction with the + <command>critical-chain</command> command (see above), also + show units, which finished <replaceable>timespan</replaceable> + earlier, than the latest unit in the same level. The unit of + <replaceable>timespan</replaceable> is seconds unless + specified with a different unit, e.g. + "50ms".</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--man=no</option></term> + + <listitem><para>Do not invoke + <citerefentry project='man-pages'><refentrytitle>man</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to verify the existence of man pages listed in <varname>Documentation=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--generators</option></term> + + <listitem><para>Invoke unit generators, see + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + Some generators require root privileges. Under a normal user, running with + generators enabled will generally result in some warnings.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root=<replaceable>PATH</replaceable></option></term> + + <listitem><para>With <command>cat-files</command>, show config files underneath + the specified root path <replaceable>PATH</replaceable>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--iterations=<replaceable>NUMBER</replaceable></option></term> + + <listitem><para>When used with the <command>calendar</command> command, show the specified number of + iterations the specified calendar expression will elapse next. Defaults to 1.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--base-time=<replaceable>TIMESTAMP</replaceable></option></term> + + <listitem><para>When used with the <command>calendar</command> command, show next iterations relative + to the specified point in time. If not specified defaults to the current time.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-ask-password-console.service.xml b/man/systemd-ask-password-console.service.xml new file mode 100644 index 0000000..03b7317 --- /dev/null +++ b/man/systemd-ask-password-console.service.xml @@ -0,0 +1,67 @@ +<?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-or-later --> +<refentry id="systemd-ask-password-console.service"> + + <refentryinfo> + <title>systemd-ask-password-console.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-ask-password-console.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-ask-password-console.service</refname> + <refname>systemd-ask-password-console.path</refname> + <refname>systemd-ask-password-wall.service</refname> + <refname>systemd-ask-password-wall.path</refname> + <refpurpose>Query the user for system passwords on the + console and via wall</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-ask-password-console.service</filename></para> + <para><filename>systemd-ask-password-console.path</filename></para> + <para><filename>systemd-ask-password-wall.service</filename></para> + <para><filename>systemd-ask-password-wall.path</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-ask-password-console.service</filename> is + a system service that queries the user for system passwords (such + as hard disk encryption keys and SSL certificate passphrases) on + the console. It is intended to be used during boot to ensure + proper handling of passwords necessary for boot. + <filename>systemd-ask-password-wall.service</filename> is a system + service that informs all logged in users for system passwords via + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + It is intended to be used after boot to ensure that users are + properly notified.</para> + + <para>See the <ulink url="https://systemd.io/PASSWORD_AGENTS/">developer + documentation</ulink> for more information about the system password logic. + </para> + + <para>Note that these services invoke + <citerefentry><refentrytitle>systemd-tty-ask-password-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry> + with either the <command>--watch --console</command> or + <command>--watch --wall</command> command line parameters.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-tty-ask-password-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml new file mode 100644 index 0000000..4332604 --- /dev/null +++ b/man/systemd-ask-password.xml @@ -0,0 +1,212 @@ +<?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-or-later --> + +<refentry id="systemd-ask-password" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-ask-password</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-ask-password</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-ask-password</refname> + <refpurpose>Query the user for a system password</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-ask-password <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="opt">MESSAGE</arg></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-ask-password</command> may be used to query + a system password or passphrase from the user, using a question + message specified on the command line. When run from a TTY it will + query a password on the TTY and print it to standard output. When + run with no TTY or with <option>--no-tty</option> it will use the + system-wide query mechanism, which allows active users to respond via + several agents, listed below.</para> + + <para>The purpose of this tool is to query system-wide passwords + — that is passwords not attached to a specific user account. + Examples include: unlocking encrypted hard disks when they are + plugged in or at boot, entering an SSL certificate passphrase for + web and VPN servers.</para> + + <para>Existing agents are: + <itemizedlist> + + <listitem><para>A boot-time password agent asking the user for + passwords using + <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + </para></listitem> + + <listitem><para>A boot-time password agent querying the user + directly on the console — + <citerefentry><refentrytitle>systemd-ask-password-console.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + </para></listitem> + + <listitem><para>An agent requesting password input via a + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + message — + <citerefentry><refentrytitle>systemd-ask-password-wall.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + </para></listitem> + + <listitem><para>A TTY agent that is temporarily spawned during + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + invocations,</para></listitem> + + <listitem><para>A command line agent which can be started + temporarily to process queued password + requests — <command>systemd-tty-ask-password-agent --query</command>. + </para></listitem> + </itemizedlist></para> + + <para>Answering system-wide password queries is a privileged operation, hence + all the agents listed above (except for the last one), run as privileged + system services. The last one also needs elevated privileges, so + should be run through + <citerefentry project='die-net'><refentrytitle>sudo</refentrytitle><manvolnum>8</manvolnum></citerefentry> + or similar.</para> + + <para>Additional password agents may be implemented according to + the <ulink url="https://systemd.io/PASSWORD_AGENTS/">systemd Password Agent + Specification</ulink>.</para> + + <para>If a password is queried on a TTY, the user may press TAB to + hide the asterisks normally shown for each character typed. + Pressing Backspace as first key achieves the same effect.</para> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--icon=</option></term> + + <listitem><para>Specify an icon name alongside the password + query, which may be used in all agents supporting graphical + display. The icon name should follow the <ulink + url="http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">XDG + Icon Naming Specification</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--id=</option></term> + <listitem><para>Specify an identifier for this password + query. This identifier is freely choosable and allows + recognition of queries by involved agents. It should include + the subsystem doing the query and the specific object the + query is done for. Example: + <literal>--id=cryptsetup:/dev/sda5</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--keyname=</option></term> + <listitem><para>Configure a kernel keyring key name to use as + cache for the password. If set, then the tool will try to push + any collected passwords into the kernel keyring of the root + user, as a key of the specified name. If combined with + <option>--accept-cached</option>, it will also try to retrieve + such cached passwords from the key in the kernel keyring + instead of querying the user right away. By using this option, + the kernel keyring may be used as effective cache to avoid + repeatedly asking users for passwords, if there are multiple + objects that may be unlocked with the same password. The + cached key will have a timeout of 2.5min set, after which it + will be purged from the kernel keyring. Note that it is + possible to cache multiple passwords under the same keyname, + in which case they will be stored as <constant>NUL</constant>-separated list of + passwords. Use + <citerefentry project='die-net'><refentrytitle>keyctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to access the cached key via the kernel keyring + directly. Example: <literal>--keyname=cryptsetup</literal></para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--timeout=</option></term> + + <listitem><para>Specify the query timeout in seconds. Defaults + to 90s. A timeout of 0 waits indefinitely. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--echo</option></term> + + <listitem><para>Echo the user input instead of masking it. + This is useful when using + <filename>systemd-ask-password</filename> to query for + usernames. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-tty</option></term> + + <listitem><para>Never ask for password on current TTY even if + one is available. Always use agent system.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--accept-cached</option></term> + + <listitem><para>If passed, accept cached passwords, i.e. + passwords previously entered.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--multiple</option></term> + + <listitem><para>When used in conjunction with + <option>--accept-cached</option> accept multiple passwords. + This will output one password per line.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-output</option></term> + + <listitem><para>Do not print passwords to standard output. + This is useful if you want to store a password in kernel + keyring with <option>--keyname</option> but do not want it + to show up on screen or in logs.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-ask-password-console.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-tty-ask-password-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>keyctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-backlight@.service.xml b/man/systemd-backlight@.service.xml new file mode 100644 index 0000000..7294910 --- /dev/null +++ b/man/systemd-backlight@.service.xml @@ -0,0 +1,70 @@ +<?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-or-later --> +<refentry id="systemd-backlight@.service" conditional='ENABLE_BACKLIGHT'> + + <refentryinfo> + <title>systemd-backlight@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-backlight@.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-backlight@.service</refname> + <refname>systemd-backlight</refname> + <refpurpose>Load and save the display backlight brightness at boot and shutdown</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-backlight@.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-backlight</filename> save [backlight|leds]:DEVICE</para> + <para><filename>/usr/lib/systemd/systemd-backlight</filename> load [backlight|leds]:DEVICE</para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-backlight@.service</filename> is a service + that restores the display backlight brightness at early boot and + saves it at shutdown. On disk, the backlight brightness is stored + in <filename>/var/lib/systemd/backlight/</filename>. During + loading, if the udev property <option>ID_BACKLIGHT_CLAMP</option> is + not set to false, the brightness is clamped to a value of at + least 1 or 5% of maximum brightness, whichever is greater. This + restriction will be removed when the kernel allows user space to + reliably set a brightness value which does not turn off the + display.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-backlight</filename> understands the + following kernel command line parameter:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.restore_state=</varname></term> + + <listitem><para>Takes a boolean argument. Defaults to + <literal>1</literal>. If <literal>0</literal>, does not + restore the backlight settings on boot. However, settings will + still be stored on shutdown. </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-binfmt.service.xml b/man/systemd-binfmt.service.xml new file mode 100644 index 0000000..25c5e6d --- /dev/null +++ b/man/systemd-binfmt.service.xml @@ -0,0 +1,68 @@ +<?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-or-later --> +<refentry id="systemd-binfmt.service" conditional='ENABLE_BINFMT' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-binfmt.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-binfmt.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-binfmt.service</refname> + <refname>systemd-binfmt</refname> + <refpurpose>Configure additional binary formats for executables at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-binfmt.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-binfmt</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-binfmt.service</filename> is an early boot + service that registers additional binary formats for executables + in the kernel.</para> + + <para>See + <citerefentry><refentrytitle>binfmt.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the configuration of this service.</para> + </refsect1> + + <refsect1><title>Options</title> + <variablelist> + + <varlistentry> + <term><option>--unregister</option></term> + <listitem><para>If passed, instead of registering configured binary formats in the kernel, the + reverse operation is executed: all currently registered binary formats are unregistered from the + kernel.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="cat-config" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>binfmt.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>wine</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-bless-boot-generator.xml b/man/systemd-bless-boot-generator.xml new file mode 100644 index 0000000..e945ee8 --- /dev/null +++ b/man/systemd-bless-boot-generator.xml @@ -0,0 +1,48 @@ +<?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-or-later --> +<refentry id="systemd-bless-boot-generator" conditional='ENABLE_EFI'> + + <refentryinfo> + <title>systemd-bless-boot-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-bless-boot-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-bless-boot-generator</refname> + <refpurpose>Pull <filename>systemd-bless-boot.service</filename> into the initial boot transaction when boot counting is in effect</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-bless-boot-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-bless-boot-generator</filename> is a generator that pulls + <filename>systemd-bless-boot.service</filename> into the initial boot transaction when boot counting, as + implemented by <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, is + enabled.</para> + + <para><filename>systemd-bless-boot-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-bless-boot.service.xml b/man/systemd-bless-boot.service.xml new file mode 100644 index 0000000..53d7e4a --- /dev/null +++ b/man/systemd-bless-boot.service.xml @@ -0,0 +1,113 @@ +<?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-or-later --> + +<refentry id="systemd-bless-boot.service" conditional='ENABLE_EFI' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-bless-boot.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-bless-boot.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-bless-boot.service</refname> + <refname>systemd-bless-boot</refname> + <refpurpose>Mark current boot process as successful</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-bless-boot.service</filename></para> + <para><filename>/usr/lib/systemd/system-bless-boot</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-bless-boot.service</filename> is a system service that marks the current boot process as + successful. It's automatically pulled into the initial transaction when + <citerefentry><refentrytitle>systemd-bless-boot-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + detects that <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> style + boot counting is used.</para> + + <para>Internally, the service operates based on the <varname>LoaderBootCountPath</varname> EFI variable (of the + vendor UUID <constant>4a67b082-0a4c-41cf-b6c7-440b29bb8c4</constant>), which is passed from the boot loader to the + OS. It contains a file system path (relative to the EFI system partition) of the <ulink + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> compliant boot loader entry + file or unified kernel image file that was used to boot up the + system. <command>systemd-bless-boot.service</command> removes the two 'tries done' and 'tries left' numeric boot + counters from the filename, which indicates to future invocations of the boot loader that the entry has completed + booting successfully at least once. (This service will hence rename the boot loader entry file or unified kernel + image file on the first successful boot.)</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The <filename>/usr/lib/systemd/system-bless-boot</filename> executable may also be invoked from the + command line, taking one of the following command arguments:</para> + + <variablelist> + <varlistentry> + <term><option>status</option></term> + + <listitem><para>The current status of the boot loader entry file or unified kernel image file is shown. This + outputs one of <literal>good</literal>, <literal>bad</literal>, <literal>indeterminate</literal>, + <literal>clean</literal>, depending on the state and previous invocations of the command. The string + <literal>indeterminate</literal> is shown initially after boot, before it has been marked as "good" or + "bad". The string <literal>good</literal> is shown after the boot was marked as "good" with the + <option>good</option> command below, and "bad" conversely after the <option>bad</option> command was + invoked. The string <literal>clean</literal> is returned when boot counting is currently not in effect.</para> + + <para>This command is implied if no command argument is specified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>good</option></term> + + <listitem><para>When invoked, the current boot loader entry file or unified kernel image file will be marked as + "good", executing the file rename operation described above. This command is intended to be invoked at the end + of a successful boot. The <filename>systemd-bless-boot.service</filename> unit invokes this + command.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>bad</option></term> + + <listitem><para>When called the 'tries left' counter in the boot loader entry file name or unified kernel image + file name is set to zero, marking the boot loader entry or kernel image as "bad", so that the boot loader won't + consider it anymore on future boots (at least as long as there are other entries available that are not marked + "bad" yet). This command is normally not executed, but can be used to instantly put an end to the boot counting + logic if a problem is detected and persistently mark the boot entry as bad.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>indeterminate</option></term> + + <listitem><para>This command undoes any marking of the current boot loader entry file or unified kernel image + file as good or bad. This is implemented by renaming the boot loader entry file or unified kernel image file + back to the path encoded in the <varname>LoaderBootCountPath</varname> EFI variable.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-boot-check-no-failures.service.xml b/man/systemd-boot-check-no-failures.service.xml new file mode 100644 index 0000000..39a2aa8 --- /dev/null +++ b/man/systemd-boot-check-no-failures.service.xml @@ -0,0 +1,52 @@ +<?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-or-later --> + +<refentry id="systemd-boot-check-no-failures.service" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-boot-check-no-failures.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-boot-check-no-failures.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-boot-check-no-failures.service</refname> + <refname>systemd-boot-check-no-failures</refname> + <refpurpose>verify that the system booted up cleanly</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-boot-check-no-failures.service</filename></para> + <para><filename>/usr/lib/systemd/system-boot-check-no-failures</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-boot-check-no-failures.service</filename> is a system service that checks whether the + system booted up successfully. This service implements a very minimal test only: whether there are any failed units on + the system. This service is disabled by default. When enabled, it is ordered before + <filename>boot-complete.target</filename>, thus ensuring the target cannot be reached when the system booted up + with failed services.</para> + + <para>Note that due the simple nature of this check this service is probably not suitable for deployment in most + scenarios. It is primarily useful only as example for developing more fine-grained checks to order before + <filename>boot-complete.target</filename>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-boot-system-token.service.xml b/man/systemd-boot-system-token.service.xml new file mode 100644 index 0000000..b94665b --- /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-or-later --> + +<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 new file mode 100644 index 0000000..09f2854 --- /dev/null +++ b/man/systemd-boot.xml @@ -0,0 +1,503 @@ +<?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-or-later --> + +<refentry id="systemd-boot" conditional='ENABLE_EFI' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd-boot</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-boot</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-boot</refname> + <refname>sd-boot</refname> + <refpurpose>A simple UEFI boot manager</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-boot</command> (short: <command>sd-boot</command>) is a simple UEFI boot + 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><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 + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> description files + located in <filename>/loader/entries/</filename> on the ESP and the Extended Boot Loader + Partition. These usually describe Linux kernel images with associated initrd images, but alternatively + may also describe arbitrary other EFI executables.</para></listitem> + + <listitem><para>Unified kernel images following the <ulink + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, as executable EFI + binaries in <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader Partition. + </para></listitem> + + <listitem><para>The Microsoft Windows EFI boot manager, if installed</para></listitem> + + <listitem><para>The Apple MacOS X boot manager, if installed</para></listitem> + + <listitem><para>The EFI Shell binary, if installed</para></listitem> + + <listitem><para>A reboot into the UEFI firmware setup option, if supported by the firmware</para></listitem> + </itemizedlist> + + <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 persistent EFI variable and derives a random seed to use by the OS as + entropy pool initialization, 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><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> + <title>Key bindings</title> + <para>The following keys may be used in the boot menu:</para> + + <variablelist> + <varlistentry> + <term><keycap>↑</keycap> (Up)</term> + <term><keycap>↓</keycap> (Down)</term> + <term><keycap>j</keycap></term> + <term><keycap>k</keycap></term> + <term><keycap>PageUp</keycap></term> + <term><keycap>PageDown</keycap></term> + <term><keycap>Home</keycap></term> + <term><keycap>End</keycap></term> + <listitem><para>Navigate up/down in the entry list</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>↵</keycap> (Enter)</term> + <term><keycap>→</keycap> (Right)</term> + <listitem><para>Boot selected entry</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>d</keycap></term> + <listitem><para>Make selected entry the default</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>e</keycap></term> + <listitem><para>Edit the kernel command line for selected entry</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>+</keycap></term> + <term><keycap>t</keycap></term> + <listitem><para>Increase the timeout before default entry is booted</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>-</keycap></term> + <term><keycap>T</keycap></term> + <listitem><para>Decrease the timeout</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>v</keycap></term> + <listitem><para>Show systemd-boot, UEFI, and firmware versions</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>P</keycap></term> + <listitem><para>Print status</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>Q</keycap></term> + <listitem><para>Quit</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>h</keycap></term> + <term><keycap>?</keycap></term> + <term><keycap>F1</keycap></term> + <listitem><para>Show a help screen</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycombo><keycap>Ctrl</keycap><keycap>l</keycap></keycombo></term> + <listitem><para>Reprint the screen</para></listitem> + </varlistentry> + </variablelist> + + <para>The following keys may be pressed during bootup or in the boot menu to directly boot a specific + entry:</para> + + <variablelist> + <varlistentry> + <term><keycap>l</keycap></term> + <listitem><para>Linux</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>w</keycap></term> + <listitem><para>Windows</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>a</keycap></term> + <listitem><para>OS X</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>s</keycap></term> + <listitem><para>EFI shell</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>1</keycap></term> + <term><keycap>2</keycap></term> + <term><keycap>3</keycap></term> + <term><keycap>4</keycap></term> + <term><keycap>5</keycap></term> + <term><keycap>6</keycap></term> + <term><keycap>7</keycap></term> + <term><keycap>8</keycap></term> + <term><keycap>9</keycap></term> + <listitem><para>Boot entry number 1 … 9</para></listitem> + </varlistentry> + </variablelist> + + <para>The boot menu is shown when a non-zero menu timeout has been configured. If the menu timeout has + been set to zero, it is sufficient to press any key — before the boot loader initializes — to bring up + the boot menu, except for the keys listed immediately above as they directly boot into the selected boot + menu item. Note that depending on the firmware implementation the time window where key presses are + accepted before the boot loader initializes might be short. If the window is missed, reboot and try + again, possibly pressing a suitable key (e.g. the space bar) continuously; on most systems it should be + possible to hit the time window after a few attempts. To avoid this problem, consider setting a non-zero + timeout, thus showing the boot menu unconditionally. Some desktop environments might offer an option to + directly boot into the boot menu, to avoid the problem altogether. Alternatively, use the command line + <command>systemctl reboot --boot-loader-menu=0</command> from the shell.</para> + + <para>In the editor, most keys simply insert themselves, but the following keys + may be used to perform additional actions:</para> + + <variablelist> + <varlistentry> + <term><keycap>←</keycap> (Left)</term> + <term><keycap>→</keycap> (Right)</term> + <term><keycap>Home</keycap></term> + <term><keycap>End</keycap></term> + <listitem><para>Navigate left/right</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>Esc</keycap></term> + <listitem><para>Abort the edit and quit the editor</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycombo><keycap>Ctrl</keycap><keycap>k</keycap></keycombo></term> + <listitem><para>Clear the command line</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycombo><keycap>Ctrl</keycap><keycap>w</keycap></keycombo></term> + <term><keycombo><keycap>Alt</keycap><keycap>Backspace</keycap></keycombo></term> + <listitem><para>Delete word backwards</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycombo><keycap>Alt</keycap><keycap>d</keycap></keycombo></term> + <listitem><para>Delete word forwards</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>↵</keycap> (Enter)</term> + <listitem><para>Boot entry with the edited command line</para></listitem> + </varlistentry> + </variablelist> + + <para>Note that unless configured otherwise in the UEFI firmware, systemd-boot will + use the US keyboard layout, so key labels might not match for keys like +/-. + </para> + </refsect1> + + <refsect1> + <title>Files</title> + + <para>The files <command>systemd-boot</command> processes generally reside on the UEFI ESP which is + usually mounted to <filename>/efi/</filename>, <filename>/boot/</filename> or + <filename>/boot/efi/</filename> during OS runtime. It also processes files on the Extended Boot Loader + partition which is typically mounted to <filename>/boot/</filename>, if it + exists. <command>systemd-boot</command> reads runtime configuration such as the boot timeout and default + entry from <filename>/loader/loader.conf</filename> on the ESP (in combination with data read from EFI + variables). See + <citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Boot + entry description files following the <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot + 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. Optionally, a random + seed for early boot entropy pool provisioning is stored in <filename>/loader/random-seed</filename> in + the ESP.</para> + </refsect1> + + <refsect1> + <title>EFI Variables</title> + + <para>The following EFI variables are defined, set and read by <command>systemd-boot</command>, under the vendor + UUID <literal>4a67b082-0a4c-41cf-b6c7-440b29bb8c4</literal>, for communication between the OS and the boot + loader:</para> + + <variablelist class='efi-variables'> + <varlistentry> + <term><varname>LoaderBootCountPath</varname></term> + <listitem><para>If boot counting is enabled, contains the path to the file in whose name the boot counters are + encoded. Set by the boot + loader. <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + uses this information to mark a boot as successful as determined by the successful activation of the + <filename>boot-complete.target</filename> target unit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderConfigTimeout</varname></term> + <term><varname>LoaderConfigTimeoutOneShot</varname></term> + <listitem><para>The menu timeout in seconds. Read by the boot loader. <varname>LoaderConfigTimeout</varname> + is maintained persistently, while <varname>LoaderConfigTimeoutOneShot</varname> is a one-time override which is + read once (in which case it takes precedence over <varname>LoaderConfigTimeout</varname>) and then + removed. <varname>LoaderConfigTimeout</varname> may be manipulated with the + <keycap>t</keycap>/<keycap>T</keycap> keys, see above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderDevicePartUUID</varname></term> + + <listitem><para>Contains the partition UUID of the EFI System Partition the boot loader was run from. Set by + the boot + loader. <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + uses this information to automatically find the disk booted from, in order to discover various other partitions + on the same disk automatically.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderEntries</varname></term> + + <listitem><para>A list of the identifiers of all discovered boot loader entries. Set by the boot + loader.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderEntryDefault</varname></term> + <term><varname>LoaderEntryOneShot</varname></term> + + <listitem><para>The identifier of the default boot loader entry. Set primarily by the OS and read by the boot + loader. <varname>LoaderEntryOneShot</varname> sets the default entry for the next boot only, while + <varname>LoaderEntryDefault</varname> sets it persistently for all future + boots. <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <option>set-default</option> and <option>set-oneshot</option> commands make use of these variables. The boot + loader modifies <varname>LoaderEntryDefault</varname> on request, when the <keycap>d</keycap> key is used, see + above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderEntrySelected</varname></term> + + <listitem><para>The identifier of the boot loader entry currently being booted. Set by the boot + loader.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderFeatures</varname></term> + + <listitem><para>A set of flags indicating the features the boot loader supports. Set by the boot loader. Use + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this + data.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderFirmwareInfo</varname></term> + <term><varname>LoaderFirmwareType</varname></term> + + <listitem><para>Brief firmware information. Set by the boot loader. Use + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this + data.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderImageIdentifier</varname></term> + + <listitem><para>The path of executable of the boot loader used for the current boot, relative to the EFI System + Partition's root directory. Set by the boot loader. Use + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this + data.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderInfo</varname></term> + + <listitem><para>Brief information about the boot loader. Set by the boot loader. Use + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this + data.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LoaderTimeExecUSec</varname></term> + <term><varname>LoaderTimeInitUSec</varname></term> + <term><varname>LoaderTimeMenuUsec</varname></term> + + <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. </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 seed 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> + <title>Boot Counting</title> + + <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 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 + decreased by one on every boot attempt, the second of the two numbers ('tries done') is increased by one (if 'tries + done' is absent it is considered equivalent to 0). Depending on the current value of these two counters the boot + entry is considered to be in one of three states:</para> + + <orderedlist> + <listitem><para>If the 'tries left' counter of an entry is greater than zero the entry is considered to be in + 'indeterminate' state. This means the entry has not completed booting successfully yet, but also hasn't been + determined not to work.</para></listitem> + + <listitem><para>If the 'tries left' counter of an entry is zero it is considered to be in 'bad' state. This means + no further attempts to boot this item will be made (that is, unless all other boot entries are also in 'bad' + state), as all attempts to boot this entry have not completed successfully.</para></listitem> + + <listitem><para>If the 'tries left' and 'tries done' counters of an entry are absent it is considered to be in + 'good' state. This means further boot counting for the entry is turned off, as it successfully booted at least + once. The + <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + service moves the currently booted entry from 'indeterminate' into 'good' state when a boot attempt completed + successfully.</para></listitem> + </orderedlist> + + <para>Generally, when new entries are added to the boot loader, they first start out in 'indeterminate' state, + i.e. with a 'tries left' counter greater than zero. The boot entry remains in this state until either it managed to + complete a full boot successfully at least once (in which case it will be in 'good' state) — or the 'tries left' + counter reaches zero (in which case it will be in 'bad' state).</para> + + <para>Example: let's say a boot loader entry file <filename>foo.conf</filename> is set up for 3 boot tries. The + installer will hence create it under the name <filename>foo+3.conf</filename>. On first boot, the boot loader will + rename it to <filename>foo+2-1.conf</filename>. If that boot does not complete successfully, the boot loader will + rename it to <filename>foo+1-2.conf</filename> on the following boot. If that fails too, it will finally be renamed + <filename>foo+0-3.conf</filename> by the boot loader on next boot, after which it will be considered 'bad'. If the + boot succeeds however the entry file will be renamed to <filename>foo.conf</filename> by the OS, so that it is + considered 'good' from then on.</para> + + <para>The boot menu takes the 'tries left' counter into account when sorting the menu entries: entries in 'bad' + state are ordered at the beginning of the list, and entries in 'good' or 'indeterminate' at the end. The user can + freely choose to boot any entry of the menu, including those already marked 'bad'. If the menu entry to boot is + automatically determined, this means that 'good' or 'indeterminate' entries are generally preferred (as the bottom + item of the menu is the one booted by default), and 'bad' entries will only be considered if there are no 'good' or + 'indeterminate' entries left.</para> + + <para>The <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry> kernel + install framework optionally sets the initial 'tries left' counter to the value specified in + <filename>/etc/kernel/tries</filename> when a boot loader entry is first created.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <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> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-cat.xml b/man/systemd-cat.xml new file mode 100644 index 0000000..aff295b --- /dev/null +++ b/man/systemd-cat.xml @@ -0,0 +1,174 @@ +<?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-or-later --> + +<refentry id="systemd-cat" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-cat</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-cat</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-cat</refname> + <refpurpose>Connect a pipeline or program's output with the journal</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-cat <arg choice="opt" rep="repeat">OPTIONS</arg> <arg>COMMAND</arg> <arg choice="opt" rep="repeat">ARGUMENTS</arg></command> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-cat <arg choice="opt" rep="repeat">OPTIONS</arg></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-cat</command> may be used to connect the + standard input and output of a process to the journal, or as a + filter tool in a shell pipeline to pass the output the previous + pipeline element generates to the journal.</para> + + <para>If no parameter is passed, <command>systemd-cat</command> + will write everything it reads from standard input (stdin) to the + journal.</para> + + <para>If parameters are passed, they are executed as command line + with standard output (stdout) and standard error output (stderr) + connected to the journal, so that all it writes is stored in the + journal.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + + <varlistentry> + <term><option>-t</option></term> + <term><option>--identifier=</option></term> + + <listitem><para>Specify a short string that is used to + identify the logging tool. If not specified, no identification + string is written to the journal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--priority=</option></term> + + <listitem><para>Specify the default priority level for the + logged messages. Pass one of + <literal>emerg</literal>, + <literal>alert</literal>, + <literal>crit</literal>, + <literal>err</literal>, + <literal>warning</literal>, + <literal>notice</literal>, + <literal>info</literal>, + <literal>debug</literal>, or a + value between 0 and 7 (corresponding to the same named + levels). These priority values are the same as defined by + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Defaults to <literal>info</literal>. Note that this simply + controls the default, individual lines may be logged with + different levels if they are prefixed accordingly. For details, + see <option>--level-prefix=</option> below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--stderr-priority=</option></term> + + <listitem><para>Specifies the default priority level for + messages from the process's standard error output (stderr). + Usage of this option is the same as the + <option>--priority=</option> option, above, and both can be + used at once. When both are used, <option>--priority=</option> + will specify the default priority for standard output (stdout). + </para> + + <para>If <option>--stderr-priority=</option> is not specified, + messages from stderr will still be logged, with the same + default priority level as stdout.</para> + + <para>Also, note that when stdout and stderr use the same + default priority, the messages will be strictly ordered, + because one channel is used for both. When the default priority + differs, two channels are used, and so stdout messages will not + be strictly ordered with respect to stderr messages - though + they will tend to be approximately ordered.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--level-prefix=</option></term> + + <listitem><para>Controls whether lines read are parsed for + syslog priority level prefixes. If enabled (the default), a + line prefixed with a priority prefix such as + <literal><5></literal> is logged at priority 5 + (<literal>notice</literal>), and similar for the other + priority levels. Takes a boolean argument.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Invoke a program</title> + + <para>This calls <filename index="false">/bin/ls</filename> + with standard output and error connected to the journal:</para> + + <programlisting># systemd-cat ls</programlisting> + </example> + + <example> + <title>Usage in a shell pipeline</title> + + <para>This builds a shell pipeline also invoking + <filename>/bin/ls</filename> and writes the output it generates + to the journal:</para> + + <programlisting># ls | systemd-cat</programlisting> + </example> + + <para>Even though the two examples have very similar effects the + first is preferable since only one process is running at a time, + and both stdout and stderr are captured while in the second + example, only stdout is captured.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>logger</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml new file mode 100644 index 0000000..da853ec --- /dev/null +++ b/man/systemd-cgls.xml @@ -0,0 +1,133 @@ +<?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-or-later --> + +<refentry id="systemd-cgls" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-cgls</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-cgls</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-cgls</refname> + <refpurpose>Recursively show control group contents</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-cgls</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">CGROUP</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-cgls</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain"><option>--unit</option>|<option>--user-unit</option></arg> + <arg choice="opt" rep="repeat">UNIT</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-cgls</command> recursively shows the + contents of the selected Linux control group hierarchy in a tree. + If arguments are specified, shows all member processes of the + specified control groups plus all their subgroups and their + members. The control groups may either be specified by their full + file paths or are assumed in the systemd control group hierarchy. + If no argument is specified and the current working directory is + beneath the control group mount point + <filename>/sys/fs/cgroup/</filename>, shows the contents of the + control group the working directory refers to. Otherwise, the full + systemd control group hierarchy is shown.</para> + + <para>By default, empty control groups are not shown.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--all</option></term> + + <listitem><para>Do not hide empty control groups in the + output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem><para>Do not ellipsize process tree members.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-u</option></term> + <term><option>--unit</option></term> + + <listitem><para>Show cgroup subtrees for the specified units.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--user-unit</option></term> + + <listitem><para>Show cgroup subtrees for the specified user units.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-k</option></term> + + <listitem><para>Include kernel threads in output. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-M <replaceable>MACHINE</replaceable></option></term> + <term><option>--machine=<replaceable>MACHINE</replaceable></option></term> + + <listitem><para>Limit control groups shown to the part + corresponding to the container + <replaceable>MACHINE</replaceable>.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cgtop</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-cgtop.xml b/man/systemd-cgtop.xml new file mode 100644 index 0000000..a6d9671 --- /dev/null +++ b/man/systemd-cgtop.xml @@ -0,0 +1,356 @@ +<?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-or-later --> + +<refentry id="systemd-cgtop" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-cgtop</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-cgtop</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-cgtop</refname> + <refpurpose>Show top control groups by their resource usage</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-cgtop</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt">GROUP</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-cgtop</command> shows the top control + groups of the local Linux control group hierarchy, ordered by + their CPU, memory, or disk I/O load. The display is refreshed in + regular intervals (by default every 1s), similar in style to + <citerefentry project='man-pages'><refentrytitle>top</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + If a control group path is specified, shows only the services of + the specified control group.</para> + + <para>If <command>systemd-cgtop</command> is not connected to a + tty, no column headers are printed and the default is to only run + one iteration. The <option>--iterations=</option> argument, if + given, is honored. This mode is suitable for scripting.</para> + + <para>Resource usage is only accounted for control groups in the + relevant hierarchy, i.e. CPU usage is only accounted for control + groups in the <literal>cpuacct</literal> hierarchy, memory usage + only for those in <literal>memory</literal> and disk I/O usage for + those in <literal>blkio</literal>. If resource monitoring for + these resources is required, it is recommended to add the + <varname>CPUAccounting=1</varname>, + <varname>MemoryAccounting=1</varname> and + <varname>BlockIOAccounting=1</varname> settings in the unit files + in question. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>The CPU load value can be between 0 and 100 times the number of + processors the system has. For example, if the system has 8 processors, + the CPU load value is going to be between 0% and 800%. The number of + processors can be found in <literal>/proc/cpuinfo</literal>.</para> + + <para>To emphasize this: unless + <literal>CPUAccounting=1</literal>, + <literal>MemoryAccounting=1</literal> and + <literal>BlockIOAccounting=1</literal> are enabled for the + services in question, no resource accounting will be available for + system services and the data shown by + <command>systemd-cgtop</command> will be incomplete.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-p</option></term> + <term><option>--order=path</option></term> + + <listitem><para>Order by control group + path name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-t</option></term> + <term><option>--order=tasks</option></term> + + <listitem><para>Order by number of tasks/processes in the control group.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-c</option></term> + <term><option>--order=cpu</option></term> + + <listitem><para>Order by CPU load.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-m</option></term> + <term><option>--order=memory</option></term> + + <listitem><para>Order by memory usage.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-i</option></term> + <term><option>--order=io</option></term> + + <listitem><para>Order by disk I/O load.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-b</option></term> + <term><option>--batch</option></term> + + <listitem><para>Run in "batch" mode: do not accept input and + run until the iteration limit set with + <option>--iterations=</option> is exhausted or until killed. + This mode could be useful for sending output from + <command>systemd-cgtop</command> to other programs or to a + file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--raw</option></term> + + <listitem><para>Format byte counts (as in memory usage and I/O metrics) and CPU time + with raw numeric values rather than human-readable + numbers.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cpu=percentage</option></term> + <term><option>--cpu=time</option></term> + + <listitem><para>Controls whether the CPU usage is shown as + percentage or time. By default, the CPU usage is shown as + percentage. This setting may also be toggled at runtime by + pressing the <keycap>%</keycap> key.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-P</option></term> + + <listitem><para>Count only userspace processes instead of all + tasks. By default, all tasks are counted: each kernel thread + and each userspace thread individually. With this setting, + kernel threads are excluded from the counting and each + userspace process only counts as one, regardless how many + threads it consists of. This setting may also be toggled at + runtime by pressing the <keycap>P</keycap> key. This option + may not be combined with + <option>-k</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-k</option></term> + + <listitem><para>Count only userspace processes and kernel + threads instead of all tasks. By default, all tasks are + counted: each kernel thread and each userspace thread + individually. With this setting, kernel threads are included in + the counting and each userspace process only counts as on one, + regardless how many threads it consists of. This setting may + also be toggled at runtime by pressing the <keycap>k</keycap> + key. This option may not be combined with + <option>-P</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--recursive=</option></term> + + <listitem><para>Controls whether the number of processes shown + for a control group shall include all processes that are + contained in any of the child control groups as well. Takes a + boolean argument, which defaults to <literal>yes</literal>. If + enabled, the processes in child control groups are included, if + disabled, only the processes in the control group itself are + counted. This setting may also be toggled at runtime by + pressing the <keycap>r</keycap> key. Note that this setting + only applies to process counting, i.e. when the + <option>-P</option> or <option>-k</option> options are + used. It has not effect if all tasks are counted, in which + case the counting is always recursive.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--iterations=</option></term> + + <listitem><para>Perform only this many iterations. A value of + 0 indicates that the program should run + indefinitely.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-1</option></term> + + <listitem><para>A shortcut for <option>--iterations=1</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-d</option></term> + <term><option>--delay=</option></term> + + <listitem><para>Specify refresh delay in seconds (or if one of + <literal>ms</literal>, <literal>us</literal>, + <literal>min</literal> is specified as unit in this time + unit). This setting may also be increased and decreased at + runtime by pressing the <keycap>+</keycap> and + <keycap>-</keycap> keys.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--depth=</option></term> + + <listitem><para>Maximum control group tree traversal depth. + Specifies how deep <command>systemd-cgtop</command> shall + traverse the control group hierarchies. If 0 is specified, + only the root group is monitored. For 1, only the first level + of control groups is monitored, and so on. Defaults to + 3.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-M <replaceable>MACHINE</replaceable></option></term> + <term><option>--machine=<replaceable>MACHINE</replaceable></option></term> + + <listitem><para>Limit control groups shown to the part + corresponding to the container + <replaceable>MACHINE</replaceable>. + This option may not be used when a control group path is specified.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Keys</title> + + <para><command>systemd-cgtop</command> is an interactive tool and + may be controlled via user input using the following keys:</para> + + <variablelist> + <varlistentry> + <term><keycap>h</keycap></term> + + <listitem><para>Shows a short help text.</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap function="space"/></term> + + <listitem><para>Immediately refresh output.</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>q</keycap></term> + + <listitem><para>Terminate the program.</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>p</keycap></term> + <term><keycap>t</keycap></term> + <term><keycap>c</keycap></term> + <term><keycap>m</keycap></term> + <term><keycap>i</keycap></term> + + <listitem><para>Sort the control groups by path, number of + tasks, CPU load, memory usage, or I/O load, respectively. This + setting may also be controlled using the + <option>--order=</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>%</keycap></term> + + <listitem><para>Toggle between showing CPU time as time or + percentage. This setting may also be controlled using the + <option>--cpu=</option> command line switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>+</keycap></term> + <term><keycap>-</keycap></term> + + <listitem><para>Increase or decrease refresh delay, + respectively. This setting may also be controlled using the + <option>--delay=</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>P</keycap></term> + + <listitem><para>Toggle between counting all tasks, or only + userspace processes. This setting may also be controlled using + the <option>-P</option> command line switch (see + above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>k</keycap></term> + + <listitem><para>Toggle between counting all tasks, or only + userspace processes and kernel threads. This setting may also + be controlled using the <option>-k</option> command line + switch (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><keycap>r</keycap></term> + + <listitem><para>Toggle between recursively including or + excluding processes in child control groups in control group + process counts. This setting may also be controlled using the + <option>--recursive=</option> command line switch. This key is + not available if all tasks are counted, it is only available + if processes are counted, as enabled with the + <keycap>P</keycap> or <keycap>k</keycap> + keys.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>top</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml new file mode 100644 index 0000000..4ac6de1 --- /dev/null +++ b/man/systemd-coredump.xml @@ -0,0 +1,149 @@ +<?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-or-later --> + +<refentry id="systemd-coredump" conditional='ENABLE_COREDUMP' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-coredump</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-coredump</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-coredump</refname> + <refname>systemd-coredump.socket</refname> + <refname>systemd-coredump@.service</refname> + <refpurpose>Acquire, save and process core dumps</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/systemd-coredump</filename></para> + <para><filename>/usr/lib/systemd/systemd-coredump</filename> <option>--backtrace</option></para> + <para><filename>systemd-coredump@.service</filename></para> + <para><filename>systemd-coredump.socket</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para><filename>systemd-coredump@.service</filename> is a system service that can acquire core + dumps from the kernel and handle them in various ways. The <command>systemd-coredump</command> + executable does the actual work. It is invoked twice: once as the handler by the kernel, and the + second time in the <filename>systemd-coredump@.service</filename> to actually write the data to + the journal.</para> + + <para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it runs + in privileged mode, and will connect to the socket created by the + <filename>systemd-coredump.socket</filename> unit, which in turn will spawn an unprivileged + <filename>systemd-coredump@.service</filename> instance to process the core dump. Hence + <filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename> + are helper units which do the actual processing of core dumps and are subject to normal service + management.</para> + + <para>Core dumps can be written to the journal or saved as a file. Once saved they can be retrieved + for further processing, for example in + <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + + <para>By default, <command>systemd-coredump</command> will log the core dump including a backtrace + if possible to the journal and store the core dump itself in an external file in + <filename>/var/lib/systemd/coredump</filename>.</para> + + <para>The behavior of a specific program upon reception of a signal is governed by a few + factors which are described in detail in + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + In particular, the core dump will only be processed when the related resource limits are sufficient. + </para> + + <para>It is also possible to invoke <command>systemd-coredump</command> with + <option>--backtrace</option> option. In this case, <command>systemd-coredump</command> expects + a journal entry in the journal + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal Export Format</ulink> + on standard input. The entry should contain a <varname>MESSAGE=</varname> field and any additional + metadata fields the caller deems reasonable. <command>systemd-coredump</command> will append + additional metadata fields in the same way it does for core dumps received from the kernel. In + this mode, no core dump is stored in the journal.</para> + </refsect1> + + <refsect1> + <title>Configuration</title> + <para>For programs started by <command>systemd</command>, process resource limits can be set by directive + <varname>LimitCORE=</varname>, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>In order to be used by the kernel to handle core dumps, + <command>systemd-coredump</command> must be configured in + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + parameter <varname>kernel.core_pattern</varname>. The syntax of this parameter is explained in + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + systemd installs the file <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures + <varname>kernel.core_pattern</varname> accordingly. This file may be masked or overridden to use a different + setting following normal + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + rules. If the sysctl configuration is modified, it must be updated in the kernel before it + takes effect, see + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para>In order to be used in the <option>--backtrace</option> mode, an appropriate backtrace + handler must be installed on the sender side. For example, in case of + <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry>, this + means a <varname>sys.excepthook</varname> must be installed, see + <ulink url="https://github.com/keszybz/systemd-coredump-python">systemd-coredump-python</ulink>. + </para> + + <para>The behavior of <command>systemd-coredump</command> itself is configured through the configuration file + <filename>/etc/systemd/coredump.conf</filename> and corresponding snippets + <filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see + <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new + instance of <command>systemd-coredump</command> is invoked upon receiving every core dump. Therefore, changes + in these files will take effect the next time a core dump is received.</para> + + <para>Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired + core dumps and files can be set in files <filename>/etc/systemd/coredump.conf</filename> and snippets mentioned + above. In addition the storage time of core dump files is restricted by <command>systemd-tmpfiles</command>, + corresponding settings are by default in <filename>/usr/lib/tmpfiles.d/systemd.conf</filename>.</para> + + <refsect2> + <title>Disabling coredump processing</title> + + <para>To disable potentially resource-intensive processing by <command>systemd-coredump</command>, + set <programlisting>Storage=none +ProcessSizeMax=0</programlisting> in + <citerefentry><refentrytitle>coredump.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. + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + can be used to retrieve saved core dumps independent of their location, to display information and to process + them e.g. by passing to the GNU debugger (gdb).</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + </refsect1> +</refentry> diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml new file mode 100644 index 0000000..4284f78 --- /dev/null +++ b/man/systemd-cryptsetup-generator.xml @@ -0,0 +1,236 @@ +<?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-or-later --> +<refentry id="systemd-cryptsetup-generator" conditional='HAVE_LIBCRYPTSETUP'> + + <refentryinfo> + <title>systemd-cryptsetup-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-cryptsetup-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-cryptsetup-generator</refname> + <refpurpose>Unit generator for <filename>/etc/crypttab</filename></refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-cryptsetup-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-cryptsetup-generator</filename> is a + generator that translates <filename>/etc/crypttab</filename> into + native systemd units early at boot and when configuration of the + system manager is reloaded. This will create + <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + units as necessary.</para> + + <para><filename>systemd-cryptsetup-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-cryptsetup-generator</filename> + understands the following kernel command line parameters:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>luks=</varname></term> + <term><varname>rd.luks=</varname></term> + + <listitem><para>Takes a boolean argument. Defaults to + <literal>yes</literal>. If <literal>no</literal>, disables the + generator entirely. <varname>rd.luks=</varname> is honored + only by initial RAM disk (initrd) while + <varname>luks=</varname> is honored by both the main system + and the initrd. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks.crypttab=</varname></term> + <term><varname>rd.luks.crypttab=</varname></term> + + <listitem><para>Takes a boolean argument. Defaults to + <literal>yes</literal>. If <literal>no</literal>, causes the + generator to ignore any devices configured in + <filename>/etc/crypttab</filename> + (<varname>luks.uuid=</varname> will still work however). + <varname>rd.luks.crypttab=</varname> is honored only by + initial RAM disk (initrd) while + <varname>luks.crypttab=</varname> is honored by both the main + system and the initrd. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks.uuid=</varname></term> + <term><varname>rd.luks.uuid=</varname></term> + + <listitem><para>Takes a LUKS superblock UUID as argument. This + will activate the specified device as part of the boot process + as if it was listed in <filename>/etc/crypttab</filename>. + This option may be specified more than once in order to set up + multiple devices. <varname>rd.luks.uuid=</varname> is honored + only by initial RAM disk (initrd) while + <varname>luks.uuid=</varname> is honored by both the main + system and the initrd.</para> + <para>If /etc/crypttab contains entries with the same UUID, + then the name, keyfile and options specified there will be + used. Otherwise, the device will have the name + <literal>luks-UUID</literal>.</para> + <para>If /etc/crypttab exists, only those UUIDs + specified on the kernel command line + will be activated in the initrd or the real root.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks.name=</varname></term> + <term><varname>rd.luks.name=</varname></term> + + <listitem><para>Takes a LUKS super block UUID followed by an + <literal>=</literal> and a name. This implies + <varname>rd.luks.uuid=</varname> or + <varname>luks.uuid=</varname> and will additionally make the + LUKS device given by the UUID appear under the provided + name.</para> + + <para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle> + <manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para> + + <para><varname>rd.luks.name=</varname> is honored only by + initial RAM disk (initrd) while <varname>luks.name=</varname> + is honored by both the main system and the initrd.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks.data=</varname></term> + <term><varname>rd.luks.data=</varname></term> + + <listitem><para>Takes a LUKS super block UUID followed by a <literal>=</literal> and a block device + specification for device hosting encrypted data.</para> + + <para>For those entries specified with <varname>rd.luks.uuid=</varname> or + <varname>luks.uuid=</varname>, the data device will be set to the one specified by + <varname>rd.luks.data=</varname> or <varname>luks.data=</varname> of the corresponding UUID.</para> + + <para>LUKS data device parameter is useful for specifying encrypted data devices with detached headers specified in + <varname>luks.options</varname> entry containing <literal>header=</literal> argument. For example, + <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40 + <varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/path/to/luks.hdr + <varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx. + Hence, in this case, we will attempt to unlock LUKS device assembled from data device <literal>/dev/sdx</literal> + and LUKS header (metadata) put in <literal>/path/to/luks.hdr</literal> file. This syntax is for now + only supported on a per-device basis, i.e. you have to specify LUKS device UUID.</para> + + <para>This parameter is the analogue of the second <citerefentry><refentrytitle>crypttab</refentrytitle> + <manvolnum>5</manvolnum></citerefentry> field <replaceable>encrypted-device</replaceable>.</para> + + <para><varname>rd.luks.data=</varname> is honored only by initial RAM disk (initrd) while + <varname>luks.data=</varname> is honored by both the main system and the initrd.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks.key=</varname></term> + <term><varname>rd.luks.key=</varname></term> + + <listitem><para>Takes a password file name as argument or a + LUKS super block UUID followed by a <literal>=</literal> and a + password file name.</para> + + <para>For those entries specified with + <varname>rd.luks.uuid=</varname> or + <varname>luks.uuid=</varname>, the password file will be set + to the one specified by <varname>rd.luks.key=</varname> or + <varname>luks.key=</varname> of the corresponding UUID, or the + password file that was specified without a UUID.</para> + + <para>It is also possible to specify an external device which + should be mounted before we attempt to unlock the LUKS device. + systemd-cryptsetup will use password file stored on that + device. Device containing password file is specified by + appending colon and a device identifier to the password file + path. For example, + <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40 + <varname>rd.luks.key=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev. + Hence, in this case, we will attempt to mount file system + residing on the block device with label <literal>keydev</literal>. + This syntax is for now only supported on a per-device basis, + i.e. you have to specify LUKS device UUID.</para> + + <para>This parameter is the analogue of the third <citerefentry><refentrytitle>crypttab</refentrytitle> + <manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para> + + <para><varname>rd.luks.key=</varname> + is honored only by initial RAM disk + (initrd) while + <varname>luks.key=</varname> is + honored by both the main system and + the initrd.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>luks.options=</varname></term> + <term><varname>rd.luks.options=</varname></term> + + <listitem><para>Takes a LUKS super block UUID followed by an + <literal>=</literal> and a string of options separated by + commas as argument. This will override the options for the + given UUID.</para> + <para>If only a list of options, without an UUID, is + specified, they apply to any UUIDs not specified elsewhere, + and without an entry in + <filename>/etc/crypttab</filename>.</para> + + <para>This parameter is the analogue of the fourth <citerefentry><refentrytitle>crypttab</refentrytitle> + <manvolnum>5</manvolnum></citerefentry> field <replaceable>options</replaceable>.</para> + + <para>It is possible to specify an external device which + should be mounted before we attempt to unlock the LUKS device. + systemd-cryptsetup will assemble LUKS device by combining + data device specified in <varname>luks.data</varname> with + detached LUKS header found in <literal>header=</literal> + argument. For example, + <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40 + <varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/luks.hdr:LABEL=hdrdev + <varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx. + Hence, in this case, we will attempt to mount file system + residing on the block device with label <literal>hdrdev</literal>, and look + for <literal>luks.hdr</literal> on that file system. Said header will be used + to unlock (decrypt) encrypted data stored on /dev/sdx. + This syntax is for now only supported on a per-device basis, + i.e. you have to specify LUKS device UUID.</para> + + <para><varname>rd.luks.options=</varname> is honored only by initial + RAM disk (initrd) while <varname>luks.options=</varname> is + honored by both the main system and the initrd.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-cryptsetup@.service.xml b/man/systemd-cryptsetup@.service.xml new file mode 100644 index 0000000..216db74 --- /dev/null +++ b/man/systemd-cryptsetup@.service.xml @@ -0,0 +1,84 @@ +<?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-or-later --> +<refentry id="systemd-cryptsetup@.service" conditional='HAVE_LIBCRYPTSETUP'> + + <refentryinfo> + <title>systemd-cryptsetup@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-cryptsetup@.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-cryptsetup@.service</refname> + <refname>systemd-cryptsetup</refname> + <refpurpose>Full disk decryption logic</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-cryptsetup@.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-cryptsetup</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-cryptsetup@.service</filename> is a + service responsible for setting up encrypted block devices. It is + instantiated for each device that requires decryption for + access.</para> + + <para><filename>systemd-cryptsetup@.service</filename> will ask + for hard disk passwords via the <ulink + url="https://systemd.io/PASSWORD_AGENTS/">password agent logic</ulink>, in + order to query the user for the password using the right mechanism at boot + and during runtime.</para> + + <para>At early boot and when the system manager configuration is reloaded, <filename>/etc/crypttab</filename> is + translated into <filename>systemd-cryptsetup@.service</filename> units by + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <para>In order to unlock a volume a password or binary key is + required. <filename>systemd-cryptsetup@.service</filename> tries to acquire a suitable password or binary + key via the following mechanisms, tried in order:</para> + + <orderedlist> + <listitem><para>If a key file is explicitly configured (via the third column in + <filename>/etc/crypttab</filename>), a key read from it is used. If a PKCS#11 token is configured + (using the <varname>pkcs11-uri=</varname> option) the key is decrypted before use.</para></listitem> + + <listitem><para>If no key file is configured explicitly this way, a key file is automatically loaded + from <filename>/etc/cryptsetup-keys.d/<replaceable>volume</replaceable>.key</filename> and + <filename>/run/cryptsetup-keys.d/<replaceable>volume</replaceable>.key</filename>, if present. Here + too, if a PKCS#11 token is configured, any key found this way is decrypted before + use.</para></listitem> + + <listitem><para>If the <varname>try-empty-password</varname> option is specified it is then attempted + to unlock the volume with an empty password.</para></listitem> + + <listitem><para>The kernel keyring is then checked for a suitable cached password from previous + attempts.</para></listitem> + + <listitem><para>Finally, the user is queried for a password, possibly multiple times.</para></listitem> + </orderedlist> + + <para>If no suitable key may be acquired via any of the mechanisms describes above, volume activation fails.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml new file mode 100644 index 0000000..531209b --- /dev/null +++ b/man/systemd-debug-generator.xml @@ -0,0 +1,85 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> +<refentry id="systemd-debug-generator"> + + <refentryinfo> + <title>systemd-debug-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-debug-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-debug-generator</refname> + <refpurpose>Generator for enabling a runtime debug shell and + masking specific units at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-debug-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-debug-generator</filename> is a generator + that reads the kernel command line and understands three + options:</para> + + <para>If the <option>systemd.mask=</option> or <option>rd.systemd.mask=</option> + option is specified and followed by a unit name, this unit is + masked for the runtime, similar to the effect of + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>mask</command> command. This is useful to boot with + certain units removed from the initial boot transaction for + debugging system startup. May be specified more than once. + <option>rd.systemd.mask=</option> is honored only by initial + RAM disk (initrd) while <option>systemd.mask=</option> is + honored only in the main system.</para> + + <para>If the <option>systemd.wants=</option> or + <option>rd.systemd.wants=</option> option is specified + and followed by a unit name, a start job for this unit is added to + the initial transaction. This is useful to start one or more + additional units at boot. May be specified more than once. + <option>rd.systemd.wants=</option> is honored only by initial + RAM disk (initrd) while <option>systemd.wants=</option> is + honored only in the main system.</para> + + <para>If the <option>systemd.debug_shell</option> or + <option>rd.systemd.debug_shell</option> option is + specified, the debug shell service + <literal>debug-shell.service</literal> is pulled into the boot + 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 + RAM disk (initrd) while <option>systemd.debug_shell</option> is + honored only in the main system.</para> + + <para><filename>systemd-debug-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml new file mode 100644 index 0000000..7a83bc9 --- /dev/null +++ b/man/systemd-delta.xml @@ -0,0 +1,178 @@ +<?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-or-later --> + +<refentry id="systemd-delta" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-delta</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-delta</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-delta</refname> + <refpurpose>Find overridden configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-delta</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-delta</command> may be used to identify and + compare configuration files that override other configuration + files. Files in <filename>/etc/</filename> have highest priority, + files in <filename>/run/</filename> have the second highest + priority, …, files in <filename>/usr/lib/</filename> have lowest + priority. Files in a directory with higher priority override files + with the same name in directories of lower priority. In addition, + certain configuration files can have <literal>.d</literal> + directories which contain "drop-in" files with configuration + snippets which augment the main configuration file. "Drop-in" + files can be overridden in the same way by placing files with the + same name in a directory of higher priority (except that, in case + of "drop-in" files, both the "drop-in" file name and the name of + the containing directory, which corresponds to the name of the + main configuration file, must match). For a fuller explanation, + see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>The command line argument will be split into a prefix and a + suffix. Either is optional. The prefix must be one of the + directories containing configuration files + (<filename>/etc/</filename>, <filename>/run/</filename>, + <filename>/usr/lib/</filename>, …). If it is given, only + overriding files contained in this directory will be shown. + Otherwise, all overriding files will be shown. The suffix must be + a name of a subdirectory containing configuration files like + <filename>tmpfiles.d</filename>, <filename>sysctl.d</filename> or + <filename>systemd/system</filename>. If it is given, only + configuration files in this subdirectory (across all configuration + paths) will be analyzed. Otherwise, all configuration files will + be analyzed. If the command line argument is not given at all, all + configuration files will be analyzed. See below for some + examples.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-t</option></term> + <term><option>--type=</option></term> + + <listitem><para>When listing the differences, only list those + that are asked for. The list itself is a comma-separated list + of desired difference types.</para> + + <para>Recognized types are: + + <variablelist> + <varlistentry> + <term><varname>masked</varname></term> + + <listitem><para>Show masked files</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>equivalent</varname></term> + + <listitem><para>Show overridden files that while + overridden, do not differ in content.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>redirected</varname></term> + + <listitem><para>Show files that are redirected to + another.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>overridden</varname></term> + + <listitem><para>Show overridden, and changed + files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>extended</varname></term> + + <listitem><para>Show <filename>*.conf</filename> files + in drop-in directories for units.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>unchanged</varname></term> + + <listitem><para>Show unmodified files + too.</para></listitem> + </varlistentry> + </variablelist> + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--diff=</option></term> + + <listitem><para>When showing modified files, when a file is + overridden show a diff as well. This option takes a boolean + argument. If omitted, it defaults to + <option>true</option>.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>To see all local configuration:</para> + <programlisting>systemd-delta</programlisting> + + <para>To see all runtime configuration:</para> + <programlisting>systemd-delta /run</programlisting> + + <para>To see all system unit configuration changes:</para> + <programlisting>systemd-delta systemd/system</programlisting> + + <para>To see all runtime "drop-in" changes for system units:</para> + <programlisting>systemd-delta --type=extended /run/systemd/system</programlisting> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml new file mode 100644 index 0000000..09491f7 --- /dev/null +++ b/man/systemd-detect-virt.xml @@ -0,0 +1,282 @@ +<?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-or-later --> + +<refentry id="systemd-detect-virt" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-detect-virt</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-detect-virt</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-detect-virt</refname> + <refpurpose>Detect execution in a virtualized environment</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-detect-virt</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-detect-virt</command> detects execution in + a virtualized environment. It identifies the virtualization + technology and can distinguish full machine virtualization from + container virtualization. <filename>systemd-detect-virt</filename> + exits with a return value of 0 (success) if a virtualization + technology is detected, and non-zero (error) otherwise. By default, + any type of virtualization is detected, and the options + <option>--container</option> and <option>--vm</option> can be used + to limit what types of virtualization are detected.</para> + + <para>When executed without <option>--quiet</option> will print a + short identifier for the detected virtualization technology. The + following technologies are currently identified:</para> + + <table> + <title>Known virtualization technologies (both + VM, i.e. full hardware virtualization, + and container, i.e. shared kernel virtualization)</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="type" /> + <colspec colname="id" /> + <colspec colname="product" /> + <thead> + <row> + <entry>Type</entry> + <entry>ID</entry> + <entry>Product</entry> + </row> + </thead> + <tbody> + <row> + <entry valign="top" morerows="13">VM</entry> + <entry><varname>qemu</varname></entry> + <entry>QEMU software virtualization, without KVM</entry> + </row> + + <row> + <entry><varname>kvm</varname></entry> + <entry>Linux KVM kernel virtual machine, with whatever software, except Oracle Virtualbox</entry> + </row> + + <row> + <entry><varname>zvm</varname></entry> + <entry>s390 z/VM</entry> + </row> + + <row> + <entry><varname>vmware</varname></entry> + <entry>VMware Workstation or Server, and related products</entry> + </row> + + <row> + <entry><varname>microsoft</varname></entry> + <entry>Hyper-V, also known as Viridian or Windows Server Virtualization</entry> + </row> + + <row> + <entry><varname>oracle</varname></entry> + <entry>Oracle VM VirtualBox (historically marketed by innotek and Sun Microsystems), for legacy and KVM hypervisor</entry> + </row> + + <row> + <entry><varname>powervm</varname></entry> + <entry>IBM PowerVM hypervisor - comes as firmware with some IBM POWER servers</entry> + </row> + + <row> + <entry><varname>xen</varname></entry> + <entry>Xen hypervisor (only domU, not dom0)</entry> + </row> + + <row> + <entry><varname>bochs</varname></entry> + <entry>Bochs Emulator</entry> + </row> + + <row> + <entry><varname>uml</varname></entry> + <entry>User-mode Linux</entry> + </row> + + <row> + <entry><varname>parallels</varname></entry> + <entry>Parallels Desktop, Parallels Server</entry> + </row> + + <row> + <entry><varname>bhyve</varname></entry> + <entry>bhyve, FreeBSD hypervisor</entry> + </row> + + <row> + <entry><varname>qnx</varname></entry> + <entry>QNX hypervisor</entry> + </row> + + <row> + <entry><varname>acrn</varname></entry> + <entry><ulink url="https://projectacrn.org">ACRN hypervisor</ulink></entry> + </row> + + <row> + <entry valign="top" morerows="9">Container</entry> + <entry><varname>openvz</varname></entry> + <entry>OpenVZ/Virtuozzo</entry> + </row> + + <row> + <entry><varname>lxc</varname></entry> + <entry>Linux container implementation by LXC</entry> + </row> + + <row> + <entry><varname>lxc-libvirt</varname></entry> + <entry>Linux container implementation by libvirt</entry> + </row> + + <row> + <entry><varname>systemd-nspawn</varname></entry> + <entry>systemd's minimal container implementation, see <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry></entry> + </row> + + <row> + <entry><varname>docker</varname></entry> + <entry>Docker container manager</entry> + </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> + + <row> + <entry><varname>wsl</varname></entry> + <entry><ulink url="https://docs.microsoft.com/en-us/windows/wsl/about">Windows Subsystem for Linux</ulink></entry> + </row> + + <row> + <entry><varname>proot</varname></entry> + <entry><ulink url="https://proot-me.github.io/">proot</ulink> userspace chroot/bind mount emulation</entry> + </row> + + <row> + <entry><varname>pouch</varname></entry> + <entry><ulink url="https://github.com/alibaba/pouch">Pouch</ulink> Container Engine</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>If multiple virtualization solutions are used, only the + "innermost" is detected and identified. That means if both + machine and container virtualization are used in + conjunction, only the latter will be identified (unless + <option>--vm</option> is passed).</para> + <para> Windows Subsystem for Linux is not a Linux container, + but an environment for running Linux userspace applications on + top of the Windows kernel using a Linux-compatible interface. + WSL is categorized as a container for practical purposes. + Multiple WSL environments share the same kernel and services + should generally behave like when being run in a container.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-c</option></term> + <term><option>--container</option></term> + + <listitem><para>Only detects container virtualization (i.e. + shared kernel virtualization).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-v</option></term> + <term><option>--vm</option></term> + + <listitem><para>Only detects hardware virtualization.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--chroot</option></term> + + <listitem><para>Detect whether invoked in a + <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry> + environment. In this mode, no output is written, but the return + value indicates whether the process was invoked in a + <function>chroot()</function> + environment or not.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--private-users</option></term> + + <listitem><para>Detect whether invoked in a user namespace. In this mode, no + output is written, but the return value indicates whether the process was invoked + inside of a user namespace or not. See + <citerefentry project='man-pages'><refentrytitle>user_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Suppress output of the virtualization + technology identifier.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--list</option></term> + + <listitem><para>Output all currently known and detectable container and VM environments.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>If a virtualization technology is detected, 0 is returned, a + non-zero code otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-dissect.xml b/man/systemd-dissect.xml new file mode 100644 index 0000000..ed2153f --- /dev/null +++ b/man/systemd-dissect.xml @@ -0,0 +1,263 @@ +<?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-or-later --> + +<refentry id="systemd-dissect" conditional='HAVE_BLKID' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-dissect</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-dissect</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-dissect</refname> + <refpurpose>Dissect file system OS images</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="plain"><replaceable>IMAGE</replaceable></arg></command> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--mount</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="plain"><replaceable>PATH</replaceable></arg></command> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--copy-from</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="plain"><replaceable>PATH</replaceable></arg> <arg choice="opt"><replaceable>TARGET</replaceable></arg></command> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--copy-to</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="opt"><replaceable>SOURCE</replaceable></arg> <arg choice="plain"><replaceable>PATH</replaceable></arg></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-dissect</command> is a tool for introspecting and interacting with file system OS + disk images. It supports four different operations:</para> + + <orderedlist> + <listitem><para>Show general OS image information, including the image's + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> data, + machine ID, partition information and more.</para></listitem> + + <listitem><para>Mount an OS image to a local directory. In this mode it will dissect the OS image and + mount the included partitions according to their designation onto a directory and possibly + sub-directories.</para></listitem> + + <listitem><para>Copy files and directories in and out of an OS image.</para></listitem> + </orderedlist> + + <para>The tool may operate on three types of OS images:</para> + + <orderedlist> + <listitem><para>OS disk images containing a GPT partition table envelope, with partitions marked + according to the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>.</para></listitem> + + <listitem><para>OS disk images containing just a plain file-system without an enveloping partition + table. (This file system is assumed to be the root file system of the OS.)</para></listitem> + + <listitem><para>OS disk images containing a GPT or MBR partition table, with a single + partition only. (This partition is assumed to contain the root file system of the OS.)</para></listitem> + </orderedlist> + + <para>OS images may use any kind of Linux-supported file systems. In addition they may make use of LUKS + disk encryption, and contain Verity integrity information. Note that qualifying OS images may be booted + with <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <option>--image=</option> switch, and be used as root file system for system service using the + <varname>RootImage=</varname> unit file setting, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>Note that the partition table shown when invoked without command switch (as listed below) does not + necessarily show all partitions included in the image, but just the partitions that are understood and + considered part of an OS disk image. Specifically, partitions of unknown types are ignored, as well as + duplicate partitions (i.e. more than one per partition type), as are root and <filename>/usr/</filename> + partitions of architectures not compatible with the local system. In other words: this tool will display + what it operates with when mounting the image. To display the complete list of partitions use a tool such + as <citerefentry + project='man-pages'><refentrytitle>fdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>If neither of the command switches listed below are passed the specified disk image is opened and + general information about the image and the contained partitions and their use is shown.</para> + + <variablelist> + <varlistentry> + <term><option>--mount</option></term> + <term><option>-m</option></term> + + <listitem><para>Mount the specified OS image to the specified directory. This will dissect the image, + determine the OS root file system — as well as possibly other partitions — and mount them to the + specified directory. If the OS image contains multiple partitions marked with the <ulink + url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions Specification</ulink> + multiple nested mounts are established. This command expects two arguments: a path to an image file + and a path to a directory where to mount the image.</para> + + <para>To unmount an OS image mounted like this use <citerefentry + project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <option>-R</option> switch (for recursive operation), so that the OS image and all nested partition + mounts are unmounted.</para> + + <para>When the OS image contains LUKS encrypted or Verity integrity protected file systems + appropriate volumes are automatically set up and marked for automatic disassembly when the image is + unmounted.</para> + + <para>The OS image may either be specified as path to an OS image stored in a regular file or may + refer to block device node (in the latter case the block device must be the "whole" device, i.e. not + a partition device). (The other supported commands described here support this, too.)</para> + + <para>All mounted file systems are checked with the appropriate <citerefentry + project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry> + implementation in automatic fixing mode, unless explicitly turned off (<option>--fsck=no</option>) or + read-only operation is requested (<option>--read-only</option>).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-M</option></term> + + <listitem><para>This is a shortcut for <option>--mount --mkdir</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--copy-from</option></term> + <term><option>-x</option></term> + + <listitem><para>Copies a file or directory from the specified OS image into the specified location on + the host file system. Expects three arguments: a path to an image file, a source path (relative to + the image's root directory) and a destination path (relative to the current working directory, or an + absolute path, both outside of the image). If the destination path is omitted or specified as dash + (<literal>-</literal>), the specified file is written to standard output. If the source path in the + image file system refers to a regular file it is copied to the destination path. In this case access + mode, extended attributes and timestamps are copied as well, but file ownership is not. If the source + path in the image refers to a directory, it is copied to the destination path, recursively with all + containing files and directories. In this case the file ownership is copied too.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--copy-to</option></term> + <term><option>-a</option></term> + + <listitem><para>Copies a file or directory from the specified location in the host file system into + the specified OS image. Expects three arguments: a path to an image file, a source path (relative to + the current working directory, or an absolute path, both outside of the image) and a destination path + (relative to the image's root directory). If the source path is omitted or specified as dash + (<literal>-</literal>), the data to write is read from standard input. If the source path in the host + file system refers to a regular file, it is copied to the destination path. In this case access mode, + extended attributes and timestamps are copied as well, but file ownership is not. If the source path + in the host file system refers to a directory it is copied to the destination path, recursively with + all containing files and directories. In this case the file ownership is copied + too.</para> + + <para>As with <option>--mount</option> file system checks are implicitly run before the copy + operation begins.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--json=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Shows output formatted as JSON. Expects one of <literal>short</literal> (for the + shortest possible output without any redundant whitespace or line breaks), <literal>pretty</literal> + (for a pretty version of the same, with indentation and line breaks) or <literal>off</literal> (to turn + off json output).</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--read-only</option></term> + <term><option>-r</option></term> + + <listitem><para>Operate in read-only mode. By default <option>--mount</option> will establish + writable mount points. If this option is specified they are established in read-only mode + instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--fsck=no</option></term> + + <listitem><para>Turn off automatic file system checking. By default when an image is accessed for + writing (by <option>--mount</option> or <option>--add</option>) the file systems contained in the OS + image are automatically checked using the appropriate <citerefentry + project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry> + command, in automatic fixing mode. This behavior may be switched off using + <option>--fsck=no</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--mkdir</option></term> + + <listitem><para>If combined with <option>--mount</option> the directory to mount the OS image to is + created if it is missing. Note that the directory is not automatically removed when the disk image is + unmounted again.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--discard=</option></term> + + <listitem><para>Takes one of <literal>disabled</literal>, <literal>loop</literal>, + <literal>all</literal>, <literal>crypto</literal>. If <literal>disabled</literal> the image is + accessed with empty block discarding turned off. if <literal>loop</literal> discarding is enabled if + operating on a regular file. If <literal>crypt</literal> discarding is enabled even on encrypted file + systems. If <literal>all</literal> discarding is unconditionally enabled.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root-hash=</option></term> + <term><option>--root-hash-sig=</option></term> + <term><option>--verity-data=</option></term> + + <listitem><para>Configure various aspects of Verity data integrity for the OS + image. <option>--root-hash=</option> expects a hex-encoding top-level Verity hash to use for setting + up the Verity integrity protection. <option>--root-hash-sig=</option> expects the path to a file + containing a PKCS#7 signature file for the hash. This signature is passed to the kernel during + activation, which will match it against signature keys available in the kernel + keyring. <option>--verity-data=</option> expects the path to a file with the Verity data to use for + the OS image, in case it is stored in a detached file. It is recommended to embed the Verity data + directly in the image, using the Verity mechanisms in the <ulink + url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions Specification</ulink>.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions Specification</ulink>, + <citerefentry project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-environment-d-generator.xml b/man/systemd-environment-d-generator.xml new file mode 100644 index 0000000..a9b6b98 --- /dev/null +++ b/man/systemd-environment-d-generator.xml @@ -0,0 +1,53 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> +<refentry id="systemd-environment-d-generator" conditional='ENABLE_ENVIRONMENT_D'> + + <refentryinfo> + <title>systemd-environment-d-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-environment-d-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-environment-d-generator</refname> + <refname>30-systemd-environment-d-generator</refname> + <refpurpose>Load variables specified by <filename>environment.d</filename> + </refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>&userenvgeneratordir;/30-systemd-environment-d-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-environment-d-generator</filename> is a + <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry> + that reads environment configuration specified by + <citerefentry><refentrytitle>environment.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration files and passes it to the + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + user manager instance.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-escape.xml b/man/systemd-escape.xml new file mode 100644 index 0000000..f5d78be --- /dev/null +++ b/man/systemd-escape.xml @@ -0,0 +1,182 @@ +<?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-or-later --> + +<refentry id="systemd-escape" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-escape</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-escape</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-escape</refname> + <refpurpose>Escape strings for usage in systemd unit names</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-escape</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">STRING</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-escape</command> may be used to escape + strings for inclusion in systemd unit names. The command may be + used to escape and to undo escaping of strings.</para> + + <para>The command takes any number of strings on the command line, + and will process them individually, one after another. It will + output them separated by spaces to stdout.</para> + + <para>By default, this command will escape the strings passed, + unless <option>--unescape</option> is passed which results in the + inverse operation being applied. If <option>--mangle</option> is given, a + special mode of escaping is applied instead, which assumes the + string is already escaped but will escape everything that + appears obviously non-escaped.</para> + + <para>For details on the escaping and unescaping algorithms see the relevant section in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--suffix=</option></term> + + <listitem><para>Appends the specified unit type suffix to the + escaped string. Takes one of the unit types supported by + systemd, such as <literal>service</literal> or + <literal>mount</literal>. May not be used in conjunction with + <option>--template=</option>, <option>--unescape</option> or + <option>--mangle</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--template=</option></term> + + <listitem><para>Inserts the escaped strings in a unit name + template. Takes a unit name template such as + <filename>foobar@.service</filename>. With + <option>--unescape</option>, expects instantiated unit names + for this template and extracts and unescapes just the instance + part. May not be used in conjunction with + <option>--suffix=</option>, + <option>--instance</option> or + <option>--mangle</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--path</option></term> + <term><option>-p</option></term> + + <listitem><para>When escaping or unescaping a string, assume it refers to a file system path. This eliminates + leading, trailing or duplicate <literal>/</literal> characters and rejects <literal>.</literal> and + <literal>..</literal> path components. This is particularly useful for generating strings suitable for + unescaping with the <literal>%f</literal> specifier in unit files, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--unescape</option></term> + <term><option>-u</option></term> + + <listitem><para>Instead of escaping the specified strings, + undo the escaping, reversing the operation. May not be used in + conjunction with <option>--suffix=</option> or + <option>--mangle</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--mangle</option></term> + <term><option>-m</option></term> + + <listitem><para>Like <option>--escape</option>, but only + escape characters that are obviously not escaped yet, and + possibly automatically append an appropriate unit type suffix + to the string. May not be used in conjunction with + <option>--suffix=</option>, <option>--template=</option> or + <option>--unescape</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--instance</option></term> + + <listitem><para>With <option>--unescape</option>, unescape + and print only the instance part of an instantiated unit name + template. Results in an error for an uninstantiated template + like <filename>ssh@.service</filename> or a non-template name + like <filename>ssh.service</filename>. + Must be used in conjunction with <option>--unescape</option> + and may not be used in conjunction with + <option>--template</option>.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Examples</title> + + <para>To escape a single string:</para> + <programlisting>$ systemd-escape 'Hallöchen, Meister' +Hall\xc3\xb6chen\x2c\x20Meister</programlisting> + + <para>To undo escaping on a single string:</para> + <programlisting>$ systemd-escape -u 'Hall\xc3\xb6chen\x2c\x20Meister' +Hallöchen, Meister</programlisting> + + <para>To generate the mount unit for a path:</para> + <programlisting>$ systemd-escape -p --suffix=mount "/tmp//waldi/foobar/" +tmp-waldi-foobar.mount</programlisting> + + <para>To generate instance names of three strings:</para> + <programlisting>$ systemd-escape --template=systemd-nspawn@.service 'My Container 1' 'containerb' 'container/III' +systemd-nspawn@My\x20Container\x201.service systemd-nspawn@containerb.service systemd-nspawn@container-III.service</programlisting> + + <para>To extract the instance part of an instantiated unit:</para> + <programlisting>$ systemd-escape -u --instance 'systemd-nspawn@My\x20Container\x201.service' +My Container 1</programlisting> + + <para>To extract the instance part of an instance of a particular template:</para> + <programlisting>$ systemd-escape -u --template=systemd-nspawn@.service 'systemd-nspawn@My\x20Container\x201.service' +My Container 1</programlisting> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml new file mode 100644 index 0000000..a1607ab --- /dev/null +++ b/man/systemd-firstboot.xml @@ -0,0 +1,327 @@ +<?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-or-later --> + +<refentry id="systemd-firstboot" conditional='ENABLE_FIRSTBOOT' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-firstboot</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-firstboot</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-firstboot</refname> + <refname>systemd-firstboot.service</refname> + <refpurpose>Initialize basic system settings on or before the first boot-up of a system</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-firstboot</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + + <para><filename>systemd-firstboot.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-firstboot</command> initializes the most + basic system settings interactively on the first boot, or + optionally non-interactively when a system image is created. + The service is started if <varname>ConditionFirstBoot=yes</varname> + is satisfied. This essentially means that <filename>/etc/</filename> + is empty, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>The following settings may be set up:</para> + + <itemizedlist> + <listitem><para>The system locale, more specifically the two + locale variables <varname>LANG=</varname> and + <varname>LC_MESSAGES</varname></para></listitem> + + <listitem><para>The system keyboard map</para></listitem> + + <listitem><para>The system time zone</para></listitem> + + <listitem><para>The system hostname</para></listitem> + + <listitem><para>The machine ID of the system</para></listitem> + + <listitem><para>The root user's password</para></listitem> + </itemizedlist> + + <para>Each of the fields may either be queried interactively by + users, set non-interactively on the tool's command line, or be + copied from a host system that is used to set up the system + image.</para> + + <para>If a setting is already initialized, it will not be + overwritten and the user will not be prompted for the + setting.</para> + + <para>Note that this tool operates directly on the file system and + does not involve any running system services, unlike + <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + or + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + This allows <command>systemd-firstboot</command> to operate on + mounted but not booted disk images and in early boot. It is not + recommended to use <command>systemd-firstboot</command> on the + running system while it is up.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--root=<replaceable>root</replaceable></option></term> + <listitem><para>Takes a directory path as an argument. All + paths will be prefixed with the given alternate + <replaceable>root</replaceable> path, including config search + paths. This is useful to operate on a system image mounted to + the specified directory instead of the host system itself. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--image=<replaceable>path</replaceable></option></term> + <listitem><para>Takes a path to a disk image file or block device node. If specified all operations + are applied to file system in the indicated disk image. This is similar to <option>--root=</option> + but operates on file systems stored in disk images or block devices. The disk image should either + contain just a file system or a set of file systems within a GPT partition table, following the + <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>. For further information on supported disk images, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + switch of the same name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--locale=<replaceable>LOCALE</replaceable></option></term> + <term><option>--locale-messages=<replaceable>LOCALE</replaceable></option></term> + + <listitem><para>Sets the system locale, more specifically the + <varname>LANG=</varname> and <varname>LC_MESSAGES</varname> + settings. The argument should be a valid locale identifier, + such as <literal>de_DE.UTF-8</literal>. This controls the + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--keymap=<replaceable>KEYMAP</replaceable></option></term> + + <listitem><para>Sets the system keyboard layout. The argument should be a valid keyboard map, + such as <literal>de-latin1</literal>. This controls the <literal>KEYMAP</literal> entry in the + <citerefentry project='man-pages'><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--timezone=<replaceable>TIMEZONE</replaceable></option></term> + + <listitem><para>Sets the system time zone. The argument should + be a valid time zone identifier, such as + <literal>Europe/Berlin</literal>. This controls the + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry> + symlink.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--hostname=<replaceable>HOSTNAME</replaceable></option></term> + + <listitem><para>Sets the system hostname. The argument should + be a hostname, compatible with DNS. This controls the + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--machine-id=<replaceable>ID</replaceable></option></term> + + <listitem><para>Sets the system's machine ID. This controls + the + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root-password=<replaceable>PASSWORD</replaceable></option></term> + <term><option>--root-password-file=<replaceable>PATH</replaceable></option></term> + <term><option>--root-password-hashed=<replaceable>HASHED_PASSWORD</replaceable></option></term> + + <listitem><para>Sets the password of the system's root user. This creates/modifies the + <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry> and + <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry> + files. This setting exists in three forms: <option>--root-password=</option> accepts the password to + set directly on the command line, <option>--root-password-file=</option> reads it from a file and + <option>--root-password-hashed=</option> accepts an already hashed password on the command line. See + <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information on the format of the hashed password. Note that it is not recommended to specify + plaintext passwords on the command line, as other users might be able to see them simply by invoking + <citerefentry project='die-net'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root-shell=<replaceable>SHELL</replaceable></option></term> + + <listitem><para>Sets the shell of the system's root user. This creates/modifies the + <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry> + file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--kernel-command-line=<replaceable>CMDLINE</replaceable></option></term> + + <listitem><para>Sets the system's kernel command line. This controls the + <filename>/etc/kernel/cmdline</filename> file which is used by + <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--prompt-locale</option></term> + <term><option>--prompt-keymap</option></term> + <term><option>--prompt-timezone</option></term> + <term><option>--prompt-hostname</option></term> + <term><option>--prompt-root-password</option></term> + <term><option>--prompt-root-shell</option></term> + + <listitem><para>Prompt the user interactively for a specific + basic setting. Note that any explicit configuration settings + specified on the command line take precedence, and the user is + not prompted for it.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--prompt</option></term> + + <listitem><para>Query the user for locale, keymap, timezone, hostname, + root's password, and root's shell. This is equivalent to specifying + <option>--prompt-locale</option>, + <option>--prompt-keymap</option>, + <option>--prompt-timezone</option>, + <option>--prompt-hostname</option>, + <option>--prompt-root-password</option>, + <option>--prompt-root-shell</option> in combination.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--copy-locale</option></term> + <term><option>--copy-keymap</option></term> + <term><option>--copy-timezone</option></term> + <term><option>--copy-root-password</option></term> + <term><option>--copy-root-shell</option></term> + + <listitem><para>Copy a specific basic setting from the host. + This only works in combination with <option>--root=</option> + (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--copy</option></term> + + <listitem><para>Copy locale, keymap, time zone and root password from + the host. This is equivalent to specifying + <option>--copy-locale</option>, + <option>--copy-keymap</option>, + <option>--copy-timezone</option>, + <option>--copy-root-password</option>, + <option>--copy-root-shell</option> in combination.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--setup-machine-id</option></term> + + <listitem><para>Initialize the system's machine ID to a random + ID. This only works in combination with + <option>--root=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--force</option></term> + + <listitem><para>systemd-firstboot doesn't modify existing files unless <option>--force</option> + is specified. For modifications to <filename>/etc/passwd</filename> and + <filename>/etc/shadow</filename>, systemd-firstboot only modifies the entry of the + <literal>root</literal> user instead of overwriting the entire file.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--delete-root-password</option></term> + + <listitem><para>Removes the password of the system's root user, enabling login as root without a + password unless the root account is locked. Note that this is extremely insecure and hence this + option should not be used lightly.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--welcome=</option></term> + + <listitem><para>Takes a boolean argument. By default when prompting the user for configuration + options a brief welcome text is shown before the first question is asked. Pass false to this option + to turn off the welcome text.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.firstboot=</varname></term> + + <listitem><para>Takes a boolean argument, defaults to on. If off, <filename>systemd-firstboot.service</filename> + won't interactively query the user for basic settings at first boot, even if those settings are not + initialized yet.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-fsck@.service.xml b/man/systemd-fsck@.service.xml new file mode 100644 index 0000000..0353829 --- /dev/null +++ b/man/systemd-fsck@.service.xml @@ -0,0 +1,114 @@ +<?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-or-later --> +<refentry id="systemd-fsck@.service"> + + <refentryinfo> + <title>systemd-fsck@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-fsck@.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-fsck@.service</refname> + <refname>systemd-fsck-root.service</refname> + <refname>systemd-fsck</refname> + <refpurpose>File system checker logic</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-fsck@.service</filename></para> + <para><filename>systemd-fsck-root.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-fsck</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-fsck@.service</filename> and + <filename>systemd-fsck-root.service</filename> are services + responsible for file system checks. They are instantiated for each + device that is configured for file system checking. + <filename>systemd-fsck-root.service</filename> is responsible for + file system checks on the root file system, but only if the + root filesystem was not checked in the initramfs. + <filename>systemd-fsck@.service</filename> is used for all other + file systems and for the root file system in the initramfs.</para> + + <para>These services are started at boot if + <option>passno</option> in <filename>/etc/fstab</filename> for the + file system is set to a value greater than zero. The file system + check for root is performed before the other file systems. Other + file systems may be checked in parallel, except when they are on + the same rotating disk.</para> + + <para><filename>systemd-fsck</filename> does not know any details + about specific filesystems, and simply executes file system + checkers specific to each filesystem type + (<filename>/sbin/fsck.<replaceable>type</replaceable></filename>). These checkers will decide if + the filesystem should actually be checked based on the time since + last check, number of mounts, unclean unmount, etc.</para> + + <para>If a file system check fails for a service without + <option>nofail</option>, emergency mode is activated, by isolating + to <filename>emergency.target</filename>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-fsck</filename> understands these kernel + command line parameters:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>fsck.mode=</varname></term> + + <listitem><para>One of <literal>auto</literal>, + <literal>force</literal>, <literal>skip</literal>. Controls + the mode of operation. The default is <literal>auto</literal>, + and ensures that file system checks are done when the file + system checker deems them necessary. <literal>force</literal> + unconditionally results in full file system checks. + <literal>skip</literal> skips any file system + checks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>fsck.repair=</varname></term> + + <listitem><para>One of <literal>preen</literal>, + <literal>yes</literal>, <literal>no</literal>. Controls the + mode of operation. The default is <literal>preen</literal>, + and will automatically repair problems that can be safely + fixed. <literal>yes</literal> will answer yes to all + questions by fsck and <literal>no</literal> will answer no to + all questions. </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.cramfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.ext4</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.fat</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.hfsplus</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.minix</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.ntfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fsck.xfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml new file mode 100644 index 0000000..ec8f5c9 --- /dev/null +++ b/man/systemd-fstab-generator.xml @@ -0,0 +1,225 @@ +<?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-or-later --> +<refentry id="systemd-fstab-generator"> + + <refentryinfo> + <title>systemd-fstab-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-fstab-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-fstab-generator</refname> + <refpurpose>Unit generator for /etc/fstab</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-fstab-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-fstab-generator</filename> is a generator + that translates <filename>/etc/fstab</filename> (see + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details) into native systemd units early at boot and when + configuration of the system manager is reloaded. This will + instantiate mount and swap units as necessary.</para> + + <para>The <varname>passno</varname> field is treated like a simple + boolean, and the ordering information is discarded. However, if + the root file system is checked, it is checked before all the + other file systems.</para> + + <para>See + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information about special <filename>/etc/fstab</filename> + mount options this generator understands.</para> + + <para>One special topic is handling of symbolic links. Historical init + implementations supported symlinks in <filename>/etc/fstab</filename>. + Because mount units will refuse mounts where the target is a symbolic link, + this generator will resolve any symlinks as far as possible when processing + <filename>/etc/fstab</filename> in order to enhance backwards compatibility. + If a symlink target does not exist at the time that this generator runs, it + is assumed that the symlink target is the final target of the mount.</para> + + <para><filename>systemd-fstab-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-fstab-generator</filename> understands the + following kernel command line parameters:</para> + + <variablelist class='kernel-commandline-options'> + + <varlistentry> + <term><varname>fstab=</varname></term> + <term><varname>rd.fstab=</varname></term> + + <listitem><para>Takes a boolean argument. Defaults to + <literal>yes</literal>. If <literal>no</literal>, causes the + generator to ignore any mounts or swap devices configured in + <filename>/etc/fstab</filename>. <varname>rd.fstab=</varname> + is honored only by the initial RAM disk (initrd) while + <varname>fstab=</varname> is honored by both the main system + and the initrd.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>root=</varname></term> + + <listitem><para>Takes the root filesystem to mount in the + initrd. <varname>root=</varname> is honored by the + initrd.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>rootfstype=</varname></term> + + <listitem><para>Takes the root filesystem type that will be + passed to the mount command. <varname>rootfstype=</varname> is + honored by the initrd.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>rootflags=</varname></term> + + <listitem><para>Takes the root filesystem mount options to use. <varname>rootflags=</varname> is + honored by the initrd.</para> + + <para>Note that unlike most kernel command line options this setting does not override settings made + in configuration files (specifically: the mount option string in + <filename>/etc/fstab</filename>). See + <citerefentry><refentrytitle>systemd-remount-fs.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>mount.usr=</varname></term> + + <listitem><para>Takes the <filename>/usr/</filename> filesystem + to be mounted by the initrd. If + <varname>mount.usrfstype=</varname> or + <varname>mount.usrflags=</varname> is set, then + <varname>mount.usr=</varname> will default to the value set in + <varname>root=</varname>.</para> + + <para>Otherwise, this parameter defaults to the + <filename>/usr/</filename> entry found in + <filename>/etc/fstab</filename> on the root filesystem.</para> + + <para><varname>mount.usr=</varname> is honored by the initrd. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>mount.usrfstype=</varname></term> + + <listitem><para>Takes the <filename>/usr/</filename> filesystem + type that will be passed to the mount command. If + <varname>mount.usr=</varname> or + <varname>mount.usrflags=</varname> is set, then + <varname>mount.usrfstype=</varname> will default to the value + set in <varname>rootfstype=</varname>.</para> + + <para>Otherwise, this value will be read from the + <filename>/usr/</filename> entry in + <filename>/etc/fstab</filename> on the root filesystem.</para> + + <para><varname>mount.usrfstype=</varname> is honored by the + initrd.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>mount.usrflags=</varname></term> + + <listitem><para>Takes the <filename>/usr/</filename> filesystem + mount options to use. If <varname>mount.usr=</varname> or + <varname>mount.usrfstype=</varname> is set, then + <varname>mount.usrflags=</varname> will default to the value + set in <varname>rootflags=</varname>.</para> + + <para>Otherwise, this value will be read from the + <filename>/usr/</filename> entry in + <filename>/etc/fstab</filename> on the root filesystem.</para> + + <para><varname>mount.usrflags=</varname> is honored by the + initrd.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.volatile=</varname></term> + + <listitem><para>Controls whether the system shall boot up in volatile mode. Takes a boolean argument or the + special value <option>state</option>.</para> + + <para>If false (the default), this generator makes no changes to the mount tree and the system is booted up in + normal mode.</para> + + <para>If true the generator ensures + <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is run as part of the initial RAM disk ("initrd"). This service changes the mount table before transitioning to + the host system, so that a volatile memory file system (<literal>tmpfs</literal>) is used as root directory, + with only <filename>/usr/</filename> mounted into it from the configured root file system, in read-only + mode. This way the system operates in fully stateless mode, with all configuration and state reset at boot and + lost at shutdown, as <filename>/etc/</filename> and <filename>/var/</filename> will be served from the (initially + unpopulated) volatile memory file system.</para> + + <para>If set to <option>state</option> the generator will leave the root directory mount point unaltered, + however will mount a <literal>tmpfs</literal> file system to <filename>/var/</filename>. In this mode the normal + system configuration (i.e. the contents of <literal>/etc/</literal>) is in effect (and may be modified during + system runtime), however the system state (i.e. the contents of <literal>/var/</literal>) is reset at boot and + lost at shutdown.</para> + + <para>If this setting is set to <literal>overlay</literal> the root file system is set up as + <literal>overlayfs</literal> mount combining the read-only root directory with a writable + <literal>tmpfs</literal>, so that no modifications are made to disk, but the file system may be modified + nonetheless with all changes being lost at reboot.</para> + + <para>Note that in none of these modes the root directory, <filename>/etc/</filename>, <filename>/var/</filename> + or any other resources stored in the root file system are physically removed. It's thus safe to boot a system + that is normally operated in non-volatile mode temporarily into volatile mode, without losing data.</para> + + <para>Note that with the exception of <literal>overlay</literal> mode, enabling this setting will only work + correctly on operating systems that can boot up with only <filename>/usr/</filename> mounted, and are able to + automatically populate <filename>/etc/</filename>, and also <filename>/var/</filename> in case of + <literal>systemd.volatile=yes</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.swap</varname></term> + + <listitem><para>Takes a boolean argument or enables the option if specified + without an argument. If disabled, causes the generator to ignore + any swap devices configured in <filename>/etc/fstab</filename>. + Defaults to enabled.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-getty-generator.xml b/man/systemd-getty-generator.xml new file mode 100644 index 0000000..507a001 --- /dev/null +++ b/man/systemd-getty-generator.xml @@ -0,0 +1,64 @@ +<?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-or-later --> +<refentry id="systemd-getty-generator"> + + <refentryinfo> + <title>systemd-getty-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-getty-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-getty-generator</refname> + <refpurpose>Generator for enabling getty instances on the + console</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-getty-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-getty-generator</filename> is a generator that automatically instantiates + <filename>serial-getty@.service</filename> on the kernel console(s), if they can function as ttys and are + not provided by the virtual console subsystem. It will also instantiate + <filename>serial-getty@.service</filename> instances for virtualizer consoles, if execution in a + virtualized environment is detected. If execution in a container environment is detected, it will instead + enable <filename>console-getty.service</filename> for <filename>/dev/console</filename>, and + <filename>container-getty@.service</filename> instances for additional container pseudo TTYs as requested + by the container manager (see <ulink url="https://systemd.io/CONTAINER_INTERFACE"><filename>Container + Interface</filename></ulink>). This should ensure that the user is shown a login prompt at the right + place, regardless of which environment the system is started in. For example, it is sufficient to + redirect the kernel console with a kernel command line argument such as <varname>console=</varname> to + get both kernel messages and a getty prompt on a serial TTY. See <ulink + url="https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt"><filename>kernel-parameters.txt</filename></ulink> + for more information on the <varname>console=</varname> kernel parameter.</para> + + <para><filename>systemd-getty-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>Further information about configuration of gettys can be + found in + <ulink url="http://0pointer.de/blog/projects/serial-console.html">systemd + for Administrators, Part XVI: Gettys on Serial Consoles (and + Elsewhere)</ulink>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-gpt-auto-generator.xml b/man/systemd-gpt-auto-generator.xml new file mode 100644 index 0000000..4a21540 --- /dev/null +++ b/man/systemd-gpt-auto-generator.xml @@ -0,0 +1,304 @@ +<?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-or-later --> + +<refentry id="systemd-gpt-auto-generator" conditional='HAVE_BLKID'> + + <refentryinfo> + <title>systemd-gpt-auto-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-gpt-auto-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-gpt-auto-generator</refname> + <refpurpose>Generator for automatically discovering and mounting root, <filename>/home/</filename>, + <filename>/srv/</filename>, <filename>/var/</filename> and <filename>/var/tmp/</filename> partitions, as + well as discovering and enabling swap partitions, based on GPT partition type GUIDs</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-gpt-auto-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-gpt-auto-generator</filename> is a unit generator that automatically discovers + root, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, + <filename>/var/tmp/</filename>, the EFI System Partition, the Extended Boot Loader Partition and swap + partitions and creates mount and swap units for them, based on the partition type GUIDs of GUID partition + tables (GPT), see <ulink url="https://uefi.org/specifications">UEFI Specification</ulink>, chapter 5. It + implements the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>. Note that this generator has no effect on non-GPT systems, and on specific mount + points that are directories already containing files. Also, on systems where the units are explicitly + configured (for example, listed in <citerefentry + project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>), the + units this generator creates are overridden, but additional implicit dependencies might be + created.</para> + + <para>This generator will only look for the root partition on the same physical disk the EFI System + Partition (ESP) is located on. Note that support from the boot loader is required: the EFI variable + <varname>LoaderDevicePartUUID</varname> of the <constant>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</constant> + vendor UUID is used to determine from which partition, and hence the disk from which the system was + booted. If the boot loader does not set this variable, this generator will not be able to autodetect the + root partition. See the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader + Interface</ulink> for details.</para> + + <para>Similarly, this generator will only look for the other partitions on the same physical disk as the + root partition. In this case, boot loader support is not required. These partitions will not be searched + for on systems where the root file system is distributed on multiple disks, for example via btrfs RAID. + </para> + + <para><filename>systemd-gpt-auto-generator</filename> is useful for centralizing file system + configuration in the partition table and making configuration in <filename>/etc/fstab</filename> or on + the kernel command line unnecessary.</para> + + <para>This generator looks for the partitions based on their + partition type GUID. The following partition type GUIDs are + identified:</para> + + <table> + <title>Partition Type GUIDs</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="guid" /> + <colspec colname="name" /> + <colspec colname="where" /> + <colspec colname="explanation" /> + <thead> + <row> + <entry>Partition Type GUID</entry> + <entry>Name</entry> + <entry>Mount Point</entry> + <entry>Explanation</entry> + </row> + </thead> + <tbody> + <row> + <entry>44479540-f297-41b2-9af7-d131d5f0458a</entry> + <entry><filename>Root Partition (x86)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On 32-bit x86 systems, the first x86 root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</entry> + <entry><filename>Root Partition (x86-64)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On 64-bit x86 systems, the first x86-64 root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>69dad710-2ce4-4e3c-b16c-21a1d49abed3</entry> + <entry><filename>Root Partition (32-bit ARM)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On 32-bit ARM systems, the first ARM root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>b921b045-1df0-41c3-af44-4c6f280d3fae</entry> + <entry><filename>Root Partition (64-bit ARM)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On 64-bit ARM systems, the first ARM root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>993d8d3d-f80e-4225-855a-9daf8ed7ea97</entry> + <entry><filename>Root Partition (Itanium/IA-64)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On Itanium systems, the first Itanium root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>60d5a7fe-8e7d-435c-b714-3dd8162144e1</entry> + <entry><filename>Root Partition (RISCV-V 32)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On RISC-V 32-bit systems, the first RISCV-V 32-bit root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>72ec70a6-cf74-40e6-bd49-4bda08e8f224</entry> + <entry><filename>Root Partition (RISCV-V 64)</filename></entry> + <entry><filename>/</filename></entry> + <entry>On RISC-V 64-bit systems, the first RISCV-V 64-bit root partition on the disk the EFI ESP is located on is mounted to the root directory <filename>/</filename>.</entry> + </row> + <row> + <entry>933ac7e1-2eb4-4f13-b844-0e14e2aef915</entry> + <entry>Home Partition</entry> + <entry><filename>/home/</filename></entry> + <entry>The first home partition on the disk the root partition is located on is mounted to <filename>/home/</filename>.</entry> + </row> + <row> + <entry>3b8f8425-20e0-4f3b-907f-1a25a76f98e8</entry> + <entry>Server Data Partition</entry> + <entry><filename>/srv/</filename></entry> + <entry>The first server data partition on the disk the root partition is located on is mounted to <filename>/srv/</filename>.</entry> + </row> + <row> + <entry>4d21b016-b534-45c2-a9fb-5c16e091fd2d</entry> + <entry>Variable Data Partition</entry> + <entry><filename>/var/</filename></entry> + <entry>The first variable data partition on the disk the root partition is located on is mounted to <filename>/var/</filename> — under the condition its partition UUID matches the first 128 bit of the HMAC-SHA256 of the GPT type uuid of this partition keyed by the machine ID of the installation stored in <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry> + </row> + <row> + <entry>7ec6f557-3bc5-4aca-b293-16ef5df639d1</entry> + <entry>Temporary Data Partition</entry> + <entry><filename>/var/tmp/</filename></entry> + <entry>The first temporary data partition on the disk the root partition is located on is mounted to <filename>/var/tmp/</filename>.</entry> + </row> + <row> + <entry>0657fd6d-a4ab-43c4-84e5-0933c84b4f4f</entry> + <entry>Swap</entry> + <entry>n/a</entry> + <entry>All swap partitions located on the disk the root partition is located on are enabled.</entry> + </row> + <row> + <entry>c12a7328-f81f-11d2-ba4b-00a0c93ec93b</entry> + <entry>EFI System Partition (ESP)</entry> + <entry><filename>/efi/</filename> or <filename>/boot/</filename></entry> + <entry>The first ESP located on the disk the root partition is located on is mounted to <filename>/boot/</filename> or <filename>/efi/</filename>, see below.</entry> + </row> + <row> + <entry>bc13c2ff-59e6-4262-a352-b275fd6f7172</entry> + <entry>Extended Boot Loader Partition</entry> + <entry><filename>/boot/</filename></entry> + <entry>The first Extended Boot Loader Partition is mounted to <filename>/boot/</filename>, see below.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>This generator understands the following attribute flags for partitions:</para> + + <table> + <title>Partition Attributes</title> + <tgroup cols='4' align='left' colsep='1' rowsep='1'> + <colspec colname="attribute" /> + <colspec colname="value" /> + <colspec colname="where" /> + <colspec colname="explanation" /> + <thead> + <row> + <entry>Name</entry> + <entry>Value</entry> + <entry>Applicable to</entry> + <entry>Explanation</entry> + </row> + </thead> + <tbody> + <row> + <entry><constant>GPT_FLAG_READ_ONLY</constant></entry> + <entry>0x1000000000000000</entry> + <entry><filename>/</filename>, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, <filename>/var/tmp/</filename>, Extended Boot Loader Partition</entry> + <entry>Partition is mounted read-only</entry> + </row> + + <row> + <entry><constant>GPT_FLAG_NO_AUTO</constant></entry> + <entry>0x8000000000000000</entry> + <entry><filename>/</filename>, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, <filename>/var/tmp/</filename>, Extended Boot Loader Partition</entry> + <entry>Partition is not mounted automatically</entry> + </row> + + <row> + <entry><constant>GPT_FLAG_NO_BLOCK_IO_PROTOCOL</constant></entry> + <entry>0x0000000000000002</entry> + <entry>EFI System Partition (ESP)</entry> + <entry>Partition is not mounted automatically</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename> and + <filename>/var/tmp/</filename> partitions may be encrypted in LUKS format. In this case, a device mapper + device is set up under the names <filename>/dev/mapper/home</filename>, + <filename>/dev/mapper/srv</filename>, <filename>/dev/mapper/var</filename> and + <filename>/dev/mapper/tmp</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 + below), unless a mount point directory <filename>/efi/</filename> exists, in which case it is mounted + there. Since this generator creates an automount unit, the mount will only be activated on-demand, when + accessed. On systems where <filename>/boot/</filename> (or <filename>/efi/</filename> if it exists) is an + explicitly configured mount (for example, listed in <citerefentry + project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>) or where + the <filename>/boot/</filename> (or <filename>/efi/</filename>) mount point is non-empty, no mount units + are generated.</para> + + <para>If the disk contains an Extended Boot Loader partition, as defined in the <ulink + url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, it is made + available at <filename>/boot/</filename> (by means of an automount point, similar to the ESP, see + above). If both an EFI System Partition and an Extended Boot Loader partition exist the latter is + preferably mounted to <filename>/boot/</filename>. Make sure to create both <filename>/efi/</filename> + and <filename>/boot/</filename> to ensure both partitions are mounted.</para> + + <para>When using this generator in conjunction with btrfs file + systems, make sure to set the correct default subvolumes on them, + using <command>btrfs subvolume set-default</command>.</para> + + <para><filename>systemd-gpt-auto-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-gpt-auto-generator</filename> understands the following kernel command line + parameters:</para> + + <variablelist class='kernel-commandline-options'> + + <varlistentry> + <term><varname>systemd.gpt_auto</varname></term> + <term><varname>rd.systemd.gpt_auto</varname></term> + + <listitem><para>Those options take an optional boolean argument, and default to yes. + The generator is enabled by default, and a negative value may be used to disable it. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>root=</varname></term> + + <listitem><para>When used with the special value <literal>gpt-auto</literal>, automatic discovery of + the root partition based on the GPT partition type is enabled. Any other value disables this + generator.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>rw</varname></term> + <term><varname>ro</varname></term> + + <listitem><para>Mount the root partition read-write or read-only <emphasis>initially</emphasis>.</para> + + <para>Note that unlike most kernel command line options these settings do not override configuration + in the file system, and the file system may be remounted later. See + <citerefentry><refentrytitle>systemd-remount-fs.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-halt.service.xml b/man/systemd-halt.service.xml new file mode 100644 index 0000000..96072ae --- /dev/null +++ b/man/systemd-halt.service.xml @@ -0,0 +1,93 @@ +<?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-or-later --> + +<refentry id="systemd-halt.service"> + + <refentryinfo> + <title>systemd-halt.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-halt.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-halt.service</refname> + <refname>systemd-poweroff.service</refname> + <refname>systemd-reboot.service</refname> + <refname>systemd-kexec.service</refname> + <refname>systemd-shutdown</refname> + <refpurpose>System shutdown logic</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-halt.service</filename></para> + <para><filename>systemd-poweroff.service</filename></para> + <para><filename>systemd-reboot.service</filename></para> + <para><filename>systemd-kexec.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-shutdown</filename></para> + <para><filename>/usr/lib/systemd/system-shutdown/</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-halt.service</filename> is a system + service that is pulled in by <filename>halt.target</filename> and + is responsible for the actual system halt. Similarly, + <filename>systemd-poweroff.service</filename> is pulled in by + <filename>poweroff.target</filename>, + <filename>systemd-reboot.service</filename> by + <filename>reboot.target</filename> and + <filename>systemd-kexec.service</filename> by + <filename>kexec.target</filename> to execute the respective + actions.</para> + + <para>When these services are run, they ensure that PID 1 is + replaced by the + <filename>/usr/lib/systemd/systemd-shutdown</filename> tool which + is then responsible for the actual shutdown. Before shutting down, + this binary will try to unmount all remaining file systems, + disable all remaining swap devices, detach all remaining storage + devices and kill all remaining processes.</para> + + <para>It is necessary to have this code in a separate binary + because otherwise rebooting after an upgrade might be broken — the + running PID 1 could still depend on libraries which are not + available any more, thus keeping the file system busy, which then + cannot be re-mounted read-only.</para> + + <para>Immediately before executing the actual system + halt/poweroff/reboot/kexec <filename>systemd-shutdown</filename> + will run all executables in + <filename>/usr/lib/systemd/system-shutdown/</filename> and pass + one arguments to them: either <literal>halt</literal>, + <literal>poweroff</literal>, <literal>reboot</literal> or + <literal>kexec</literal>, depending on the chosen action. All + executables in this directory are executed in parallel, and + execution of the action is not continued before all executables + finished.</para> + + <para>Note that <filename>systemd-halt.service</filename> (and the + related units) should never be executed directly. Instead, trigger + system shutdown with a command such as <literal>systemctl + halt</literal> or suchlike.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-hibernate-resume-generator.xml b/man/systemd-hibernate-resume-generator.xml new file mode 100644 index 0000000..910fcae --- /dev/null +++ b/man/systemd-hibernate-resume-generator.xml @@ -0,0 +1,83 @@ +<?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-or-later --> +<refentry id="systemd-hibernate-resume-generator" conditional='ENABLE_HIBERNATE'> + + <refentryinfo> + <title>systemd-hibernate-resume-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-hibernate-resume-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-hibernate-resume-generator</refname> + <refpurpose>Unit generator for resume= kernel parameter</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-hibernate-resume-generator</command> is a + generator that initiates the procedure to resume the system from hibernation. + It instantiates the + <citerefentry><refentrytitle>systemd-hibernate-resume@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + unit according to the value of <option>resume=</option> parameter + specified on the kernel command line, which will instruct the kernel + to resume the system from the hibernation image on that device.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-hibernate-resume-generator</filename> + understands the following kernel command line parameters:</para> + + <variablelist class='kernel-commandline-options'> + + <varlistentry> + <term><varname>resume=</varname></term> + + <listitem><para>Takes a path to the resume device. Both + persistent block device paths like + <filename index="false">/dev/disk/by-foo/bar</filename> and + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-style + specifiers like <literal>FOO=bar</literal> are + supported.</para></listitem> + </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 + present, <varname>resume=</varname> is ignored.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate-resume@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-hibernate-resume@.service.xml b/man/systemd-hibernate-resume@.service.xml new file mode 100644 index 0000000..c460393 --- /dev/null +++ b/man/systemd-hibernate-resume@.service.xml @@ -0,0 +1,56 @@ +<?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-or-later --> +<refentry id="systemd-hibernate-resume@.service" conditional='ENABLE_HIBERNATE'> + + <refentryinfo> + <title>systemd-hibernate-resume@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-hibernate-resume@.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-hibernate-resume@.service</refname> + <refname>systemd-hibernate-resume</refname> + <refpurpose>Resume from hibernation</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-hibernate-resume@.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-hibernate-resume</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-hibernate-resume@.service</filename> + initiates the resume from hibernation. It is instantiated with the + device to resume from as the template argument.</para> + + <para><filename>systemd-hibernate-resume</filename> only supports + the in-kernel hibernation implementation, known as + <ulink url="https://www.kernel.org/doc/Documentation/power/swsusp.txt">swsusp</ulink>. + Internally, it works by writing the major:minor of specified + device node to <filename>/sys/power/resume</filename>.</para> + + <para>Failing to initiate a resume is not an error condition. It + may mean that there was no resume image (e. g. if the system has + been simply powered off and not hibernated). In such case, the + boot is ordinarily continued.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-homed.service.xml b/man/systemd-homed.service.xml new file mode 100644 index 0000000..2bc1dba --- /dev/null +++ b/man/systemd-homed.service.xml @@ -0,0 +1,110 @@ +<?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-or-later --> + +<refentry id="systemd-homed.service" conditional='ENABLE_HOMED'> + + <refentryinfo> + <title>systemd-homed.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-homed.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-homed.service</refname> + <refname>systemd-homed</refname> + <refpurpose>Home Area/User Account Manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-homed.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-homed</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-homed</command> is a system service that may be used to create, remove, change or + inspect home areas (directories and network mounts and real or loopback block devices with a filesystem, + optionally encrypted).</para> + + <para>Most of <command>systemd-homed</command>'s functionality is accessible through the + <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> command.</para> + + <para>See the <ulink url="https://systemd.io/HOME_DIRECTORY">Home Directories</ulink> documentation for + details about the format and design of home areas managed by + <filename>systemd-homed.service</filename>.</para> + + <para>Each home directory managed by <filename>systemd-homed.service</filename> synthesizes a local user + and group. These are made available to the system using the <ulink + url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>, and thus may be + browsed with + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Key Management</title> + + <para>User records are cryptographically signed with a public/private key pair (the signature is part of + the JSON record itself). For a user to be permitted to log in locally the public key matching the + signature of their user record must be installed. For a user record to be modified locally the private + key matching the signature must be installed locally, too. The keys are stored in the + <filename>/var/lib/systemd/home/</filename> directory:</para> + + <variablelist> + + <varlistentry> + <term><filename>/var/lib/systemd/home/local.private</filename></term> + + <listitem><para>The private key of the public/private key pair used for local records. Currently, + only a single such key may be installed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/lib/systemd/home/local.public</filename></term> + + <listitem><para>The public key of the public/private key pair used for local records. Currently, + only a single such key may be installed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/var/lib/systemd/home/*.public</filename></term> + + <listitem><para>Additional public keys. Any users whose user records are signed with any of these keys + are permitted to log in locally. An arbitrary number of keys may be installed this + way.</para></listitem> + </varlistentry> + </variablelist> + + <para>All key files listed above are in PEM format.</para> + + <para>In order to migrate a home directory from a host <literal>foobar</literal> to another host + <literal>quux</literal> it is hence sufficient to copy + <filename>/var/lib/systemd/home/local.public</filename> from the host <literal>foobar</literal> to + <literal>quux</literal>, maybe calling the file on the destination <filename + index="false">/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the + user record should be modifiable on <literal>quux</literal> the pair + <filename>/var/lib/systemd/home/local.public</filename> and + <filename>/var/lib/systemd/home/local.private</filename> need to be copied from <literal>foobar</literal> + to <literal>quux</literal>, and placed under the identical paths there, as currently only a single + private key is supported per host. Note of course that the latter means that user records + generated/signed before the key pair is copied in, lose their validity.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>pam_systemd_home</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>org.freedesktop.home1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-hostnamed.service.xml b/man/systemd-hostnamed.service.xml new file mode 100644 index 0000000..c0c46b6 --- /dev/null +++ b/man/systemd-hostnamed.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-or-later --> + +<refentry id="systemd-hostnamed.service" conditional='ENABLE_HOSTNAMED'> + + <refentryinfo> + <title>systemd-hostnamed.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-hostnamed.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-hostnamed.service</refname> + <refname>systemd-hostnamed</refname> + <refpurpose>Daemon to control system hostname from programs</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-hostnamed.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-hostnamed</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-hostnamed.service</filename> is a system service that may be used to change the + system's hostname and related machine metadata from user programs. It is automatically activated on + request and terminates itself when unused.</para> + + <para>It currently offers access to five variables: + <itemizedlist> + <listitem><para>The current hostname (Example: <literal>dhcp-192-168-47-11</literal>)</para> + </listitem> + + <listitem><para>The static (configured) hostname (Example: + <literal>lennarts-computer</literal>)</para></listitem> + + <listitem><para>The pretty hostname (Example: <literal>Lennart's Computer</literal>)</para> + </listitem> + + <listitem><para>A suitable icon name for the local host (Example: + <literal>computer-laptop</literal>)</para></listitem> + + <listitem><para>A chassis type (Example: <literal>tablet</literal>)</para> + </listitem> + </itemizedlist></para> + + <para>The tool + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + is a command line client to this service.</para> + + <para>See + <citerefentry><refentrytitle>org.freedesktop.hostname1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of the D-Bus API.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-hwdb.xml b/man/systemd-hwdb.xml new file mode 100644 index 0000000..70c052e --- /dev/null +++ b/man/systemd-hwdb.xml @@ -0,0 +1,84 @@ +<?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-or-later --> + +<refentry id="systemd-hwdb" conditional="ENABLE_HWDB" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-hwdb</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-hwdb</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-hwdb</refname><refpurpose>hardware database management tool</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-hwdb <optional>options</optional> update</command> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-hwdb <optional>options</optional> query <replaceable>modalias</replaceable></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1><title>Description</title> + <para><command>systemd-hwdb</command> expects a command and command + specific arguments. It manages the binary hardware database.</para> + </refsect1> + + <refsect1><title>Options</title> + <variablelist> + <varlistentry> + <term><option>--usr</option></term> + <listitem> + <para>Generate in /usr/lib/udev instead of /etc/udev.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-r</option></term> + <term><option>--root=<replaceable>PATH</replaceable></option></term> + <listitem> + <para>Alternate root path in the filesystem.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-s</option></term> + <term><option>--strict</option></term> + <listitem> + <para>When updating, return non-zero exit value on any parsing error.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + + <refsect2><title>systemd-hwdb + <arg choice="opt"><replaceable>options</replaceable></arg> + update</title> + <para>Update the binary database.</para> + </refsect2> + + <refsect2><title>systemd-hwdb + <arg choice="opt"><replaceable>options</replaceable></arg> + query + <arg><replaceable>MODALIAS</replaceable></arg> + </title> + <para>Query database and print result.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + <para><citerefentry> + <refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum> + </citerefentry></para> + </refsect1> +</refentry> diff --git a/man/systemd-id128.xml b/man/systemd-id128.xml new file mode 100644 index 0000000..21cbf16 --- /dev/null +++ b/man/systemd-id128.xml @@ -0,0 +1,136 @@ +<?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-or-later --> + +<refentry id="systemd-id128" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-id128</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-id128</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-id128</refname> + <refpurpose>Generate and print sd-128 identifiers</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-id128</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">new</arg> + </cmdsynopsis> + + <cmdsynopsis> + <command>systemd-id128</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">machine-id</arg> + </cmdsynopsis> + + <cmdsynopsis> + <command>systemd-id128</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">boot-id</arg> + </cmdsynopsis> + + <cmdsynopsis> + <command>systemd-id128</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">invocation-id</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>id128</command> may be used to conveniently print + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry> + UUIDs. What identifier is printed depends on the specific verb.</para> + + <para>With <command>new</command>, a new random identifier will be generated.</para> + + <para>With <command>machine-id</command>, the identifier of the current machine will be + printed. See + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>With <command>boot-id</command>, the identifier of the current boot will be + printed.</para> + + <para>Both <command>machine-id</command> and <command>boot-id</command> may be combined + with the <option>--app-specific=<replaceable>app-id</replaceable></option> switch to + generate application-specific IDs. See + <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for the discussion when this is useful.</para> + + <para>With <command>invocation-id</command>, the identifier of the current service invocation + will be printed. This is available in systemd services. See + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>With <command>show</command>, well-known UUIDs are printed. When no arguments are specified, all + known UUIDs are shown. When arguments are specified, they must be the names or values of one or more + known UUIDs, which are then printed.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-p</option></term> + <term><option>--pretty</option></term> + + <listitem><para>Generate output as programming language snippets.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-a <replaceable>app-id</replaceable></option></term> + <term><option>--app-specific=<replaceable>app-id</replaceable></option></term> + + <listitem><para>With this option, an identifier that is the result of hashing the + application identifier <replaceable>app-id</replaceable> and the machine identifier will be + printed. The <replaceable>app-id</replaceable> argument must be a valid sd-id128 string + identifying the application.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-u</option></term> + <term><option>--uuid</option></term> + + <listitem><para>Generate output as an UUID formatted in the "canonical representation", with five + groups of digits separated by hyphens. See the + <ulink url="https://en.wikipedia.org/wiki/Universally_unique_identifier#Format">wikipedia</ulink> + for more discussion.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-importd.service.xml b/man/systemd-importd.service.xml new file mode 100644 index 0000000..19cc69f --- /dev/null +++ b/man/systemd-importd.service.xml @@ -0,0 +1,56 @@ +<?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-or-later --> + +<refentry id="systemd-importd.service" conditional='ENABLE_IMPORTD'> + + <refentryinfo> + <title>systemd-importd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-importd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-importd.service</refname> + <refname>systemd-importd</refname> + <refpurpose>VM and container image import and export service</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-importd.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-importd</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-importd</command> is a system service that allows importing, exporting and downloading of + system images suitable for running as VM or containers. It is a companion service for + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, and provides the implementation for + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>pull-raw</command>, <command>pull-tar</command>, <command>import-raw</command>, + <command>import-tar</command>, <command>export-raw</command>, and <command>export-tar</command> commands.</para> + + <para>See + <citerefentry><refentrytitle>org.freedesktop.import1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of the D-Bus API.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-inhibit.xml b/man/systemd-inhibit.xml new file mode 100644 index 0000000..2fee0ed --- /dev/null +++ b/man/systemd-inhibit.xml @@ -0,0 +1,154 @@ +<?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-or-later --> + +<refentry id="systemd-inhibit" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-inhibit</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-inhibit</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-inhibit</refname> + <refpurpose>Execute a program with an inhibition lock taken</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-inhibit <arg choice="opt" rep="repeat">OPTIONS</arg> <arg>COMMAND</arg> <arg choice="opt" rep="repeat">ARGUMENTS</arg></command> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-inhibit <arg choice="opt" rep="repeat">OPTIONS</arg> --list</command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-inhibit</command> may be used to execute a + program with a shutdown, sleep, or idle inhibitor lock taken. The + lock will be acquired before the specified command line is + executed and released afterwards.</para> + + <para>Inhibitor locks may be used to block or delay system sleep + and shutdown requests from the user, as well as automatic idle + handling of the OS. This is useful to avoid system suspends while + an optical disc is being recorded, or similar operations that + should not be interrupted.</para> + + <para>For more information see the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor + Lock Developer Documentation</ulink>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--what=</option></term> + + <listitem><para>Takes a colon-separated list of one or more + operations to inhibit: + <literal>shutdown</literal>, + <literal>sleep</literal>, + <literal>idle</literal>, + <literal>handle-power-key</literal>, + <literal>handle-suspend-key</literal>, + <literal>handle-hibernate-key</literal>, + <literal>handle-lid-switch</literal>, + for inhibiting reboot/power-off/halt/kexec, + suspending/hibernating, the automatic idle detection, or the + low-level handling of the power/sleep key and the lid switch, + respectively. If omitted, defaults to + <literal>idle:sleep:shutdown</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--who=</option></term> + + <listitem><para>Takes a short, human-readable descriptive + string for the program taking the lock. If not passed, + defaults to the command line string.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--why=</option></term> + + <listitem><para>Takes a short, human-readable descriptive + string for the reason for taking the lock. Defaults to + "Unknown reason".</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--mode=</option></term> + + <listitem><para>Takes either <literal>block</literal> or + <literal>delay</literal> and describes how the lock is + applied. If <literal>block</literal> is used (the default), + the lock prohibits any of the requested operations without + time limit, and only privileged users may override it. If + <literal>delay</literal> is used, the lock can only delay the + requested operations for a limited time. If the time elapses, + the lock is ignored and the operation executed. The time limit + may be specified in + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Note that <literal>delay</literal> is only available for + <literal>sleep</literal> and + <literal>shutdown</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--list</option></term> + + <listitem><para>Lists all active inhibition locks instead of + acquiring one.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>Returns the exit status of the executed program.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <programlisting># systemd-inhibit wodim foobar.iso</programlisting> + + <para>This burns the ISO image + <filename>foobar.iso</filename> on a CD using + <citerefentry project='man-pages'><refentrytitle>wodim</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + and inhibits system sleeping, shutdown and idle while + doing so.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-initctl.service.xml b/man/systemd-initctl.service.xml new file mode 100644 index 0000000..b435800 --- /dev/null +++ b/man/systemd-initctl.service.xml @@ -0,0 +1,49 @@ +<?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-or-later --> + +<refentry id="systemd-initctl.service" conditional='HAVE_SYSV_COMPAT'> + + <refentryinfo> + <title>systemd-initctl.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-initctl.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-initctl.service</refname> + <refname>systemd-initctl.socket</refname> + <refname>systemd-initctl</refname> + <refpurpose>/dev/initctl compatibility</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-initctl.service</filename></para> + <para><filename>systemd-initctl.socket</filename></para> + <para><filename>/usr/lib/systemd/systemd-initctl</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-initctl</filename> is a system service + that implements compatibility with the + <filename>/dev/initctl</filename> FIFO file system object, as + implemented by the SysV init system. + <filename>systemd-initctl</filename> is automatically activated on + request and terminates itself when it is unused.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-journal-gatewayd.service.xml b/man/systemd-journal-gatewayd.service.xml new file mode 100644 index 0000000..43ceb97 --- /dev/null +++ b/man/systemd-journal-gatewayd.service.xml @@ -0,0 +1,293 @@ +<?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-or-later --> + +<refentry id="systemd-journal-gatewayd.service" conditional='HAVE_MICROHTTPD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-journal-gatewayd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-journal-gatewayd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-journal-gatewayd.service</refname> + <refname>systemd-journal-gatewayd.socket</refname> + <refname>systemd-journal-gatewayd</refname> + <refpurpose>HTTP server for journal events</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-journal-gatewayd.service</filename></para> + <para><filename>systemd-journal-gatewayd.socket</filename></para> + <cmdsynopsis> + <command>/usr/lib/systemd/systemd-journal-gatewayd</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-journal-gatewayd</command> serves journal + events over the network. Clients must connect using + HTTP. The server listens on port 19531 by default. + If <option>--cert=</option> is specified, the server expects + HTTPS connections.</para> + + <para>The program is started by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and expects to receive a single socket. Use + <command>systemctl start systemd-journal-gatewayd.socket</command> to start + the service, and <command>systemctl enable systemd-journal-gatewayd.socket</command> + to have it started on boot.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--cert=</option></term> + + <listitem><para>Specify the path to a file or <constant>AF_UNIX</constant> stream socket to read the + server certificate from. The certificate must be in PEM format. This option switches + <command>systemd-journal-gatewayd</command> into HTTPS mode and must be used together with + <option>--key=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--key=</option></term> + + <listitem><para>Specify the path to a file or <constant>AF_UNIX</constant> stream socket to read the + secret server key corresponding to the certificate specified with <option>--cert=</option> from. The + key must be in PEM format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--trust=</option></term> + + <listitem><para>Specify the path to a file or <constant>AF_UNIX</constant> stream socket to read a CA + certificate from. The certificate must be in PEM format.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-D <replaceable>DIR</replaceable></option></term> + <term><option>--directory=<replaceable>DIR</replaceable></option></term> + + <listitem><para>Takes a directory path as argument. If + specified, <command>systemd-journal-gatewayd</command> will serve the + specified journal directory <replaceable>DIR</replaceable> instead of + the default runtime and system journal paths.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Supported URLs</title> + + <para>The following URLs are recognized:</para> + + <variablelist> + <varlistentry> + <term><uri>/browse</uri></term> + + <listitem><para>Interactive browsing.</para></listitem> + </varlistentry> + + <varlistentry> + <term><uri>/entries[?option1&option2=value…]</uri></term> + + <listitem><para>Retrieval of events in various formats.</para> + + <para>The <option>Accept:</option> part of the HTTP header + determines the format. Supported values are described below. + </para> + + <para>The <option>Range:</option> part of the HTTP header + determines the range of events returned. Supported values are + described below. + </para> + + <para>GET parameters can be used to modify what events are + returned. Supported parameters are described below.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><uri>/machine</uri></term> + + <listitem><para>Return a JSON structure describing the machine.</para> + + <para>Example: + <programlisting>{ "machine_id" : "8cf7ed9d451ea194b77a9f118f3dc446", + "boot_id" : "3d3c9efaf556496a9b04259ee35df7f7", + "hostname" : "fedora", + "os_pretty_name" : "Fedora 19 (Rawhide)", + "virtualization" : "kvm", + …}</programlisting> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><uri>/fields/<replaceable>FIELD_NAME</replaceable></uri></term> + + <listitem><para>Return a list of values of this field present in the logs.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Accept header</title> + + <para> + <option>Accept: <replaceable>format</replaceable></option> + </para> + + <para>Recognized formats:</para> + + <variablelist> + <varlistentry> + <term><constant>text/plain</constant></term> + + <listitem><para>The default. Plaintext syslog-like output, + one line per journal entry + (like <command>journalctl --output short</command>).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>application/json</constant></term> + + <listitem><para>Entries are formatted as JSON data structures, + one per line + (like <command>journalctl --output json</command>). + See <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/json">Journal + JSON Format</ulink> for more information.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>text/event-stream</constant></term> + + <listitem><para>Entries are formatted as JSON data structures, + wrapped in a format suitable for <ulink + url="https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events"> + Server-Sent Events</ulink> + (like <command>journalctl --output json-sse</command>). + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>application/vnd.fdo.journal</constant></term> + + <listitem><para>Entries are serialized into a binary (but + mostly text-based) stream suitable for backups and network + transfer + (like <command>journalctl --output export</command>). + See <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal + Export Format</ulink> for more information.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Range header</title> + + <para> + <option>Range: entries=<replaceable>cursor</replaceable>[[:<replaceable>num_skip</replaceable>]:<replaceable>num_entries</replaceable>]</option> + </para> + + <para>where + <replaceable>cursor</replaceable> is a cursor string, + <replaceable>num_skip</replaceable> is an integer, + <replaceable>num_entries</replaceable> is an unsigned integer. + </para> + + <para>Range defaults to all available events.</para> + </refsect1> + + <refsect1> + <title>URL GET parameters</title> + + <para>Following parameters can be used as part of the URL:</para> + + <variablelist> + <varlistentry> + <term><uri>follow</uri></term> + + <listitem><para>wait for new events + (like <command>journalctl --follow</command>, except that + the number of events returned is not limited).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><uri>discrete</uri></term> + + <listitem><para>Test that the specified cursor refers to an + entry in the journal. Returns just this entry.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><uri>boot</uri></term> + + <listitem><para>Limit events to the current boot of the system + (like <command>journalctl -b</command>).</para></listitem> + </varlistentry> + + <varlistentry> + <term><uri><replaceable>KEY</replaceable>=<replaceable>match</replaceable></uri></term> + + <listitem><para>Match journal fields. See + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + <para>Retrieve events from this boot from local journal + in <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal + Export Format</ulink>: + <programlisting>curl --silent -H'Accept: application/vnd.fdo.journal' \ + 'http://localhost:19531/entries?boot'</programlisting> + </para> + + <para>Listen for core dumps: + <programlisting>curl 'http://localhost:19531/entries?follow&MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1'</programlisting></para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-journal-remote.service.xml b/man/systemd-journal-remote.service.xml new file mode 100644 index 0000000..bea0936 --- /dev/null +++ b/man/systemd-journal-remote.service.xml @@ -0,0 +1,346 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd-journal-remote" conditional='HAVE_MICROHTTPD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-journal-remote.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-journal-remote.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-journal-remote.service</refname> + <refname>systemd-journal-remote.socket</refname> + <refname>systemd-journal-remote</refname> + <refpurpose>Receive journal messages over the network</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-journal-remote.service</filename></para> + <para><filename>systemd-journal-remote.socket</filename></para> + <cmdsynopsis> + <command>/usr/lib/systemd/systemd-journal-remote</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="norepeat">-o/--output=<replaceable>DIR</replaceable>|<replaceable>FILE</replaceable></arg> + <arg choice="opt" rep="repeat">SOURCES</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-journal-remote</command> is a command to receive serialized journal + events and store them to journal files. Input streams are in the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal Export Format</ulink>, + i.e. like the output from <command>journalctl --output=export</command>. For transport over the + network, this serialized stream is usually carried over an HTTPS connection.</para> + + <para><filename>systemd-journal-remote.service</filename> is a system service that uses + <command>systemd-journal-remote</command> to listen for connections. + <filename>systemd-journal-remote.socket</filename> configures the network address that + <filename>systemd-journal-remote.service</filename> listens on. By default this is port 19532. + What connections are accepted and how the received data is stored can be configured through the + <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration file.</para> + </refsect1> + + <refsect1> + <title>Sources</title> + + <para> + Sources can be either "active" + (<command>systemd-journal-remote</command> requests and pulls + the data), or "passive" + (<command>systemd-journal-remote</command> waits for a + connection and then receives events pushed by the other side). + </para> + + <para> + <command>systemd-journal-remote</command> can read more than one + event stream at a time. They will be interleaved in the output + file. In case of "active" connections, each "source" is one + stream, and in case of "passive" connections, each connection can + result in a separate stream. Sockets can be configured in + "accept" mode (i.e. only one connection), or "listen" mode (i.e. + multiple connections, each resulting in a stream). + </para> + + <para> + When there are no more connections, and no more can be created + (there are no listening sockets), then + <command>systemd-journal-remote</command> will exit. + </para> + + <para>Active sources can be specified in the following + ways:</para> + + <variablelist> + <varlistentry> + <term><arg choice="opt" rep="repeat">SOURCES</arg></term> + + <listitem><para>When <option>-</option> is given as a + positional argument, events will be read from standard input. + Other positional arguments will be treated as filenames + to open and read from.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--url=<replaceable>ADDRESS</replaceable></option></term> + + <listitem><para>With the + <option>--url=<replaceable>ADDRESS</replaceable></option> option, + events will be retrieved using HTTP from + <replaceable>ADDRESS</replaceable>. This URL should refer to the + root of a remote + <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + instance, e.g. http://some.host:19531/ or + https://some.host:19531/.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--getter='<replaceable>PROG</replaceable> <arg choice="opt" rep="repeat">OPTIONS</arg>'</option></term> + + <listitem><para>Program to invoke to retrieve data. The journal + event stream must be generated on standard output.</para> + + <para>Examples:</para> + + <programlisting>--getter='curl "-HAccept: application/vnd.fdo.journal" https://some.host:19531/'</programlisting> + + <programlisting>--getter='wget --header="Accept: application/vnd.fdo.journal" -O- https://some.host:19531/'</programlisting> + </listitem> + </varlistentry> + </variablelist> + + <para>Passive sources can be specified in the following + ways:</para> + + <variablelist> + <varlistentry> + <term><option>--listen-raw=<replaceable>ADDRESS</replaceable></option></term> + + <listitem><para><replaceable>ADDRESS</replaceable> must be an + address suitable for <option>ListenStream=</option> (cf. + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + <command>systemd-journal-remote</command> will listen on this + socket for connections. Each connection is expected to be a + stream of journal events.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--listen-http=<replaceable>ADDRESS</replaceable></option></term> + <term><option>--listen-https=<replaceable>ADDRESS</replaceable></option></term> + + <listitem><para><replaceable>ADDRESS</replaceable> must be + either a negative integer, in which case it will be + interpreted as the (negated) file descriptor number, or an + address suitable for <option>ListenStream=</option> (c.f. + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + In the first case, the server listens on port 19532 by default, + and the matching file descriptor must be inherited through + <varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname>. + In the second case, an HTTP or HTTPS server will be spawned on + this port, respectively for <option>--listen-http=</option> and + <option>--listen-https=</option>. Currently, only POST requests + to <filename>/upload</filename> with <literal>Content-Type: + application/vnd.fdo.journal</literal> are supported.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>$LISTEN_FDS</varname></term> + + <listitem><para><command>systemd-journal-remote</command> + supports the + <varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname> + protocol. Open sockets inherited through socket activation + behave like those opened with <option>--listen-raw=</option> + described above, unless they are specified as an argument in + <option>--listen-http=-<replaceable>n</replaceable></option> + or + <option>--listen-https=-<replaceable>n</replaceable></option> + above. In the latter case, an HTTP or HTTPS server will be + spawned using this descriptor and connections must be made + over the HTTP protocol.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--key=</option></term> + + <listitem><para>Takes a path to a SSL secret key file in PEM format. Defaults to + <filename>&CERTIFICATE_ROOT;/private/journal-remote.pem</filename>. This option can be used with + <option>--listen-https=</option>. If the path refers to an <constant>AF_UNIX</constant> stream socket + in the file system a connection is made to it and the key read from it.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cert=</option></term> + + <listitem><para> Takes a path to a SSL certificate file in PEM format. Defaults to + <filename>&CERTIFICATE_ROOT;/certs/journal-remote.pem</filename>. This option can be used with + <option>--listen-https=</option>. If the path refers to an <constant>AF_UNIX</constant> stream socket + in the file system a connection is made to it and the certificate read from it.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--trust=</option></term> + + <listitem><para> Takes a path to a SSL CA certificate file in PEM format, or <option>all</option>. If + <option>all</option> is set, then certificate checking will be disabled. Defaults to + <filename>&CERTIFICATE_ROOT;/ca/trusted.pem</filename>. This option can be used with + <option>--listen-https=</option>. If the path refers to an <constant>AF_UNIX</constant> stream socket + in the file system a connection is made to it and the certificate read from it.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--gnutls-log=</option></term> + + <listitem><para> + Takes a comma separated list of gnutls logging categories. + This option can be used with <option>--listen-http=</option> or + <option>--listen-https=</option>. + </para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Sinks</title> + + <para>The location of the output journal can be specified + with <option>-o</option> or <option>--output=</option>. + </para> + + <variablelist> + <varlistentry> + <term><option>--output=<replaceable>FILE</replaceable></option></term> + + <listitem><para>Will write to this journal file. The filename + must end with <filename>.journal</filename>. The file will be + created if it does not exist. If necessary (journal file full, + or corrupted), the file will be renamed following normal + journald rules and a new journal file will be created in its + stead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--output=<replaceable>DIR</replaceable></option></term> + + <listitem><para>Will create journal files underneath directory + <replaceable>DIR</replaceable>. The directory must exist. If + necessary (journal files over size, or corrupted), journal + files will be rotated following normal journald rules. Names + of files underneath <replaceable>DIR</replaceable> will be + generated using the rules described below.</para></listitem> + </varlistentry> + </variablelist> + + <para>If <option>--output=</option> is not used, the output + directory <filename>/var/log/journal/remote/</filename> will be + used. In case the output file is not specified, journal files + will be created underneath the selected directory. Files will be + called + <filename>remote-<replaceable>hostname</replaceable>.journal</filename>, + where the <replaceable>hostname</replaceable> part is the + escaped hostname of the source endpoint of the connection, or the + numerical address if the hostname cannot be determined.</para> + + <para>In the case that "active" sources are given by the positional + arguments or <option>--getter=</option> option, the output file name + must always be given explicitly.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--split-mode</option></term> + + <listitem><para>One of <constant>none</constant> or + <constant>host</constant>. For the first, only one output + journal file is used. For the latter, a separate output file + is used, based on the hostname of the other endpoint of a + connection.</para> + + <para>In the case that "active" sources are given by the positional + arguments or <option>--getter=</option> option, the output file name must + always be given explicitly and only <constant>none</constant> + is allowed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--compress</option> [<replaceable>BOOL</replaceable>]</term> + + <listitem><para>If this is set to <literal>yes</literal> then compress + the data in the journal using XZ. The default is <literal>yes</literal>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--seal</option> [<replaceable>BOOL</replaceable>]</term> + + <listitem><para>If this is set to <literal>yes</literal> then + periodically sign the data in the journal using Forward Secure Sealing. + The default is <literal>no</literal>.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + <para>Copy local journal events to a different journal directory: + <programlisting> +journalctl -o export | systemd-journal-remote -o /tmp/dir/foo.journal - + </programlisting> + </para> + + <para>Retrieve all available events from a remote + <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + instance and store them in + <filename>/var/log/journal/remote/remote-some.host.journal</filename>: + <programlisting> +systemd-journal-remote --url http://some.host:19531/ + </programlisting> + </para> + + <para>Retrieve current boot events and wait for new events from a remote + <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + instance, and store them in + <filename>/var/log/journal/remote/remote-some.host.journal</filename>: + <programlisting> +systemd-journal-remote --url http://some.host:19531/entries?boot&follow + </programlisting> + </para> +</refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-gatewayd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-journal-upload.service.xml b/man/systemd-journal-upload.service.xml new file mode 100644 index 0000000..e2b39bf --- /dev/null +++ b/man/systemd-journal-upload.service.xml @@ -0,0 +1,289 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd-journal-upload" conditional='HAVE_MICROHTTPD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-journal-upload.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-journal-upload.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-journal-upload.service</refname> + <refname>systemd-journal-upload</refname> + <refpurpose>Send journal messages over the network</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-journal-upload.service</filename></para> + <cmdsynopsis> + <command>/usr/lib/systemd/systemd-journal-upload</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="norepeat">-u/--url=<replaceable>URL</replaceable></arg> + <arg choice="opt" rep="repeat">SOURCES</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-journal-upload</command> will upload journal entries to the URL specified + with <option>--url=</option>. This program reads journal entries from one or more journal files, + similarly to + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + Unless limited by one of the options specified below, all journal entries accessible to the user + the program is running as will be uploaded, and then the program will wait and send new entries + as they become available.</para> + + <para><filename>systemd-journal-upload.service</filename> is a system service that uses + <command>systemd-journal-upload</command> to upload journal entries to a server. It uses the + configuration in + <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + At least the <varname>URL=</varname> option must be specified.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <variablelist> + <varlistentry> + <term><option>-u</option></term> + <term><option>--url=<optional>https://</optional><replaceable>URL</replaceable>[:<replaceable>PORT</replaceable>]</option></term> + <term><option>--url=<optional>http://</optional><replaceable>URL</replaceable>[:<replaceable>PORT</replaceable>]</option></term> + + <listitem><para>Upload to the specified + address. <replaceable>URL</replaceable> may specify either + just the hostname or both the protocol and + hostname. <constant>https</constant> is the default. + The port number may be specified after a colon (<literal>:</literal>), + otherwise <constant>19532</constant> will be used by default. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--system</option></term> + <term><option>--user</option></term> + + <listitem><para>Limit uploaded entries to entries from system + services and the kernel, or to entries from services of + current user. This has the same meaning as + <option>--system</option> and <option>--user</option> options + for + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If + neither is specified, all accessible entries are uploaded. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-m</option></term> + <term><option>--merge</option></term> + + <listitem><para>Upload entries interleaved from all available + journals, including other machines. This has the same meaning + as <option>--merge</option> option for + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-D</option></term> + <term><option>--directory=<replaceable>DIR</replaceable></option></term> + + <listitem><para>Takes a directory path as argument. Upload + entries from the specified journal directory + <replaceable>DIR</replaceable> instead of the default runtime + and system journal paths. This has the same meaning as + <option>--directory=</option> option for + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--file=<replaceable>GLOB</replaceable></option></term> + + <listitem><para>Takes a file glob as an argument. Upload + entries from the specified journal files matching + <replaceable>GLOB</replaceable> instead of the default runtime + and system journal paths. May be specified multiple times, in + which case files will be suitably interleaved. This has the same meaning as + <option>--file=</option> option for + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cursor=</option></term> + + <listitem><para>Upload entries from the location in the + journal specified by the passed cursor. This has the same + meaning as <option>--cursor=</option> option for + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--after-cursor=</option></term> + + <listitem><para>Upload entries from the location in the + journal <emphasis>after</emphasis> the location specified by + the this cursor. This has the same meaning as + <option>--after-cursor=</option> option for + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--save-state</option><optional>=<replaceable>PATH</replaceable></optional></term> + + <listitem><para>Upload entries from the location in the + journal <emphasis>after</emphasis> the location specified by + the cursor saved in file at <replaceable>PATH</replaceable> + (<filename>/var/lib/systemd/journal-upload/state</filename> by default). + After an entry is successfully uploaded, update this file + with the cursor of that entry. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--follow</option><optional>=<replaceable>BOOL</replaceable></optional></term> + + <listitem><para> + If set to yes, then <command>systemd-journal-upload</command> waits for input. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--key=</option></term> + + <listitem><para> + Takes a path to a SSL key file in PEM format, or <option>-</option>. + If <option>-</option> is set, then client certificate authentication checking + will be disabled. + Defaults to <filename>&CERTIFICATE_ROOT;/private/journal-upload.pem</filename>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cert=</option></term> + + <listitem><para> + Takes a path to a SSL certificate file in PEM format, or <option>-</option>. + If <option>-</option> is set, then client certificate authentication checking + will be disabled. + Defaults to <filename>&CERTIFICATE_ROOT;/certs/journal-upload.pem</filename>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--trust=</option></term> + + <listitem><para> + Takes a path to a SSL CA certificate file in PEM format, or <option>-</option>/<option>all</option>. + If <option>-</option>/<option>all</option> is set, then certificate checking will be disabled. + Defaults to <filename>&CERTIFICATE_ROOT;/ca/trusted.pem</filename>. + </para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned; otherwise, a non-zero + failure code is returned.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>Setting up certificates for authentication</title> + + <para>Certificates signed by a trusted authority are used to + verify that the server to which messages are uploaded is + legitimate, and vice versa, that the client is trusted.</para> + + <para>A suitable set of certificates can be generated with + <command>openssl</command>. Note, 2048 bits of key length + is minimally recommended to use for security reasons:</para> + + <programlisting>openssl req -newkey rsa:2048 -days 3650 -x509 -nodes \ + -out ca.pem -keyout ca.key -subj '/CN=Certificate authority/' + +cat >ca.conf <<EOF +[ ca ] +default_ca = this + +[ this ] +new_certs_dir = . +certificate = ca.pem +database = ./index +private_key = ca.key +serial = ./serial +default_days = 3650 +default_md = default +policy = policy_anything + +[ policy_anything ] +countryName = optional +stateOrProvinceName = optional +localityName = optional +organizationName = optional +organizationalUnitName = optional +commonName = supplied +emailAddress = optional +EOF + +touch index +echo 0001 >serial + +SERVER=server +CLIENT=client + +openssl req -newkey rsa:2048 -nodes -out $SERVER.csr -keyout $SERVER.key -subj "/CN=$SERVER/" +openssl ca -batch -config ca.conf -notext -in $SERVER.csr -out $SERVER.pem + +openssl req -newkey rsa:2048 -nodes -out $CLIENT.csr -keyout $CLIENT.key -subj "/CN=$CLIENT/" +openssl ca -batch -config ca.conf -notext -in $CLIENT.csr -out $CLIENT.pem +</programlisting> + + <para>Generated files <filename>ca.pem</filename>, + <filename>server.pem</filename>, and + <filename>server.key</filename> should be installed on server, + and <filename>ca.pem</filename>, + <filename>client.pem</filename>, and + <filename>client.key</filename> on the client. The location of + those files can be specified using + <varname>TrustedCertificateFile=</varname>, + <varname>ServerCertificateFile=</varname>, + and <varname>ServerKeyFile=</varname> in + <filename>/etc/systemd/journal-remote.conf</filename> and + <filename>/etc/systemd/journal-upload.conf</filename>, + respectively. The default locations can be queried by using + <command>systemd-journal-remote --help</command> and + <command>systemd-journal-upload --help</command>.</para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journal-gatewayd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml new file mode 100644 index 0000000..35cfbde --- /dev/null +++ b/man/systemd-journald.service.xml @@ -0,0 +1,351 @@ +<?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-or-later --> + +<refentry id="systemd-journald.service"> + + <refentryinfo> + <title>systemd-journald.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-journald.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-journald.service</refname> + <refname>systemd-journald.socket</refname> + <refname>systemd-journald-dev-log.socket</refname> + <refname>systemd-journald-audit.socket</refname> + <refname>systemd-journald@.service</refname> + <refname>systemd-journald@.socket</refname> + <refname>systemd-journald-varlink@.socket</refname> + <refname>systemd-journald</refname> + <refpurpose>Journal service</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-journald.service</filename></para> + <para><filename>systemd-journald.socket</filename></para> + <para><filename>systemd-journald-dev-log.socket</filename></para> + <para><filename>systemd-journald-audit.socket</filename></para> + <para><filename>systemd-journald@.service</filename></para> + <para><filename>systemd-journald@.socket</filename></para> + <para><filename>systemd-journald-varlink@.socket</filename></para> + <para><filename>/usr/lib/systemd/systemd-journald</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-journald</filename> is a system service + that collects and stores logging data. It creates and maintains + structured, indexed journals based on logging information that is + received from a variety of sources:</para> + + <itemizedlist> + <listitem><para>Kernel log messages, via kmsg</para></listitem> + + <listitem><para>Simple system log messages, via the <filename>libc</filename> <citerefentry + project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call</para></listitem> + + <listitem><para>Structured system log messages via the native + Journal API, see + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry></para></listitem> + + <listitem><para>Standard output and standard error of service units. For further details see + below.</para></listitem> + + <listitem><para>Audit records, originating from the kernel audit subsystem</para></listitem> + </itemizedlist> + + <para>The daemon will implicitly collect numerous metadata fields + for each log messages in a secure and unfakeable way. See + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information about the collected metadata. + </para> + + <para>Log data collected by the journal is primarily text-based but can also include binary data where + necessary. Individual fields making up a log record stored in the journal may be up to 2^64-1 bytes in size.</para> + + <para>The journal service stores log data either persistently below <filename>/var/log/journal</filename> or in a + volatile way below <filename>/run/log/journal/</filename> (in the latter case it is lost at reboot). By default, log + data is stored persistently if <filename>/var/log/journal/</filename> exists during boot, with an implicit fallback + to volatile storage otherwise. Use <varname>Storage=</varname> in + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> to configure + where log data is placed, independently of the existence of <filename>/var/log/journal/</filename>.</para> + + <para>On systems where <filename>/var/log/journal/</filename> does not exist yet but where persistent logging is + desired (and the default <filename>journald.conf</filename> is used), it is sufficient to create the directory, and + ensure it has the correct access modes and ownership:</para> + + <programlisting>mkdir -p /var/log/journal +systemd-tmpfiles --create --prefix /var/log/journal</programlisting> + + <para>See + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the configuration of this service.</para> + </refsect1> + + <refsect1> + <title>Stream logging</title> + + <para>The systemd service manager invokes all service processes with standard output and standard error connected + to the journal by default. This behaviour may be altered via the + <varname>StandardOutput=</varname>/<varname>StandardError=</varname> unit file settings, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. The + journal converts the log byte stream received this way into individual log records, splitting the stream at newline + (<literal>\n</literal>, ASCII <constant>10</constant>) and <constant>NUL</constant> bytes.</para> + + <para>If <filename>systemd-journald.service</filename> is stopped, the stream connections associated with all + services are terminated. Further writes to those streams by the service will result in <constant>EPIPE</constant> + errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error + ignore such errors. If the <constant>SIGPIPE</constant> UNIX signal handler is not blocked or turned off, such + write attempts will also result in such process signals being generated, see + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + To mitigate this issue, systemd service manager explicitly turns off the <constant>SIGPIPE</constant> + signal for all invoked processes by default (this may be changed for each unit individually via the + <varname>IgnoreSIGPIPE=</varname> option, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details). After the standard output/standard error streams have been terminated they may not be recovered + until the services they are associated with are restarted. Note that during normal operation, + <filename>systemd-journald.service</filename> stores copies of the file descriptors for those streams in + the service manager. If <filename>systemd-journald.service</filename> is restarted using + <command>systemctl restart</command> or equivalent operation instead of a pair of separate + <command>systemctl stop</command> and <command>systemctl start</command> commands (or equivalent + operations), these stream connections are not terminated and survive the restart. It is thus safe to + restart <filename>systemd-journald.service</filename>, but stopping it is not recommended.</para> + + <para>Note that the log record metadata for records transferred via such standard output/error streams reflect the + metadata of the peer the stream was originally created for. If the stream connection is passed on to other + processes (such as further child processes forked off the main service process), the log records will not reflect + their metadata, but will continue to describe the original process. This is different from the other logging + transports listed above, which are inherently record based and where the metadata is always associated with the + individual record.</para> + + <para>In addition to the implicit standard output/error logging of services, stream logging is also available + via the <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> command + line tool.</para> + + <para>Currently, the number of parallel log streams <filename>systemd-journald</filename> will accept is limited to + 4096. When this limit is reached further log streams may be established but will receive + <constant>EPIPE</constant> right from the beginning.</para> + </refsect1> + + <refsect1> + <title>Journal Namespaces</title> + + <para>Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects + consisting of one or more services from the rest of the system and a mechanism for improving + performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log + stream managed by its own instance of <command>systemd-journald</command>. Namespaces are independent of + each other, both in the data store and in the IPC interface. By default only a single 'default' namespace + exists, managed by <filename>systemd-journald.service</filename> (and its associated socket + units). Additional namespaces are created by starting an instance of the + <filename>systemd-journald@.service</filename> service template. The instance name is the namespace + identifier, which is a short string used for referencing the journal namespace. Service units may be + assigned to a specific journal namespace through the <varname>LogNamespace=</varname> unit file setting, + see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. The <option>--namespace=</option> switch of + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be + used to view the log stream of a specific namespace. If the switch is not used the log stream of the + default namespace is shown, i.e. log data from other namespaces is not visible.</para> + + <para>Services associated with a specific log namespace may log via syslog, the native logging protocol + of the journal and via stdout/stderr; the logging from all three transports is associated with the + namespace.</para> + + <para>By default only the default namespace will collect kernel and audit log messages.</para> + + <para>The <command>systemd-journald</command> instance of the default namespace is configured through + <filename>/etc/systemd/journald.conf</filename> (see below), while the other instances are configured + through <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename>. The journal + log data for the default namespace is placed in + <filename>/var/log/journal/<replaceable>MACHINE_ID</replaceable></filename> (see below) while the data + for the other namespaces is located in + <filename>/var/log/journal/<replaceable>MACHINE_ID</replaceable>.<replaceable>NAMESPACE</replaceable></filename>.</para> + </refsect1> + + <refsect1> + <title>Signals</title> + + <variablelist> + <varlistentry> + <term>SIGUSR1</term> + + <listitem><para>Request that journal data from <filename>/run/</filename> is flushed to + <filename>/var/</filename> in order to make it persistent (if this is enabled). This must be used + after <filename>/var/</filename> is mounted, as otherwise log data from <filename>/run/</filename> is + never flushed to <filename>/var/</filename> regardless of the configuration. Use the + <command>journalctl --flush</command> command to request flushing of the journal files, and wait for + the operation to complete. See + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term>SIGUSR2</term> + + <listitem><para>Request immediate rotation of the journal files. Use the <command>journalctl + --rotate</command> command to request journal file rotation, and wait for the operation to + complete.</para></listitem> + </varlistentry> + + <varlistentry> + <term>SIGRTMIN+1</term> + + <listitem><para>Request that all unwritten log data is written to disk. Use the <command>journalctl + --sync</command> command to trigger journal synchronization, and wait for the operation to + complete.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para>A few configuration parameters from + <filename>journald.conf</filename> may be overridden on the kernel + command line:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.journald.forward_to_syslog=</varname></term> + <term><varname>systemd.journald.forward_to_kmsg=</varname></term> + <term><varname>systemd.journald.forward_to_console=</varname></term> + <term><varname>systemd.journald.forward_to_wall=</varname></term> + + <listitem><para>Enables/disables forwarding of collected log + messages to syslog, the kernel log buffer, the system console + or wall. + </para> + + <para>See + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about these settings.</para> + </listitem> + + </varlistentry> + </variablelist> + + <para>Note that these kernel command line options are only honoured by the default namespace, see + above.</para> + </refsect1> + + <refsect1> + <title>Access Control</title> + + <para>Journal files are, by default, owned and readable by the + <literal>systemd-journal</literal> system group but are not + writable. Adding a user to this group thus enables them to read + the journal files.</para> + + <para>By default, each user, with a UID outside the range of system users, + dynamic service users, and the nobody user, will get their own set of + journal files in <filename>/var/log/journal/</filename>. See + <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink> + for more details about UID ranges. These journal + files will not be owned by the user, however, in order to avoid + that the user can write to them directly. Instead, file system + ACLs are used to ensure the user gets read access only.</para> + + <para>Additional users and groups may be granted access to journal + files via file system access control lists (ACL). Distributions + and administrators may choose to grant read access to all members + of the <literal>wheel</literal> and <literal>adm</literal> system + groups with a command such as the following:</para> + + <programlisting># setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/</programlisting> + + <para>Note that this command will update the ACLs both for + existing journal files and for future journal files created in the + <filename>/var/log/journal/</filename> directory.</para> + </refsect1> + + <refsect1> + <title>Files</title> + + <variablelist> + <varlistentry> + <term><filename>/etc/systemd/journald.conf</filename></term> + + <listitem><para>Configure <command>systemd-journald</command> behavior. See + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term> + <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term> + <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term> + <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term> + + <listitem><para><command>systemd-journald</command> writes entries to files in + <filename>/run/log/journal/<replaceable>machine-id</replaceable>/</filename> + or + <filename>/var/log/journal/<replaceable>machine-id</replaceable>/</filename> + with the <literal>.journal</literal> suffix. If the daemon is + stopped uncleanly, or if the files are found to be corrupted, + they are renamed using the <literal>.journal~</literal> + suffix, and <command>systemd-journald</command> starts writing + to a new file. <filename>/run/</filename> is used when + <filename>/var/log/journal</filename> is not available, or + when <option>Storage=volatile</option> is set in the + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration file.</para> + + <para>When <filename>systemd-journald</filename> ceases writing to a journal file, + it will be renamed to <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal</replaceable></literal> + (or <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal~</replaceable></literal>). + Such files are "archived" and will not be written to any more.</para> + + <para>In general, it is safe to read or copy any journal file (active or archived). + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and the functions in the + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry> + library should be able to read all entries that have been fully written.</para> + + <para><filename>systemd-journald</filename> will automatically remove the oldest + archived journal files to limit disk use. See <varname>SystemMaxUse=</varname> + and related settings in + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/dev/kmsg</filename></term> + <term><filename>/dev/log</filename></term> + <term><filename>/run/systemd/journal/dev-log</filename></term> + <term><filename>/run/systemd/journal/socket</filename></term> + <term><filename>/run/systemd/journal/stdout</filename></term> + + <listitem><para>Sockets and other file node paths that <command>systemd-journald</command> will + listen on and are visible in the file system. In addition to these, + <command>systemd-journald</command> can listen for audit events using <citerefentry + project='man-pages'><refentrytitle>netlink</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + </variablelist> + + <para>If journal namespacing is used these paths are slightly altered to include a namespace identifier, see above.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <command>pydoc systemd.journal</command> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-localed.service.xml b/man/systemd-localed.service.xml new file mode 100644 index 0000000..b0a4a9f --- /dev/null +++ b/man/systemd-localed.service.xml @@ -0,0 +1,61 @@ +<?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-or-later --> + +<refentry id="systemd-localed.service" conditional='ENABLE_LOCALED'> + + <refentryinfo> + <title>systemd-localed.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-localed.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-localed.service</refname> + <refname>systemd-localed</refname> + <refpurpose>Locale bus mechanism</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-localed.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-localed</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-localed.service</filename> is a system service + that may be used as mechanism to change the system locale + settings, as well as the console key mapping and default X11 key + mapping. <filename>systemd-localed</filename> is automatically + activated on request and terminates itself when it is + unused.</para> + + <para>The tool + <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + is a command line client to this service.</para> + + <para>See + <citerefentry><refentrytitle>org.freedesktop.locale1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of the D-Bus API.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-logind.service.xml b/man/systemd-logind.service.xml new file mode 100644 index 0000000..746c916 --- /dev/null +++ b/man/systemd-logind.service.xml @@ -0,0 +1,111 @@ +<?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-or-later --> + +<refentry id="systemd-logind.service" conditional='ENABLE_LOGIND'> + + <refentryinfo> + <title>systemd-logind.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-logind.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-logind.service</refname> + <refname>systemd-logind</refname> + <refpurpose>Login manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-logind.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-logind</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-logind</command> is a system service that + manages user logins. It is responsible for:</para> + + <itemizedlist> + <listitem><para>Keeping track of users and sessions, their processes and their idle state. This is implemented by + allocating a systemd slice unit for each user below <filename>user.slice</filename>, and a scope unit below it + for each concurrent session of a user. Also, a per-user service manager is started as system service instance of + <filename>user@.service</filename> for each logged in user.</para></listitem> + + <listitem><para>Generating and managing session IDs. If auditing is available and an audit session ID is already set for + a session, then this ID is reused as the session ID. Otherwise, an independent session counter is + used.</para></listitem> + + <listitem><para>Providing <ulink + url="http://www.freedesktop.org/wiki/Software/polkit">polkit</ulink>-based + access for users for operations such as system shutdown or sleep</para> + </listitem> + + <listitem><para>Implementing a shutdown/sleep inhibition logic + for applications</para></listitem> + + <listitem><para>Handling of power/sleep hardware + keys</para></listitem> + + <listitem><para>Multi-seat management</para></listitem> + + <listitem><para>Session switch management</para></listitem> + + <listitem><para>Device access management for + users</para></listitem> + + <listitem><para>Automatic spawning of text logins (gettys) on + virtual console activation and user runtime directory + management</para></listitem> + </itemizedlist> + + <para>User sessions are registered with logind via the + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + PAM module.</para> + + <para>See + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the configuration of this service.</para> + + <para>See + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for information about the basic concepts of logind + such as users, sessions and seats.</para> + + <para>See + <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the D-Bus APIs <filename>systemd-logind</filename> provides.</para> + + <para>For more information on the inhibition logic see the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor + Lock Developer Documentation</ulink>.</para> + + <para>If you are interested in writing a display manager that makes use of logind, please have look at + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers">Writing Display + Managers</ulink>. + If you are interested in writing a desktop environment that makes use of logind, please have look at + <ulink url="http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments">Writing + Desktop Environments</ulink>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-user-sessions.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-machine-id-commit.service.xml b/man/systemd-machine-id-commit.service.xml new file mode 100644 index 0000000..cffc3e5 --- /dev/null +++ b/man/systemd-machine-id-commit.service.xml @@ -0,0 +1,74 @@ +<?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-or-later + + Copyright © 2014 Didier Roche +--> +<refentry id="systemd-machine-id-commit.service"> + + <refentryinfo> + <title>systemd-machine-id-commit.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-machine-id-commit.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-machine-id-commit.service</refname> + <refpurpose>Commit a transient machine ID to disk</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-machine-id-commit.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-machine-id-commit.service</filename> is an + early boot service responsible for committing transient + <filename>/etc/machine-id</filename> files to a writable disk file + system. See + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information about machine IDs.</para> + + <para>This service is started after + <filename>local-fs.target</filename> in case + <filename>/etc/machine-id</filename> is a mount point of its own + (usually from a memory file system such as + <literal>tmpfs</literal>) and /etc is writable. The service will + invoke <command>systemd-machine-id-setup --commit</command>, which + writes the current transient machine ID to disk and unmount the + <filename>/etc/machine-id</filename> file in a race-free manner to + ensure that file is always valid and accessible for other + processes. See + <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for details.</para> + + <para>The main use case of this service are systems where + <filename>/etc/machine-id</filename> is read-only and initially + not initialized. In this case, the system manager will generate a + transient machine ID file on a memory file system, and mount it + over <filename>/etc/machine-id</filename>, during the early boot + phase. This service is then invoked in a later boot phase, as soon + as <filename>/etc/</filename> has been remounted writable and the + ID may thus be committed to disk to make it permanent.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-machine-id-setup.xml b/man/systemd-machine-id-setup.xml new file mode 100644 index 0000000..2c2a096 --- /dev/null +++ b/man/systemd-machine-id-setup.xml @@ -0,0 +1,148 @@ +<?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-or-later --> + +<refentry id="systemd-machine-id-setup" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-machine-id-setup</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-machine-id-setup</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-machine-id-setup</refname> + <refpurpose>Initialize the machine ID in /etc/machine-id</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-machine-id-setup</command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-machine-id-setup</command> may be used by + system installer tools to initialize the machine ID stored in + <filename>/etc/machine-id</filename> at install time, with a + provisioned or randomly generated ID. See + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information about this file.</para> + + <para>If the tool is invoked without the <option>--commit</option> + switch, <filename>/etc/machine-id</filename> is initialized with a + valid, new machined ID if it is missing or empty. The new machine + ID will be acquired in the following fashion:</para> + + <orderedlist> + <listitem><para>If a valid D-Bus machine ID is already + configured for the system, the D-Bus machine ID is copied and + used to initialize the machine ID in + <filename>/etc/machine-id</filename>.</para></listitem> + + <listitem><para>If run inside a KVM virtual machine and a UUID + is configured (via the <option>-uuid</option> + option), this UUID is used to initialize the machine ID. The + caller must ensure that the UUID passed is sufficiently unique + and is different for every booted instance of the + VM.</para></listitem> + + <listitem><para>Similarly, if run inside a Linux container environment and a UUID is configured for the + container, this is used to initialize the machine ID. For details, see the documentation of the <ulink + url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink>.</para></listitem> + + <listitem><para>Otherwise, a new ID is randomly + generated.</para></listitem> + </orderedlist> + + <para>The <option>--commit</option> switch may be used to commit a + transient machined ID to disk, making it persistent. For details, + see below.</para> + + <para>Use + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to initialize the machine ID on mounted (but not booted) system + images.</para> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + + <varlistentry> + <term><option>--root=<replaceable>root</replaceable></option></term> + <listitem><para>Takes a directory path as argument. All paths + operated will be prefixed with the given alternate + <replaceable>root</replaceable> path, including the path for + <filename>/etc/machine-id</filename> itself.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--commit</option></term> + <listitem><para>Commit a transient machine ID to disk. This + command may be used to convert a transient machine ID into a + persistent one. A transient machine ID file is one that was + bind mounted from a memory file system (usually + <literal>tmpfs</literal>) to + <filename>/etc/machine-id</filename> during the early phase of + the boot process. This may happen because + <filename>/etc/</filename> is initially read-only and was + missing a valid machine ID file at that point.</para> + + <para>This command will execute no operation if + <filename>/etc/machine-id</filename> is not mounted from a + memory file system, or if <filename>/etc/</filename> is + read-only. The command will write the current transient + machine ID to disk and unmount the + <filename>/etc/machine-id</filename> mount point in a + race-free manner to ensure that this file is always valid and + accessible for other processes.</para> + + <para>This command is primarily used by the + <citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + early boot service.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--print</option></term> + + <listitem><para>Print the machine ID generated or committed after the operation is complete.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='dbus'><refentrytitle>dbus-uuidgen</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-machined.service.xml b/man/systemd-machined.service.xml new file mode 100644 index 0000000..1b4318f --- /dev/null +++ b/man/systemd-machined.service.xml @@ -0,0 +1,139 @@ +<?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-or-later --> + +<refentry id="systemd-machined.service" conditional='ENABLE_MACHINED'> + + <refentryinfo> + <title>systemd-machined.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-machined.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-machined.service</refname> + <refname>systemd-machined</refname> + <refpurpose>Virtual machine and container registration manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-machined.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-machined</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-machined</command> is a system service that keeps track of locally running virtual + machines and containers.</para> + + <para><command>systemd-machined</command> is useful for registering and keeping track of both OS + containers (containers that share the host kernel but run a full init system of their own and behave in + most regards like a full virtual operating system rather than just one virtualized app) and full virtual + machines (virtualized hardware running normal operating systems and possibly different kernels).</para> + + <para><command>systemd-machined</command> should <emphasis>not</emphasis> be used for registering/keeping + track of application sandbox containers. A <emphasis>machine</emphasis> in the context of + <command>systemd-machined</command> is supposed to be an abstract term covering both OS containers and + full virtual machines, but not application sandboxes.</para> + + <para>Machines registered with machined are exposed in various ways in the system. For example: + <itemizedlist> + <listitem><para>Tools like + <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will show to which machine a specific process belongs in a column of + its own, and so will + <ulink url="https://help.gnome.org/users/gnome-system-monitor/">gnome-system-monitor</ulink> or + <citerefentry><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + + <listitem><para>systemd's various tools + (<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, ...) + support the <option>-M</option> switch to operate on local containers instead of the host system. + </para></listitem> + + <listitem><para><command>systemctl list-machines</command> will show the system state of all local + containers, connecting to the container's init system for that.</para></listitem> + + <listitem><para>systemctl's <option>--recursive</option> switch has the effect of not only showing the + locally running services, but recursively showing the services of all registered containers.</para></listitem> + + <listitem><para>The <command>machinectl</command> command provides access to a number of useful + operations on registered containers, such as introspecting them, rebooting, shutting them down, and + getting a login prompt on them.</para></listitem> + + <listitem><para>The + <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> library + exposes the + <citerefentry><refentrytitle>sd_bus_open_system_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call to connect to the system bus of any registered container.</para></listitem> + + <listitem><para>The + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry> + module makes sure all registered containers can be resolved via normal glibc + <citerefentry project='man-pages'><refentrytitle>gethostbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or + <citerefentry project='man-pages'><refentrytitle>getaddrinfo</refentrytitle><manvolnum>3</manvolnum></citerefentry> + calls.</para></listitem> + </itemizedlist></para> + + <para>See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for some examples on how to run containers with OS tools.</para> + + <para>If you are interested in writing a VM or container manager that makes use of machined, please have + look at <ulink url="https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers">Writing + Virtual Machine or Container Managers</ulink>. Also see the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New Control Group + Interfaces</ulink>.</para> + + <para>The daemon provides both a C library interface + (which is shared with <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>) + as well as a D-Bus interface. + The library interface may be used to introspect and watch the state of virtual machines/containers. + The bus interface provides the same but in addition may also be used to register or terminate + machines. + For more information please consult + <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.machine1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>A small companion daemon + <citerefentry><refentrytitle>systemd-importd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is also available, which implements importing, exporting, and downloading of container and VM images. + </para> + + <para>For each container registered with <filename>systemd-machined.service</filename> that employs user + namespacing, users/groups are synthesized for the used UIDs/GIDs. These are made available to the system + using the <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via + Varlink</ulink>, and thus may be resolved with + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> or the + usual glibc NSS calls.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-makefs@.service.xml b/man/systemd-makefs@.service.xml new file mode 100644 index 0000000..5ea200c --- /dev/null +++ b/man/systemd-makefs@.service.xml @@ -0,0 +1,95 @@ +<?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-or-later --> +<refentry id="systemd-makefs@.service"> + + <refentryinfo> + <title>systemd-makefs@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-makefs@.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-makefs@.service</refname> + <refname>systemd-mkswap@.service</refname> + <refname>systemd-growfs@.service</refname> + <refname>systemd-makefs</refname> + <refname>systemd-growfs</refname> + <refpurpose>Creating and growing file systems on demand</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-makefs@<replaceable>device</replaceable>.service</filename></para> + <para><filename>systemd-mkswap@<replaceable>device</replaceable>.service</filename></para> + <para><filename>systemd-growfs@<replaceable>mountpoint</replaceable>.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-makefs</filename></para> + <para><filename>/usr/lib/systemd/systemd-growfs</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-makefs@.service</filename>, + <filename>systemd-mkswap@.service</filename>, and + <filename>systemd-growfs@.service</filename> are used to implement the + <option>x-systemd.makefs</option> and <option>x-systemd.growfs</option> options + in <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + see <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + They are instantiated for each device for which the file system or swap structure + needs to be initialized, and for each mount point where the file system needs to + be grown.</para> + + <para>These services are started at boot, either right before or right after the + mount point or swap device are used.</para> + + <para><filename>systemd-makefs</filename> knows very little about specific file + systems and swap devices, and after checking that the block device does not already + contain a file system or other content, it will execute binaries specific to + each filesystem type (<filename>/sbin/mkfs.<replaceable>type</replaceable></filename> + or <filename>/sbin/mkswap</filename>).</para> + + <para><filename>systemd-growfs</filename> knows very little about specific file + systems and swap devices, and will instruct the kernel to grow the mounted + filesystem to full size of the underlying block device. Nevertheless, it needs + to know the + <citerefentry project='man-pages'><refentrytitle>ioctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + number specific to each file system, so only certain types are supported. + Currently: + <citerefentry project='man-pages'><refentrytitle>ext4</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='url'><refentrytitle url='https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)'>btrfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>xfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <!-- yes, that's what the man page is called. --> + and dm-crypt partitions (see + <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>). + </para> + + <para>If the creation of a file system or swap device fails, the mount point or + swap is failed too. If the growing of a file system fails, a warning is emitted. + </para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.cramfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.ext4</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.fat</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.hfsplus</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.minix</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.ntfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkfs.xfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-modules-load.service.xml b/man/systemd-modules-load.service.xml new file mode 100644 index 0000000..0144650 --- /dev/null +++ b/man/systemd-modules-load.service.xml @@ -0,0 +1,72 @@ +<?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-or-later --> +<refentry id="systemd-modules-load.service" conditional='HAVE_KMOD'> + + <refentryinfo> + <title>systemd-modules-load.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-modules-load.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-modules-load.service</refname> + <refname>systemd-modules-load</refname> + <refpurpose>Load kernel modules at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-modules-load.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-modules-load</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-modules-load.service</filename> is an early boot service that loads kernel + modules. It reads static configuration from files in <filename>/usr/</filename> and + <filename>/etc/</filename>, but also runtime configuration from <filename>/run/</filename> and the kernel + command line (see below).</para> + + <para>See + <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + information about the configuration format of this service and paths where configuration files can be + created.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-modules-load.service</filename> + understands the following kernel command line parameters:</para> + + <variablelist class='kernel-commandline-options'> + + <varlistentry> + <term><varname>modules_load=</varname></term> + <term><varname>rd.modules_load=</varname></term> + + <listitem><para>Takes a comma-separated list of kernel modules + to statically load during early boot. The option prefixed with + <literal>rd.</literal> is read by the initial RAM disk + only.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-mount.xml b/man/systemd-mount.xml new file mode 100644 index 0000000..1cde3ab --- /dev/null +++ b/man/systemd-mount.xml @@ -0,0 +1,338 @@ +<?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-or-later --> + +<refentry id="systemd-mount" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-mount</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-mount</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-mount</refname> + <refname>systemd-umount</refname> + <refpurpose>Establish and destroy transient mount or auto-mount points</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-mount</command> + <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg> + <arg choice="plain"><replaceable>WHAT</replaceable></arg> + <arg choice="opt"><replaceable>WHERE</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-mount</command> + <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg> + <arg choice="plain"><option>--list</option></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-mount</command> + <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg> + <arg choice="plain"><option>--umount</option></arg> + <arg choice="plain" rep="repeat"><replaceable>WHAT|WHERE</replaceable></arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-mount</command> may be used to create and start a transient <filename>.mount</filename> or + <filename>.automount</filename> unit of the file system <replaceable>WHAT</replaceable> on the mount point + <replaceable>WHERE</replaceable>.</para> + + <para>In many ways, <command>systemd-mount</command> is similar to the lower-level + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> + command, however instead of executing the mount operation directly and immediately, + <command>systemd-mount</command> schedules it through the service manager job queue, so that it may pull + in further dependencies (such as parent mounts, or a file system checker to execute a priori), and may + make use of the auto-mounting logic.</para> + + <para>The command takes either one or two arguments. If only one argument is specified it should refer to + a block device or regular file containing a file system (e.g. <literal>/dev/sdb1</literal> or + <literal>/path/to/disk.img</literal>). The block device or image file is then probed for a file system + label and other metadata, and is mounted to a directory below <filename>/run/media/system/</filename> + whose name is generated from the file system label. In this mode the block device or image file must + exist at the time of invocation of the command, so that it may be probed. If the device is found to be a + removable block device (e.g. a USB stick), an automount point is created instead of a regular mount point + (i.e. the <option>--automount=</option> option is implied, see below).</para> + + <para>If two arguments are specified, the first indicates the mount source (the + <replaceable>WHAT</replaceable>) and the second indicates the path to mount it on (the + <replaceable>WHERE</replaceable>). In this mode no probing of the source is attempted, and a backing + device node doesn't have to exist. However, if this mode is combined with <option>--discover</option>, + device node probing for additional metadata is enabled, and – much like in the single-argument case + discussed above – the specified device has to exist at the time of invocation of the command.</para> + + <para>Use the <option>--list</option> command to show a terse table of all local, known block devices with file + systems that may be mounted with this command.</para> + + <para><command>systemd-umount</command> can be used to unmount a mount or automount point. It is the same + as <command>systemd-mount</command> <option>--umount</option>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + + <varlistentry> + <term><option>--no-block</option></term> + + <listitem> + <para>Do not synchronously wait for the requested operation to finish. If this is not specified, the job will + be verified, enqueued and <command>systemd-mount</command> will wait until the mount or automount unit's + start-up is completed. By passing this argument, it is only verified and enqueued.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-l</option></term> + <term><option>--full</option></term> + + <listitem> + <para>Do not ellipsize the output when <option>--list</option> is specified.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager"/> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="no-ask-password"/> + + <varlistentry> + <term><option>--quiet</option></term> + <term><option>-q</option></term> + + <listitem><para>Suppresses additional informational output while running.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--discover</option></term> + + <listitem><para>Enable probing of the mount source. This switch is implied if a single argument is specified on + the command line. If passed, additional metadata is read from the device to enhance the unit to create. For + example, a descriptive string for the transient units is generated from the file system label and device + model. Moreover if a removable block device (e.g. USB stick) is detected an automount unit instead of a regular + mount unit is created, with a short idle timeout, in order to ensure the file-system is placed in a clean + state quickly after each access.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--type=</option></term> + <term><option>-t</option></term> + + <listitem><para>Specifies the file system type to mount (e.g. <literal>vfat</literal> or + <literal>ext4</literal>). If omitted or set to <literal>auto</literal>, the file system type is + determined automatically.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--options=</option></term> + <term><option>-o</option></term> + + <listitem><para>Additional mount options for the mount point.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--owner=<replaceable>USER</replaceable></option></term> + + <listitem><para>Let the specified user <replaceable>USER</replaceable> own the mounted file system. + This is done by appending <option>uid=</option> and <option>gid=</option> options to the list + of mount options. Only certain file systems support this option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--fsck=</option></term> + + <listitem><para>Takes a boolean argument, defaults to on. Controls whether to run a file system check + immediately before the mount operation. In the automount case (see <option>--automount=</option> below) the + check will be run the moment the first access to the device is made, which might slightly delay the + access.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--description=</option></term> + + <listitem><para>Provide a description for the mount or automount unit. See <varname>Description=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--property=</option></term> + <term><option>-p</option></term> + + <listitem><para>Sets a unit property for the mount unit that is created. This takes an assignment in the same + format as <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>set-property</command> command.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--automount=</option></term> + + <listitem><para>Takes a boolean argument. Controls whether to create an automount point or a regular mount + point. If true an automount point is created that is backed by the actual file system at the time of first + access. If false a plain mount point is created that is backed by the actual file system immediately. Automount + points have the benefit that the file system stays unmounted and hence in clean state until it is first + accessed. In automount mode the <option>--timeout-idle-sec=</option> switch (see below) may be used to ensure + the mount point is unmounted automatically after the last access and an idle period passed.</para> + + <para>If this switch is not specified it defaults to false. If not specified and <option>--discover</option> is + used (or only a single argument passed, which implies <option>--discover</option>, see above), and the file + system block device is detected to be removable, it is set to true, in order to increase the chance that the + file system is in a fully clean state if the device is unplugged abruptly.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-A</option></term> + + <listitem><para>Equivalent to <option>--automount=yes</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--timeout-idle-sec=</option></term> + + <listitem><para>Takes a time value that controls the idle timeout in automount mode. If set to + <literal>infinity</literal> (the default) no automatic unmounts are done. Otherwise the file system backing the + automount point is detached after the last access and the idle timeout passed. See + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on + the time syntax supported. This option has no effect if only a regular mount is established, and automounting + is not used.</para> + + <para>Note that if <option>--discover</option> is used (or only a single argument passed, which implies + <option>--discover</option>, see above), and the file system block device is detected to be removable, + <option>--timeout-idle-sec=1s</option> is implied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--automount-property=</option></term> + + <listitem><para>Similar to <option>--property=</option>, but applies additional properties to the automount + unit created, instead of the mount unit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--bind-device</option></term> + + <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> + + <para>Note that if <option>--discover</option> is used (or only a single argument passed, which implies + <option>--discover</option>, see above), and the file system block device is detected to be removable, this + option is implied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--list</option></term> + + <listitem><para>Instead of establishing a mount or automount point, print a terse list of block devices + containing file systems that may be mounted with <literal>systemd-mount</literal>, along with useful metadata + such as labels, etc.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-u</option></term> + <term><option>--umount</option></term> + + <listitem><para>Stop the mount and automount units corresponding to the specified mount points + <replaceable>WHERE</replaceable> or the devices <replaceable>WHAT</replaceable>. + <command>systemd-mount</command> with this option or <command>systemd-umount</command> can take multiple arguments + which can be mount points, devices, <filename>/etc/fstab</filename> style node names, or backing files + corresponding to loop devices, like + <command>systemd-mount --umount /path/to/umount /dev/sda1 UUID=xxxxxx-xxxx LABEL=xxxxx /path/to/disk.img</command>. + Note that when <option>-H</option> or <option>-M</option> is specified, only absolute paths to mount points are + supported.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-G</option></term> + <term><option>--collect</option></term> + + <listitem><para>Unload the transient unit after it completed, even if it failed. Normally, without this option, + all mount units that mount and failed are kept in memory until the user explicitly resets their failure state with + <command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that stopped + successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more + aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for + <command>--property=CollectMode=inactive-or-failed</command>, see the explanation for + <varname>CollectMode=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further + information.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="user" /> + <xi:include href="user-system-options.xml" xpointer="system" /> + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure + code otherwise.</para> + </refsect1> + + <refsect1> + <title>The udev Database</title> + + <para>If <option>--discover</option> is used, <command>systemd-mount</command> honors a couple of additional udev + properties of block devices:</para> + + <variablelist class='udev-directives'> + <varlistentry> + <term><varname>SYSTEMD_MOUNT_OPTIONS=</varname></term> + + <listitem><para>The mount options to use, if <option>--options=</option> is not used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYSTEMD_MOUNT_WHERE=</varname></term> + + <listitem><para>The file system path to place the mount point at, instead of the automatically generated + one.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Example</title> + + <para>Use a udev rule like the following to automatically mount all USB storage plugged in:</para> + + <programlisting>ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", \ + RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode"</programlisting> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-network-generator.service.xml b/man/systemd-network-generator.service.xml new file mode 100644 index 0000000..67567c4 --- /dev/null +++ b/man/systemd-network-generator.service.xml @@ -0,0 +1,103 @@ +<?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-or-later --> + +<refentry id="systemd-network-generator.service" conditional='ENABLE_NETWORKD'> + + <refentryinfo> + <title>systemd-network-generator.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-network-generator.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-network-generator.service</refname> + <refname>systemd-network-generator</refname> + <refpurpose>Generate network configuration from the kernel command line</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-network-generator.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-network-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-network-generator.service</filename> is a system service that translates + <varname>ip=</varname> and the related settings on the kernel command line (see below) into + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry> + configuration files understood by + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para>Files are generated in <filename>/run/systemd/network/</filename>.</para> + </refsect1> + + <refsect1><title>Kernel command line options</title> + <para>This tool understands the following options:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>ip=</varname></term> + <term><varname>rd.route=</varname></term> + <term><varname>rd.peerdns=</varname></term> + <listitem> + <para>— translated into + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> files.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ifname=</varname></term> + <listitem> + <para>— translated into + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry> files.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>vlan=</varname></term> + <term><varname>bond=</varname></term> + <term><varname>bridge=</varname></term> + <term><varname>bootdev=</varname></term> + <listitem> + <para>— translated into + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry> files.</para> + </listitem> + </varlistentry> + + <!-- unsupported: + team=<teammaster>:<teamslaves> + bootdev= + BOOTIF= + bootdev= + bootdev= + bootdev= + --> + </variablelist> + + <para>See + <citerefentry project='man-pages'><refentrytitle>dracut.kernel</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for option syntax and details.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml new file mode 100644 index 0000000..6d2c71d --- /dev/null +++ b/man/systemd-networkd-wait-online.service.xml @@ -0,0 +1,129 @@ +<?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-or-later --> + +<refentry id="systemd-networkd-wait-online.service" conditional='ENABLE_NETWORKD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-networkd-wait-online.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-networkd-wait-online.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-networkd-wait-online.service</refname> + <refname>systemd-networkd-wait-online</refname> + <refpurpose>Wait for network to come online</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-networkd-wait-online.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-networkd-wait-online</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-networkd-wait-online</command> is a + oneshot system service (see <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>), that waits for the network to be + configured. By default, it will wait for all links it is aware of + and which are managed by + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + to be fully configured or failed, and for at least one link to be online. Here, online means that + the link's operational state is equal or higher than <literal>degraded</literal>. The threshold + can be configured by <option>--operational-state=</option> option.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-i</option> <replaceable>INTERFACE</replaceable><optional>:<replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></optional></term> + <term><option>--interface=</option><replaceable>INTERFACE</replaceable><optional>:<replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></optional></term> + + <listitem><para>Network interface to wait for before deciding if the system is online. This + is useful when a system has several interfaces which will be configured, but a particular + 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. Optionally, required minimum and maximum operational + states 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 + the value from <varname>RequiredForOnline=</varname> in the corresponding + <filename>.network</filename> file is used if present, and <literal>degraded</literal> otherwise. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--ignore=</option><replaceable>INTERFACE</replaceable></term> + + <listitem><para>Network interfaces to be ignored when deciding + if the system is online. By default, only the loopback + interface is ignored. This option may be used more than once + to ignore multiple network interfaces. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-o</option> <replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></term> + <term><option>--operational-state=</option><replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></term> + + <listitem><para>Takes a minimum operational state and an optional maximum operational state. + Please see <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for possible operational states. If set, the specified value overrides + <varname>RequiredForOnline=</varname> settings in <filename>.network</filename> files. + But this does not override operational states specified in <option>--interface=</option> option. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--any</option></term> + + <listitem><para>Even if several interfaces are in configuring state, + <command>systemd-networkd-wait-online</command> exits with success when at least one interface + becomes online. When this option is specified with <option>--interface=</option>, then + <command>systemd-networkd-wait-online</command> waits for one of the specified interfaces to be + online. This option is useful when some interfaces may not have carrier on boot. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--timeout=</option><replaceable>SECS</replaceable></term> + + <listitem><para>Fail the service if the network is not online + by the time the timeout elapses. A timeout of 0 disables the + timeout. Defaults to 120 seconds. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Suppress log messages.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml new file mode 100644 index 0000000..df6e180 --- /dev/null +++ b/man/systemd-networkd.service.xml @@ -0,0 +1,99 @@ +<?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-or-later --> + +<refentry id="systemd-networkd.service" conditional='ENABLE_NETWORKD'> + + <refentryinfo> + <title>systemd-networkd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-networkd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-networkd.service</refname> + <refname>systemd-networkd</refname> + <refpurpose>Network manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-networkd.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-networkd</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-networkd</command> is a system service that + manages networks. It detects and configures network devices as + they appear, as well as creating virtual network devices.</para> + + <para>To configure low-level link settings independently of + networks, see + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para><command>systemd-networkd</command> will create network devices based + on the configuration in + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry> + files, respecting the [Match] sections in those files.</para> + + <para><command>systemd-networkd</command> will manage network addresses and + routes for any link for which it finds a <filename>.network</filename> file + with an appropriate [Match] section, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + For those links, it will flush existing network addresses and routes when + bringing up the device. Any links not matched by one of the + <filename>.network</filename> files will be ignored. It is also possible to + explicitly tell <filename>systemd-networkd</filename> to ignore a link by + using <varname>Unmanaged=yes</varname> option, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>When <filename>systemd-networkd</filename> exits, it generally leaves + existing network devices and configuration intact. This makes it possible to + transition from the initramfs and to restart the service without breaking + connectivity. This also means that when configuration is updated and + <filename>systemd-networkd</filename> is restarted, netdev interfaces for + which configuration was removed will not be dropped, and may need to be + cleaned up manually.</para> + + <para><command>systemd-networkd</command> may be introspected and controlled at runtime using + <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1><title>Configuration Files</title> + <para>The configuration files are read from the files located in the + system network directory <filename>/usr/lib/systemd/network</filename>, + the volatile runtime network directory + <filename>/run/systemd/network</filename> and the local administration + network directory <filename>/etc/systemd/network</filename>.</para> + + <para>Networks are configured in <filename>.network</filename> + files, see + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + and virtual network devices are configured in + <filename>.netdev</filename> files, see + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd-wait-online.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-notify.xml b/man/systemd-notify.xml new file mode 100644 index 0000000..3fed92e --- /dev/null +++ b/man/systemd-notify.xml @@ -0,0 +1,196 @@ +<?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-or-later --> + +<refentry id="systemd-notify" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-notify</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-notify</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-notify</refname> + <refpurpose>Notify service manager about start-up completion and other daemon status changes</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-notify <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="opt" rep="repeat">VARIABLE=VALUE</arg></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-notify</command> may be called by daemon + scripts to notify the init system about status changes. It can be + used to send arbitrary information, encoded in an + environment-block-like list of strings. Most importantly, it can be + used for start-up completion notification.</para> + + <para>This is mostly just a wrapper around + <function>sd_notify()</function> and makes this functionality + available to shell scripts. For details see + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <para>The command line may carry a list of environment variables + to send as part of the status update.</para> + + <para>Note that systemd will refuse reception of status updates from this command unless + <varname>NotifyAccess=</varname> is set for the service unit this command is called from.</para> + + <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if either + the sending process is still around at the time PID 1 processes the message, or if the sending process is + explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally forked + off the process, i.e. on all processes that match <varname>NotifyAccess=</varname><option>main</option> or + <varname>NotifyAccess=</varname><option>exec</option>. Conversely, if an auxiliary process of the unit sends an + <function>sd_notify()</function> message and immediately exits, the service manager might not be able to properly + attribute the message to the unit, and thus will ignore it, even if <varname>NotifyAccess=</varname><option>all + </option> is set for it. When <option>--no-block</option> is used, all synchronization for reception of notifications + is disabled, and hence the aforementioned race may occur if the invoking process is not the service manager or spawned + by the service manager.</para> + + <para>Hence, <command>systemd-notify</command> will first attempt to invoke <function>sd_notify()</function> + pretending to have the PID of the invoking process. This will only succeed when invoked with sufficient privileges. + On failure, it will then fall back to invoking it under its own PID. This behaviour is useful in order that when + the tool is invoked from a shell script the shell process — and not the <command>systemd-notify</command> process + — appears as sender of the message, which in turn is helpful if the shell process is the main process of a service, + due to the limitations of <varname>NotifyAccess=</varname><option>all</option>. Use the <option>--pid=</option> + switch to tweak this behaviour.</para> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--ready</option></term> + + <listitem><para>Inform the init system about service start-up + completion. This is equivalent to <command>systemd-notify + READY=1</command>. For details about the semantics of this + option see + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--pid=</option></term> + + <listitem><para>Inform the service manager about the main PID of the daemon. Takes a PID as + argument. If the argument is specified as <literal>auto</literal> or omitted, the PID of the process + that invoked <command>systemd-notify</command> is used, except if that's the service manager. If the + argument is specified as <literal>self</literal>, the PID of the <command>systemd-notify</command> + command itself is used, and if <literal>parent</literal> is specified the calling process' PID is + used — even if it is the service manager. This is equivalent to <command>systemd-notify + MAINPID=$PID</command>. For details about the semantics of this option see + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--uid=</option><replaceable>USER</replaceable></term> + + <listitem><para>Set the user ID to send the notification from. Takes a UNIX user name or numeric UID. When + specified the notification message will be sent with the specified UID as sender, in place of the user the + command was invoked as. This option requires sufficient privileges in order to be able manipulate the user + identity of the process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--status=</option></term> + + <listitem><para>Send a free-form status string for the daemon + to the init systemd. This option takes the status string as + argument. This is equivalent to <command>systemd-notify + STATUS=…</command>. For details about the semantics of this + option see + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--booted</option></term> + + <listitem><para>Returns 0 if the system was booted up with + systemd, non-zero otherwise. If this option is passed, no + message is sent. This option is hence unrelated to the other + options. For details about the semantics of this option, see + <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>. An + alternate way to check for this state is to call + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + with the <command>is-system-running</command> command. It will + return <literal>offline</literal> if the system was not booted + with systemd. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-block</option></term> + + <listitem><para>Do not synchronously wait for the requested operation to finish. Use of this option + is only recommended when <command>systemd-notify</command> is spawned by the service manager, or when + the invoking process is directly spawned by the service manager and has enough privileges to allow + <command>systemd-notify</command> to send the notification on its behalf. Sending notifications with + this option set is prone to race conditions in all other cases.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <example> + <title>Start-up Notification and Status Updates</title> + + <para>A simple shell daemon that sends start-up notifications + after having set up its communication channel. During runtime it + sends further status updates to the init system:</para> + + <programlisting>#!/bin/bash + +mkfifo /tmp/waldo +systemd-notify --ready --status="Waiting for data…" + +while : ; do + read a < /tmp/waldo + systemd-notify --status="Processing $a" + + # Do something with $a … + + systemd-notify --status="Waiting for data…" +done</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml new file mode 100644 index 0000000..21e5944 --- /dev/null +++ b/man/systemd-nspawn.xml @@ -0,0 +1,1590 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd-nspawn" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-nspawn</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-nspawn</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-nspawn</refname> + <refpurpose>Spawn a command or OS in a light-weight container</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-nspawn</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt"><replaceable>COMMAND</replaceable> + <arg choice="opt" rep="repeat">ARGS</arg> + </arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-nspawn</command> + <arg choice="plain">--boot</arg> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">ARGS</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-nspawn</command> may be used to run a command or OS in a light-weight namespace + container. In many ways it is similar to <citerefentry + project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>, but more powerful + since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and + the host and domain name.</para> + + <para><command>systemd-nspawn</command> may be invoked on any directory tree containing an operating system tree, + using the <option>--directory=</option> command line option. By using the <option>--machine=</option> option an OS + tree is automatically searched for in a couple of locations, most importantly in + <filename>/var/lib/machines/</filename>, the suggested directory to place OS container images installed on the + system.</para> + + <para>In contrast to <citerefentry + project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>systemd-nspawn</command> + may be used to boot full Linux-based operating systems in a container.</para> + + <para><command>systemd-nspawn</command> limits access to various kernel interfaces in the container to read-only, + such as <filename>/sys/</filename>, <filename>/proc/sys/</filename> or <filename>/sys/fs/selinux/</filename>. The + host's network interfaces and the system clock may not be changed from within the container. Device nodes may not + be created. The host system cannot be rebooted and kernel modules may not be loaded from within the + container.</para> + + <para>Use a tool like <citerefentry + project='mankier'><refentrytitle>dnf</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry + project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or + <citerefentry project='archlinux'><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry> to + set up an OS directory tree suitable as file system hierarchy for <command>systemd-nspawn</command> containers. See + the Examples section below for details on suitable invocation of these commands.</para> + + <para>As a safety check <command>systemd-nspawn</command> will verify the existence of + <filename>/usr/lib/os-release</filename> or <filename>/etc/os-release</filename> in the container tree before + starting the container (see + <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>). It might be + necessary to add this file to the container tree manually if the OS of the container is too old to contain this + file out-of-the-box.</para> + + <para><command>systemd-nspawn</command> may be invoked directly from the interactive command line or run as system + service in the background. In this mode each container instance runs as its own service instance; a default + template unit file <filename>systemd-nspawn@.service</filename> is provided to make this easy, taking the container + name as instance identifier. Note that different default options apply when <command>systemd-nspawn</command> is + invoked by the template unit file than interactively on the command line. Most importantly the template unit file + makes use of the <option>--boot</option> which is not the default in case <command>systemd-nspawn</command> is + invoked from the interactive command line. Further differences with the defaults are documented along with the + various supported options below.</para> + + <para>The <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool may + be used to execute a number of operations on containers. In particular it provides easy-to-use commands to run + containers as system services using the <filename>systemd-nspawn@.service</filename> template unit + file.</para> + + <para>Along with each container a settings file with the <filename>.nspawn</filename> suffix may exist, containing + additional settings to apply when running the container. See + <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. Settings files override the default options used by the <filename>systemd-nspawn@.service</filename> + template unit file, making it usually unnecessary to alter this template file directly.</para> + + <para>Note that <command>systemd-nspawn</command> will mount file systems private to the container to + <filename>/dev/</filename>, <filename>/run/</filename> and similar. These will not be visible outside of the + container, and their contents will be lost when the container exits.</para> + + <para>Note that running two <command>systemd-nspawn</command> containers from the same directory tree will not make + processes in them see each other. The PID namespace separation of the two containers is complete and the containers + will share very few runtime objects except for the underlying file system. Use + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>login</command> or <command>shell</command> commands to request an additional login session in a running + container.</para> + + <para><command>systemd-nspawn</command> implements the <ulink + url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> specification.</para> + + <para>While running, containers invoked with <command>systemd-nspawn</command> are registered with the + <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry> service that + keeps track of running containers, and provides programming interfaces to interact with them.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>If option <option>-b</option> is specified, the arguments + are used as arguments for the init program. Otherwise, + <replaceable>COMMAND</replaceable> specifies the program to launch + in the container, and the remaining arguments are used as + arguments for this program. If <option>--boot</option> is not used and + no arguments are specified, a shell is launched in the + container.</para> + + <para>The following options are understood:</para> + + <variablelist> + + <varlistentry> + <term><option>-q</option></term> + <term><option>--quiet</option></term> + + <listitem><para>Turns off any status output by the tool + itself. When this switch is used, the only output from nspawn + will be the console output of the container OS + itself.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--settings=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Controls whether + <command>systemd-nspawn</command> shall search for and use + additional per-container settings from + <filename>.nspawn</filename> files. Takes a boolean or the + special values <option>override</option> or + <option>trusted</option>.</para> + + <para>If enabled (the default), a settings file named after the + machine (as specified with the <option>--machine=</option> + setting, or derived from the directory or image file name) + with the suffix <filename>.nspawn</filename> is searched in + <filename>/etc/systemd/nspawn/</filename> and + <filename>/run/systemd/nspawn/</filename>. If it is found + there, its settings are read and used. If it is not found + there, it is subsequently searched in the same directory as the + image file or in the immediate parent of the root directory of + the container. In this case, if the file is found, its settings + will be also read and used, but potentially unsafe settings + are ignored. Note that in both these cases, settings on the + command line take precedence over the corresponding settings + from loaded <filename>.nspawn</filename> files, if both are + specified. Unsafe settings are considered all settings that + elevate the container's privileges or grant access to + additional resources such as files or directories of the + host. For details about the format and contents of + <filename>.nspawn</filename> files, consult + <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>If this option is set to <option>override</option>, the + file is searched, read and used the same way, however, the order of + precedence is reversed: settings read from the + <filename>.nspawn</filename> file will take precedence over + the corresponding command line options, if both are + specified.</para> + + <para>If this option is set to <option>trusted</option>, the + file is searched, read and used the same way, but regardless + of being found in <filename>/etc/systemd/nspawn/</filename>, + <filename>/run/systemd/nspawn/</filename> or next to the image + file or container root directory, all settings will take + effect, however, command line arguments still take precedence + over corresponding settings.</para> + + <para>If disabled, no <filename>.nspawn</filename> file is read + and no settings except the ones on the command line are in + effect.</para></listitem> + </varlistentry> + + </variablelist> + + <refsect2> + <title>Image Options</title> + + <variablelist> + + <varlistentry> + <term><option>-D</option></term> + <term><option>--directory=</option></term> + + <listitem><para>Directory to use as file system root for the + container.</para> + + <para>If neither <option>--directory=</option>, nor + <option>--image=</option> is specified the directory is + determined by searching for a directory named the same as the + machine name specified with <option>--machine=</option>. See + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + section "Files and Directories" for the precise search path.</para> + + <para>If neither <option>--directory=</option>, + <option>--image=</option>, nor <option>--machine=</option> + are specified, the current directory will + be used. May not be specified together with + <option>--image=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--template=</option></term> + + <listitem><para>Directory or <literal>btrfs</literal> subvolume to use as template for the + container's root directory. If this is specified and the container's root directory (as configured by + <option>--directory=</option>) does not yet exist it is created as <literal>btrfs</literal> snapshot + (if supported) or plain directory (otherwise) and populated from this template tree. Ideally, the + specified template path refers to the root of a <literal>btrfs</literal> subvolume, in which case a + simple copy-on-write snapshot is taken, and populating the root directory is instant. If the + specified template path does not refer to the root of a <literal>btrfs</literal> subvolume (or not + even to a <literal>btrfs</literal> file system at all), the tree is copied (though possibly in a + 'reflink' copy-on-write scheme — if the file system supports that), which can be substantially more + time-consuming. Note that the snapshot taken is of the specified directory or subvolume, including + all subdirectories and subvolumes below it, but excluding any sub-mounts. May not be specified + together with <option>--image=</option> or <option>--ephemeral</option>.</para> + + <para>Note that this switch leaves hostname, machine ID and + all other settings that could identify the instance + unmodified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-x</option></term> + <term><option>--ephemeral</option></term> + + <listitem><para>If specified, the container is run with a temporary snapshot of its file system that is removed + immediately when the container terminates. May not be specified together with + <option>--template=</option>.</para> + <para>Note that this switch leaves hostname, machine ID and all other settings that could identify + the instance unmodified. Please note that — as with <option>--template=</option> — taking the + temporary snapshot is more efficient on file systems that support subvolume snapshots or 'reflinks' + natively (<literal>btrfs</literal> or new <literal>xfs</literal>) than on more traditional file + systems that do not (<literal>ext4</literal>). Note that the snapshot taken is of the specified + directory or subvolume, including all subdirectories and subvolumes below it, but excluding any + sub-mounts.</para> + + <para>With this option no modifications of the container image are retained. Use + <option>--volatile=</option> (described below) for other mechanisms to restrict persistency of + container images during runtime.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-i</option></term> + <term><option>--image=</option></term> + + <listitem><para>Disk image to mount the root directory for the + container from. Takes a path to a regular file or to a block + device node. The file or block device must contain + either:</para> + + <itemizedlist> + <listitem><para>An MBR partition table with a single + partition of type 0x83 that is marked + bootable.</para></listitem> + + <listitem><para>A GUID partition table (GPT) with a single + partition of type + 0fc63daf-8483-4772-8e79-3d69d8477de4.</para></listitem> + + <listitem><para>A GUID partition table (GPT) with a marked + root partition which is mounted as the root directory of the + container. Optionally, GPT images may contain a home and/or + a server data partition which are mounted to the appropriate + places in the container. All these partitions must be + identified by the partition types defined by the <ulink + url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable + Partitions Specification</ulink>.</para></listitem> + + <listitem><para>No partition table, and a single file system spanning the whole image.</para></listitem> + </itemizedlist> + + <para>On GPT images, if an EFI System Partition (ESP) is discovered, it is automatically mounted to + <filename>/efi</filename> (or <filename>/boot</filename> as fallback) in case a directory by this name exists + and is empty.</para> + + <para>Partitions encrypted with LUKS are automatically decrypted. Also, on GPT images dm-verity data integrity + hash partitions are set up if the root hash for them is specified using the <option>--root-hash=</option> + option.</para> + + <para>Single file system images (i.e. file systems without a surrounding partition table) can be opened using + dm-verity if the integrity data is passed using the <option>--root-hash=</option> and + <option>--verity-data=</option> (and optionally <option>--root-hash-sig=</option>) options.</para> + + <para>Any other partitions, such as foreign partitions or swap partitions are not mounted. May not be specified + together with <option>--directory=</option>, <option>--template=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--oci-bundle=</option></term> + + <listitem><para>Takes the path to an OCI runtime bundle to invoke, as specified in the <ulink + url="https://github.com/opencontainers/runtime-spec/blob/master/spec.md">OCI Runtime Specification</ulink>. In + this case no <filename>.nspawn</filename> file is loaded, and the root directory and various settings are read + from the OCI runtime JSON data (but data passed on the command line takes precedence).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--read-only</option></term> + + <listitem><para>Mount the container's root file system (and any other file systems container in the container + image) read-only. This has no effect on additional mounts made with <option>--bind=</option>, + <option>--tmpfs=</option> and similar options. This mode is implied if the container image file or directory is + marked read-only itself. It is also implied if <option>--volatile=</option> is used. In this case the container + image on disk is strictly read-only, while changes are permitted but kept non-persistently in memory only. For + further details, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--volatile</option></term> + <term><option>--volatile=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Boots the container in volatile mode. When no mode parameter is passed or when mode is + specified as <option>yes</option>, full volatile mode is enabled. This means the root directory is mounted as a + mostly unpopulated <literal>tmpfs</literal> instance, and <filename>/usr/</filename> from the OS tree is + mounted into it in read-only mode (the system thus starts up with read-only OS image, but pristine state and + configuration, any changes are lost on shutdown). When the mode parameter is specified as + <option>state</option>, the OS tree is mounted read-only, but <filename>/var/</filename> is mounted as a + writable <literal>tmpfs</literal> instance into it (the system thus starts up with read-only OS resources and + configuration, but pristine state, and any changes to the latter are lost on shutdown). When the mode parameter + is specified as <option>overlay</option> the read-only root file system is combined with a writable + <filename>tmpfs</filename> instance through <literal>overlayfs</literal>, so that it appears at it normally + would, but any changes are applied to the temporary file system only and lost when the container is + terminated. When the mode parameter is specified as <option>no</option> (the default), the whole OS tree is + made available writable (unless <option>--read-only</option> is specified, see above).</para> + + <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system + (or <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the + hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system + partition that might be mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or + explicitly (e.g. through an additional command line option such as <option>--bind=</option>, see + below). This means, even if <option>--volatile=overlay</option> is used changes to + <filename>/efi/</filename> or <filename>/boot/</filename> are prohibited in case such a partition + exists in the container image operated on, and even if <option>--volatile=state</option> is used the + hypothetical file <filename index="false">/etc/foobar</filename> is potentially writable if + <option>--bind=/etc/foobar</option> if used to mount it from outside the read-only container + <filename>/etc/</filename> directory.</para> + + <para>The <option>--ephemeral</option> option is closely related to this setting, and provides similar + behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details, + see above.</para> + + <para>The <option>--tmpfs=</option> and <option>--overlay=</option> options provide similar functionality, but + for specific sub-directories of the OS image only. For details, see below.</para> + + <para>This option provides similar functionality for containers as the <literal>systemd.volatile=</literal> + kernel command line switch provides for host systems. See + <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 <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> + <term><option>--root-hash=</option></term> + + <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data + integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The + specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 + formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but + the image file carries the <literal>user.verity.roothash</literal> extended file attribute (see <citerefentry + project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root + hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or + is not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is + found next to the image file, bearing otherwise the same name (except if the image has the + <filename>.raw</filename> suffix, in which case the root hash file must not have it in its name), the root hash + is read from it and automatically used, also as formatted hexadecimal characters.</para> + + <para>Note that this configures the root hash for the root file system. Disk images may also contain + separate file systems for the <filename>/usr/</filename> hierarchy, which may be Verity protected as + well. The root hash for this protection may be configured via the + <literal>user.verity.usrhash</literal> extended file attribute or via a <filename>.usrhash</filename> + file adjacent to the disk image, following the same format and logic as for the root hash for the + root file system described here. Note that there's currently no switch to configure the root hash for + the <filename>/usr/</filename> from the command line.</para> + + <para>Also see the <varname>RootHash=</varname> option in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--root-hash-sig=</option></term> + + <listitem><para>Takes a PKCS7 signature of the <option>--root-hash=</option> option. + The semantics are the same as for the <varname>RootHashSignature=</varname> option, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--verity-data=</option></term> + + <listitem><para>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks + using dm-verity, if a root-hash is passed and if the used image itself does not contains the integrity data. + The integrity data must be matched by the root hash. If this option is not specified, but a file with the + <filename>.verity</filename> suffix is found next to the image file, bearing otherwise the same name (except if + the image has the <filename>.raw</filename> suffix, in which case the verity data file must not have it in its name), + the verity data is read from it and automatically used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--pivot-root=</option></term> + + <listitem><para>Pivot the specified directory to <filename>/</filename> inside the container, and either unmount the + container's old root, or pivot it to another specified directory. Takes one of: a path argument — in which case the + specified path will be pivoted to <filename>/</filename> and the old root will be unmounted; or a colon-separated pair + of new root path and pivot destination for the old root. The new root path will be pivoted to <filename>/</filename>, + and the old <filename>/</filename> will be pivoted to the other directory. Both paths must be absolute, and are resolved + in the container's file system namespace.</para> + + <para>This is for containers which have several bootable directories in them; for example, several + <ulink url="https://ostree.readthedocs.io/en/latest/">OSTree</ulink> deployments. It emulates the behavior of + the boot loader and initial RAM disk which normally select which directory to mount as the root and start the + container's PID 1 in.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Execution Options</title> + + <variablelist> + <varlistentry> + <term><option>-a</option></term> + <term><option>--as-pid2</option></term> + + <listitem><para>Invoke the shell or specified program as process ID (PID) 2 instead of PID 1 (init). By + default, if neither this option nor <option>--boot</option> is used, the selected program is run as the process + with PID 1, a mode only suitable for programs that are aware of the special semantics that the process with + PID 1 has on UNIX. For example, it needs to reap all processes reparented to it, and should implement + <command>sysvinit</command> compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute + on SIGTERM, reload configuration on SIGHUP, and so on). With <option>--as-pid2</option> a minimal stub init + process is run as PID 1 and the selected program is executed as PID 2 (and hence does not need to implement any + special semantics). The stub init process will reap processes as necessary and react appropriately to + signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been + modified to run correctly as PID 1. Or in other words: this switch should be used for pretty much all commands, + except when the command refers to an init or shell implementation, as these are generally capable of running + correctly as PID 1. This option may not be combined with <option>--boot</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-b</option></term> + <term><option>--boot</option></term> + + <listitem><para>Automatically search for an init program and invoke it as PID 1, instead of a shell or a user + supplied program. If this option is used, arguments specified on the command line are used as arguments for the + init program. This option may not be combined with <option>--as-pid2</option>.</para> + + <para>The following table explains the different modes of invocation and relationship to + <option>--as-pid2</option> (see above):</para> + + <table> + <title>Invocation Mode</title> + <tgroup cols='2' align='left' colsep='1' rowsep='1'> + <colspec colname="switch" /> + <colspec colname="explanation" /> + <thead> + <row> + <entry>Switch</entry> + <entry>Explanation</entry> + </row> + </thead> + <tbody> + <row> + <entry>Neither <option>--as-pid2</option> nor <option>--boot</option> specified</entry> + <entry>The passed parameters are interpreted as the command line, which is executed as PID 1 in the container.</entry> + </row> + + <row> + <entry><option>--as-pid2</option> specified</entry> + <entry>The passed parameters are interpreted as the command line, which is executed as PID 2 in the container. A stub init process is run as PID 1.</entry> + </row> + + <row> + <entry><option>--boot</option> specified</entry> + <entry>An init program is automatically searched for and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process.</entry> + </row> + + </tbody> + </tgroup> + </table> + + <para>Note that <option>--boot</option> is the default mode of operation if the + <filename>systemd-nspawn@.service</filename> template unit file is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--chdir=</option></term> + + <listitem><para>Change to the specified working directory before invoking the process in the container. Expects + an absolute path in the container's file system namespace.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-E <replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term> + <term><option>--setenv=<replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term> + + <listitem><para>Specifies an environment variable assignment + to pass to the init process in the container, in the format + <literal>NAME=VALUE</literal>. This may be used to override + the default variables or to set additional variables. This + parameter may be used more than once.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-u</option></term> + <term><option>--user=</option></term> + + <listitem><para>After transitioning into the container, change to the specified user defined in the + container's user database. Like all other systemd-nspawn features, this is not a security feature and + provides protection against accidental destructive operations only.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--kill-signal=</option></term> + + <listitem><para>Specify the process signal to send to the container's PID 1 when nspawn itself receives + <constant>SIGTERM</constant>, in order to trigger an orderly shutdown of the container. Defaults to + <constant>SIGRTMIN+3</constant> if <option>--boot</option> is used (on systemd-compatible init systems + <constant>SIGRTMIN+3</constant> triggers an orderly shutdown). If <option>--boot</option> is not used and this + option is not specified the container's processes are terminated abruptly via <constant>SIGKILL</constant>. For + a list of valid signals, see <citerefentry + project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--notify-ready=</option></term> + + <listitem><para>Configures support for notifications from the container's init process. + <option>--notify-ready=</option> takes a boolean (<option>no</option> and <option>yes</option>). + With option <option>no</option> systemd-nspawn notifies systemd + with a <literal>READY=1</literal> message when the init process is created. + With option <option>yes</option> systemd-nspawn waits for the + <literal>READY=1</literal> message from the init process in the container + before sending its own to systemd. For more details about notifications + see <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>System Identity Options</title> + + <variablelist> + <varlistentry> + <term><option>-M</option></term> + <term><option>--machine=</option></term> + + <listitem><para>Sets the machine name for this container. This + name may be used to identify this container during its runtime + (for example in tools like + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and similar), and is used to initialize the container's + hostname (which the container can choose to override, + however). If not specified, the last component of the root + directory path of the container is used, possibly suffixed + with a random identifier in case <option>--ephemeral</option> + mode is selected. If the root directory selected is the host's + root directory the host's hostname is used as default + instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--hostname=</option></term> + + <listitem><para>Controls the hostname to set within the container, if different from the machine name. Expects + a valid hostname as argument. If this option is used, the kernel hostname of the container will be set to this + value, otherwise it will be initialized to the machine name as controlled by the <option>--machine=</option> + option described above. The machine name is used for various aspect of identification of the container from the + outside, the kernel hostname configurable with this option is useful for the container to identify itself from + the inside. It is usually a good idea to keep both forms of identification synchronized, in order to avoid + confusion. It is hence recommended to avoid usage of this option, and use <option>--machine=</option> + exclusively. Note that regardless whether the container's hostname is initialized from the name set with + <option>--hostname=</option> or the one set with <option>--machine=</option>, the container can later override + its kernel hostname freely on its own as well.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--uuid=</option></term> + + <listitem><para>Set the specified UUID for the container. The + init system will initialize + <filename>/etc/machine-id</filename> from this if this file is + not set yet. Note that this option takes effect only if + <filename>/etc/machine-id</filename> in the container is + unpopulated.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Property Options</title> + + <variablelist> + <varlistentry> + <term><option>-S</option></term> + <term><option>--slice=</option></term> + + <listitem><para>Make the container part of the specified slice, instead of the default + <filename>machine.slice</filename>. This applies only if the machine is run in its own scope unit, i.e. if + <option>--keep-unit</option> isn't used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--property=</option></term> + + <listitem><para>Set a unit property on the scope unit to register for the machine. This applies only if the + machine is run in its own scope unit, i.e. if <option>--keep-unit</option> isn't used. Takes unit property + assignments in the same format as <command>systemctl set-property</command>. This is useful to set memory + limits and similar for container.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--register=</option></term> + + <listitem><para>Controls whether the container is registered with + <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes a + boolean argument, which defaults to <literal>yes</literal>. This option should be enabled when the container + runs a full Operating System (more specifically: a system and service manager as PID 1), and is useful to + ensure that the container is accessible via + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and shown by + tools such as <citerefentry + project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If the container + does not run a service manager, it is recommended to set this option to + <literal>no</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--keep-unit</option></term> + + <listitem><para>Instead of creating a transient scope unit to run the container in, simply use the service or + scope unit <command>systemd-nspawn</command> has been invoked in. If <option>--register=yes</option> is set + this unit is registered with + <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This + switch should be used if <command>systemd-nspawn</command> is invoked from within a service unit, and the + service unit's sole purpose is to run a single <command>systemd-nspawn</command> container. This option is not + available if run from a user session.</para> + <para>Note that passing <option>--keep-unit</option> disables the effect of <option>--slice=</option> and + <option>--property=</option>. Use <option>--keep-unit</option> and <option>--register=no</option> in + combination to disable any kind of unit allocation or registration with + <command>systemd-machined</command>.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>User Namespacing Options</title> + + <variablelist> + <varlistentry> + <term><option>--private-users=</option></term> + + <listitem><para>Controls user namespacing. If enabled, the container will run with its own private set of UNIX + user and group ids (UIDs and GIDs). This involves mapping the private UIDs/GIDs used in the container (starting + with the container's root user 0 and up) to a range of UIDs/GIDs on the host that are not used for other + purposes (usually in the range beyond the host's UID/GID 65536). The parameter may be specified as follows:</para> + + <orderedlist> + <listitem><para>If one or two colon-separated numbers are specified, user namespacing is turned on. The first + parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the + number of host UIDs/GIDs to assign to the container. If the second parameter is omitted, 65536 UIDs/GIDs are + assigned.</para></listitem> + + <listitem><para>If the parameter is omitted, or true, user namespacing is turned on. The UID/GID range to + use is determined automatically from the file ownership of the root directory of the container's directory + tree. To use this option, make sure to prepare the directory tree in advance, and ensure that all files and + directories in it are owned by UIDs/GIDs in the range you'd like to use. Also, make sure that used file ACLs + exclusively reference UIDs/GIDs in the appropriate range. If this mode is used the number of UIDs/GIDs + assigned to the container for use is 65536, and the UID/GID of the root directory must be a multiple of + 65536.</para></listitem> + + <listitem><para>If the parameter is false, user namespacing is turned off. This is the default.</para> + </listitem> + + <listitem><para>The special value <literal>pick</literal> turns on user namespacing. In this case the UID/GID + range is automatically chosen. As first step, the file owner of the root directory of the container's + directory tree is read, and it is checked that it is currently not used by the system otherwise (in + particular, that no other container is using it). If this check is successful, the UID/GID range determined + this way is used, similar to the behavior if "yes" is specified. If the check is not successful (and thus + the UID/GID range indicated in the root directory's file owner is already used elsewhere) a new – currently + unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host UID/GIDs of 524288 and + 1878982656, always starting at a multiple of 65536, and, if possible, consistently hashed from the machine + name. This setting implies + <option>--private-users-chown</option> (see below), which has the effect that the files and directories in + the container's directory tree will be owned by the appropriate users of the range picked. Using this option + makes user namespace behavior fully automatic. Note that the first invocation of a previously unused + container image might result in picking a new UID/GID range for it, and thus in the (possibly expensive) file + ownership adjustment operation. However, subsequent invocations of the container will be cheap (unless of + course the picked UID/GID range is assigned to a different use by then).</para></listitem> + </orderedlist> + + <para>It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the + container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is + hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16 + bit encode the container UID/GID used. This is in fact the behavior enforced by the + <option>--private-users=pick</option> option.</para> + + <para>When user namespaces are used, the GID range assigned to each container is always chosen identical to the + UID range.</para> + + <para>In most cases, using <option>--private-users=pick</option> is the recommended option as it enhances + container security massively and operates fully automatically in most cases.</para> + + <para>Note that the picked UID/GID range is not written to <filename>/etc/passwd</filename> or + <filename>/etc/group</filename>. In fact, the allocation of the range is not stored persistently anywhere, + except in the file ownership of the files and directories of the container.</para> + + <para>Note that when user namespacing is used file ownership on disk reflects this, and all of the container's + files and directories are owned by the container's effective user and group IDs. This means that copying files + from and to the container image requires correction of the numeric UID/GID values, according to the UID/GID + shift applied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--private-users-chown</option></term> + + <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> + </varlistentry> + + <varlistentry> + <term><option>-U</option></term> + + <listitem><para>If the kernel supports the user namespaces feature, equivalent to + <option>--private-users=pick --private-users-chown</option>, otherwise equivalent to + <option>--private-users=no</option>.</para> + + <para>Note that <option>-U</option> is the default if the + <filename>systemd-nspawn@.service</filename> template unit file is used.</para> + + <para>Note: it is possible to undo the effect of <option>--private-users-chown</option> (or + <option>-U</option>) on the file system by redoing the operation with the first UID of 0:</para> + + <programlisting>systemd-nspawn … --private-users=0 --private-users-chown</programlisting> + </listitem> + </varlistentry> + + </variablelist> + + </refsect2><refsect2> + <title>Networking Options</title> + + <variablelist> + + <varlistentry> + <term><option>--private-network</option></term> + + <listitem><para>Disconnect networking of the container from + the host. This makes all network interfaces unavailable in the + container, with the exception of the loopback device and those + specified with <option>--network-interface=</option> and + configured with <option>--network-veth</option>. If this + option is specified, the <constant>CAP_NET_ADMIN</constant> capability will be + added to the set of capabilities the container retains. The + latter may be disabled by using <option>--drop-capability=</option>. + If this option is not specified (or implied by one of the options + listed below), the container will have full access to the host network. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-interface=</option></term> + + <listitem><para>Assign the specified network interface to the + container. This will remove the specified interface from the + calling namespace and place it in the container. When the + container terminates, it is moved back to the host namespace. + Note that <option>--network-interface=</option> implies + <option>--private-network</option>. This option may be used + more than once to add multiple network interfaces to the + container.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-macvlan=</option></term> + + <listitem><para>Create a <literal>macvlan</literal> interface + of the specified Ethernet network interface and add it to the + container. A <literal>macvlan</literal> interface is a virtual + interface that adds a second MAC address to an existing + physical Ethernet link. The interface in the container will be + named after the interface on the host, prefixed with + <literal>mv-</literal>. Note that + <option>--network-macvlan=</option> implies + <option>--private-network</option>. This option may be used + more than once to add multiple network interfaces to the + container.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-ipvlan=</option></term> + + <listitem><para>Create an <literal>ipvlan</literal> interface + of the specified Ethernet network interface and add it to the + container. An <literal>ipvlan</literal> interface is a virtual + interface, similar to a <literal>macvlan</literal> interface, + which uses the same MAC address as the underlying interface. + The interface in the container will be named after the + interface on the host, prefixed with <literal>iv-</literal>. + Note that <option>--network-ipvlan=</option> implies + <option>--private-network</option>. This option may be used + more than once to add multiple network interfaces to the + container.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-n</option></term> + <term><option>--network-veth</option></term> + + <listitem><para>Create a virtual Ethernet link (<literal>veth</literal>) between host and container. The host + side of the Ethernet link will be available as a network interface named after the container's name (as + specified with <option>--machine=</option>), prefixed with <literal>ve-</literal>. The container side of the + Ethernet link will be named <literal>host0</literal>. The <option>--network-veth</option> option implies + <option>--private-network</option>.</para> + + <para>Note that + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + includes by default a network file <filename>/usr/lib/systemd/network/80-container-ve.network</filename> + matching the host-side interfaces created this way, which contains settings to enable automatic address + provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external + network interfaces. It also contains <filename>/usr/lib/systemd/network/80-container-host0.network</filename> + matching the container-side interface created this way, containing settings to enable client side address + assignment via DHCP. In case <filename>systemd-networkd</filename> is running on both the host and inside the + container, automatic IP communication from the container to the host is thus available, with further + connectivity to the external network.</para> + + <para>Note that <option>--network-veth</option> is the default if the + <filename>systemd-nspawn@.service</filename> template unit file is used.</para> + + <para>Note that on Linux network interface names may have a length of 15 characters at maximum, while + container names may have a length up to 64 characters. As this option derives the host-side interface + name from the container name the name is possibly truncated. Thus, care needs to be taken to ensure + that interface names remain unique in this case, or even better container names are generally not + chosen longer than 12 characters, to avoid the truncation. If the name is truncated, + <command>systemd-nspawn</command> will automatically append a 4-digit hash value to the name to + reduce the chance of collisions. However, the hash algorithm is not collision-free. (See + <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details on older naming algorithms for this interface). Alternatively, the + <option>--network-veth-extra=</option> option may be used, which allows free configuration of the + host-side interface name independently of the container name — but might require a bit more + additional configuration in case bridging in a fashion similar to <option>--network-bridge=</option> + is desired.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-veth-extra=</option></term> + + <listitem><para>Adds an additional virtual Ethernet link + between host and container. Takes a colon-separated pair of + host interface name and container interface name. The latter + may be omitted in which case the container and host sides will + be assigned the same name. This switch is independent of + <option>--network-veth</option>, and — in contrast — may be + used multiple times, and allows configuration of the network + interface names. Note that <option>--network-bridge=</option> + has no effect on interfaces created with + <option>--network-veth-extra=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-bridge=</option></term> + + <listitem><para>Adds the host side of the Ethernet link created with <option>--network-veth</option> + to the specified Ethernet bridge interface. Expects a valid network interface name of a bridge device + as argument. Note that <option>--network-bridge=</option> implies <option>--network-veth</option>. If + this option is used, the host side of the Ethernet link will use the <literal>vb-</literal> prefix + instead of <literal>ve-</literal>. Regardless of the used naming prefix the same network interface + name length limits imposed by Linux apply, along with the complications this creates (for details see + above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-zone=</option></term> + + <listitem><para>Creates a virtual Ethernet link (<literal>veth</literal>) to the container and adds it to an + automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument, + prefixed with <literal>vz-</literal>. The bridge interface is automatically created when the first container + configured for its name is started, and is automatically removed when the last container configured for its + name exits. Hence, each bridge interface configured this way exists only as long as there's at least one + container referencing it running. This option is very similar to <option>--network-bridge=</option>, besides + this automatic creation/removal of the bridge device.</para> + + <para>This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based + broadcast domain, here called a "zone". Each container may only be part of one zone, but each zone may contain + any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form + valid network interface names when prefixed with <literal>vz-</literal>), and it is sufficient to pass the same + name to the <option>--network-zone=</option> switch of the various concurrently running containers to join + them in one zone.</para> + + <para>Note that + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + includes by default a network file <filename>/usr/lib/systemd/network/80-container-vz.network</filename> + matching the bridge interfaces created this way, which contains settings to enable automatic address + provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external + network interfaces. Using <option>--network-zone=</option> is hence in most cases fully automatic and + sufficient to connect multiple local containers in a joined broadcast domain to the host, with further + connectivity to the external network.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--network-namespace-path=</option></term> + + <listitem><para>Takes the path to a file representing a kernel + network namespace that the container shall run in. The specified path + should refer to a (possibly bind-mounted) network namespace file, as + exposed by the kernel below <filename>/proc/$PID/ns/net</filename>. + This makes the container enter the given network namespace. One of the + typical use cases is to give a network namespace under + <filename>/run/netns</filename> created by <citerefentry + project='man-pages'><refentrytitle>ip-netns</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + for example, <option>--network-namespace-path=/run/netns/foo</option>. + Note that this option cannot be used together with other + network-related options, such as <option>--private-network</option> + or <option>--network-interface=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--port=</option></term> + + <listitem><para>If private networking is enabled, maps an IP + port on the host onto an IP port on the container. Takes a + protocol specifier (either <literal>tcp</literal> or + <literal>udp</literal>), separated by a colon from a host port + number in the range 1 to 65535, separated by a colon from a + container port number in the range from 1 to 65535. The + protocol specifier and its separating colon may be omitted, in + which case <literal>tcp</literal> is assumed. The container + port number and its colon may be omitted, in which case the + same port as the host port is implied. This option is only + supported if private networking is used, such as with + <option>--network-veth</option>, <option>--network-zone=</option> + <option>--network-bridge=</option>.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Security Options</title> + + <variablelist> + <varlistentry> + <term><option>--capability=</option></term> + + <listitem><para>List one or more additional capabilities to grant the container. Takes a + comma-separated list of capability names, see <citerefentry + project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information. Note that the following capabilities will be granted in any way: + <constant>CAP_AUDIT_CONTROL</constant>, <constant>CAP_AUDIT_WRITE</constant>, + <constant>CAP_CHOWN</constant>, <constant>CAP_DAC_OVERRIDE</constant>, + <constant>CAP_DAC_READ_SEARCH</constant>, <constant>CAP_FOWNER</constant>, + <constant>CAP_FSETID</constant>, <constant>CAP_IPC_OWNER</constant>, <constant>CAP_KILL</constant>, + <constant>CAP_LEASE</constant>, <constant>CAP_LINUX_IMMUTABLE</constant>, + <constant>CAP_MKNOD</constant>, <constant>CAP_NET_BIND_SERVICE</constant>, + <constant>CAP_NET_BROADCAST</constant>, <constant>CAP_NET_RAW</constant>, + <constant>CAP_SETFCAP</constant>, <constant>CAP_SETGID</constant>, <constant>CAP_SETPCAP</constant>, + <constant>CAP_SETUID</constant>, <constant>CAP_SYS_ADMIN</constant>, + <constant>CAP_SYS_BOOT</constant>, <constant>CAP_SYS_CHROOT</constant>, + <constant>CAP_SYS_NICE</constant>, <constant>CAP_SYS_PTRACE</constant>, + <constant>CAP_SYS_RESOURCE</constant>, <constant>CAP_SYS_TTY_CONFIG</constant>. Also + <constant>CAP_NET_ADMIN</constant> is retained if <option>--private-network</option> is specified. + If the special value <literal>all</literal> is passed, all capabilities are retained.</para> + + <para>If the special value of <literal>help</literal> is passed, the program will print known + capability names and exit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--drop-capability=</option></term> + + <listitem><para>Specify one or more additional capabilities to + drop for the container. This allows running the container with + fewer capabilities than the default (see + above).</para> + + <para>If the special value of <literal>help</literal> is passed, the program will print known + capability names and exit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-new-privileges=</option></term> + + <listitem><para>Takes a boolean argument. Specifies the value of the + <constant>PR_SET_NO_NEW_PRIVS</constant> flag for the container payload. Defaults to off. When turned + on the payload code of the container cannot acquire new privileges, i.e. the "setuid" file bit as + well as file system capabilities will not have an effect anymore. See <citerefentry + project='man-pages'><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details about this flag. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--system-call-filter=</option></term> <listitem><para>Alter the system call filter + applied to containers. Takes a space-separated list of system call names or group names (the latter + prefixed with <literal>@</literal>, as listed by the <command>syscall-filter</command> command of + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Passed + system calls will be permitted. The list may optionally be prefixed by <literal>~</literal>, in which + case all listed system calls are prohibited. If this command line option is used multiple times the + configured lists are combined. If both a positive and a negative list (that is one system call list + without and one with the <literal>~</literal> prefix) are configured, the negative list takes + precedence over the positive list. Note that <command>systemd-nspawn</command> always implements a + system call allow list (as opposed to a deny list!), and this command line option hence adds or + removes entries from the default allow list, depending on the <literal>~</literal> prefix. Note that + the applied system call filter is also altered implicitly if additional capabilities are passed using + the <command>--capabilities=</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-Z</option></term> + <term><option>--selinux-context=</option></term> + + <listitem><para>Sets the SELinux security context to be used + to label processes in the container.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-L</option></term> + <term><option>--selinux-apifs-context=</option></term> + + <listitem><para>Sets the SELinux security context to be used + to label files in the virtual API file systems in the + container.</para> + </listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Resource Options</title> + + <variablelist> + + <varlistentry> + <term><option>--rlimit=</option></term> + + <listitem><para>Sets the specified POSIX resource limit for the container payload. Expects an assignment of the + form + <literal><replaceable>LIMIT</replaceable>=<replaceable>SOFT</replaceable>:<replaceable>HARD</replaceable></literal> + or <literal><replaceable>LIMIT</replaceable>=<replaceable>VALUE</replaceable></literal>, where + <replaceable>LIMIT</replaceable> should refer to a resource limit type, such as + <constant>RLIMIT_NOFILE</constant> or <constant>RLIMIT_NICE</constant>. The <replaceable>SOFT</replaceable> and + <replaceable>HARD</replaceable> fields should refer to the numeric soft and hard resource limit values. If the + second form is used, <replaceable>VALUE</replaceable> may specify a value that is used both as soft and hard + limit. In place of a numeric value the special string <literal>infinity</literal> may be used to turn off + resource limiting for the specific type of resource. This command line option may be used multiple times to + control limits on multiple limit types. If used multiple times for the same limit type, the last use + wins. For details about resource limits see <citerefentry + project='man-pages'><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>. By default + resource limits for the container's init process (PID 1) are set to the same values the Linux kernel originally + passed to the host init system. Note that some resource limits are enforced on resources counted per user, in + particular <constant>RLIMIT_NPROC</constant>. This means that unless user namespacing is deployed + (i.e. <option>--private-users=</option> is used, see above), any limits set will be applied to the resource + usage of the same user on all local containers as well as the host. This means particular care needs to be + taken with these limits as they might be triggered by possibly less trusted code. Example: + <literal>--rlimit=RLIMIT_NOFILE=8192:16384</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--oom-score-adjust=</option></term> + + <listitem><para>Changes the OOM ("Out Of Memory") score adjustment value for the container payload. This controls + <filename>/proc/self/oom_score_adj</filename> which influences the preference with which this container is + terminated when memory becomes scarce. For details see <citerefentry + project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Takes an + integer in the range -1000…1000.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--cpu-affinity=</option></term> + + <listitem><para>Controls the CPU affinity of the container payload. Takes a comma separated list of CPU numbers + or number ranges (the latter's start and end value separated by dashes). See <citerefentry + project='man-pages'><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--personality=</option></term> + + <listitem><para>Control the architecture ("personality") + reported by + <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> + in the container. Currently, only <literal>x86</literal> and + <literal>x86-64</literal> are supported. This is useful when + running a 32-bit container on a 64-bit host. If this setting + is not used, the personality reported in the container is the + same as the one reported on the host.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Integration Options</title> + + <variablelist> + <varlistentry> + <term><option>--resolv-conf=</option></term> + + <listitem><para>Configures how <filename>/etc/resolv.conf</filename> inside of the container shall be + handled (i.e. DNS configuration synchronization from host to container). Takes one of + <literal>off</literal>, <literal>copy-host</literal>, <literal>copy-static</literal>, + <literal>copy-uplink</literal>, <literal>copy-stub</literal>, <literal>replace-host</literal>, + <literal>replace-static</literal>, <literal>replace-uplink</literal>, + <literal>replace-stub</literal>, <literal>bind-host</literal>, <literal>bind-static</literal>, + <literal>bind-uplink</literal>, <literal>bind-stub</literal>, <literal>delete</literal> or + <literal>auto</literal>.</para> + + <para>If set to <literal>off</literal> the <filename>/etc/resolv.conf</filename> file in the + container is left as it is included in the image, and neither modified nor bind mounted over.</para> + + <para>If set to <literal>copy-host</literal>, the <filename>/etc/resolv.conf</filename> file from the + host is copied into the container, unless the file exists already and is not a regular file (e.g. a + symlink). Similar, if <literal>replace-host</literal> is used the file is copied, replacing any + existing inode, including symlinks. Similar, if <literal>bind-host</literal> is used, the file is + bind mounted from the host into the container.</para> + + <para>If set to <literal>copy-static</literal>, <literal>replace-static</literal> or + <literal>bind-static</literal> the static <filename>resolv.conf</filename> file supplied with + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + (specifically: <filename>/usr/lib/systemd/resolv.conf</filename>) is copied or bind mounted into the + container.</para> + + <para>If set to <literal>copy-uplink</literal>, <literal>replace-uplink</literal> or + <literal>bind-uplink</literal> the uplink <filename>resolv.conf</filename> file managed by + <filename>systemd-resolved.service</filename> (specifically: + <filename>/run/systemd/resolve/resolv.conf</filename>) is copied or bind mounted into the + container.</para> + + <para>If set to <literal>copy-stub</literal>, <literal>replace-stub</literal> or + <literal>bind-stub</literal> the stub <filename>resolv.conf</filename> file managed by + <filename>systemd-resolved.service</filename> (specifically: + <filename>/run/systemd/resolve/stub-resolv.conf</filename>) is copied or bind mounted into the + container.</para> + + <para>If set to <literal>delete</literal> the <filename>/etc/resolv.conf</filename> file in the + container is deleted if it exists.</para> + + <para>Finally, if set to <literal>auto</literal> the file is left as it is if private networking is + turned on (see <option>--private-network</option>). Otherwise, if + <filename>systemd-resolved.service</filename> is running its stub <filename>resolv.conf</filename> + file is used, and if not the host's <filename>/etc/resolv.conf</filename> file. In the latter cases + the file is copied if the image is writable, and bind mounted otherwise.</para> + + <para>It's recommended to use <literal>copy-…</literal> or <literal>replace-…</literal> if the + container shall be able to make changes to the DNS configuration on its own, deviating from the + host's settings. Otherwise <literal>bind</literal> is preferable, as it means direct changes to + <filename>/etc/resolv.conf</filename> in the container are not allowed, as it is a read-only bind + mount (but note that if the container has enough privileges, it might simply go ahead and unmount the + bind mount anyway). Note that both if the file is bind mounted and if it is copied no further + propagation of configuration is generally done after the one-time early initialization (this is + because the file is usually updated through copying and renaming). Defaults to + <literal>auto</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--timezone=</option></term> + + <listitem><para>Configures how <filename>/etc/localtime</filename> inside of the container + (i.e. local timezone synchronization from host to container) shall be handled. Takes one of + <literal>off</literal>, <literal>copy</literal>, <literal>bind</literal>, <literal>symlink</literal>, + <literal>delete</literal> or <literal>auto</literal>. If set to <literal>off</literal> the + <filename>/etc/localtime</filename> file in the container is left as it is included in the image, and + neither modified nor bind mounted over. If set to <literal>copy</literal> the + <filename>/etc/localtime</filename> file of the host is copied into the container. Similarly, if + <literal>bind</literal> is used, the file is bind mounted from the host into the container. If set to + <literal>symlink</literal>, a symlink is created pointing from <filename>/etc/localtime</filename> in + the container to the timezone file in the container that matches the timezone setting on the host. If + set to <literal>delete</literal>, the file in the container is deleted, should it exist. If set to + <literal>auto</literal> and the <filename>/etc/localtime</filename> file of the host is a symlink, + then <literal>symlink</literal> mode is used, and <literal>copy</literal> otherwise, except if the + image is read-only in which case <literal>bind</literal> is used instead. Defaults to + <literal>auto</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--link-journal=</option></term> + + <listitem><para>Control whether the container's journal shall + be made visible to the host system. If enabled, allows viewing + the container's journal files from the host (but not vice + versa). Takes one of <literal>no</literal>, + <literal>host</literal>, <literal>try-host</literal>, + <literal>guest</literal>, <literal>try-guest</literal>, + <literal>auto</literal>. If <literal>no</literal>, the journal + is not linked. If <literal>host</literal>, the journal files + are stored on the host file system (beneath + <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>) + and the subdirectory is bind-mounted into the container at the + same location. If <literal>guest</literal>, the journal files + are stored on the guest file system (beneath + <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>) + and the subdirectory is symlinked into the host at the same + location. <literal>try-host</literal> and + <literal>try-guest</literal> do the same but do not fail if + the host does not have persistent journaling enabled. If + <literal>auto</literal> (the default), and the right + subdirectory of <filename>/var/log/journal</filename> exists, + it will be bind mounted into the container. If the + subdirectory does not exist, no linking is performed. + Effectively, booting a container once with + <literal>guest</literal> or <literal>host</literal> will link + the journal persistently if further on the default of + <literal>auto</literal> is used.</para> + + <para>Note that <option>--link-journal=try-guest</option> is the default if the + <filename>systemd-nspawn@.service</filename> template unit file is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-j</option></term> + + <listitem><para>Equivalent to + <option>--link-journal=try-guest</option>.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect2><refsect2> + <title>Mount Options</title> + + <variablelist> + + <varlistentry> + <term><option>--bind=</option></term> + <term><option>--bind-ro=</option></term> + + <listitem><para>Bind mount a file or directory from the host into the container. Takes one of: a path + argument — in which case the specified path will be mounted from the host to the same path in the container, or + a colon-separated pair of paths — in which case the first specified path is the source in the host, and the + second path is the destination in the container, or a colon-separated triple of source path, destination path + and mount options. The source path may optionally be prefixed with a <literal>+</literal> character. If so, the + source path is taken relative to the image's root directory. This permits setting up bind mounts within the + container image. The source path may be specified as empty string, in which case a temporary directory below + the host's <filename>/var/tmp/</filename> directory is used. It is automatically removed when the container is + shut down. Mount options are comma-separated and currently, only <option>rbind</option> and + <option>norbind</option> are allowed, controlling whether to create a recursive or a regular bind + mount. Defaults to "rbind". Backslash escapes are interpreted, so <literal>\:</literal> may be used to embed + colons in either path. This option may be specified multiple times for creating multiple independent bind + mount points. The <option>--bind-ro=</option> option creates read-only bind mounts.</para> + + <para>Note that when this option is used in combination with <option>--private-users</option>, the resulting + mount points will be owned by the <constant>nobody</constant> user. That's because the mount and its files and + directories continue to be owned by the relevant host users and groups, which do not exist in the container, + and thus show up under the wildcard UID 65534 (nobody). If such bind mounts are created, it is recommended to + make them read-only, using <option>--bind-ro=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--inaccessible=</option></term> + + <listitem><para>Make the specified path inaccessible in the container. This over-mounts the specified path + (which must exist in the container) with a file node of the same type that is empty and has the most + restrictive access mode supported. This is an effective way to mask files, directories and other file system + objects from the container payload. This option may be used more than once in case all specified paths are + masked.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--tmpfs=</option></term> + + <listitem><para>Mount a tmpfs file system into the container. Takes a single absolute path argument that + specifies where to mount the tmpfs instance to (in which case the directory access mode will be chosen as 0755, + owned by root/root), or optionally a colon-separated pair of path and mount option string that is used for + mounting (in which case the kernel default for access mode and owner will be chosen, unless otherwise + specified). Backslash escapes are interpreted in the path, so <literal>\:</literal> may be used to embed colons + in the path.</para> + + <para>Note that this option cannot be used to replace the root file system of the container with a temporary + file system. However, the <option>--volatile=</option> option described below provides similar + functionality, with a focus on implementing stateless operating system images.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--overlay=</option></term> + <term><option>--overlay-ro=</option></term> + + <listitem><para>Combine multiple directory trees into one + overlay file system and mount it into the container. Takes a + list of colon-separated paths to the directory trees to + combine and the destination mount point.</para> + + <para>Backslash escapes are interpreted in the paths, so + <literal>\:</literal> may be used to embed colons in the paths. + </para> + + <para>If three or more paths are specified, then the last + specified path is the destination mount point in the + container, all paths specified before refer to directory trees + on the host and are combined in the specified order into one + overlay file system. The left-most path is hence the lowest + directory tree, the second-to-last path the highest directory + tree in the stacking order. If <option>--overlay-ro=</option> + is used instead of <option>--overlay=</option>, a read-only + overlay file system is created. If a writable overlay file + system is created, all changes made to it are written to the + highest directory tree in the stacking order, i.e. the + second-to-last specified.</para> + + <para>If only two paths are specified, then the second + specified path is used both as the top-level directory tree in + the stacking order as seen from the host, as well as the mount + point for the overlay file system in the container. At least + two paths have to be specified.</para> + + <para>The source paths may optionally be prefixed with <literal>+</literal> character. If so they are + taken relative to the image's root directory. The uppermost source path may also be specified as an + empty string, in which case a temporary directory below the host's <filename>/var/tmp/</filename> is + used. The directory is removed automatically when the container is shut down. This behaviour is + useful in order to make read-only container directories writable while the container is running. For + example, use <literal>--overlay=+/var::/var</literal> in order to automatically overlay a writable + temporary directory on a read-only <filename>/var/</filename> directory.</para> + + <para>For details about overlay file systems, see <ulink + url="https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt">overlayfs.txt</ulink>. Note + that the semantics of overlay file systems are substantially + different from normal file systems, in particular regarding + reported device and inode information. Device and inode + information may change for a file while it is being written + to, and processes might see out-of-date versions of files at + times. Note that this switch automatically derives the + <literal>workdir=</literal> mount option for the overlay file + system from the top-level directory tree, making it a sibling + of it. It is hence essential that the top-level directory tree + is not a mount point itself (since the working directory must + be on the same file system as the top-most directory + tree). Also note that the <literal>lowerdir=</literal> mount + option receives the paths to stack in the opposite order of + this switch.</para> + + <para>Note that this option cannot be used to replace the root file system of the container with an overlay + file system. However, the <option>--volatile=</option> option described above provides similar functionality, + with a focus on implementing stateless operating system images.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Input/Output Options</title> + + <variablelist> + <varlistentry> + <term><option>--console=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Configures how to set up standard input, output and error output for the container + payload, as well as the <filename>/dev/console</filename> device for the container. Takes one of + <option>interactive</option>, <option>read-only</option>, <option>passive</option>, + <option>pipe</option> or <option>autopipe</option>. If <option>interactive</option>, a pseudo-TTY is + allocated and made available as <filename>/dev/console</filename> in the container. It is then + bi-directionally connected to the standard input and output passed to + <command>systemd-nspawn</command>. <option>read-only</option> is similar but only the output of the + container is propagated and no input from the caller is read. If <option>passive</option>, a pseudo + TTY is allocated, but it is not connected anywhere. In <option>pipe</option> mode no pseudo TTY is + allocated, but the standard input, output and error output file descriptors passed to + <command>systemd-nspawn</command> are passed on — as they are — to the container payload, see the + following paragraph. Finally, <option>autopipe</option> mode operates like + <option>interactive</option> when <command>systemd-nspawn</command> is invoked on a terminal, and + like <option>pipe</option> otherwise. Defaults to <option>interactive</option> if + <command>systemd-nspawn</command> is invoked from a terminal, and <option>read-only</option> + otherwise.</para> + + <para>In <option>pipe</option> mode, <filename>/dev/console</filename> will not exist in the + container. This means that the container payload generally cannot be a full init system as init + systems tend to require <filename>/dev/console</filename> to be available. On the other hand, in this + mode container invocations can be used within shell pipelines. This is because intermediary pseudo + TTYs do not permit independent bidirectional propagation of the end-of-file (EOF) condition, which is + necessary for shell pipelines to work correctly. <emphasis>Note that the <option>pipe</option> mode + should be used carefully</emphasis>, as passing arbitrary file descriptors to less trusted container + payloads might open up unwanted interfaces for access by the container payload. For example, if a + passed file descriptor refers to a TTY of some form, APIs such as <constant>TIOCSTI</constant> may be + used to synthesize input that might be used for escaping the container. Hence <option>pipe</option> + mode should only be used if the payload is sufficiently trusted or when the standard + input/output/error output file descriptors are known safe, for example pipes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--pipe</option></term> + <term><option>-P</option></term> + + <listitem><para>Equivalent to <option>--console=pipe</option>.</para></listitem> + </varlistentry> + </variablelist> + + </refsect2><refsect2> + <title>Credentials</title> + + <variablelist> + <varlistentry> + <term><option>--load-credential=</option><replaceable>ID</replaceable>:<replaceable>PATH</replaceable></term> + <term><option>--set-credential=</option><replaceable>ID</replaceable>:<replaceable>VALUE</replaceable></term> + + <listitem><para>Pass a credential to the container. These two options correspond to the + <varname>LoadCredential=</varname> and <varname>SetCredential=</varname> settings in unit files. See + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details about these concepts, as well as the syntax of the option's arguments.</para> + + <para>Note: when <command>systemd-nspawn</command> runs as systemd system service it can propagate + the credentials it received via <varname>LoadCredential=</varname>/<varname>SetCredential=</varname> + to the container payload. A systemd service manager running as PID 1 in the container can further + propagate them to the services it itself starts. It is thus possible to easily propagate credentials + from a parent service manager to a container manager service and from there into its payload. This + can even be done recursively.</para> + + <para>In order to embed binary data into the credential data for <option>--set-credential=</option> + use C-style escaping (i.e. <literal>\n</literal> to embed a newline, or <literal>\x00</literal> to + embed a <constant>NUL</constant> byte. Note that the invoking shell might already apply unescaping + once, hence this might require double escaping!).</para></listitem> + </varlistentry> + + </variablelist> + + </refsect2><refsect2> + <title>Other</title> + + <variablelist> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect2> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>Examples</title> + + <example> + <title>Download a + <ulink url="https://getfedora.org">Fedora</ulink> image and start a shell in it</title> + + <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 \ + Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# 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> + and opens a shell in it.</para> + </example> + + <example> + <title>Build and boot a minimal Fedora distribution in a container</title> + + <programlisting># dnf -y --releasever=&fedora_latest_version; --installroot=/var/lib/machines/f&fedora_latest_version; \ + --disablerepo='*' --enablerepo=fedora --enablerepo=updates install \ + systemd passwd dnf fedora-release vim-minimal glibc-minimal-langpack +# systemd-nspawn -bD /var/lib/machines/f&fedora_latest_version;</programlisting> + + <para>This installs a minimal Fedora distribution into the + directory <filename index="false">/var/lib/machines/f&fedora_latest_version;</filename> + and then boots that OS in a namespace container. Because the installation + is located underneath the standard <filename>/var/lib/machines/</filename> + directory, it is also possible to start the machine using + <command>systemd-nspawn -M f&fedora_latest_version;</command>.</para> + </example> + + <example> + <title>Spawn a shell in a container of a minimal Debian unstable distribution</title> + + <programlisting># debootstrap unstable ~/debian-tree/ +# systemd-nspawn -D ~/debian-tree/</programlisting> + + <para>This installs a minimal Debian unstable distribution into + the directory <filename>~/debian-tree/</filename> and then + spawns a shell from this image in a namespace container.</para> + + <para><command>debootstrap</command> supports + <ulink url="https://www.debian.org">Debian</ulink>, + <ulink url="https://www.ubuntu.com">Ubuntu</ulink>, + and <ulink url="https://www.tanglu.org">Tanglu</ulink> + out of the box, so the same command can be used to install any of those. For other + distributions from the Debian family, a mirror has to be specified, see + <citerefentry project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + </example> + + <example> + <title>Boot a minimal + <ulink url="https://www.archlinux.org">Arch Linux</ulink> distribution in a container</title> + + <programlisting># pacstrap -c ~/arch-tree/ base +# systemd-nspawn -bD ~/arch-tree/</programlisting> + + <para>This installs a minimal Arch Linux distribution into the + directory <filename>~/arch-tree/</filename> and then boots an OS + in a namespace container in it.</para> + </example> + + <example> + <title>Install the + <ulink url="https://software.opensuse.org/distributions/tumbleweed">OpenSUSE Tumbleweed</ulink> + rolling distribution</title> + + <programlisting># zypper --root=/var/lib/machines/tumbleweed ar -c \ + https://download.opensuse.org/tumbleweed/repo/oss tumbleweed +# zypper --root=/var/lib/machines/tumbleweed refresh +# zypper --root=/var/lib/machines/tumbleweed install --no-recommends \ + systemd shadow zypper openSUSE-release vim +# systemd-nspawn -M tumbleweed passwd root +# systemd-nspawn -M tumbleweed -b</programlisting> + </example> + + <example> + <title>Boot into an ephemeral snapshot of the host system</title> + + <programlisting># systemd-nspawn -D / -xb</programlisting> + + <para>This runs a copy of the host system in a snapshot which is removed immediately when the container + exits. All file system changes made during runtime will be lost on shutdown, hence.</para> + </example> + + <example> + <title>Run a container with SELinux sandbox security contexts</title> + + <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container +# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \ + -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh</programlisting> + </example> + + <example> + <title>Run a container with an OSTree deployment</title> + + <programlisting># systemd-nspawn -b -i ~/image.raw \ + --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \ + --bind=+/sysroot/ostree/deploy/$OS/var:/var</programlisting> + </example> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>The exit code of the program executed in the container is + returned.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>dnf</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='archlinux'><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>zypper</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-oomd.service.xml b/man/systemd-oomd.service.xml new file mode 100644 index 0000000..9cb9c60 --- /dev/null +++ b/man/systemd-oomd.service.xml @@ -0,0 +1,98 @@ +<?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-or-later --> + +<refentry id="systemd-oomd.service" conditional='ENABLE_OOMD'> + + <refentryinfo> + <title>systemd-oomd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-oomd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-oomd.service</refname> + <refname>systemd-oomd</refname> + <refpurpose>A userspace out-of-memory (OOM) killer</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-oomd.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-oomd</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-oomd</command> is a system service that uses cgroups-v2 and pressure stall information (PSI) + to monitor and take action on processes before an OOM occurs in kernel space.</para> + + <para>You can enable monitoring and actions on units by setting <varname>ManagedOOMSwap=</varname> and/or + <varname>ManagedOOMMemoryPressure=</varname> to the appropriate value. <command>systemd-oomd</command> will + periodically poll enabled units' cgroup data to detect when corrective action needs to occur. When an action needs + to happen, it will only be performed on the descendant cgroups of the enabled units. More precisely, only cgroups with + <filename>memory.oom.group</filename> set to <constant>1</constant> and leaf cgroup nodes are eligible candidates. + Action will be taken recursively on all of the processes under the chosen candidate.</para> + + <para>See + <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information about the configuration of this service.</para> + </refsect1> + + <refsect1> + <title>Setup Information</title> + + <para>The system must be running systemd with a full unified cgroup hierarchy for the expected cgroups-v2 features. + Furthermore, resource accounting must be turned on for all units monitored by <command>systemd-oomd</command>. + The easiest way to turn on resource accounting is by ensuring the values for <varname>DefaultCPUAccounting</varname>, + <varname>DefaultIOAccounting</varname>, <varname>DefaultMemoryAccounting</varname>, and + <varname>DefaultTasksAccounting</varname> are set to <constant>true</constant> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>You will need a kernel compiled with PSI support. This is available in Linux 4.20 and above.</para> + + <para>The system must also have swap enabled for <command>systemd-oomd</command> to function correctly. With swap + enabled, the system spends enough time swapping pages to let <command>systemd-oomd</command> react. + Without swap, the system enters a livelocked state much more quickly and may prevent <command>systemd-oomd</command> + from responding in a reasonable amount of time. See + <ulink url="https://chrisdown.name/2018/01/02/in-defence-of-swap.html">"In defence of swap: common misconceptions"</ulink> + for more details on swap.</para> + + <para>Be aware that if you intend to enable monitoring and actions on <filename>user.slice</filename>, + <filename>user-$UID.slice</filename>, or their ancestor cgroups, it is highly recommended that your programs be + managed by the systemd user manager to prevent running too many processes under the same session scope (and thus + avoid a situation where memory intensive tasks trigger <command>systemd-oomd</command> to kill everything under the + cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the + systemd user manager.</para> + </refsect1> + + <refsect1> + <title>Usage Recommendations</title> + + <para><varname>ManagedOOMSwap=</varname> works with the system-wide swap values, so setting it on the root slice + <filename>-.slice</filename>, and allowing all descendant cgroups to be eligible candidates may make the most + sense.</para> + + <para><varname>ManagedOOMMemoryPressure=</varname> tends to work better on the cgroups below the root slice + <filename>-.slice</filename>. For units which tend to have processes that are less latency sensitive (e.g. + <filename>system.slice</filename>), a higher limit like the default of 60% may be acceptable, as those processes + can usually ride out slowdowns caused by lack of memory without serious consequences. However, something like + <filename>user@$UID.service</filename> may prefer a much lower value like 40%.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>oomctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-path.xml b/man/systemd-path.xml new file mode 100644 index 0000000..f2ca87d --- /dev/null +++ b/man/systemd-path.xml @@ -0,0 +1,81 @@ +<?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-or-later --> + +<refentry id="systemd-path" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-path</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-path</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-path</refname> + <refpurpose>List and query system and user paths</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-path</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-path</command> may be used to query system + and user paths. The tool makes many of the paths described in + <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry> + available for querying.</para> + + <para>When invoked without arguments, a list of known paths and + their current values is shown. When at least one argument is + passed, the path with this name is queried and its value shown. + The variables whose name begins with <literal>search-</literal> + do not refer to individual paths, but instead to a list of + colon-separated search paths, in their order of precedence.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--suffix=</option></term> + + <listitem><para>Printed paths are suffixed by the specified string.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-portabled.service.xml b/man/systemd-portabled.service.xml new file mode 100644 index 0000000..ce91b4f --- /dev/null +++ b/man/systemd-portabled.service.xml @@ -0,0 +1,50 @@ +<?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-or-later --> + +<refentry id="systemd-portabled.service" conditional='ENABLE_PORTABLED'> + + <refentryinfo> + <title>systemd-portabled.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-portabled.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-portabled.service</refname> + <refname>systemd-portabled</refname> + <refpurpose>Portable service manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-portabled.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-portabled</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-portabled</command> is a system service that may be used to attach, detach and inspect + portable service images.</para> + + <para>Most of <command>systemd-portabled</command>'s functionality is accessible through the + <citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> command.</para> + + <para>See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable + Services Documentation</ulink> for details about the concepts this service implements.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-pstore.service.xml b/man/systemd-pstore.service.xml new file mode 100644 index 0000000..306f109 --- /dev/null +++ b/man/systemd-pstore.service.xml @@ -0,0 +1,117 @@ +<?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-or-later --> + +<refentry id="systemd-pstore" conditional='ENABLE_PSTORE' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-pstore.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-pstore.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-pstore.service</refname> + <refname>systemd-pstore</refname> + <refpurpose>A service to archive contents of pstore</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> file is read and the <filename>/sys/fs/pstore</filename> + directory contents are processed according to the options. Pstore files are written to the + journal, and optionally saved into <filename>/var/lib/systemd/pstore</filename>.</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> + + <refsect2> + <title>Controlling kernel parameters</title> + + <para> The kernel has two parameters, + <filename>/sys/module/kernel/parameters/crash_kexec_post_notifiers</filename> and + <filename>/sys/module/printk/parameters/always_kmsg_dump</filename>, + that control writes into pstore. + The crash_kexec_post_notifiers parameter enables the kernel to write + dmesg (including stack trace) into pstore upon a panic or crash, and + printk.always_kmsg_dump parameter enables the kernel to write dmesg + upon a normal shutdown (shutdown, reboot, halt). These kernel + parameters are managed via the + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + mechanism, specifically the file <filename>/usr/lib/tmpfiles/systemd-pstore.conf</filename>. + </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-quotacheck.service.xml b/man/systemd-quotacheck.service.xml new file mode 100644 index 0000000..4e2a5a4 --- /dev/null +++ b/man/systemd-quotacheck.service.xml @@ -0,0 +1,69 @@ +<?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-or-later --> +<refentry id="systemd-quotacheck.service" conditional='ENABLE_QUOTACHECK'> + + <refentryinfo> + <title>systemd-quotacheck.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-quotacheck.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-quotacheck.service</refname> + <refname>systemd-quotacheck</refname> + <refpurpose>File system quota checker logic</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-quotacheck.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-quotacheck</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-quotacheck.service</filename> is a service + responsible for file system quota checks. It is run once at boot + after all necessary file systems are mounted. It is pulled in only + if at least one file system has quotas enabled.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-quotacheck</filename> understands one + kernel command line parameter:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>quotacheck.mode=</varname></term> + + <listitem><para>One of <literal>auto</literal>, + <literal>force</literal>, <literal>skip</literal>. Controls + the mode of operation. The default is <literal>auto</literal>, + and ensures that file system quota checks are done when the + file system quota checker deems them necessary. + <literal>force</literal> unconditionally results in full file + system quota checks. <literal>skip</literal> skips any file + system quota checks.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>quotacheck</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-random-seed.service.xml b/man/systemd-random-seed.service.xml new file mode 100644 index 0000000..3137ed0 --- /dev/null +++ b/man/systemd-random-seed.service.xml @@ -0,0 +1,92 @@ +<?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-or-later --> +<refentry id="systemd-random-seed.service" conditional='ENABLE_RANDOMSEED'> + + <refentryinfo> + <title>systemd-random-seed.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-random-seed.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-random-seed.service</refname> + <refname>systemd-random-seed</refname> + <refpurpose>Load and save the system random seed at boot and shutdown</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-random-seed.service</filename></para> + <para><filename>/usr/lib/systemd/random-seed</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <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, the 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>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>4</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-rc-local-generator.xml b/man/systemd-rc-local-generator.xml new file mode 100644 index 0000000..9e17524 --- /dev/null +++ b/man/systemd-rc-local-generator.xml @@ -0,0 +1,56 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd-rc-local-generator" conditional='HAVE_SYSV_COMPAT'> + <refentryinfo> + <title>systemd-rc-local-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-rc-local-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-rc-local-generator</refname> + <refpurpose>Compatibility generator for starting <filename>&RC_LOCAL_PATH;</filename> during boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-rc-local-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-rc-local-generator</filename> is a generator that checks whether + <filename>&RC_LOCAL_PATH;</filename> exists and is executable, and if it is pulls the + <filename>rc-local.service</filename> unit into the boot process. This unit is responsible for running + this script during late boot. Note that the script will be run with slightly different semantics than the + original System V version, which was run "last" in the boot process, which is a concept that does not + translate to systemd. The script is run after <filename>network.target</filename>, but in parallel with + most other regular system services.</para> + + <para>Support for <filename>&RC_LOCAL_PATH;</filename> is provided for compatibility with specific System + V systems only. However, it is strongly recommended to avoid making use of this script today, and instead + provide proper unit files with appropriate dependencies for any scripts to run during the boot process. + Note that the path to the script is set a compile time and varies between distributions.</para> + + <para><filename>systemd-rc-local-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-remount-fs.service.xml b/man/systemd-remount-fs.service.xml new file mode 100644 index 0000000..be74307 --- /dev/null +++ b/man/systemd-remount-fs.service.xml @@ -0,0 +1,70 @@ +<?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-or-later --> +<refentry id="systemd-remount-fs.service"> + + <refentryinfo> + <title>systemd-remount-fs.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-remount-fs.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-remount-fs.service</refname> + <refname>systemd-remount-fs</refname> + <refpurpose>Remount root and kernel file systems</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-remount-fs.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-remount-fs</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-remount-fs.service</filename> is an early boot service that applies mount options + listed in <citerefentry + project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, or + gathered from the partition table (when + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is active) to the root file system, the <filename>/usr/</filename> file system, and the kernel API file + systems. This is required so that the mount options of these file systems — which are pre-mounted by the + kernel, the initial RAM disk, container environments or system manager code — are updated to those + configured in <filename>/etc/fstab</filename> and the other sources. This service ignores normal file + systems and only changes the root file system (i.e. <filename>/</filename>), <filename>/usr/</filename>, + and the virtual kernel API file systems such as <filename>/proc/</filename>, <filename>/sys/</filename> or + <filename>/dev/</filename>. This service executes no operation if no configuration is found + (<filename>/etc/fstab</filename> does not exist or lists no entries for the mentioned file systems, or + the partition table does not contain relevant entries).</para> + + <para>For a longer discussion of kernel API file systems see + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems">API + File Systems</ulink>.</para> + + <para>Note: <filename>systemd-remount-fs.service</filename> is usually pulled in by + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + hence it is also affected by the kernel command line option <varname>fstab=</varname>, which may be used + to disable the generator. It may also pulled in by + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + which is affected by <varname>systemd.gpt_auto</varname> and other options.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-repart.xml b/man/systemd-repart.xml new file mode 100644 index 0000000..16add32 --- /dev/null +++ b/man/systemd-repart.xml @@ -0,0 +1,325 @@ +<?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-or-later --> + +<refentry id="systemd-repart" conditional='ENABLE_REPART' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-repart</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-repart</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-repart</refname> + <refname>systemd-repart.service</refname> + <refpurpose>Automatically grow and add partitions</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-repart</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat"><replaceable><optional>BLOCKDEVICE</optional></replaceable></arg> + </cmdsynopsis> + + <para><filename>systemd-repart.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-repart</command> grows and adds partitions to a partition table, based on the + configuration files described in + <citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>If invoked with no arguments, it operates on the block device backing the root file system partition + of the OS, thus growing and adding partitions of the booted OS image itself. When called in the initial + RAM disk it operates on the block device backing <filename>/sysroot/</filename> instead, i.e. on the + block device the system will soon transition into. The <filename>systemd-repart.service</filename> + service is generally run at boot in the initial RAM disk, in order to augment the partition table of the + OS before its partitions are mounted. <command>systemd-repart</command> (mostly) operates in a purely + incremental mode: it only grows existing and adds new partitions; it does not shrink, delete or move + existing partitions. The service is intended to be run on every boot, but when it detects that the + partition table already matches the installed <filename>repart.d/*.conf</filename> configuration + files, it executes no operation.</para> + + <para><command>systemd-repart</command> is intended to be used when deploying OS images, to automatically + adjust them to the system they are running on, during first boot. This way the deployed image can be + minimal in size and may be augmented automatically at boot when needed, taking possession of disk space + available but not yet used. Specifically the following use cases are among those covered:</para> + + <itemizedlist> + <listitem><para>The root partition may be grown to cover the whole available disk space.</para></listitem> + <listitem><para>A <filename>/home/</filename>, swap or <filename>/srv/</filename> partition can be + added.</para></listitem> + <listitem><para>A second (or third, …) root partition may be added, to cover A/B style setups + where a second version of the root file system is alternatingly used for implementing update + schemes. The deployed image would carry only a single partition ("A") but on first boot a second + partition ("B") for this purpose is automatically created.</para></listitem> + </itemizedlist> + + <para>The algorithm executed by <command>systemd-repart</command> is roughly as follows:</para> + + <orderedlist> + <listitem><para>The <filename>repart.d/*.conf</filename> configuration files are loaded and parsed, + and ordered by filename (without the directory prefix).</para></listitem> + + <listitem><para>The partition table already existing on the block device is loaded and + parsed.</para></listitem> + + <listitem><para>The existing partitions in the partition table are matched up with the + <filename>repart.d/*.conf</filename> files by GPT partition type UUID. The first existing partition + of a specific type is assigned the first configuration file declaring the same type. The second + existing partition of a specific type is then assigned the second configuration file declaring the same + type, and so on. After this iterative assigning is complete any left-over existing partitions that have + no matching configuration file are considered "foreign" and left as they are. And any configuration + files for which no partition currently exists are understood as a request to create such a + partition.</para></listitem> + + <listitem><para>Taking the size constraints and weights declared in the configuration files into + account, all partitions that shall be created are now allocated to the disk, taking up all free space, + always respecting the size and padding requests. Similar, existing partitions that are determined to + grow are grown. New partitions are always appended to the end of the existing partition table, taking + the first partition table slot whose index is greater than the indexes of all existing + partitions. Partition table slots are never reordered and thus partition numbers are ensured to remain + stable. Note that this allocation happens in RAM only, the partition table on disk is not updated + yet.</para></listitem> + + <listitem><para>All existing partitions for which configuration files exist and which currently have no + GPT partition label set will be assigned a label, either explicitly configured in the configuration or + (if that's missing) derived automatically from the partition type. The same is done for all partitions + that are newly created. These assignments are done in RAM only, too, the disk is not updated + yet.</para></listitem> + + <listitem><para>Similarly, all existing partitions for which configuration files exist and which + currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically + hashed from a common seed value together with the partition type UUID (and a counter in case multiple + partitions of the same type are defined), see below. The same is done for all partitions that are + created anew. These assignments are done in RAM only, too, the disk is not updated + yet.</para></listitem> + + <listitem><para>Similarly, if the disk's volume UUID is all zeroes it is also initialized, also + cryptographically hashed from the same common seed value. Also, in RAM only, too.</para></listitem> + + <listitem><para>The disk space assigned to new partitions (i.e. what was previously considered free + space but is no longer) is now erased. Specifically, all file system signatures are removed, and if the + device supports it the <constant>BLKDISCARD</constant> I/O control command is issued to inform the + hardware that the space is empty now. In addition any "padding" between partitions and at the end of + the device is similarly erased.</para></listitem> + + <listitem><para>The new partition table is finally written to disk. The kernel is asked to reread the + partition table.</para></listitem> + </orderedlist> + + <para>As exception to the normally strictly incremental operation, when called in a special "factory + reset" mode, <command>systemd-repart</command> may also be used to erase existing partitions to + reset an installation back to vendor defaults. This mode of operation is used when either the + <option>--factory-reset=yes</option> switch is passed on the tool's command line, or the + <option>systemd.factory_reset=yes</option> option specified on the kernel command line, or the + <varname>FactoryReset</varname> EFI variable (vendor UUID + <constant>8cf2644b-4b0b-428f-9387-6d876050dc67</constant>) is set to "yes". It alters the algorithm above + slightly: between the 3rd and the 4th step above any partition marked explicitly via the + <varname>FactoryReset=</varname> boolean is deleted, and the algorithm restarted, thus immediately + re-creating these partitions anew empty.</para> + + <para>Note that <command>systemd-repart</command> only changes partition tables, it does not create or + resize any file systems within these partitions. A separate mechanism should be used for that, for + example + <citerefentry><refentrytitle>systemd-growfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> and + <command>systemd-makefs</command>.</para> + + <para>The UUIDs identifying the new partitions created (or assigned to existing partitions that have no + UUID yet), as well as the disk as a whole are hashed cryptographically from a common seed value. This + seed value is usually the + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> of the + system, so that the machine ID reproducibly determines the UUIDs assigned to all partitions. If the + machine ID cannot be read (or the user passes <option>--seed=random</option>, see below) the seed is + generated randomly instead, so that the partition UUIDs are also effectively random. The seed value may + also be set explicitly, formatted as UUID via the <option>--seed=</option> option. By hashing these UUIDs + from a common seed images prepared with this tool become reproducible and the result of the algorithm + above deterministic.</para> + + <para>The positional argument should specify the block device to operate on. Instead of a block device + node path a regular file may be specified too, in which case the command operates on it like it would if + a loopback block device node was specified with the file attached. If <option>--empty=create</option> is + specified the specified path is created as regular file, which is useful for generating disk images from + scratch.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--dry-run=</option></term> + <listitem><para>Takes a boolean. If this switch is not specified <option>--dry-run=yes</option> is + the implied default. Controls whether <filename>systemd-repart</filename> executes the requested + re-partition operations or whether it should only show what it would do. Unless + <option>--dry-run=no</option> is specified <filename>systemd-repart</filename> will not actually + touch the device's partition table.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--empty=</option></term> + <listitem><para>Takes one of <literal>refuse</literal>, <literal>allow</literal>, + <literal>require</literal>, <literal>force</literal> or <literal>create</literal>. Controls how to + operate on block devices that are entirely empty, i.e. carry no partition table/disk label yet. If + this switch is not specified the implied default is <literal>refuse</literal>.</para> + + <para>If <literal>refuse</literal> <command>systemd-repart</command> requires that the block device + it shall operate on already carries a partition table and refuses operation if none is found. If + <literal>allow</literal> the command will extend an existing partition table or create a new one if + none exists. If <literal>require</literal> the command will create a new partition table if none + exists so far, and refuse operation if one already exists. If <literal>force</literal> it will create + a fresh partition table unconditionally, erasing the disk fully in effect. If + <literal>force</literal> no existing partitions will be taken into account or survive the + operation. Hence: use with care, this is a great way to lose all your data. If + <literal>create</literal> a new loopback file is create under the path passed via the device node + parameter, of the size indicated with <option>--size=</option>, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--discard=</option></term> + + <listitem><para>Takes a boolean. If this switch is not specified <option>--discard=yes</option> is + the implied default. Controls whether to issue the <constant>BLKDISCARD</constant> I/O control + command on the space taken up by any added partitions or on the space in between them. Usually, it's + a good idea to issue this request since it tells the underlying hardware that the covered blocks + shall be considered empty, improving performance. If operating on a regular file instead of a block + device node, a sparse file is generated.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--size=</option></term> + + <listitem><para>Takes a size in bytes, using the usual K, M, G, T suffixes, or the special value + <literal>auto</literal>. If used the specified device node path must refer to a regular file, which + is then grown to the specified size if smaller, before any change is made to the partition table. If + specified as <literal>auto</literal> the minimal size for the disk image is automatically determined + (i.e. the minimal sizes of all partitions are summed up, taking space for additional metadata into + account). This switch is not supported if the specified node is a block device. This switch has no + effect if the file is already as large as the specified size or larger. The specified size is + implicitly rounded up to multiples of 4096. When used with <option>--empty=create</option> this + specifies the initial size of the loopback file to create.</para> + + <para>The <option>--size=auto</option> option takes the sizes of pre-existing partitions into + account. However, it does not accommodate for partition tables that are not tightly packed: the + configured partitions might still not fit into the backing device if empty space exists between + pre-existing partitions (or before the first partition) that cannot be fully filled by partitions to + grow or create.</para> + + <para>Also note that the automatic size determination does not take files or directories specified + with <option>CopyFiles=</option> into account: operation might fail if the specified files or + directories require more disk space then the configured per-partition minimal size + limit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--factory-reset=</option></term> + + <listitem><para>Takes boolean. If this switch is not specified <option>--factory=reset=no</option> is + the implied default. Controls whether to operate in "factory reset" mode, see above. If set to true + this will remove all existing partitions marked with <varname>FactoryReset=</varname> set to yes + early while executing the re-partitioning algorithm. Use with care, this is a great way to lose all + your data. Note that partition files need to explicitly turn <varname>FactoryReset=</varname> on, as + the option defaults to off. If no partitions are marked for factory reset this switch has no + effect. Note that there are two other methods to request factory reset operation: via the kernel + command line and via an EFI variable, see above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--can-factory-reset</option></term> + + <listitem><para>If this switch is specified the disk is not re-partitioned. Instead it is determined + if any existing partitions are marked with <varname>FactoryReset=</varname>. If there are the tool + will exit with exit status zero, otherwise non-zero. This switch may be used to quickly determine + whether the running system supports a factory reset mechanism built on + <command>systemd-repart</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root=</option></term> + + <listitem><para>Takes a path to a directory to use as root file system when searching for + <filename>repart.d/*.conf</filename> files and for the machine ID file to use as seed. By default + when invoked on the regular system this defaults to the host's root file system + <filename>/</filename>. If invoked from the initial RAM disk this defaults to + <filename>/sysroot/</filename>, so that the tool operates on the configuration and machine ID stored + in the root file system later transitioned into itself.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--seed=</option></term> + + <listitem><para>Takes a UUID as argument or the special value <constant>random</constant>. If a UUID + is specified the UUIDs to assign to partitions and the partition table itself are derived via + cryptographic hashing from it. If not specified it is attempted to read the machine ID from the host + (or more precisely, the root directory configured via <option>--root=</option>) and use it as seed + instead, falling back to a randomized seed otherwise. Use <option>--seed=random</option> to force a + randomized seed. Explicitly specifying the seed may be used to generated strictly reproducible + partition tables.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--pretty=</option></term> + + <listitem><para>Takes a boolean argument. If this switch is not specified, it defaults to on when + called from an interactive terminal and off otherwise. Controls whether to show a user friendly table + and graphic illustrating the changes applied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--json=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Shows output formatted as JSON. Expects one of <literal>short</literal> (for the + shortest possible output without any redundant whitespace or line breaks), <literal>pretty</literal> + (for a pretty version of the same, with indentation and line breaks) or <literal>off</literal> (to turn + off json output).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--definitions=</option></term> + + <listitem><para>Takes a file system path. If specified the <filename>*.conf</filename> files are read + from the specified directory instead of searching in <filename>/usr/lib/repart.d/*.conf</filename>, + <filename>/etc/repart.d/*.conf</filename>, + <filename>/run/repart.d/*.conf</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--key-file=</option></term> + + <listitem><para>Takes a file system path. Configures the encryption key to use when setting up LUKS2 + volumes configured with the <varname>Encrypt=</varname> setting in partition files. Should refer to a + regular file containing the key, or an <constant>AF_UNIX</constant> stream socket in the file + system. In the latter case a connection is made to it and the key read from it. If this switch is not + specified the empty key (i.e. zero length key) is used. This behaviour is useful for setting up encrypted + partitions during early first boot that receive their user-supplied password only in a later setup + step.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml new file mode 100644 index 0000000..12aefd5 --- /dev/null +++ b/man/systemd-resolved.service.xml @@ -0,0 +1,381 @@ +<?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-or-later --> + +<refentry id="systemd-resolved.service" conditional='ENABLE_RESOLVE'> + + <refentryinfo> + <title>systemd-resolved.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-resolved.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-resolved.service</refname> + <refname>systemd-resolved</refname> + <refpurpose>Network Name Resolution manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-resolved.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-resolved</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-resolved</command> is a system service that provides network name resolution to + local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR + and MulticastDNS resolver and responder. Local applications may submit network name resolution requests + via three interfaces:</para> + + <itemizedlist> + <listitem><para>The native, fully-featured API <command>systemd-resolved</command> exposes on the bus, + see + <citerefentry><refentrytitle>org.freedesktop.resolve1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. Usage of this API is generally recommended to clients as it is asynchronous and fully + featured (for example, properly returns DNSSEC validation status and interface scope for addresses as + necessary for supporting link-local networking).</para></listitem> + + <listitem><para>The glibc + <citerefentry project='man-pages'><refentrytitle>getaddrinfo</refentrytitle><manvolnum>3</manvolnum></citerefentry> + API as defined by <ulink url="https://tools.ietf.org/html/rfc3493">RFC3493</ulink> and its related + resolver functions, including + <citerefentry project='man-pages'><refentrytitle>gethostbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This API is widely supported, including beyond the Linux platform. In its current form it does not + expose DNSSEC validation status information however, and is synchronous only. This API is backed by the + glibc Name Service Switch + (<citerefentry project='man-pages'><refentrytitle>nss</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + Usage of the glibc NSS module + <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry> is + required in order to allow glibc's NSS resolver functions to resolve hostnames via + <command>systemd-resolved</command>.</para></listitem> + + <listitem><para>Additionally, <command>systemd-resolved</command> provides a local DNS stub listener on + IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, + bypassing any local API may be directed to this stub, in order to connect them to + <command>systemd-resolved</command>. Note however that it is strongly recommended that local programs + use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts + (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS + protocol.</para></listitem> + </itemizedlist> + + <para>The DNS servers contacted are determined from the global settings in + <filename>/etc/systemd/resolved.conf</filename>, the per-link static settings in + <filename>/etc/systemd/network/*.network</filename> files (in case + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is used), the per-link dynamic settings received over DHCP, information provided via + <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, and any + DNS server information made available by other system services. See + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> and + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details about systemd's own configuration files for DNS servers. To improve compatibility, + <filename>/etc/resolv.conf</filename> is read in order to discover configured system DNS servers, but + only if it is not a symlink to <filename>/run/systemd/resolve/stub-resolv.conf</filename>, + <filename>/usr/lib/systemd/resolv.conf</filename> or + <filename>/run/systemd/resolve/resolv.conf</filename> (see below).</para> + + </refsect1> + + <refsect1> + <title>Synthetic Records</title> + + <para><command>systemd-resolved</command> synthetizes DNS resource records (RRs) for the following + cases:</para> + + <itemizedlist> + <listitem><para>The local, configured hostname is resolved to all locally configured IP addresses + ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local + loopback interface) and the IPv6 address ::1 (which is the local host).</para></listitem> + + <listitem><para>The hostnames <literal>localhost</literal> and <literal>localhost.localdomain</literal> + as well as any hostname ending in <literal>.localhost</literal> or + <literal>.localhost.localdomain</literal> are resolved to the IP addresses 127.0.0.1 and ::1. + </para></listitem> + + <listitem><para>The hostname <literal>_gateway</literal> is resolved to all current default routing + gateway addresses, ordered by their metric. This assigns a stable hostname to the current gateway, + useful for referencing it independently of the current network configuration state.</para></listitem> + + <listitem><para>The mappings defined in <filename>/etc/hosts</filename> are resolved to their + configured addresses and back, but they will not affect lookups for non-address types (like MX). + Support for <filename>/etc/hosts</filename> may be disabled with <varname>ReadEtcHosts=no</varname>, + see <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </itemizedlist> + </refsect1> + + <refsect1> + <title>Protocols and Routing</title> + + <para>Lookup requests are routed to the available DNS servers, LLMNR, and MulticastDNS interfaces + according to the following rules:</para> + + <itemizedlist> + <listitem><para>Names for which synthetic records are generated (the local hostname, + <literal>localhost</literal> and <literal>localdomain</literal>, local gateway, as listed in the + previous section) and addresses configured in <filename>/etc/hosts</filename> are never routed to the + network and a reply is sent immediately.</para></listitem> + + <listitem><para>Single-label names are resolved using LLMNR on all local interfaces where LLMNR is + enabled. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are + only sent via LLMNR on IPv6. Note that lookups for single-label synthetized names are not routed to + LLMNR, MulticastDNS or unicast DNS.</para></listitem> + + <listitem><para>Queries for the address records (A and AAAA) of single-label non-synthetized names are + resolved via unicast DNS using search domains. For any interface which defines search domains, such + look-ups are routed to that interface, suffixed with each of the search domains defined on that + interface in turn. When global search domains are defined, such look-ups are routed to all interfaces, + suffixed by each of the global search domains in turn. Additionally, lookup of single-label names via + unicast DNS may be enabled with the <varname>ResolveUnicastSingleLabel=yes</varname> setting. The + details of which servers are queried and how the final reply is chosen are described below. Note that + this means that address queries for single-label names are never sent out to remote DNS servers by + default, and resoulution is only possible if search domains are defined.</para></listitem> + + <listitem><para>Multi-label names with the domain suffix <literal>.local</literal> are resolved using + MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups + are sent via IPv4 and IPv6 address lookups are sent via IPv6.</para></listitem> + + <listitem><para>Queries for multi-label names are routed via unicast DNS on local interfaces that have + a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces + are used is determined by the routing logic based on search and route-only domains, described below. + Note that by default, lookups for domains with the <literal>.local</literal> suffix are not routed to + DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server + and interface. This means that on networks where the <literal>.local</literal> domain is defined in a + site-specific DNS server, explicit search or routing domains need to be configured to make lookups work + within this DNS domain. Note that these days, it's generally recommended to avoid defining + <literal>.local</literal> in a DNS server, as <ulink + url="https://tools.ietf.org/html/rfc6762">RFC6762</ulink> reserves this domain for exclusive + MulticastDNS use.</para></listitem> + + <listitem><para>Address lookups (reverse lookups) are routed similarly to multi-label names, with the + exception that addresses from the link-local address range are never routed to unicast DNS and are only + resolved using LLMNR and MulticastDNS (when enabled).</para></listitem> + </itemizedlist> + + <para>If lookups are routed to multiple interfaces, the first successful response is returned (thus + effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces, + the last failing response is returned.</para> + + <para>Routing of lookups is determined by the per-interface routing domains (search and route-only) and + global search domains. See + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> and + <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for a + description how those settings are set dynamically and the discussion of <varname>Domains=</varname> in + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a + description of globally configured DNS settings.</para> + + <para>The following query routing logic applies for unicast DNS traffic:</para> + + <itemizedlist> + <listitem><para>If a name to look up matches (that is: is equal to or has as suffix) any of the + configured routing domains (search or route-only) of any link, or the globally configured DNS settings, + "best matching" routing domain is determined: the matching one with the most labels. The query is then + sent to all DNS servers of any links or the globally configured DNS servers associated with this "best + matching" routing domain. (Note that more than one link might have this same "best matching" routing + domain configured, in which case the query is sent to all of them in parallel).</para> + + <para>In case of single-label names, when search domains are defined, the same logic applies, except + that the name is first suffixed by each of the search domains in turn. Note that this search logic + doesn't apply to any names with at least one dot. Also see the discussion about compatibility with + the traditional glibc resolver below.</para></listitem> + + <listitem><para>If a query does not match any configured routing domain (either per-link or global), it + is sent to all DNS servers that are configured on links with the <varname>DefaultRoute=</varname> + option set, as well as the globally configured DNS server.</para></listitem> + + <listitem><para>If there is no link configured as <varname>DefaultRoute=</varname> and no global DNS + server configured, one of the compiled-in fallback DNS servers is used.</para></listitem> + + <listitem><para>Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined. + </para></listitem> + </itemizedlist> + + <para>The <varname>DefaultRoute=</varname> 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 a route-only domain other than + <literal>~.</literal>, it defaults to false, otherwise to true.</para> + + <para>Effectively this means: in order to support single-label non-synthetized names, define appropriate + search domains. In order to preferably route all DNS queries not explicitly matched by routing domain + configuration to a specific link, configure a <literal>~.</literal> route-only domain on it. This will + ensure that other links will not be considered for these queries (unless they too carry such a routing + domain). In order to route all such DNS queries to a specific link only if no other link is preferred, + set the <varname>DefaultRoute=</varname> option for the link to true and do not configure a + <literal>~.</literal> route-only domain on it. Finally, in order to ensure that a specific link never + receives any DNS traffic not matching any of its configured routing domains, set the + <varname>DefaultRoute=</varname> option for it to false.</para> + + <para>See + <citerefentry><refentrytitle>org.freedesktop.resolve1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the D-Bus APIs <filename>systemd-resolved</filename> provides.</para> + </refsect1> + + <refsect1> + <title>Compatibility with the traditional glibc stub resolver</title> + + <para>This section provides a short summary of differences in the stub resolver implemented by + <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry> together + with <command>systemd-resolved</command> and the tranditional stub resolver implemented in + <citerefentry><refentrytitle>nss-dns</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + + <itemizedlist> + <listitem><para>Some names are always resolved internally (see Synthetic Records above). Traditionally + they would be resolved by <filename>nss-files</filename>, and only if provided in + <filename>/etc/hosts</filename>.</para></listitem> + + <listitem><para>Single-label names are not resolved for A and AAAA records using unicast DNS (unless + overridden with <varname>ResolveUnicastSingleLabel=</varname>, see + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + This is similar to the <option>no-tld-query</option> option being set in + <citerefentry><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + + <listitem><para>Search domains are not used for <emphasis>suffixing</emphasis> of multi-label names. + (Search domains are nevertheless used for lookup <emphasis>routing</emphasis>, for names that were + originally specified as single-label or multi-label.) Any name with at least one dot is always + interpreted as a FQDN. <filename>nss-dns</filename> would resolve names both as relative (using search + domains) and absolute FQDN names. Some names would be resolved as relative first, and after that query + has failed, as absolute, while other names would be resolved in opposite order. The + <varname>ndots</varname> option in <filename>/etc/resolv.conf</filename> was used to control how many + dots the name needs to have to be resolved as relative first. This stub resolver does not implement + this at all: multi-label names are only resolved as FQDNs. (There are currently more than 1500 + top-level domain names defined, and new ones are added regularly, often using "attractive" names that + are also likely to be used locally. Not looking up multi-label names in this fashion avoids fragility + in both directions: a valid global name could be obscured by a local name, and resolution of a relative + local name could suddenly break when a new top-level domain is created, or when a new subdomain of a + top-level domain in registered. Resolving any given name as either relative or absolute avoids this + ambiguity.)</para></listitem> + + <listitem><para>This resolver has a notion of the special <literal>.local</literal> domain used for + MulticastDNS, and will not route queries with that suffix to unicast DNS servers unless explicitly + configured, see above. Also, reverse lookups for link-local addresses are not sent to unicast DNS + servers.</para></listitem> + + <listitem><para>This resolver reads and caches <filename>/etc/hosts</filename> internally. (In other + words, <filename>nss-resolve</filename> replaces <filename>nss-files</filename> in addition to + <filename>nss-dns</filename>). Entries in <filename>/etc/hosts</filename> have highest priority.</para> + </listitem> + + <listitem><para>This resolver also implements LLMNR and MulticastDNS in addition to the classic unicast + DNS protocol, and will resolve single-label names using LLMNR (when enabled) and names ending in + <literal>.local</literal> using MulticastDNS (when enabled).</para></listitem> + + <listitem><para>Environment variables <varname>$LOCALDOMAIN</varname> and + <varname>$RES_OPTIONS</varname> described in + <citerefentry><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> are not + supported currently.</para></listitem> + </itemizedlist> + </refsect1> + + <refsect1> + <title><filename>/etc/resolv.conf</filename></title> + + <para>Four modes of handling <filename>/etc/resolv.conf</filename> (see + <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) are + supported:</para> + + <itemizedlist> + <listitem><para><command>systemd-resolved</command> maintains the + <filename>/run/systemd/resolve/stub-resolv.conf</filename> file for compatibility with traditional + Linux programs. This file may be symlinked from <filename>/etc/resolv.conf</filename>. This file lists + the 127.0.0.53 DNS stub (see above) as the only DNS server. It also contains a list of search domains + that are in use by systemd-resolved. The list of search domains is always kept up-to-date. Note that + <filename>/run/systemd/resolve/stub-resolv.conf</filename> should not be used directly by applications, + but only through a symlink from <filename>/etc/resolv.conf</filename>. This file may be symlinked from + <filename>/etc/resolv.conf</filename> in order to connect all local clients that bypass local DNS APIs + to <command>systemd-resolved</command> with correct search domains settings. This mode of operation is + recommended.</para></listitem> + + <listitem><para>A static file <filename>/usr/lib/systemd/resolv.conf</filename> is provided that lists + the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from + <filename>/etc/resolv.conf</filename> in order to connect all local clients that bypass local DNS APIs + to <command>systemd-resolved</command>. This file does not contain any search domains. + </para></listitem> + + <listitem><para><command>systemd-resolved</command> maintains the + <filename>/run/systemd/resolve/resolv.conf</filename> file for compatibility with traditional Linux + programs. This file may be symlinked from <filename>/etc/resolv.conf</filename> and is always kept + up-to-date, containing information about all known DNS servers. Note the file format's limitations: it + does not know a concept of per-interface DNS servers and hence only contains system-wide DNS server + definitions. Note that <filename>/run/systemd/resolve/resolv.conf</filename> should not be used + directly by applications, but only through a symlink from <filename>/etc/resolv.conf</filename>. If + this mode of operation is used local clients that bypass any local DNS API will also bypass + <command>systemd-resolved</command> and will talk directly to the known DNS servers.</para></listitem> + + <listitem><para>Alternatively, <filename>/etc/resolv.conf</filename> may be managed by other packages, + in which case <command>systemd-resolved</command> will read it for DNS configuration data. In this mode + of operation <command>systemd-resolved</command> is consumer rather than provider of this configuration + file. </para></listitem> + </itemizedlist> + + <para>Note that the selected mode of operation for this file is detected fully automatically, depending + on whether <filename>/etc/resolv.conf</filename> is a symlink to + <filename>/run/systemd/resolve/resolv.conf</filename> or lists 127.0.0.53 as DNS server.</para> + </refsect1> + + <refsect1> + <title>Signals</title> + + <variablelist> + <varlistentry> + <term><constant>SIGUSR1</constant></term> + + <listitem><para>Upon reception of the <constant>SIGUSR1</constant> process signal + <command>systemd-resolved</command> will dump the contents of all DNS resource record caches it + maintains, as well as all feature level information it learnt about configured DNS servers into the + system logs.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGUSR2</constant></term> + + <listitem><para>Upon reception of the <constant>SIGUSR2</constant> process signal + <command>systemd-resolved</command> will flush all caches it maintains. Note that it should normally + not be necessary to request this explicitly – except for debugging purposes – as + <command>systemd-resolved</command> flushes the caches automatically anyway any time the host's + network configuration changes. Sending this signal to <command>systemd-resolved</command> is + equivalent to the <command>resolvectl flush-caches</command> command, however the latter is + recommended since it operates in a synchronous way.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+1</constant></term> + + <listitem><para>Upon reception of the <constant>SIGRTMIN+1</constant> process signal + <command>systemd-resolved</command> will forget everything it learnt about the configured DNS + servers. Specifically any information about server feature support is flushed out, and the server + feature probing logic is restarted on the next request, starting with the most fully featured + level. Note that it should normally not be necessary to request this explicitly – except for + debugging purposes – as <command>systemd-resolved</command> automatically forgets learnt information + any time the DNS server configuration changes. Sending this signal to + <command>systemd-resolved</command> is equivalent to the <command>resolvectl + reset-server-features</command> command, however the latter is recommended since it operates in a + synchronous way.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>hosts</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-rfkill.service.xml b/man/systemd-rfkill.service.xml new file mode 100644 index 0000000..d89eb91 --- /dev/null +++ b/man/systemd-rfkill.service.xml @@ -0,0 +1,65 @@ +<?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-or-later --> +<refentry id="systemd-rfkill.service" conditional='ENABLE_RFKILL'> + + <refentryinfo> + <title>systemd-rfkill.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-rfkill.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-rfkill.service</refname> + <refname>systemd-rfkill.socket</refname> + <refname>systemd-rfkill</refname> + <refpurpose>Load and save the RF kill switch state at boot and change</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-rfkill.service</filename></para> + <para><filename>systemd-rfkill.socket</filename></para> + <para><filename>/usr/lib/systemd/systemd-rfkill</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-rfkill.service</filename> is a service + that restores the RF kill switch state at early boot and saves it + on each change. On disk, the RF kill switch state is stored in + <filename>/var/lib/systemd/rfkill/</filename>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-rfkill</filename> understands the + following kernel command line parameter:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.restore_state=</varname></term> + + <listitem><para>Takes a boolean argument. Defaults to + <literal>1</literal>. If <literal>0</literal>, does not + restore the rfkill settings on boot. However, settings will + still be stored on shutdown. </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-run-generator.xml b/man/systemd-run-generator.xml new file mode 100644 index 0000000..02924b4 --- /dev/null +++ b/man/systemd-run-generator.xml @@ -0,0 +1,81 @@ +<?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-or-later --> +<refentry id="systemd-run-generator"> + + <refentryinfo> + <title>systemd-run-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-run-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-run-generator</refname> + <refpurpose>Generator for invoking commands specified on the kernel command line as system service</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-run-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-run-generator</filename> is a generator + that reads the kernel command line and understands three + options:</para> + + <para>If the <option>systemd.run=</option> option is specified and followed by a command line, a unit named + <filename>kernel-command-line.service</filename> is generated for it and booted into. The service has + <varname>Type=oneshot</varname> set, and has <varname>SuccessAction=exit</varname> and + <varname>FailureAction=exit</varname> configured by default, thus ensuring that the system is shut down as soon as + the command completes. The exit status of the command line is propagated to the invoking container manager, if + this applies (which might propagate this further, to the calling shell — e.g. + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry> does this). If + this option is used multiple times the unit file will contain multiple <varname>ExecStart=</varname> lines, to + execute all commands in order. The command is started as regular service, i.e. with + <varname>DefaultDependencies=</varname> on. </para> + + <para>Use <option>systemd.run_success_action=</option> and <option>systemd.run_failure_action=</option> to tweak + how to react to the process completing. In particular assigning <literal>none</literal> will leave the system + running after the command completes. For further details on supported arguments, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para><filename>systemd-run-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Example</title> + + <para>Use a command like the following to add a user to the user database inside a container run with + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry>:</para> + + <programlisting># systemd-nspawn -D mycontainer -b systemd.run='"adduser test"'</programlisting> + <para>(Note the requirement for double quoting in the command line above. The first level of quoting ('') is + processed and removed by the command shell used to invoke <command>systemd-nspawn</command>. The second level of + quoting ("") is propagated to the kernel command line of the container and processed and removed by + <command>systemd-run-generator</command>. Both together make sure both words of the specified command line + <command>adduser test</command> end up in the generated unit file together and are neither split apart by the + command shell nor by the generator.)</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-run.xml b/man/systemd-run.xml new file mode 100644 index 0000000..fc8716e --- /dev/null +++ b/man/systemd-run.xml @@ -0,0 +1,556 @@ +<?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-or-later --> + +<refentry id="systemd-run" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-run</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-run</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-run</refname> + <refpurpose>Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-run</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain"><replaceable>COMMAND</replaceable> + <arg choice="opt" rep="repeat">ARGS</arg> + </arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-run</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">PATH OPTIONS</arg> + <arg choice="req"><replaceable>COMMAND</replaceable></arg> + <arg choice="opt" rep="repeat">ARGS</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-run</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">SOCKET OPTIONS</arg> + <arg choice="req"><replaceable>COMMAND</replaceable></arg> + <arg choice="opt" rep="repeat">ARGS</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-run</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">TIMER OPTIONS</arg> + <arg choice="req"><replaceable>COMMAND</replaceable></arg> + <arg choice="opt" rep="repeat">ARGS</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-run</command> may be used to create and start a transient <filename>.service</filename> or + <filename>.scope</filename> unit and run the specified <replaceable>COMMAND</replaceable> in it. It may also be + used to create and start a transient <filename>.path</filename>, <filename>.socket</filename>, or + <filename>.timer</filename> unit, that activates a <filename>.service</filename> unit when elapsing.</para> + + <para>If a command is run as transient service unit, it will be started and managed by the service manager like any + other service, and thus shows up in the output of <command>systemctl list-units</command> like any other unit. It + will run in a clean and detached execution environment, with the service manager as its parent process. In this + mode, <command>systemd-run</command> will start the service asynchronously in the background and return after the + command has begun execution (unless <option>--no-block</option> or <option>--wait</option> are specified, see + below).</para> + + <para>If a command is run as transient scope unit, it will be executed by <command>systemd-run</command> itself as + parent process and will thus inherit the execution environment of the caller. However, the processes of the command + are managed by the service manager similar to normal services, and will show up in the output of <command>systemctl + list-units</command>. Execution in this case is synchronous, and will return only when the command finishes. This + mode is enabled via the <option>--scope</option> switch (see below). </para> + + <para>If a command is run with path, socket, or timer options such as <option>--on-calendar=</option> (see below), + a transient path, socket, or timer unit is created alongside the service unit for the specified command. Only the + transient path, socket, or timer unit is started immediately, the transient service unit will be triggered by the + path, socket, or timer unit. If the <option>--unit=</option> option is specified, the + <replaceable>COMMAND</replaceable> may be omitted. In this case, <command>systemd-run</command> creates only a + <filename>.path</filename>, <filename>.socket</filename>, or <filename>.timer</filename> unit that triggers the + specified unit.</para> + + <para>By default, services created with <command>systemd-run</command> default to the <option>simple</option> type, + see the description of <varname>Type=</varname> in + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. Note that when this type is used the service manager (and thus the <command>systemd-run</command> command) + considers service start-up successful as soon as the <function>fork()</function> for the main service process + succeeded, i.e. before the <function>execve()</function> is invoked, and thus even if the specified command cannot + be started. Consider using the <option>exec</option> service type (i.e. <option>--property=Type=exec</option>) to + ensure that <command>systemd-run</command> returns successfully only if the specified command line has been + successfully started.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--no-ask-password</option></term> + + <listitem><para>Do not query the user for authentication for + privileged operations.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--scope</option></term> + + <listitem> + <para>Create a transient <filename>.scope</filename> unit instead of the default transient + <filename>.service</filename> unit (see above). + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--unit=</option></term> + <term><option>-u</option></term> + + <listitem><para>Use this unit name instead of an automatically + generated one.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--property=</option></term> + <term><option>-p</option></term> + + <listitem><para>Sets a property on the scope or service unit that is created. This option takes an assignment + in the same format as + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>set-property</command> command.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--description=</option></term> + + <listitem><para>Provide a description for the service, scope, path, socket, or timer unit. If not specified, + the command itself will be used as a description. See <varname>Description=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--slice=</option></term> + + <listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part + of the specified slice, instead of <filename>system.slice</filename> (when running in + <option>--system</option> mode) or the root slice (when running in <option>--user</option> + mode).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--slice-inherit</option></term> + + <listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part + of the inherited slice. This option can be combined with <option>--slice=</option>.</para> + + <para>An inherited slice is located within <command>systemd-run</command> slice. Example: if + <command>systemd-run</command> slice is <filename>foo.slice</filename>, and the + <option>--slice=</option> argument is <filename>bar</filename>, the unit will be placed under the + <filename>foo-bar.slice</filename>.</para> + + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-r</option></term> + <term><option>--remain-after-exit</option></term> + + <listitem><para>After the service process has terminated, keep the service around until it is explicitly + stopped. This is useful to collect runtime information about the service after it finished running. Also see + <varname>RemainAfterExit=</varname> in + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--send-sighup</option></term> + + <listitem><para>When terminating the scope or service unit, send a SIGHUP immediately after SIGTERM. This is + useful to indicate to shells and shell-like processes that the connection has been severed. Also see + <varname>SendSIGHUP=</varname> in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--service-type=</option></term> + + <listitem><para>Sets the service type. Also see + <varname>Type=</varname> in + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This + option has no effect in conjunction with + <option>--scope</option>. Defaults to + <constant>simple</constant>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--uid=</option></term> + <term><option>--gid=</option></term> + + <listitem><para>Runs the service process under the specified UNIX user and group. Also see + <varname>User=</varname> and <varname>Group=</varname> in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--nice=</option></term> + + <listitem><para>Runs the service process with the specified + nice level. Also see <varname>Nice=</varname> in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--working-directory=</option></term> + + <listitem><para>Runs the service process with the specified working directory. Also see + <varname>WorkingDirectory=</varname> in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--same-dir</option></term> + <term><option>-d</option></term> + + <listitem><para>Similar to <option>--working-directory=</option> but uses the current working directory of the + caller for the service to execute.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-E <replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term> + <term><option>--setenv=<replaceable>NAME</replaceable>=<replaceable>VALUE</replaceable></option></term> + + <listitem><para>Runs the service process with the specified environment variable set. + Also see <varname>Environment=</varname> in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--pty</option></term> + <term><option>-t</option></term> + + <listitem><para>When invoking the command, the transient service connects its standard input, output and error + to the terminal <command>systemd-run</command> is invoked on, via a pseudo TTY device. This allows running + programs that expect interactive user input/output as services, such as interactive command shells.</para> + + <para>Note that + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>shell</command> command is usually a better alternative for requesting a new, interactive login + session on the local host or a local container.</para> + + <para>See below for details on how this switch combines with <option>--pipe</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--pipe</option></term> + <term><option>-P</option></term> + + <listitem><para>If specified, standard input, output, and error of the transient service are inherited from the + <command>systemd-run</command> command itself. This allows <command>systemd-run</command> + to be used within shell pipelines. + Note that this mode is not suitable for interactive command shells and similar, as the + service process will not become a TTY controller when invoked on a terminal. Use <option>--pty</option> instead + in that case.</para> + + <para>When both <option>--pipe</option> and <option>--pty</option> are used in combination the more appropriate + option is automatically determined and used. Specifically, when invoked with standard input, output and error + connected to a TTY <option>--pty</option> is used, and otherwise <option>--pipe</option>.</para> + + <para>When this option is used the original file descriptors <command>systemd-run</command> receives are passed + to the service processes as-is. If the service runs with different privileges than + <command>systemd-run</command>, this means the service might not be able to re-open the passed file + descriptors, due to normal file descriptor access restrictions. If the invoked process is a shell script that + uses the <command>echo "hello" > /dev/stderr</command> construct for writing messages to stderr, this might + cause problems, as this only works if stderr can be re-opened. To mitigate this use the construct <command>echo + "hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--shell</option></term> + <term><option>-S</option></term> + + <listitem><para>A shortcut for <literal>--pty --same-dir --wait --collect --service-type=exec $SHELL</literal>, + i.e. requests an interactive shell in the current working directory, running in service context, accessible + with a single switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--quiet</option></term> + <term><option>-q</option></term> + + <listitem><para>Suppresses additional informational output + while running. This is particularly useful in combination with + <option>--pty</option> when it will suppress the initial + message explaining how to terminate the TTY connection.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--on-active=</option></term> + <term><option>--on-boot=</option></term> + <term><option>--on-startup=</option></term> + <term><option>--on-unit-active=</option></term> + <term><option>--on-unit-inactive=</option></term> + + <listitem><para>Defines a monotonic timer relative to different starting points for starting the specified + command. See <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>, + <varname>OnUnitActiveSec=</varname> and <varname>OnUnitInactiveSec=</varname> in + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. These options are shortcuts for <command>--timer-property=</command> with the relevant properties. + These options may not be combined with <option>--scope</option> or <option>--pty</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--on-calendar=</option></term> + + <listitem><para>Defines a calendar timer for starting the specified command. See <varname>OnCalendar=</varname> + in <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This + option is a shortcut for <command>--timer-property=OnCalendar=</command>. This option may not be combined with + <option>--scope</option> or <option>--pty</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--on-clock-change</option></term> + <term><option>--on-timezone-change</option></term> + + <listitem><para>Defines a trigger based on system clock jumps or timezone changes for starting the + specified command. See <varname>OnClockChange=</varname> and <varname>OnTimezoneChange=</varname> in + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. These + options are shortcuts for <command>--timer-property=OnClockChange=yes</command> and + <command>--timer-property=OnTimezoneChange=yes</command>. These options may not be combined with + <option>--scope</option> or <option>--pty</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--path-property=</option></term> + <term><option>--socket-property=</option></term> + <term><option>--timer-property=</option></term> + + <listitem><para>Sets a property on the path, socket, or timer unit that is created. This option is similar to + <option>--property=</option> but applies to the transient path, socket, or timer unit rather than the + transient service unit created. This option takes an assignment in the same format as + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>set-property</command> command. These options may not be combined with + <option>--scope</option> or <option>--pty</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--no-block</option></term> + + <listitem> + <para>Do not synchronously wait for the unit start operation to finish. If this option is not specified, the + start request for the transient unit will be verified, enqueued and <command>systemd-run</command> will wait + until the unit's start-up is completed. By passing this argument, it is only verified and enqueued. This + option may not be combined with <option>--wait</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--wait</option></term> + + <listitem><para>Synchronously wait for the transient service to terminate. If this option is specified, the + start request for the transient unit is verified, enqueued, and waited for. Subsequently the invoked unit is + monitored, and it is waited until it is deactivated again (most likely because the specified command + completed). On exit, terse information about the unit's runtime is shown, including total runtime (as well as + CPU usage, if <option>--property=CPUAccounting=1</option> was set) and the exit code and status of the main + process. This output may be suppressed with <option>--quiet</option>. This option may not be combined with + <option>--no-block</option>, <option>--scope</option> or the various path, socket, or timer options.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-G</option></term> + <term><option>--collect</option></term> + + <listitem><para>Unload the transient unit after it completed, even if it failed. Normally, without this option, + all units that ran and failed are kept in memory until the user explicitly resets their failure state with + <command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that ran + successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more + aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for + <command>--property=CollectMode=inactive-or-failed</command>, see the explanation for + <varname>CollectMode=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further + information.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="user" /> + <xi:include href="user-system-options.xml" xpointer="system" /> + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + <para>All command line arguments after the first non-option + argument become part of the command line of the launched + process. If a command is run as service unit, the first argument + needs to be an absolute program path.</para> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned. If <command>systemd-run</command> failed to start the service, a + non-zero return value will be returned. If <command>systemd-run</command> waits for the service to + terminate, the return value will be propagated from the service. 0 will be returned on success, including + all the cases where systemd considers a service to have exited cleanly, see the discussion of + <varname>SuccessExitStatus=</varname> in + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Logging environment variables provided by systemd to services</title> + + <programlisting># systemd-run env +Running as unit: run-19945.service +# journalctl -u run-19945.service +Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env... +Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env. +Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8 +Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64</programlisting> + </example> + + <example> + <title>Limiting resources available to a command</title> + + <programlisting># systemd-run -p BlockIOWeight=10 updatedb</programlisting> + + <para>This command invokes the + <citerefentry project='man-pages'><refentrytitle>updatedb</refentrytitle><manvolnum>8</manvolnum></citerefentry> + tool, but lowers the block I/O weight for it to 10. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information on the <varname>BlockIOWeight=</varname> + property.</para> + </example> + + <example> + <title>Running commands at a specified time</title> + + <para>The following command will touch a file after 30 seconds.</para> + + <programlisting># date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo +Mon Dec 8 20:44:24 KST 2014 +Running as unit: run-71.timer +Will run service as unit: run-71.service +# journalctl -b -u run-71.timer +-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. -- +Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo. +Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo. +# journalctl -b -u run-71.service +-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. -- +Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo... +Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.</programlisting> + </example> + + <example> + <title>Allowing access to the tty</title> + + <para>The following command invokes <filename>/bin/bash</filename> as a service + passing its standard input, output and error to the calling TTY.</para> + + <programlisting># systemd-run -t --send-sighup /bin/bash</programlisting> + </example> + + <example> + <title>Start <command>screen</command> as a user service</title> + + <programlisting>$ systemd-run --scope --user screen +Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope. + +$ screen -ls +There is a screen on: + 492..laptop (Detached) +1 Socket in /var/run/screen/S-fatima. +</programlisting> + + <para>This starts the <command>screen</command> process as a child of the + <command>systemd --user</command> process that was started by + <filename>user@.service</filename>, in a scope unit. A + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry> + unit is used instead of a + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + unit, because <command>screen</command> will exit when detaching from the terminal, + and a service unit would be terminated. Running <command>screen</command> + as a user unit has the advantage that it is not part of the session scope. + If <varname>KillUserProcesses=yes</varname> is configured in + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + the default, the session scope will be terminated when the user logs + out of that session.</para> + + <para>The <filename>user@.service</filename> is started automatically + when the user first logs in, and stays around as long as at least one + login session is open. After the user logs out of the last session, + <filename>user@.service</filename> and all services underneath it + are terminated. This behavior is the default, when "lingering" is + not enabled for that user. Enabling lingering means that + <filename>user@.service</filename> is started automatically during + boot, even if the user is not logged in, and that the service is + not terminated when the user logs out.</para> + + <para>Enabling lingering allows the user to run processes without being logged in, + for example to allow <command>screen</command> to persist after the user logs out, + even if the session scope is terminated. In the default configuration, users can + enable lingering for themselves:</para> + + <programlisting>$ loginctl enable-linger</programlisting> + </example> + + <example> + <title>Return value</title> + + <programlisting>$ systemd-run --user --wait true +$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11' +$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 bash -c 'kill -SIGUSR1 $$$$'</programlisting> + + <para>Those three invocations will succeed, i.e. terminate with an exit code of 0.</para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml new file mode 100644 index 0000000..d117a21 --- /dev/null +++ b/man/systemd-sleep.conf.xml @@ -0,0 +1,202 @@ +<?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-or-later --> + +<refentry id="systemd-sleep.conf" + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd-sleep.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-sleep.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-sleep.conf</refname> + <refname>sleep.conf.d</refname> + <refpurpose>Suspend and hibernation configuration file</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/sleep.conf</filename></para> + <para><filename>/etc/systemd/sleep.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/sleep.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/sleep.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd</command> supports four general + power-saving modes:</para> + + <variablelist> + <varlistentry> + <term>suspend</term> + + <listitem><para>a low-power state + where execution of the OS is paused, + and complete power loss might result + in lost data, and which is fast to + enter and exit. This corresponds to + suspend, standby, or freeze states as + understood by the kernel. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>hibernate</term> + + <listitem><para>a low-power state + where execution of the OS is paused, + and complete power loss does not + result in lost data, and which might + be slow to enter and exit. This + corresponds to the hibernation as + understood by the kernel. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>hybrid-sleep</term> + + <listitem><para>a low-power state + where execution of the OS is paused, + which might be slow to enter, and on + complete power loss does not result in + lost data but might be slower to exit + in that case. This mode is called + suspend-to-both by the kernel. + </para></listitem> + </varlistentry> + + <varlistentry> + <term>suspend-then-hibernate</term> + + <listitem><para>A low power state where the system is initially suspended + (the state is stored in RAM). If not interrupted within the delay specified by + <command>HibernateDelaySec=</command>, the system will be woken using an RTC + alarm and hibernated (the state is then stored on disk). + </para></listitem> + </varlistentry> + + </variablelist> + + <para>Settings in these files determine what strings + will be written to + <filename>/sys/power/disk</filename> and + <filename>/sys/power/state</filename> by + <citerefentry><refentrytitle>systemd-sleep</refentrytitle><manvolnum>8</manvolnum></citerefentry> + when + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + attempts to suspend or hibernate the machine. + See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>The following options can be configured in the + [Sleep] section of + <filename>/etc/systemd/sleep.conf</filename> or a + <filename>sleep.conf.d</filename> file:</para> + + <variablelist class='config-directives'> + <varlistentry> + <term><varname>AllowSuspend=</varname></term> + <term><varname>AllowHibernation=</varname></term> + <term><varname>AllowSuspendThenHibernate=</varname></term> + <term><varname>AllowHybridSleep=</varname></term> + + <listitem><para>By default any power-saving mode is advertised if possible (i.e. + the kernel supports that mode, the necessary resources are available). Those + switches can be used to disable specific modes.</para> + + <para>If <varname>AllowHibernation=no</varname> or <varname>AllowSuspend=no</varname> is + used, this implies <varname>AllowSuspendThenHibernate=no</varname> and + <varname>AllowHybridSleep=no</varname>, since those methods use both suspend and hibernation + internally. <varname>AllowSuspendThenHibernate=yes</varname> and + <varname>AllowHybridSleep=yes</varname> can be used to override and enable those specific + modes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SuspendMode=</varname></term> + <term><varname>HibernateMode=</varname></term> + <term><varname>HybridSleepMode=</varname></term> + + <listitem><para>The string to be written to + <filename>/sys/power/disk</filename> by, + respectively, + <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hybrid-sleep.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or + <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + More than one value can be specified by separating + multiple values with whitespace. They will be tried + in turn, until one is written without error. If + neither succeeds, the operation will be aborted. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SuspendState=</varname></term> + <term><varname>HibernateState=</varname></term> + <term><varname>HybridSleepState=</varname></term> + + <listitem><para>The string to be written to + <filename>/sys/power/state</filename> by, + respectively, + <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hybrid-sleep.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or + <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + More than one value can be specified by separating + multiple values with whitespace. They will be tried + in turn, until one is written without error. If + neither succeeds, the operation will be aborted. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>HibernateDelaySec=</varname></term> + + <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> + + <refsect1> + <title>Example: freeze</title> + + <para>Example: to exploit the <quote>freeze</quote> mode added + in Linux 3.9, one can use <command>systemctl suspend</command> + with + <programlisting>[Sleep] +SuspendState=freeze</programlisting></para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-sleep</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hybrid-sleep.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-socket-activate.xml b/man/systemd-socket-activate.xml new file mode 100644 index 0000000..a9d00dc --- /dev/null +++ b/man/systemd-socket-activate.xml @@ -0,0 +1,182 @@ +<?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-or-later --> + +<refentry id="systemd-socket-activate" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-socket-activate</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-socket-activate</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-socket-activate</refname> + <refpurpose>Test socket activation of daemons</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-socket-activate</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain"><replaceable>daemon</replaceable></arg> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-socket-activate</command> may be used to launch a socket-activated service program from the + command line for testing purposes. It may also be used to launch individual instances of the service program per + connection. + </para> + + <para>The daemon to launch and its options should be specified + after options intended for <command>systemd-socket-activate</command>. + </para> + + <para>If the <option>--inetd</option> option is given, the socket file descriptor will be used as the standard + input and output of the launched process. Otherwise, standard input and output will be inherited, and sockets will + be passed through file descriptors 3 and higher. Sockets passed through <varname>$LISTEN_FDS</varname> to + <command>systemd-socket-activate</command> will be passed through to the daemon, in the original positions. Other sockets + specified with <option>--listen=</option> will use consecutive descriptors. By default, + <command>systemd-socket-activate</command> listens on a stream socket, use <option>--datagram</option> and + <option>--seqpacket</option> to listen on datagram or sequential packet sockets instead (see below). + </para> + </refsect1> + + <refsect1> + <title>Options</title> + <variablelist> + <varlistentry> + <term><option>-l <replaceable>address</replaceable></option></term> + <term><option>--listen=<replaceable>address</replaceable></option></term> + + <listitem><para>Listen on this <replaceable>address</replaceable>. + Takes a string like <literal>2000</literal> or + <literal>127.0.0.1:2001</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-a</option></term> + <term><option>--accept</option></term> + + <listitem><para>Launch an instance of the service program for each connection and pass the connection + socket.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-d</option></term> + <term><option>--datagram</option></term> + + <listitem><para>Listen on a datagram socket (<constant>SOCK_DGRAM</constant>), instead of a stream socket + (<constant>SOCK_STREAM</constant>). May not be combined with <option>--seqpacket</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--seqpacket</option></term> + + <listitem><para>Listen on a sequential packet socket (<constant>SOCK_SEQPACKET</constant>), instead of a stream + socket (<constant>SOCK_STREAM</constant>). May not be combined with + <option>--datagram</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--inetd</option></term> + + <listitem><para>Use the inetd protocol for passing file descriptors, i.e. as standard input and standard + output, instead of the new-style protocol for passing file descriptors using <varname>$LISTEN_FDS</varname> + (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-E <replaceable>VAR</replaceable><optional>=<replaceable>VALUE</replaceable></optional></option></term> + <term><option>--setenv=<replaceable>VAR</replaceable><optional>=<replaceable>VALUE</replaceable></optional></option></term> + + <listitem><para>Add this variable to the environment of the + launched process. If <replaceable>VAR</replaceable> is + followed by <literal>=</literal>, assume that it is a + variable–value pair. Otherwise, obtain the value from the + environment of <command>systemd-socket-activate</command> itself. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--fdname=</option><replaceable>NAME</replaceable><optional>:<replaceable>NAME</replaceable>…</optional></term> + + <listitem><para>Specify names for the file descriptors passed. This is equivalent to setting + <varname>FileDescriptorName=</varname> in socket unit files, and enables use of + <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Multiple entries may be specifies using separate options or by separating names with colons + (<literal>:</literal>) in one option. In case more names are given than descriptors, superfluous ones will be + ignored. In case less names are given than descriptors, the remaining file descriptors will be unnamed. + </para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Environment variables</title> + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$LISTEN_FDS</varname></term> + <term><varname>$LISTEN_PID</varname></term> + <term><varname>$LISTEN_FDNAMES</varname></term> + + <listitem><para>See + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_LOG_TARGET</varname></term> + <term><varname>$SYSTEMD_LOG_LEVEL</varname></term> + <term><varname>$SYSTEMD_LOG_TIME</varname></term> + <term><varname>$SYSTEMD_LOG_COLOR</varname></term> + <term><varname>$SYSTEMD_LOG_LOCATION</varname></term> + + <listitem><para>Same as in + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Run an echo server on port 2000</title> + + <programlisting>$ systemd-socket-activate -l 2000 --inetd -a cat</programlisting> + </example> + + <example> + <title>Run a socket-activated instance of <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry></title> + + <programlisting>$ systemd-socket-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-socket-proxyd.xml b/man/systemd-socket-proxyd.xml new file mode 100644 index 0000000..e512a43 --- /dev/null +++ b/man/systemd-socket-proxyd.xml @@ -0,0 +1,184 @@ +<?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-or-later --> +<refentry id="systemd-socket-proxyd" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-socket-proxyd</title> + <productname>systemd</productname> + </refentryinfo> + <refmeta> + <refentrytitle>systemd-socket-proxyd</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + <refnamediv> + <refname>systemd-socket-proxyd</refname> + <refpurpose>Bidirectionally proxy local sockets to another (possibly remote) socket</refpurpose> + </refnamediv> + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-socket-proxyd</command> + <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg> + <arg choice="plain"><replaceable>HOST</replaceable>:<replaceable>PORT</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-socket-proxyd</command> + <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg> + <arg choice="plain"><replaceable>UNIX-DOMAIN-SOCKET-PATH</replaceable> + </arg> + </cmdsynopsis> + </refsynopsisdiv> + <refsect1> + <title>Description</title> + <para> + <command>systemd-socket-proxyd</command> is a generic + socket-activated network socket forwarder proxy daemon for IPv4, + IPv6 and UNIX stream sockets. It may be used to bi-directionally + forward traffic from a local listening socket to a local or remote + destination socket.</para> + + <para>One use of this tool is to provide socket activation support + for services that do not natively support socket activation. On + behalf of the service to activate, the proxy inherits the socket + from systemd, accepts each client connection, opens a connection + to a configured server for each client, and then bidirectionally + forwards data between the two.</para> + <para>This utility's behavior is similar to + <citerefentry project='die-net'><refentrytitle>socat</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + The main differences for <command>systemd-socket-proxyd</command> + are support for socket activation with + <literal>Accept=no</literal> and an event-driven + design that scales better with the number of + connections.</para> + </refsect1> + <refsect1> + <title>Options</title> + <para>The following options are understood:</para> + <variablelist> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <varlistentry> + <term><option>--connections-max=</option></term> + <term><option>-c</option></term> + + <listitem><para>Sets the maximum number of simultaneous connections, defaults to 256. + If the limit of concurrent connections is reached further connections will be refused.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--exit-idle-time=</option></term> + + <listitem><para>Sets the time before exiting when there are no connections, defaults to + <constant>infinity</constant>. Takes a unit-less value in seconds, or a time span value such + as <literal>5min 20s</literal>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> + <title>Exit status</title> + <para>On success, 0 is returned, a non-zero failure + code otherwise.</para> + </refsect1> + <refsect1> + <title>Examples</title> + <refsect2> + <title>Simple Example</title> + <para>Use two services with a dependency and no namespace + isolation.</para> + <example> + <title>proxy-to-nginx.socket</title> + <programlisting><![CDATA[[Socket] +ListenStream=80 + +[Install] +WantedBy=sockets.target]]></programlisting> + </example> + <example> + <title>proxy-to-nginx.service</title> + <programlisting><![CDATA[[Unit] +Requires=nginx.service +After=nginx.service +Requires=proxy-to-nginx.socket +After=proxy-to-nginx.socket + +[Service] +ExecStart=/usr/lib/systemd/systemd-socket-proxyd /run/nginx/socket +PrivateTmp=yes +PrivateNetwork=yes]]></programlisting> + </example> + <example> + <title>nginx.conf</title> + <programlisting> +<![CDATA[[…] +server { + listen unix:/run/nginx/socket; + […]]]> +</programlisting> + </example> + <example> + <title>Enabling the proxy</title> + <programlisting><![CDATA[# systemctl enable --now proxy-to-nginx.socket +$ curl http://localhost:80/]]></programlisting> + </example> + <para>If <filename>nginx.service</filename> has <varname>StopWhenUnneeded=</varname> set, then + passing <option>--exit-idle-time=</option> to <command>systemd-socket-proxyd</command> allows + both services to stop during idle periods.</para> + </refsect2> + <refsect2> + <title>Namespace Example</title> + <para>Similar as above, but runs the socket proxy and the main + service in the same private namespace, assuming that + <filename>nginx.service</filename> has + <varname>PrivateTmp=</varname> and + <varname>PrivateNetwork=</varname> set, too.</para> + <example> + <title>proxy-to-nginx.socket</title> + <programlisting><![CDATA[[Socket] +ListenStream=80 + +[Install] +WantedBy=sockets.target]]></programlisting> + </example> + <example> + <title>proxy-to-nginx.service</title> + <programlisting><![CDATA[[Unit] +Requires=nginx.service +After=nginx.service +Requires=proxy-to-nginx.socket +After=proxy-to-nginx.socket +JoinsNamespaceOf=nginx.service + +[Service] +ExecStart=/usr/lib/systemd/systemd-socket-proxyd 127.0.0.1:8080 +PrivateTmp=yes +PrivateNetwork=yes]]></programlisting> + </example> + <example> + <title>nginx.conf</title> + <programlisting><![CDATA[[…] +server { + listen 8080; + […]]]></programlisting> + </example> + <example> + <title>Enabling the proxy</title> + <programlisting><![CDATA[# systemctl enable --now proxy-to-nginx.socket +$ curl http://localhost:80/]]></programlisting> + </example> + </refsect2> + </refsect1> + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>socat</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>nginx</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>curl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml new file mode 100644 index 0000000..e4a6de5 --- /dev/null +++ b/man/systemd-suspend.service.xml @@ -0,0 +1,124 @@ +<?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-or-later --> + +<refentry id="systemd-suspend.service" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-suspend.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-suspend.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-suspend.service</refname> + <refname>systemd-hibernate.service</refname> + <refname>systemd-hybrid-sleep.service</refname> + <refname>systemd-suspend-then-hibernate.service</refname> + <refname>systemd-sleep</refname> + <refpurpose>System sleep state logic</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-suspend.service</filename></para> + <para><filename>systemd-hibernate.service</filename></para> + <para><filename>systemd-hybrid-sleep.service</filename></para> + <para><filename>systemd-suspend-then-hibernate.service</filename></para> + <para><filename>/usr/lib/systemd/system-sleep</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-suspend.service</filename> is a system + service that is pulled in by <filename>suspend.target</filename> + and is responsible for the actual system suspend. Similarly, + <filename>systemd-hibernate.service</filename> is pulled in by + <filename>hibernate.target</filename> to execute the actual + hibernation. Finally, + <filename>systemd-hybrid-sleep.service</filename> is pulled in by + <filename>hybrid-sleep.target</filename> to execute hybrid + hibernation with system suspend and pulled in by + <filename>suspend-then-hibernate.target</filename> to execute system suspend + with a timeout that will activate hibernate later.</para> + + <para>Immediately before entering system suspend and/or + hibernation <filename>systemd-suspend.service</filename> (and the + other mentioned units, respectively) will run all executables in + <filename>/usr/lib/systemd/system-sleep/</filename> and pass two + arguments to them. The first argument will be + <literal>pre</literal>, the second either + <literal>suspend</literal>, <literal>hibernate</literal>, + <literal>hybrid-sleep</literal>, or <literal>suspend-then-hibernate</literal> + depending on the chosen action. + Immediately after leaving system suspend and/or hibernation the + same executables are run, but the first argument is now + <literal>post</literal>. All executables in this directory are + executed in parallel, and execution of the action is not continued + until all executables have finished.</para> + + <para>Note that scripts or binaries dropped in + <filename>/usr/lib/systemd/system-sleep/</filename> are intended + for local use only and should be considered hacks. If applications + want to react to system suspend/hibernation and resume, + they should rather use the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor + interface</ulink>.</para> + + <para>Note that <filename>systemd-suspend.service</filename>, + <filename>systemd-hibernate.service</filename>, <filename>systemd-hybrid-sleep.service</filename>, and + <filename>systemd-suspend-then-hibernate.service</filename> should never be executed directly. Instead, + trigger system sleep with a command such as <command>systemctl suspend</command> or <command>systemctl + hibernate</command>.</para> + + <para>Internally, this service will echo a string like + <literal>mem</literal> into <filename>/sys/power/state</filename>, + to trigger the actual system suspend. What exactly is written + where can be configured in the [Sleep] section + of <filename>/etc/systemd/sleep.conf</filename> or a + <filename>sleep.conf.d</filename> file. See + <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para><command>systemd-sleep</command> understands the + following commands:</para> + + <variablelist> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + + <varlistentry> + <term><option>suspend</option></term> + <term><option>hibernate</option></term> + <term><option>hybrid-sleep</option></term> + <term><option>suspend-then-hibernate</option></term> + + <listitem><para>Suspend, hibernate, suspend then hibernate, or put the + system to hybrid sleep.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-sysctl.service.xml b/man/systemd-sysctl.service.xml new file mode 100644 index 0000000..751aa2b --- /dev/null +++ b/man/systemd-sysctl.service.xml @@ -0,0 +1,129 @@ +<?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-or-later --> +<refentry id="systemd-sysctl.service" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-sysctl.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-sysctl.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-sysctl.service</refname> + <refname>systemd-sysctl</refname> + <refpurpose>Configure kernel parameters at boot</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>/usr/lib/systemd/systemd-sysctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg> + </cmdsynopsis> + <para><filename>systemd-sysctl.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-sysctl.service</filename> is an early boot + service that configures + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + kernel parameters by invoking <command>/usr/lib/systemd/systemd-sysctl</command>.</para> + + <para>When invoked with no arguments, <command>/usr/lib/systemd/systemd-sysctl</command> applies + all directives from configuration files listed in + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + If one or more filenames are passed on the command line, only the directives in these files are + applied.</para> + + <para>In addition, <option>--prefix=</option> option may be used to limit which sysctl + settings are applied.</para> + + <para>See + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the configuration of sysctl settings. After sysctl configuration is + changed on disk, it must be written to the files in <filename>/proc/sys/</filename> before it + takes effect. It is possible to update specific settings, or simply to reload all configuration, + see Examples below.</para> + </refsect1> + + <refsect1><title>Options</title> + <variablelist> + <varlistentry id='prefix'> + <term><option>--prefix=</option></term> + <listitem> + <para>Only apply rules with the specified prefix.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="cat-config" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Reset all sysctl settings</title> + + <programlisting>systemctl restart systemd-sysctl</programlisting> + </example> + + <example> + <title>View coredump handler configuration</title> + + <programlisting># sysctl kernel.core_pattern +kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I +</programlisting> + </example> + + <example> + <title>Update coredump handler configuration</title> + + <programlisting># /usr/lib/systemd/systemd-sysctl --prefix kernel.core_pattern</programlisting> + + <para>This searches all the directories listed in + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for configuration files and writes <filename>/proc/sys/kernel/core_pattern</filename>.</para> + </example> + + <example> + <title>Update coredump handler configuration according to a specific file</title> + + <programlisting># /usr/lib/systemd/systemd-sysctl 50-coredump.conf</programlisting> + + <para>This applies all the settings found in <filename>50-coredump.conf</filename>. + Either <filename>/etc/sysctl.d/50-coredump.conf</filename>, or + <filename>/run/sysctl.d/50-coredump.conf</filename>, or + <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> will be used, in the order + of preference.</para> + </example> + + <para>See + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for various ways to directly apply sysctl settings.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-system-update-generator.xml b/man/systemd-system-update-generator.xml new file mode 100644 index 0000000..8711be2 --- /dev/null +++ b/man/systemd-system-update-generator.xml @@ -0,0 +1,50 @@ +<?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-or-later --> +<refentry id="systemd-system-update-generator"> + + <refentryinfo> + <title>systemd-system-update-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-system-update-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-system-update-generator</refname> + <refpurpose>Generator for redirecting boot to offline update mode</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-system-update-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-system-update-generator</filename> is a + generator that automatically redirects the boot process to + <filename>system-update.target</filename>, if + <filename>/system-update</filename> exists. This is required to + implement the logic explained in the + <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + + <para><filename>systemd-system-update-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml new file mode 100644 index 0000000..075666a --- /dev/null +++ b/man/systemd-system.conf.xml @@ -0,0 +1,424 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd-system.conf" + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd-system.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-system.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-system.conf</refname> + <refname>system.conf.d</refname> + <refname>systemd-user.conf</refname> + <refname>user.conf.d</refname> + <refpurpose>System and session service manager configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/system.conf</filename>, + <filename>/etc/systemd/system.conf.d/*.conf</filename>, + <filename>/run/systemd/system.conf.d/*.conf</filename>, + <filename>/usr/lib/systemd/system.conf.d/*.conf</filename></para> + <para><filename>/etc/systemd/user.conf</filename>, + <filename>/etc/systemd/user.conf.d/*.conf</filename>, + <filename>/run/systemd/user.conf.d/*.conf</filename>, + <filename>/usr/lib/systemd/user.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>When run as a system instance, systemd interprets the + configuration file <filename>system.conf</filename> and the files + in <filename>system.conf.d</filename> directories; when run as a + user instance, systemd interprets the configuration file + <filename>user.conf</filename> and the files in + <filename>user.conf.d</filename> directories. These configuration + files contain a few settings controlling basic manager + operations. See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>All options are configured in the + [Manager] section:</para> + + <variablelist class='config-directives'> + + <varlistentry> + <term><varname>LogColor=</varname></term> + <term><varname>LogLevel=</varname></term> + <term><varname>LogLocation=</varname></term> + <term><varname>LogTarget=</varname></term> + <term><varname>LogTime=</varname></term> + <term><varname>DumpCore=yes</varname></term> + <term><varname>CrashChangeVT=no</varname></term> + <term><varname>CrashShell=no</varname></term> + <term><varname>CrashReboot=no</varname></term> + <term><varname>ShowStatus=yes</varname></term> + <term><varname>DefaultStandardOutput=journal</varname></term> + <term><varname>DefaultStandardError=inherit</varname></term> + + <listitem><para>Configures various parameters of basic manager operation. These options may be overridden by + the respective process and kernel command line arguments. See + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CtrlAltDelBurstAction=</varname></term> + + <listitem><para>Defines what action will be performed + if user presses Ctrl-Alt-Delete more than 7 times in 2s. + Can be set to <literal>reboot-force</literal>, <literal>poweroff-force</literal>, + <literal>reboot-immediate</literal>, <literal>poweroff-immediate</literal> + or disabled with <literal>none</literal>. Defaults to + <literal>reboot-force</literal>. + </para></listitem> + </varlistentry> + + <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. 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>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>, + <literal>d</literal>, <literal>w</literal>). If <varname>RuntimeWatchdogSec=</varname> is set to a non-zero + value, the watchdog hardware (<filename>/dev/watchdog</filename> or the path specified with + <varname>WatchdogDevice=</varname> or the kernel option <varname>systemd.watchdog-device=</varname>) will be + programmed to automatically reboot the system if it is not contacted within the specified timeout interval. The + 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>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>RebootWatchdogSec=</varname> timeout + applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and + after the system and service manager process (PID 1) got replaced by the <filename>systemd-shutdown</filename> + binary, see system <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details. During the first phase of the shutdown operation the system and service manager remains running + and hence <varname>RuntimeWatchdogSec=</varname> is still honoured. In order to define a timeout on this first + phase of system shutdown, configure <varname>JobTimeoutSec=</varname> and <varname>JobTimeoutAction=</varname> + in the [Unit] section of the <filename>shutdown.target</filename> unit. By default + <varname>RuntimeWatchdogSec=</varname> defaults to 0 (off), and <varname>RebootWatchdogSec=</varname> to + 10min. <varname>KExecWatchdogSec=</varname> may be used to additionally enable the watchdog when kexec + is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on kexec (depending + on the specific hardware and/or driver), in this case the watchdog might not get disabled after kexec succeeds + and thus the system might get rebooted, unless <varname>RuntimeWatchdogSec=</varname> is also enabled at the same time. + For this reason it is recommended to enable <varname>KExecWatchdogSec=</varname> only if + <varname>RuntimeWatchdogSec=</varname> is also enabled. + These settings have no effect if a hardware watchdog is not available.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WatchdogDevice=</varname></term> + + <listitem><para>Configure the hardware watchdog device that the + runtime and shutdown watchdog timers will open and use. Defaults + to <filename>/dev/watchdog</filename>. This setting has no + effect if a hardware watchdog is not available.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CapabilityBoundingSet=</varname></term> + + <listitem><para>Controls which capabilities to include in the + capability bounding set for PID 1 and its children. See + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details. Takes a whitespace-separated list of capability + names as read by + <citerefentry project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Capabilities listed will be included in the bounding set, all + others are removed. If the list of capabilities is prefixed + with ~, all but the listed capabilities will be included, the + effect of the assignment inverted. Note that this option also + affects the respective capabilities in the effective, + permitted and inheritable capability sets. The capability + bounding set may also be individually configured for units + using the <varname>CapabilityBoundingSet=</varname> directive + for units, but note that capabilities dropped for PID 1 cannot + be regained in individual units, they are lost for + good.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NoNewPrivileges=</varname></term> + + <listitem><para>Takes a boolean argument. If true, ensures that PID 1 + and all its children can never gain new privileges through + <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> + (e.g. via setuid or setgid bits, or filesystem capabilities). + Defaults to false. General purpose distributions commonly rely + on executables with setuid or setgid bits and will thus not + function properly with this option enabled. Individual units + cannot disable this option. + Also see <ulink url="https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html">No New Privileges Flag</ulink>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SystemCallArchitectures=</varname></term> + + <listitem><para>Takes a space-separated list of architecture + identifiers. Selects from which architectures system calls may + be invoked on this system. This may be used as an effective + way to disable invocation of non-native binaries system-wide, + for example to prohibit execution of 32-bit x86 binaries on + 64-bit x86-64 systems. This option operates system-wide, and + acts similar to the + <varname>SystemCallArchitectures=</varname> setting of unit + files, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. This setting defaults to the empty list, in which + case no filtering of system calls based on architecture is + applied. Known architecture identifiers are + <literal>x86</literal>, <literal>x86-64</literal>, + <literal>x32</literal>, <literal>arm</literal> and the special + identifier <literal>native</literal>. The latter implicitly + maps to the native architecture of the system (or more + specifically, the architecture the system manager was compiled + for). Set this setting to <literal>native</literal> to + prohibit execution of any non-native binaries. When a binary + executes a system call of an architecture that is not listed + in this setting, it will be immediately terminated with the + SIGSYS signal.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimerSlackNSec=</varname></term> + + <listitem><para>Sets the timer slack in nanoseconds for PID 1, + which is inherited by all executed processes, unless + overridden individually, for example with the + <varname>TimerSlackNSec=</varname> setting in service units + (for details see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + The timer slack controls the accuracy of wake-ups triggered by + system timers. See + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for more information. Note that in contrast to most other time + span definitions this parameter takes an integer value in + nano-seconds if no unit is specified. The usual time units are + understood too.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>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 + controls the global default for the + <varname>AccuracySec=</varname> setting of timer units, see + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. <varname>AccuracySec=</varname> set in individual + units override the global default for the specific unit. + Defaults to 1min. Note that the accuracy of timer units is + also affected by the configured timer slack for PID 1, see + <varname>TimerSlackNSec=</varname> above.</para></listitem> + </varlistentry> + + <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, + 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>, + <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 + service with <varname>Type=oneshot</varname> is used. + For non-service units, + <varname>DefaultTimeoutStartSec=</varname> sets the default + <varname>TimeoutSec=</varname> + value. <varname>DefaultTimeoutStartSec=</varname> and + <varname>DefaultTimeoutStopSec=</varname> default 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> + + <varlistentry> + <term><varname>DefaultStartLimitIntervalSec=</varname></term> + <term><varname>DefaultStartLimitBurst=</varname></term> + + <listitem><para>Configure the default unit start rate + limiting, as configured per-service by + <varname>StartLimitIntervalSec=</varname> and + <varname>StartLimitBurst=</varname>. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details on the per-service settings. + <varname>DefaultStartLimitIntervalSec=</varname> defaults to + 10s. <varname>DefaultStartLimitBurst=</varname> defaults to + 5.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultEnvironment=</varname></term> + + <listitem><para>Sets manager environment variables passed to + all executed processes. Takes a space-separated list of + variable assignments. See + <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about environment variables.</para> + + <para>Example: + + <programlisting>DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6"</programlisting> + + Sets three variables + <literal>VAR1</literal>, + <literal>VAR2</literal>, + <literal>VAR3</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultCPUAccounting=</varname></term> + <term><varname>DefaultBlockIOAccounting=</varname></term> + <term><varname>DefaultMemoryAccounting=</varname></term> + <term><varname>DefaultTasksAccounting=</varname></term> + <term><varname>DefaultIOAccounting=</varname></term> + <term><varname>DefaultIPAccounting=</varname></term> + + <listitem><para>Configure the default resource accounting settings, as configured per-unit by + <varname>CPUAccounting=</varname>, <varname>BlockIOAccounting=</varname>, <varname>MemoryAccounting=</varname>, + <varname>TasksAccounting=</varname>, <varname>IOAccounting=</varname> and <varname>IPAccounting=</varname>. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details on the per-unit settings. <varname>DefaultTasksAccounting=</varname> defaults to yes, + <varname>DefaultMemoryAccounting=</varname> to &MEMORY_ACCOUNTING_DEFAULT;. <varname>DefaultCPUAccounting=</varname> + defaults to yes if enabling CPU accounting doesn't require the CPU controller to be enabled (Linux 4.15+ using the + unified hierarchy for resource control), otherwise it defaults to no. The other three settings default to no.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultTasksMax=</varname></term> + + <listitem><para>Configure the default value for the per-unit <varname>TasksMax=</varname> setting. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. This setting applies to all unit types that support resource control settings, with the exception + of slice units. Defaults to 15% of the minimum of <varname>kernel.pid_max=</varname>, <varname>kernel.threads-max=</varname> + and root cgroup <varname>pids.max</varname>. + Kernel has a default value for <varname>kernel.pid_max=</varname> and an algorithm of counting in case of more than 32 cores. + For example with the default <varname>kernel.pid_max=</varname>, <varname>DefaultTasksMax=</varname> defaults to 4915, + but might be greater in other systems or smaller in OS containers.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultLimitCPU=</varname></term> + <term><varname>DefaultLimitFSIZE=</varname></term> + <term><varname>DefaultLimitDATA=</varname></term> + <term><varname>DefaultLimitSTACK=</varname></term> + <term><varname>DefaultLimitCORE=</varname></term> + <term><varname>DefaultLimitRSS=</varname></term> + <term><varname>DefaultLimitNOFILE=</varname></term> + <term><varname>DefaultLimitAS=</varname></term> + <term><varname>DefaultLimitNPROC=</varname></term> + <term><varname>DefaultLimitMEMLOCK=</varname></term> + <term><varname>DefaultLimitLOCKS=</varname></term> + <term><varname>DefaultLimitSIGPENDING=</varname></term> + <term><varname>DefaultLimitMSGQUEUE=</varname></term> + <term><varname>DefaultLimitNICE=</varname></term> + <term><varname>DefaultLimitRTPRIO=</varname></term> + <term><varname>DefaultLimitRTTIME=</varname></term> + + <listitem><para>These settings control various default resource limits for processes executed by + units. See + <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details. These settings may be overridden in individual units using the corresponding + <varname>LimitXXX=</varname> directives and they accept the same parameter syntax, + see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. Note that these resource limits are only defaults + for units, they are not applied to the service manager process (i.e. PID 1) itself.</para></listitem> + </varlistentry> + + <varlistentry> + <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> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-sysusers.xml b/man/systemd-sysusers.xml new file mode 100644 index 0000000..950a8b4 --- /dev/null +++ b/man/systemd-sysusers.xml @@ -0,0 +1,148 @@ +<?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-or-later --> + +<refentry id="systemd-sysusers" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-sysusers</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-sysusers</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-sysusers</refname> + <refname>systemd-sysusers.service</refname> + <refpurpose>Allocate system users and groups</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-sysusers</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg> + </cmdsynopsis> + + <para><filename>systemd-sysusers.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-sysusers</command> creates system users and + groups, based on the file format and location specified in + <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>If invoked with no arguments, it applies all directives from all files + found in the directories specified by + <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + When invoked with positional arguments, if option + <option>--replace=<replaceable>PATH</replaceable></option> is specified, arguments + specified on the command line are used instead of the configuration file + <replaceable>PATH</replaceable>. Otherwise, just the configuration specified by + the command line arguments is executed. The string <literal>-</literal> may be + specified instead of a filename to instruct <command>systemd-sysusers</command> + to read the configuration from standard input. If only the basename of a file is + specified, all configuration directories are searched for a matching file and + the file found that has the highest priority is executed.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--root=<replaceable>root</replaceable></option></term> + <listitem><para>Takes a directory path as an argument. All + paths will be prefixed with the given alternate + <replaceable>root</replaceable> path, including config search + paths. </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--image=<replaceable>image</replaceable></option></term> + + <listitem><para>Takes a path to a disk image file or block device node. If specified all operations + are applied to file system in the indicated disk image. This is similar to <option>--root=</option> + but operates on file systems stored in disk images or block devices. The disk image should either + contain just a file system or a set of file systems within a GPT partition table, following the + <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>. For further information on supported disk images, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + switch of the same name.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--replace=<replaceable>PATH</replaceable></option></term> + <listitem><para>When this option is given, one ore more positional arguments + must be specified. All configuration files found in the directories listed in + <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + will be read, and the configuration given on the command line will be + handled instead of and with the same priority as the configuration file + <replaceable>PATH</replaceable>.</para> + + <para>This option is intended to be used when package installation scripts + are running and files belonging to that package are not yet available on + disk, so their contents must be given on the command line, but the admin + configuration might already exist and should be given higher priority. + </para> + + <example> + <title>RPM installation script for radvd</title> + + <programlisting>echo 'u radvd - "radvd daemon"' | \ + systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf -</programlisting> + + <para>This will create the radvd user as if + <filename>/usr/lib/sysusers.d/radvd.conf</filename> was already on disk. + An admin might override the configuration specified on the command line by + placing <filename>/etc/sysusers.d/radvd.conf</filename> or even + <filename>/etc/sysusers.d/00-overrides.conf</filename>.</para> + + <para>Note that this is the expanded form, and when used in a package, this + would be written using a macro with "radvd" and a file containing the + configuration line as arguments.</para> + </example> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--inline</option></term> + <listitem><para>Treat each positional argument as a separate configuration + line instead of a file name.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="cat-config" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code + otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-sysv-generator.xml b/man/systemd-sysv-generator.xml new file mode 100644 index 0000000..14ab932 --- /dev/null +++ b/man/systemd-sysv-generator.xml @@ -0,0 +1,72 @@ +<?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-or-later --> +<refentry id="systemd-sysv-generator" conditional="HAVE_SYSV_COMPAT"> + + <refentryinfo> + <title>systemd-sysv-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-sysv-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-sysv-generator</refname> + <refpurpose>Unit generator for SysV init scripts</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-sysv-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-sysv-generator</filename> is a generator + that creates wrapper .service units for + <ulink url="https://savannah.nongnu.org/projects/sysvinit">SysV init</ulink> + scripts in <filename>/etc/init.d/*</filename> at boot and when + configuration of the system manager is reloaded. This will allow + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to support them similarly to native units.</para> + + <para><ulink url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB headers</ulink> + in SysV init scripts are interpreted, and the ordering specified + in the header is turned into dependencies between the generated + unit and other units. The LSB facilities + <literal>$remote_fs</literal>, <literal>$network</literal>, + <literal>$named</literal>, <literal>$portmap</literal>, + <literal>$time</literal> are supported and will be turned into + dependencies on specific native systemd targets. See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more details.</para> + + <para>SysV runlevels have corresponding systemd targets + (<filename>runlevel<replaceable>X</replaceable>.target</filename>). + The wrapper unit that is generated will be wanted by those targets + which correspond to runlevels for which the script is + enabled.</para> + + <para><command>systemd</command> does not support SysV scripts as + part of early boot, so all wrapper units are ordered after + <filename>basic.target</filename>.</para> + + <para><filename>systemd-sysv-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-time-wait-sync.service.xml b/man/systemd-time-wait-sync.service.xml new file mode 100644 index 0000000..28f55a1 --- /dev/null +++ b/man/systemd-time-wait-sync.service.xml @@ -0,0 +1,68 @@ +<?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-or-later --> + +<refentry id="systemd-time-wait-sync.service" conditional='ENABLE_TIMESYNCD'> + + <refentryinfo> + <title>systemd-time-wait-sync.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-time-wait-sync.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-time-wait-sync.service</refname> + <refname>systemd-time-wait-sync</refname> + <refpurpose>Wait until kernel time is synchronized</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-time-wait-sync.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-time-wait-sync</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-time-wait-sync</filename> is a system service that delays the start of units that depend on + <filename>time-sync.target</filename> until the system time has been synchronized with an accurate time source by + <filename>systemd-timesyncd.service</filename>.</para> + + <para><filename>systemd-timesyncd.service</filename> notifies on successful synchronization. + <filename>systemd-time-wait-sync</filename> also tries to detect when the kernel marks the time as synchronized, + but this detection is not reliable and is intended only as a fallback for other services that can be used to + synchronize time (e.g., ntpd, chronyd).</para> + + </refsect1> + + <refsect1> + <title>Files</title> + + <variablelist> + <varlistentry> + <term><filename>/run/systemd/timesync/synchronized</filename></term> + + <listitem> + <para>The presence of this file indicates to this service that the system clock has been synchronized.</para> + </listitem> + + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-timedated.service.xml b/man/systemd-timedated.service.xml new file mode 100644 index 0000000..112bdf3 --- /dev/null +++ b/man/systemd-timedated.service.xml @@ -0,0 +1,105 @@ +<?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-or-later --> + +<refentry id="systemd-timedated.service" conditional='ENABLE_TIMEDATED'> + + <refentryinfo> + <title>systemd-timedated.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-timedated.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-timedated.service</refname> + <refname>systemd-timedated</refname> + <refpurpose>Time and date bus mechanism</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-timedated.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-timedated</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-timedated.service</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 network time synchronization. + <filename>systemd-timedated</filename> is automatically activated + on request and terminates itself when it is unused.</para> + + <para>The tool + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + is a command line client to this service.</para> + + <para><filename>systemd-timedated</filename> currently offers access to + the following four settings: + <itemizedlist> + <listitem><para>The system time</para></listitem> + + <listitem><para>The system timezone</para></listitem> + + <listitem><para>A boolean controlling whether the system RTC is in local or UTC + timezone</para></listitem> + + <listitem><para>Whether the time synchronization service is enabled/started or + disabled/stopped, see next section.</para></listitem> + </itemizedlist></para> + + <para>See + <citerefentry><refentrytitle>org.freedesktop.timedate1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the D-Bus API.</para> + </refsect1> + + <refsect1> + <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> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-timesyncd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-timesyncd.service.xml b/man/systemd-timesyncd.service.xml new file mode 100644 index 0000000..ff14c40 --- /dev/null +++ b/man/systemd-timesyncd.service.xml @@ -0,0 +1,104 @@ +<?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-or-later --> + +<refentry id="systemd-timesyncd.service" conditional='ENABLE_TIMESYNCD'> + + <refentryinfo> + <title>systemd-timesyncd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-timesyncd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-timesyncd.service</refname> + <refname>systemd-timesyncd</refname> + <refpurpose>Network Time Synchronization</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-timesyncd.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-timesyncd</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-timesyncd</filename> is a system service + that may be used to synchronize the local system clock with a + remote Network Time Protocol server. It also saves the local time + to disk every time the clock has been synchronized and uses this + to possibly advance the system realtime clock on subsequent + reboots to ensure it monotonically advances even if the system + lacks a battery-buffered RTC chip.</para> + + <para>The <filename>systemd-timesyncd</filename> service + specifically implements only SNTP. This minimalistic + service will set the system clock for large offsets or + slowly adjust it for smaller deltas. More complex use + cases are not covered by <filename>systemd-timesyncd</filename>.</para> + + <para>The NTP servers contacted are determined from the global + settings in + <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + the per-link static settings in <filename>.network</filename> + files, and the per-link dynamic settings received over DHCP. See + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more details.</para> + + <para><citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>set-ntp</command> command may be used to enable and + start, or disable and stop this service.</para> + + <para><citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>timesync-status</command> or <command>show-timesync</command> command can be used to show the + current status of this service.</para> + </refsect1> + + <refsect1> + <title>Files</title> + + <variablelist> + <varlistentry> + <term><filename>/var/lib/systemd/timesync/clock</filename></term> + + <listitem> + <para>The modification time of this file indicates the timestamp of the last successful + synchronization (or at least the systemd build date, in case synchronization was not + possible).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>/run/systemd/timesync/synchronized</filename></term> + + <listitem> + <para>A file that is touched on each successful synchronization, to assist + <filename>systemd-time-wait-sync</filename> and other applications to detecting synchronization + events.</para> + </listitem> + + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml new file mode 100644 index 0000000..90c2626 --- /dev/null +++ b/man/systemd-tmpfiles.xml @@ -0,0 +1,265 @@ +<?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-or-later --> + +<refentry id="systemd-tmpfiles" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-tmpfiles</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-tmpfiles</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-tmpfiles</refname> + <refname>systemd-tmpfiles-setup.service</refname> + <refname>systemd-tmpfiles-setup-dev.service</refname> + <refname>systemd-tmpfiles-clean.service</refname> + <refname>systemd-tmpfiles-clean.timer</refname> + <refpurpose>Creates, deletes and cleans up volatile + and temporary files and directories</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-tmpfiles</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg> + </cmdsynopsis> + + <para>System units: +<literallayout><filename>systemd-tmpfiles-setup.service</filename> +<filename>systemd-tmpfiles-setup-dev.service</filename> +<filename>systemd-tmpfiles-clean.service</filename> +<filename>systemd-tmpfiles-clean.timer</filename></literallayout></para> + + <para>User units: +<literallayout><filename>systemd-tmpfiles-setup.service</filename> +<filename>systemd-tmpfiles-clean.service</filename> +<filename>systemd-tmpfiles-clean.timer</filename></literallayout></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-tmpfiles</command> creates, deletes, and + cleans up volatile and temporary files and directories, based on + the configuration file format and location specified in + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>If invoked with no arguments, it applies all directives from all configuration + files. When invoked with <option>--replace=<replaceable>PATH</replaceable></option>, + arguments specified on the command line are used instead of the configuration file + <replaceable>PATH</replaceable>. Otherwise, if one or more absolute filenames are + passed on the command line, only the directives in these files are applied. If + <literal>-</literal> is specified instead of a filename, directives are read from + standard input. If only the basename of a configuration file is specified, all + configuration directories as specified in + <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-controlled 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> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--create</option></term> + <listitem><para>If this option is passed, all files and + directories marked with + <varname>f</varname>, + <varname>F</varname>, + <varname>w</varname>, + <varname>d</varname>, + <varname>D</varname>, + <varname>v</varname>, + <varname>p</varname>, + <varname>L</varname>, + <varname>c</varname>, + <varname>b</varname>, + <varname>m</varname> + in the configuration files are created or written to. Files + and directories marked with + <varname>z</varname>, + <varname>Z</varname>, + <varname>t</varname>, + <varname>T</varname>, + <varname>a</varname>, and + <varname>A</varname> have their ownership, access mode and + security labels set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--clean</option></term> + <listitem><para>If this option is passed, all files and + directories with an age parameter configured will be cleaned + up.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--remove</option></term> + <listitem><para>If this option is passed, the contents of + directories marked with <varname>D</varname> or + <varname>R</varname>, and files or directories themselves + marked with <varname>r</varname> or <varname>R</varname> are + removed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--user</option></term> + <listitem><para>Execute "user" configuration, i.e. <filename>tmpfiles.d</filename> + files in user configuration directories.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--boot</option></term> + <listitem><para>Also execute lines with an exclamation mark. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--prefix=<replaceable>path</replaceable></option></term> + <listitem><para>Only apply rules with paths that start with + the specified prefix. This option can be specified multiple + times.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--exclude-prefix=<replaceable>path</replaceable></option></term> + <listitem><para>Ignore rules with paths that start with the + specified prefix. This option can be specified multiple + times.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-E</option></term> + <listitem><para>A shortcut for <literal>--exclude-prefix=/dev --exclude-prefix=/proc + --exclude-prefix=/run --exclude-prefix=/sys</literal>, i.e. exclude the hierarchies typically backed + by virtual or memory file systems. This is useful in combination with <option>--root=</option>, if + the specified directory tree contains an OS tree without these virtual/memory file systems mounted + in, as it is typically not desirable to create any files and directories below these subdirectories + if they are supposed to be overmounted during runtime.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--root=<replaceable>root</replaceable></option></term> + <listitem><para>Takes a directory path as an argument. All paths will be prefixed with the given alternate + <replaceable>root</replaceable> path, including config search paths.</para> + + <para>When this option is used, the libc Name Service Switch (NSS) is bypassed for resolving users + and groups. Instead the files <filename>/etc/passwd</filename> and <filename>/etc/group</filename> + inside the alternate root are read directly. This means that users/groups not listed in these files + will not be resolved, i.e. LDAP NIS and other complex databases are not considered.</para> + + <para>Consider combining this with <option>-E</option> to ensure the invocation does not create files + or directories below mount points in the OS image operated on that are typically overmounted during + runtime.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--image=<replaceable>image</replaceable></option></term> + + <listitem><para>Takes a path to a disk image file or block device node. If specified all operations + are applied to file system in the indicated disk image. This is similar to <option>--root=</option> + but operates on file systems stored in disk images or block devices. The disk image should either + contain just a file system or a set of file systems within a GPT partition table, following the + <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>. For further information on supported disk images, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + switch of the same name.</para> + + <para>Implies <option>-E</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--replace=<replaceable>PATH</replaceable></option></term> + <listitem><para>When this option is given, one ore more positional arguments + must be specified. All configuration files found in the directories listed in + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + will be read, and the configuration given on the command line will be + handled instead of and with the same priority as the configuration file + <replaceable>PATH</replaceable>.</para> + + <para>This option is intended to be used when package installation scripts + are running and files belonging to that package are not yet available on + disk, so their contents must be given on the command line, but the admin + configuration might already exist and should be given higher priority. + </para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="cat-config" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </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 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> + + <programlisting>systemd-tmpfiles --remove --create</programlisting> + </refsect1> + + <refsect1> + <title>Unprivileged --cleanup operation</title> + + <para><command>systemd-tmpfiles</command> tries to avoid changing + the access and modification times on the directories it accesses, + which requires <constant>CAP_FOWNER</constant> privileges. When + running as non-root, directories which are checked for files to + clean up will have their access time bumped, which might prevent + their cleanup. + </para> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned. If the configuration was syntactically invalid (syntax errors, + missing arguments, …), so some lines had to be ignored, but no other errors occurred, + <constant>65</constant> is returned (<constant>EX_DATAERR</constant> from + <filename>/usr/include/sysexits.h</filename>). If the configuration was syntactically valid, but + could not be executed (lack of permissions, creation of files in missing directories, invalid + contents when writing to <filename>/sys/</filename> values, …), <constant>73</constant> is + returned (<constant>EX_CANTCREAT</constant> from <filename>/usr/include/sysexits.h</filename>). + Otherwise, <constant>1</constant> is returned (<constant>EXIT_FAILURE</constant> from + <filename>/usr/include/stdlib.h</filename>). + </para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-tty-ask-password-agent.xml b/man/systemd-tty-ask-password-agent.xml new file mode 100644 index 0000000..9956576 --- /dev/null +++ b/man/systemd-tty-ask-password-agent.xml @@ -0,0 +1,126 @@ +<?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-or-later --> + +<refentry id="systemd-tty-ask-password-agent" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-tty-ask-password-agent</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-tty-ask-password-agent</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-tty-ask-password-agent</refname> + <refpurpose>List or process pending systemd password requests</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>systemd-tty-ask-password-agent</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="opt" rep="repeat">VARIABLE=VALUE</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-tty-ask-password-agent</command> is a + password agent that handles password requests of the system, for + example for hard disk encryption passwords or SSL certificate + passwords that need to be queried at boot-time or during + runtime.</para> + + <para><command>systemd-tty-ask-password-agent</command> implements + the <ulink url="https://systemd.io/PASSWORD_AGENTS/">Password Agents + Specification</ulink>, and is one of many possible response agents which + answer to queries formulated with + <citerefentry><refentrytitle>systemd-ask-password</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--list</option></term> + + <listitem><para>Lists all currently pending system password requests.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--query</option></term> + + <listitem><para>Process all currently pending system password + requests by querying the user on the calling + TTY.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--watch</option></term> + + <listitem><para>Continuously process password + requests.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--wall</option></term> + + <listitem><para>Forward password requests to + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + instead of querying the user on the calling + TTY.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--plymouth</option></term> + + <listitem><para>Ask question with + <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry> + instead of querying the user on the calling + TTY.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--console</option></term> + + <listitem><para>Ask question on + <filename>/dev/console</filename> instead of querying the user + on the calling TTY. </para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure + code otherwise.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-ask-password-console.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-udev-settle.service.xml b/man/systemd-udev-settle.service.xml new file mode 100644 index 0000000..2852f31 --- /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-or-later --> + +<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 new file mode 100644 index 0000000..5df4cd6 --- /dev/null +++ b/man/systemd-udevd.service.xml @@ -0,0 +1,239 @@ +<?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-or-later --> + +<refentry id="systemd-udevd.service" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd-udevd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-udevd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-udevd.service</refname> + <refname>systemd-udevd-control.socket</refname> + <refname>systemd-udevd-kernel.socket</refname> + <refname>systemd-udevd</refname> + <refpurpose>Device event managing daemon</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-udevd.service</filename></para> + <para><filename>systemd-udevd-control.socket</filename></para> + <para><filename>systemd-udevd-kernel.socket</filename></para> + + <cmdsynopsis> + <command>/usr/lib/systemd/systemd-udevd</command> + <arg><option>--daemon</option></arg> + <arg><option>--debug</option></arg> + <arg><option>--children-max=</option></arg> + <arg><option>--exec-delay=</option></arg> + <arg><option>--event-timeout=</option></arg> + <arg><option>--resolve-names=early|late|never</option></arg> + <arg><option>--version</option></arg> + <arg><option>--help</option></arg> + </cmdsynopsis> + + </refsynopsisdiv> + + <refsect1><title>Description</title> + <para><command>systemd-udevd</command> listens to kernel uevents. + For every event, systemd-udevd executes matching instructions + specified in udev rules. See <citerefentry> + <refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum> + </citerefentry>.</para> + + <para>The behavior of the daemon can be configured using + <citerefentry><refentrytitle>udev.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + its command line options, environment variables, and on the kernel + command line, or changed dynamically with <command>udevadm + control</command>. + </para> + </refsect1> + + <refsect1><title>Options</title> + <variablelist> + <varlistentry> + <term><option>-d</option></term> + <term><option>--daemon</option></term> + <listitem> + <para>Detach and run in the background.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-D</option></term> + <term><option>--debug</option></term> + <listitem> + <para>Print debug messages to standard error.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-c</option></term> + <term><option>--children-max=</option></term> + <listitem> + <para>Limit the number of events executed in parallel.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-e</option></term> + <term><option>--exec-delay=</option></term> + <listitem> + <para>Delay the execution of <varname>RUN</varname> + instructions by the given number of seconds. This option + might be useful when debugging system crashes during + coldplug caused by loading non-working kernel + modules.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-t</option></term> + <term><option>--event-timeout=</option></term> + <listitem> + <para>Set the number of seconds to wait for events to finish. After + this time, the event will be terminated. The default is 180 seconds.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-s</option></term> + <term><option>--timeout-signal=</option></term> + <listitem> + <para>Set the signal which <filename>systemd-udevd</filename> will send to + forked off processes after reaching event timeout. The setting can be overridden + at boot time with the kernel command line option + <varname>udev.timeout_signal=</varname>. Setting to <constant>SIGABRT</constant> + may be helpful in order to debug worker timeouts. Defaults to + <constant>SIGKILL</constant>. Note that setting the option on the command line + overrides the setting from the configuration file. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-N</option></term> + <term><option>--resolve-names=</option></term> + <listitem> + <para>Specify when systemd-udevd should resolve names of users and groups. + When set to <option>early</option> (the default), names will be + resolved when the rules are parsed. When set to + <option>late</option>, names will be resolved for every event. + When set to <option>never</option>, names will never be resolved + and all devices will be owned by root.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1><title>Kernel command line</title> + <variablelist class='kernel-commandline-options'> + <para>Parameters prefixed with "rd." will be read when <command>systemd-udevd</command> is used in an + initrd, those without will be processed both in the initrd and on the host.</para> + <varlistentry> + <term><varname>udev.log_level=</varname></term> + <term><varname>rd.udev.log_level=</varname></term> + <listitem> + <para>Set the log level.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>udev.children_max=</varname></term> + <term><varname>rd.udev.children_max=</varname></term> + <listitem> + <para>Limit the number of events executed in parallel.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>udev.exec_delay=</varname></term> + <term><varname>rd.udev.exec_delay=</varname></term> + <listitem> + <para>Delay the execution of <varname>RUN</varname> instructions by the given + number of seconds. This option might be useful when + debugging system crashes during coldplug caused by loading + non-working kernel modules.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>udev.event_timeout=</varname></term> + <term><varname>rd.udev.event_timeout=</varname></term> + <listitem> + <para>Wait for events to finish up to the given number + of seconds. This option might be useful if events are + terminated due to kernel drivers taking too long to initialize.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>udev.timeout_signal=</varname></term> + <term><varname>rd.udev.timeout_signal=</varname></term> + <listitem> + <para>Specifies a signal that <filename>systemd-udevd</filename> will send to + workers on timeout. Note that kernel command line option overrides both the + setting in the configuration file and the one on the program command line.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>udev.blockdev_read_only</varname></term> + <term><varname>rd.udev.blockdev_read_only</varname></term> + <listitem> + <para>If specified, mark all physical block devices read-only as they appear. Synthetic block + devices (such as loopback block devices or device mapper devices) are left as they are. This is + useful to guarantee that the contents of physical block devices remains unmodified during runtime, + for example to implement fully stateless systems, for testing or for recovery situations where + corrupted file systems shall not be corrupted further through accidental modification.</para> + + <para>A block device may be marked writable again by issuing the <command>blockdev + --setrw</command> command, see <citerefentry + project='man-pages'><refentrytitle>blockdev</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>net.ifnames=</varname></term> + <listitem> + <para>Network interfaces are renamed to give them predictable names + when possible. It is enabled by default; specifying 0 disables it.</para> + </listitem> + </varlistentry> + <varlistentry> + <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). 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 + updated, previously missing attributes <filename>systemd-udevd.service</filename> is checking might + appear, which affects older name derivation algorithms, too.</para> + </listitem> + </varlistentry> + </variablelist> + <!-- when adding entries here, consider also adding them in kernel-command-line.xml --> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>udev.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-update-done.service.xml b/man/systemd-update-done.service.xml new file mode 100644 index 0000000..3393010 --- /dev/null +++ b/man/systemd-update-done.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-or-later --> +<refentry id="systemd-update-done.service"> + + <refentryinfo> + <title>systemd-update-done.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-update-done.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-update-done.service</refname> + <refname>systemd-update-done</refname> + <refpurpose>Mark <filename>/etc/</filename> and <filename>/var/</filename> fully updated</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-update-done.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-update-done</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-update-done.service</filename> is a + service that is invoked as part of the first boot after the vendor + operating system resources in <filename>/usr/</filename> have been + updated. This is useful to implement offline updates of + <filename>/usr/</filename> which might require updates to + <filename>/etc/</filename> or <filename>/var/</filename> on the + following boot.</para> + + <para><filename>systemd-update-done.service</filename> updates the + file modification time (mtime) of the stamp files + <filename>/etc/.updated</filename> and + <filename>/var/.updated</filename> to the modification time of the + <filename>/usr/</filename> directory, unless the stamp files are + already newer.</para> + + <para>Services that shall run after offline upgrades of + <filename>/usr/</filename> should order themselves before + <filename>systemd-update-done.service</filename>, and use the + <varname>ConditionNeedsUpdate=</varname> (see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) + condition to make sure to run when <filename>/etc/</filename> or + <filename>/var/</filename> are older than <filename>/usr/</filename> + according to the modification times of the files described above. + This requires that updates to <filename>/usr/</filename> are always + followed by an update of the modification time of + <filename>/usr/</filename>, for example by invoking + <citerefentry project='man-pages'><refentrytitle>touch</refentrytitle><manvolnum>1</manvolnum></citerefentry> + on it.</para> + + <para>Note that if the <varname>systemd.condition-needs-update=</varname> kernel command line option is + used it overrides the <varname>ConditionNeedsUpdate=</varname> unit condition checks. In that case + <filename>systemd-update-done.service</filename> will not reset the condition state until a follow-up + reboot where the kernel switch is not specified anymore.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>touch</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-update-utmp.service.xml b/man/systemd-update-utmp.service.xml new file mode 100644 index 0000000..ff01893 --- /dev/null +++ b/man/systemd-update-utmp.service.xml @@ -0,0 +1,51 @@ +<?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-or-later --> +<refentry id="systemd-update-utmp.service" conditional="ENABLE_UTMP"> + + <refentryinfo> + <title>systemd-update-utmp.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-update-utmp.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-update-utmp.service</refname> + <refname>systemd-update-utmp-runlevel.service</refname> + <refname>systemd-update-utmp</refname> + <refpurpose>Write audit and utmp updates at bootup, runlevel + changes and shutdown</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-update-utmp.service</filename></para> + <para><filename>systemd-update-utmp-runlevel.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-update-utmp</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-update-utmp-runlevel.service</filename> is + a service that writes SysV runlevel changes to utmp and wtmp, as + well as the audit logs, as they occur. + <filename>systemd-update-utmp.service</filename> does the same for + system reboots and shutdown requests.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>auditd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-user-sessions.service.xml b/man/systemd-user-sessions.service.xml new file mode 100644 index 0000000..f05e4e3 --- /dev/null +++ b/man/systemd-user-sessions.service.xml @@ -0,0 +1,50 @@ +<?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-or-later --> +<refentry id="systemd-user-sessions.service" conditional='HAVE_PAM'> + + <refentryinfo> + <title>systemd-user-sessions.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-user-sessions.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-user-sessions.service</refname> + <refname>systemd-user-sessions</refname> + <refpurpose>Permit user logins after boot, prohibit user logins at shutdown</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-user-sessions.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-user-sessions</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-user-sessions.service</filename> is a + service that controls user logins through + <citerefentry project='man-pages'><refentrytitle>pam_nologin</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + After basic system initialization is complete, it removes + <filename>/run/nologin</filename>, thus permitting logins. Before + system shutdown, it creates <filename>/run/nologin</filename>, thus + prohibiting further logins.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam_nologin</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-userdbd.service.xml b/man/systemd-userdbd.service.xml new file mode 100644 index 0000000..a6234be --- /dev/null +++ b/man/systemd-userdbd.service.xml @@ -0,0 +1,69 @@ +<?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-or-later --> + +<refentry id="systemd-userdbd.service" conditional='ENABLE_USERDB'> + + <refentryinfo> + <title>systemd-userdbd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-userdbd.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-userdbd.service</refname> + <refname>systemd-userdbd</refname> + <refpurpose>JSON User/Group Record Query Multiplexer/NSS Compatibility</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-userdbd.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-userdbd</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-userdbd</command> is a system service that multiplexes user/group lookups to all + local services that provide JSON user/group record definitions to the system. In addition it synthesizes + JSON user/group records from classic UNIX/glibc NSS user/group records in order to provide full backwards + compatibility.</para> + + <para>Most of <command>systemd-userdbd</command>'s functionality is accessible through the + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + command.</para> + + <para>The user and group records this service provides access to follow the <ulink + url="https://systemd.io/USER_RECORD">JSON User Record</ulink> and <ulink + url="https://systemd.io/GROUP_RECORD">JSON Group Record</ulink> definitions. This service implements the + <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>, and + multiplexes access other services implementing this API, too. It is thus both server and client of this + API.</para> + + <para>This service provides two distinct <ulink url="https://varlink.org/">Varlink</ulink> services: + <constant>io.systemd.Multiplexer</constant> provides a single, unified API for querying JSON user and + group records. Internally it talks to all other user/group record services running on the system in + parallel and forwards any information discovered. This simplifies clients substantially since they need + to talk to a single service only instead of all of them in + parallel. <constant>io.systemd.NameSeviceSwitch</constant> provides compatibility with classic UNIX/glibc + NSS user records, i.e. converts <type>struct passwd</type> and <type>struct group</type> records as + acquired with APIs such as <citerefentry + project='man-pages'><refentrytitle>getpwnam</refentrytitle><manvolnum>1</manvolnum></citerefentry> to JSON + user/group records, thus hiding the differences between the services as much as possible.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml new file mode 100644 index 0000000..80577ed --- /dev/null +++ b/man/systemd-vconsole-setup.service.xml @@ -0,0 +1,63 @@ +<?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-or-later --> +<refentry id="systemd-vconsole-setup.service" conditional='ENABLE_VCONSOLE'> + + <refentryinfo> + <title>systemd-vconsole-setup.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-vconsole-setup.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-vconsole-setup.service</refname> + <refname>systemd-vconsole-setup</refname> + <refpurpose>Configure the virtual consoles</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-vconsole-setup.service</filename></para> + <cmdsynopsis> + <command>/usr/lib/systemd/systemd-vconsole-setup</command> + <arg choice="opt">TTY</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <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 + 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 + it as needed when language or console changes are made. Internally, this program calls <citerefentry + project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry> and <citerefentry + project='die-net'><refentrytitle>setfont</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para>Execute <command>systemctl restart systemd-vconsole-setup.service</command> in order to apply any manual + changes made to <filename>/etc/vconsole.conf</filename>.</para> + + <para>See <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + information about the configuration files and kernel command line options understood by this program.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>setfont</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-veritysetup-generator.xml b/man/systemd-veritysetup-generator.xml new file mode 100644 index 0000000..d2736a7 --- /dev/null +++ b/man/systemd-veritysetup-generator.xml @@ -0,0 +1,97 @@ +<?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-or-later --> +<refentry id="systemd-veritysetup-generator" conditional='HAVE_LIBCRYPTSETUP'> + + <refentryinfo> + <title>systemd-veritysetup-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-veritysetup-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-veritysetup-generator</refname> + <refpurpose>Unit generator for integrity protected block devices</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/system-generators/systemd-veritysetup-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <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 + 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 set up with this generator, backing the root file system of the + OS.</para> + + <para><filename>systemd-veritysetup-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para><filename>systemd-veritysetup-generator</filename> + understands the following kernel command line parameters:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.verity=</varname></term> + <term><varname>rd.systemd.verity=</varname></term> + + <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If <literal>no</literal>, + disables the generator entirely. <varname>rd.systemd.verity=</varname> is honored only by the initial RAM disk + (initrd) while <varname>systemd.verity=</varname> is honored by both the host system and the + initrd. </para></listitem> + </varlistentry> + + <varlistentry> + <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 + <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 + partition device is looked for under a GPT partition UUID derived from the last 128bit of the root hash. Hence + it is usually sufficient to specify the root hash to boot from an integrity protected root file system, as + device paths are automatically determined from it — as long as the partition table is properly set up.</para> + </listitem> + </varlistentry> + + <varlistentry> + <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 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> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>veritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-veritysetup@.service.xml b/man/systemd-veritysetup@.service.xml new file mode 100644 index 0000000..c9554b0 --- /dev/null +++ b/man/systemd-veritysetup@.service.xml @@ -0,0 +1,50 @@ +<?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-or-later --> +<refentry id="systemd-veritysetup@.service" conditional='HAVE_LIBCRYPTSETUP'> + + <refentryinfo> + <title>systemd-veritysetup@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-veritysetup@.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-veritysetup@.service</refname> + <refname>systemd-veritysetup</refname> + <refpurpose>Disk integrity protection logic</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-veritysetup@.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-veritysetup</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-veritysetup@.service</filename> is a service responsible for setting up integrity + protection (verity) block devices. It should be instantiated for each device that requires integrity + protection.</para> + + <para>At early boot and when the system manager configuration is reloaded kernel command line configuration for + integrity protected block devices is translated into <filename>systemd-veritysetup@.service</filename> units by + <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>veritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-volatile-root.service.xml b/man/systemd-volatile-root.service.xml new file mode 100644 index 0000000..d591da2 --- /dev/null +++ b/man/systemd-volatile-root.service.xml @@ -0,0 +1,54 @@ +<?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-or-later --> +<refentry id="systemd-volatile-root.service"> + + <refentryinfo> + <title>systemd-volatile-root.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-volatile-root.service</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-volatile-root.service</refname> + <refname>systemd-volatile-root</refname> + <refpurpose>Make the root file system volatile</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>systemd-volatile-root.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-volatile-root</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-volatile-root.service</filename> is a service that replaces the root directory with a + volatile memory file system (<literal>tmpfs</literal>), mounting the original (non-volatile) + <filename>/usr/</filename> inside it read-only. This way, vendor data from <filename>/usr/</filename> is available as + usual, but all configuration data in <filename>/etc/</filename>, all state data in <filename>/var/</filename> and all + other resources stored directly under the root directory are reset on boot and lost at shutdown, enabling fully + stateless systems.</para> + + <para>This service is only enabled if full volatile mode is selected, for example by specifying + <literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initial RAM disk + ("initrd"), before the system transitions to the host's root directory. Note that this service is not used if + <literal>systemd.volatile=state</literal> is used, as in that mode the root directory is non-volatile.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-xdg-autostart-generator.xml b/man/systemd-xdg-autostart-generator.xml new file mode 100644 index 0000000..4d153c3 --- /dev/null +++ b/man/systemd-xdg-autostart-generator.xml @@ -0,0 +1,57 @@ +<?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-or-later --> +<refentry id="systemd-xdg-autostart-generator" conditional="ENABLE_XDG_AUTOSTART"> + + <refentryinfo> + <title>systemd-xdg-autostart-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd-xdg-autostart-generator</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd-xdg-autostart-generator</refname> + <refpurpose>User unit generator for XDG autostart files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/usr/lib/systemd/user-generators/systemd-xdg-autostart-generator</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>systemd-xdg-autostart-generator</filename> is a generator + that creates .service units for + <ulink url="https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html">XDG autostart</ulink> + files. + This permits desktop environments to delegate startup of these applications to + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + .</para> + + <para>Units created by <filename>systemd-xdg-autostart-generator</filename> + can be started by the desktop environment using <literal>xdg-desktop-autostart.target</literal>. + See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more details.</para> + + <para><filename>systemd-xdg-autostart-generator</filename> implements + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.automount.xml b/man/systemd.automount.xml new file mode 100644 index 0000000..a6bc81e --- /dev/null +++ b/man/systemd.automount.xml @@ -0,0 +1,175 @@ +<?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-or-later --> + +<refentry id="systemd.automount"> + <refentryinfo> + <title>systemd.automount</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.automount</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.automount</refname> + <refpurpose>Automount unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>automount</replaceable>.automount</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.automount</literal> encodes information about a file + system automount point controlled and supervised by + systemd.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The automount specific configuration options + are configured in the [Automount] section.</para> + + <para>Automount units must be named after the automount directories they control. Example: the automount point + <filename index="false">/home/lennart</filename> must be configured in a unit file + <filename>home-lennart.automount</filename>. For details about the escaping logic used to convert a file system + path to a unit name see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note that + automount units cannot be templated, nor is it possible to add multiple names to an automount unit by creating + additional symlinks to its unit file.</para> + + <para>For each automount unit file a matching mount unit file (see + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details) must exist which is activated when the automount path + is accessed. Example: if an automount unit + <filename>home-lennart.automount</filename> is active and the user + accesses <filename>/home/lennart</filename> the mount unit + <filename>home-lennart.mount</filename> will be activated.</para> + + <para>Automount units may be used to implement on-demand mounting + as well as parallelized mounting of file systems.</para> + + <para>Note that automount units are separate from the mount itself, so you + should not set <varname>After=</varname> or <varname>Requires=</varname> + for mount dependencies here. For example, you should not set + <varname>After=network-online.target</varname> or similar on network + filesystems. Doing so may result in an ordering cycle.</para> + + <para>Note that automount support on Linux is privileged, automount units are hence only available in the + system service manager (and root's user service manager), but not in unprivileged user's service + manager.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>If an automount unit is beneath another mount unit in the + file system hierarchy, both a requirement and an ordering + dependency between both units are created automatically.</para></listitem> + + <listitem><para>An implicit <varname>Before=</varname> dependency is created + between an automount unit and the mount unit it activates.</para></listitem> + </itemizedlist> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Automount units acquire automatic <varname>Before=</varname> and + <varname>Conflicts=</varname> on <filename>umount.target</filename> in order to be stopped during + shutdown.</para></listitem> + + <listitem><para>Automount units automatically gain an <varname>After=</varname> dependency + on <filename>local-fs-pre.target</filename>, and a <varname>Before=</varname> dependency on + <filename>local-fs.target</filename>.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title><filename>fstab</filename></title> + + <para>Automount units may either be configured via unit files, or + via <filename>/etc/fstab</filename> (see + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details).</para> + + <para>For details how systemd parses + <filename>/etc/fstab</filename> see + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>If an automount point is configured in both + <filename>/etc/fstab</filename> and a unit file, the configuration + in the latter takes precedence.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Automount files must include an [Automount] section, which + carries information about the file system automount points it + supervises. The options specific to the [Automount] section of + automount units are the following:</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>Where=</varname></term> + <listitem><para>Takes an absolute path of a directory of the + automount point. If the automount point does not exist at time + that the automount point is installed, it is created. This + string must be reflected in the unit filename. (See above.) + This option is mandatory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DirectoryMode=</varname></term> + <listitem><para>Directories of automount points (and any + parent directories) are automatically created if needed. This + option specifies the file system access mode used when + creating these directories. Takes an access mode in octal + notation. Defaults to 0755.</para></listitem> + </varlistentry> + <varlistentry> + <term><varname>TimeoutIdleSec=</varname></term> + <listitem><para>Configures an idle timeout. Once the mount has been + idle for the specified time, systemd will attempt to unmount. Takes a + unit-less value in seconds, or a time span value such as "5min 20s". + Pass 0 to disable the timeout logic. The timeout is disabled by + default.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>automount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.device.xml b/man/systemd.device.xml new file mode 100644 index 0000000..255ca33 --- /dev/null +++ b/man/systemd.device.xml @@ -0,0 +1,165 @@ +<?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-or-later --> + +<refentry id="systemd.device"> + <refentryinfo> + <title>systemd.device</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.device</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.device</refname> + <refpurpose>Device unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>device</replaceable>.device</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.device</literal> encodes information about a device unit + as exposed in the + sysfs/<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> + device tree.</para> + + <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 [Device] section does not + exist, since no device-specific options may be configured.</para> + + <para>systemd will dynamically create device units for all kernel + devices that are marked with the "systemd" udev tag (by default + all block and network devices, and a few others). This may be used + to define dependencies between devices and other units. To tag a + udev device, use <literal>TAG+="systemd"</literal> in the udev + rules file, see + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details.</para> + + <para>Device units are named after the <filename>/sys/</filename> + and <filename>/dev/</filename> paths they control. Example: the + device <filename index="false">/dev/sda5</filename> is exposed in + systemd as <filename>dev-sda5.device</filename>. For details about + the escaping logic used to convert a file system path to a unit + name see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>Device units will be reloaded by systemd whenever the + corresponding device generates a <literal>changed</literal> event. + Other units can use <varname>ReloadPropagatedFrom=</varname> to react + to that event.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>Many unit types automatically acquire dependencies on device + units of devices they require. For example, + <filename>.socket</filename> unit acquire dependencies on the + device units of the network interface specified in + <varname>BindToDevice=</varname>. Similar, swap and mount units + acquire dependencies on the units encapsulating their backing + block devices.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>There are no default dependencies for device units.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>The udev Database</title> + + <para>Unit settings of device units may either be configured via unit files, or directly from the udev + database. The following udev device properties are understood by the service manager:</para> + + <variablelist class='udev-directives'> + <varlistentry> + <term><varname>SYSTEMD_WANTS=</varname></term> + <term><varname>SYSTEMD_USER_WANTS=</varname></term> + <listitem><para>Adds dependencies of type <varname>Wants=</varname> from the device unit to the specified + units. <varname>SYSTEMD_WANTS=</varname> is read by the system service manager, + <varname>SYSTEMD_USER_WANTS=</varname> by user service manager instances. These properties may be used to + activate arbitrary units when a specific device becomes available.</para> + + <para>Note that this and the other udev device properties are not taken into account unless the device is + tagged with the <literal>systemd</literal> tag in the udev database, because otherwise the device is not + exposed as a systemd unit (see above).</para> + + <para>Note that systemd will only act on <varname>Wants=</varname> dependencies when a device first becomes + active. It will not act on them if they are added to devices that are already active. Use + <varname>SYSTEMD_READY=</varname> (see below) to configure when a udev device shall be considered active, and + thus when to trigger the dependencies.</para> + + <!-- Note that we don't document here that we actually apply unit_name_mangle() to all specified names, since + that's kinda ugly, and people should instead specify correctly escaped names --> + + <para>The specified property value should be a space-separated list of valid unit names. If a unit template + name is specified (that is, a unit name containing an <literal>@</literal> character indicating a unit name to + use for multiple instantiation, but with an empty instance name following the <literal>@</literal>), it will be + automatically instantiated by the device's <literal>sysfs</literal> path (that is: the path is escaped and + inserted as instance name into the template unit name). This is useful in order to instantiate a specific + template unit once for each device that appears and matches specific properties.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYSTEMD_ALIAS=</varname></term> + <listitem><para>Adds an additional alias name to the device + unit. This must be an absolute path that is automatically + transformed into a unit name. (See above.)</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYSTEMD_READY=</varname></term> + <listitem><para>If set to 0, systemd will consider this device unplugged even if it shows up in the udev + tree. If this property is unset or set to 1, the device will be considered plugged if it is visible in the udev + tree.</para> + + <para>This option is useful for devices that initially show up in an uninitialized state in the tree, and for + which a <literal>changed</literal> event is generated the moment they are fully set up. Note that + <varname>SYSTEMD_WANTS=</varname> (see above) is not acted on as long as <varname>SYSTEMD_READY=0</varname> is + set for a device.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ID_MODEL_FROM_DATABASE=</varname></term> + <term><varname>ID_MODEL=</varname></term> + + <listitem><para>If set, this property is used as description + string for the device unit.</para></listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.dnssd.xml b/man/systemd.dnssd.xml new file mode 100644 index 0000000..96a14b1 --- /dev/null +++ b/man/systemd.dnssd.xml @@ -0,0 +1,223 @@ +<?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-or-later --> + +<refentry id="systemd.dnssd" + xmlns:xi="http://www.w3.org/2001/XInclude" + conditional='ENABLE_RESOLVE'> + + <refentryinfo> + <title>systemd.dnssd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.dnssd</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.dnssd</refname> + <refpurpose>DNS-SD configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>network_service</replaceable>.dnssd</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>DNS-SD setup is performed by + <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para>The main network service file must have the extension <filename>.dnssd</filename>; other + extensions are ignored.</para> + + <para>The <filename>.dnssd</filename> files are read from the files located in the system network + directories <filename>/usr/lib/systemd/dnssd</filename> and + <filename>/usr/local/lib/systemd/dnssd</filename>, the volatile runtime network directory + <filename>/run/systemd/dnssd</filename> and the local administration network directory + <filename>/etc/systemd/dnssd</filename>. All configuration files are collectively sorted and processed in + lexical order, regardless of the directories in which they live. However, files with identical filenames + replace each other. Files in <filename>/etc/</filename> have the highest priority, files in + <filename>/run/</filename> take precedence over files with the same name in + <filename>/usr/lib/</filename>. This can be used to override a system-supplied configuration file with a + local file if needed.</para> + + <para>Along with the network service file <filename>foo.dnssd</filename>, a "drop-in" directory + <filename>foo.dnssd.d/</filename> may exist. All files with the suffix + <literal>.conf</literal> from this directory will be parsed after the file itself is + parsed. This is useful to alter or add configuration settings, without having to modify the main + configuration file. Each drop-in file must have appropriate section headers.</para> + + <para>In addition to <filename>/etc/systemd/dnssd</filename>, drop-in <literal>.d</literal> directories + can be placed in <filename>/usr/lib/systemd/dnssd</filename> or <filename>/run/systemd/dnssd</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> or + <filename>/usr/local/lib</filename>. Drop-in files under any of these directories take precedence over + the main network service file wherever located.</para> + </refsect1> + + <refsect1> + <title>[Service] Section Options</title> + + <para>The network service file contains a [Service] + section, which specifies a discoverable network service announced in a + local network with Multicast DNS broadcasts.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>An instance name of the network service as defined in the section 4.1.1 of <ulink + url="https://tools.ietf.org/html/rfc6763">RFC 6763</ulink>, e.g. <literal>webserver</literal>.</para> + <para>The option supports simple specifier expansion. The following expansions are understood:</para> + <table class='specifiers'> + <title>Specifiers available</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="spec" /> + <colspec colname="mean" /> + <colspec colname="detail" /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Meaning</entry> + <entry>Details</entry> + </row> + </thead> + <tbody> + <xi:include href="standard-specifiers.xml" xpointer="a"/> + <xi:include href="standard-specifiers.xml" xpointer="b"/> + <xi:include href="standard-specifiers.xml" xpointer="B"/> + <xi:include href="standard-specifiers.xml" xpointer="H"/> + <xi:include href="standard-specifiers.xml" xpointer="m"/> + <xi:include href="standard-specifiers.xml" xpointer="o"/> + <xi:include href="standard-specifiers.xml" xpointer="v"/> + <xi:include href="standard-specifiers.xml" xpointer="w"/> + <xi:include href="standard-specifiers.xml" xpointer="W"/> + <xi:include href="standard-specifiers.xml" xpointer="percent"/> + </tbody> + </tgroup> + </table> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Type=</varname></term> + <listitem> + <para>A type of the network service as defined in the section 4.1.2 of <ulink + url="https://tools.ietf.org/html/rfc6763">RFC 6763</ulink>, e.g. <literal>_http._tcp</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Port=</varname></term> + <listitem> + <para>An IP port number of the network service.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Priority=</varname></term> + <listitem> + <para>A priority number set in SRV resource records corresponding to the network service.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Weight=</varname></term> + <listitem> + <para>A weight number set in SRV resource records corresponding to the network service.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TxtText=</varname></term> + <listitem> + <para>A whitespace-separated list of arbitrary key/value pairs + conveying additional information about the named service in the corresponding TXT resource record, + e.g. <literal>path=/portal/index.html</literal>. Keys and values can contain C-style escape + sequences which get translated upon reading configuration files. + </para> + <para>This option together with <varname>TxtData=</varname> may be specified more than once, in which + case multiple TXT resource records will be created for the service. If the empty string is assigned to + this option, the list is reset and all prior assignments will have no effect. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TxtData=</varname></term> + <listitem> + <para>A whitespace-separated list of arbitrary key/value pairs + conveying additional information about the named service in the corresponding TXT resource record + where values are base64-encoded string representing any binary data, + e.g. <literal>data=YW55IGJpbmFyeSBkYXRhCg==</literal>. Keys can contain C-style escape + sequences which get translated upon reading configuration files. + </para> + <para>This option together with <varname>TxtText=</varname> may be specified more than once, in which + case multiple TXT resource records will be created for the service. If the empty string is assigned to + this option, the list is reset and all prior assignments will have no effect. + </para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>HTTP service</title> + + <programlisting># /etc/systemd/dnssd/http.dnssd +[Service] +Name=%H +Type=_http._tcp +Port=80 +TxtText=path=/stats/index.html t=temperature_sensor</programlisting> + + <para>This makes the http server running on the host discoverable in the local network + given MulticastDNS is enabled on the network interface.</para> + + <para>Now the utility <literal>resolvectl</literal> should be able to resolve the + service to the host's name:</para> + + <programlisting>$ resolvectl service meteo._http._tcp.local +meteo._http._tcp.local: meteo.local:80 [priority=0, weight=0] + 169.254.208.106%senp0s21f0u2u4 + fe80::213:3bff:fe49:8aa%senp0s21f0u2u4 + path=/stats/index.html + t=temperature_sensor + (meteo/_http._tcp/local) + +-- Information acquired via protocol mDNS/IPv6 in 4.0ms. +-- Data is authenticated: yes</programlisting> + + <para><literal>Avahi</literal> running on a different host in the same local network should see the service as well:</para> + + <programlisting>$ avahi-browse -a -r ++ enp3s0 IPv6 meteo Web Site local ++ enp3s0 IPv4 meteo Web Site local += enp3s0 IPv6 meteo Web Site local + hostname = [meteo.local] + address = [fe80::213:3bff:fe49:8aa] + port = [80] + txt = ["path=/stats/index.html" "t=temperature_sensor"] += enp3s0 IPv4 meteo Web Site local + hostname = [meteo.local] + address = [169.254.208.106] + port = [80] + txt = ["path=/stats/index.html" "t=temperature_sensor"]</programlisting> + + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.environment-generator.xml b/man/systemd.environment-generator.xml new file mode 100644 index 0000000..663d7dc --- /dev/null +++ b/man/systemd.environment-generator.xml @@ -0,0 +1,134 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.environment-generator" conditional='ENABLE_ENVIRONMENT_D' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd.environment-generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.environment-generator</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.environment-generator</refname> + <refpurpose>systemd environment file generators</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>&systemenvgeneratordir;/some-generator</command> + </cmdsynopsis> + <cmdsynopsis> + <command>&userenvgeneratordir;/some-generator</command> + </cmdsynopsis> + + <para> + <literallayout><filename>/run/systemd/system-environment-generators/*</filename> +<filename>/etc/systemd/system-environment-generators/*</filename> +<filename>/usr/local/lib/systemd/system-environment-generators/*</filename> +<filename>&systemenvgeneratordir;/*</filename></literallayout> + </para> + + <para> + <literallayout><filename>/run/systemd/user-environment-generators/*</filename> +<filename>/etc/systemd/user-environment-generators/*</filename> +<filename>/usr/local/lib/systemd/user-environment-generators/*</filename> +<filename>&userenvgeneratordir;/*</filename></literallayout> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para>Generators are small executables that live in + <filename>&systemenvgeneratordir;/</filename> and other directories listed above. + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will + execute those binaries very early at the startup of each manager and at configuration + reload time, before running the generators described in + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry> + and before starting any units. Environment generators can override the environment that the + manager exports to services and other processes.</para> + + <para>Generators are loaded from a set of paths determined during compilation, as listed + above. System and user environment generators are loaded from directories with names ending in + <filename>system-environment-generators/</filename> and + <filename>user-environment-generators/</filename>, respectively. Generators found in directories + listed earlier override the ones with the same name in directories lower in the list. A symlink + to <filename>/dev/null</filename> or an empty file can be used to mask a generator, thereby + preventing it from running. Please note that the order of the two directories with the highest + priority is reversed with respect to the unit load path, and generators in + <filename>/run/</filename> overwrite those in <filename>/etc/</filename>.</para> + + <para>After installing new generators or updating the configuration, <command>systemctl + daemon-reload</command> may be executed. This will re-run all generators, updating environment + configuration. It will be used for any services that are started subsequently.</para> + + <para>Environment file generators are executed similarly to unit file generators described + in + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + with the following differences:</para> + + <itemizedlist> + <listitem> + <para>Generators are executed sequentially in the alphanumerical order of the final + component of their name. The output of each generator output is immediately parsed and used + to update the environment for generators that run after that. Thus, later generators can use + and/or modify the output of earlier generators.</para> + </listitem> + + <listitem> + <para>Generators are run by every manager instance, their output can be different for each + user.</para> + </listitem> + </itemizedlist> + + <para>It is recommended to use numerical prefixes for generator names to simplify ordering.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>A simple generator that extends an environment variable if a directory exists in the file system</title> + + <programlisting># 50-xdg-data-dirs.sh + +<xi:include href="50-xdg-data-dirs.sh" parse="text" /></programlisting> + </example> + + <example> + <title>A more complicated generator which reads existing configuration and mutates one variable</title> + + <programlisting># 90-rearrange-path.py + +<xi:include href="90-rearrange-path.py" parse="text" /></programlisting> + </example> + + <example> + <title>Debugging a generator</title> + + <programlisting>SYSTEMD_LOG_LEVEL=debug VAR_A=something VAR_B="something else" \ +&systemenvgeneratordir;/path-to-generator +</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See also</title> + + <para> + <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml new file mode 100644 index 0000000..a9d863b --- /dev/null +++ b/man/systemd.exec.xml @@ -0,0 +1,3678 @@ +<?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-or-later --> + +<refentry id="systemd.exec" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd.exec</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.exec</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.exec</refname> + <refpurpose>Execution environment configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>service</replaceable>.service</filename>, + <filename><replaceable>socket</replaceable>.socket</filename>, + <filename><replaceable>mount</replaceable>.mount</filename>, + <filename><replaceable>swap</replaceable>.swap</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Unit configuration files for services, sockets, mount points, and swap devices share a subset of + configuration options which define the execution environment of spawned processes.</para> + + <para>This man page lists the configuration options shared by these four unit types. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for the common + options of all unit configuration files, and + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more + information on the specific unit configuration files. The execution specific configuration options are configured + in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.</para> + + <para>In addition, options which control resources through Linux Control Groups (cgroups) are listed in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Those options complement options listed here.</para> + </refsect1> + + <refsect1> + <title>Implicit Dependencies</title> + + <para>A few execution parameters result in additional, automatic dependencies to be added:</para> + + <itemizedlist> + <listitem><para>Units with <varname>WorkingDirectory=</varname>, <varname>RootDirectory=</varname>, + <varname>RootImage=</varname>, <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>, + <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname> or + <varname>ConfigurationDirectory=</varname> set automatically gain dependencies of type + <varname>Requires=</varname> and <varname>After=</varname> on all mount units required to access the specified + paths. This is equivalent to having them listed explicitly in + <varname>RequiresMountsFor=</varname>.</para></listitem> + + <listitem><para>Similarly, units with <varname>PrivateTmp=</varname> enabled automatically get mount + unit dependencies for all mounts required to access <filename>/tmp/</filename> and + <filename>/var/tmp/</filename>. They will also gain an automatic <varname>After=</varname> dependency + on + <citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + + <listitem><para>Units whose standard output or error output is connected to <option>journal</option> or + <option>kmsg</option> (or their combinations with console output, see below) automatically acquire + dependencies of type <varname>After=</varname> on + <filename>systemd-journald.socket</filename>.</para></listitem> + + <listitem><para>Units using <varname>LogNamespace=</varname> will automatically gain ordering and + requirement dependencies on the two socket units associated with + <filename>systemd-journald@.service</filename> instances.</para></listitem> + </itemizedlist> + </refsect1> + + <!-- We don't have any default dependency here. --> + + <refsect1> + <title>Paths</title> + + <para>The following settings may be used to change a service's view of the filesystem. Please note that the paths + must be absolute and must not contain a <literal>..</literal> path component.</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>WorkingDirectory=</varname></term> + + <listitem><para>Takes a directory path relative to the service's root directory specified by + <varname>RootDirectory=</varname>, or the special value <literal>~</literal>. Sets the working directory for + executed processes. If set to <literal>~</literal>, the home directory of the user specified in + <varname>User=</varname> is used. If not set, defaults to the root directory when systemd is running as a + system instance and the respective user's home directory if run as user. If the setting is prefixed with the + <literal>-</literal> character, a missing working directory is not considered fatal. If + <varname>RootDirectory=</varname>/<varname>RootImage=</varname> is not set, then + <varname>WorkingDirectory=</varname> is relative to the root of the system running the service manager. Note + that setting this parameter might result in additional dependencies to be added to the unit (see + above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootDirectory=</varname></term> + + <listitem><para>Takes a directory path relative to the host's root directory (i.e. the root of the system + running the service manager). Sets the root directory for executed processes, with the <citerefentry + project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system + call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in + the <function>chroot()</function> jail. Note that setting this parameter might result in additional + dependencies to be added to the unit (see above).</para> + + <para>The <varname>MountAPIVFS=</varname> and <varname>PrivateUsers=</varname> settings are particularly useful + in conjunction with <varname>RootDirectory=</varname>. For details, see below.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootImage=</varname></term> + + <listitem><para>Takes a path to a block device node or regular file as argument. This call is similar + to <varname>RootDirectory=</varname> however mounts a file system hierarchy from a block device node + or loopback file instead of a directory. The device node or file system image file needs to contain a + file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table + with only a single Linux-compatible partition, or a set of file systems within a GPT partition table + that follows the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions + Specification</ulink>.</para> + + <para>When <varname>DevicePolicy=</varname> is set to <literal>closed</literal> or + <literal>strict</literal>, or set to <literal>auto</literal> and <varname>DeviceAllow=</varname> is + set, then this setting adds <filename>/dev/loop-control</filename> with <constant>rw</constant> mode, + <literal>block-loop</literal> and <literal>block-blkext</literal> with <constant>rwm</constant> mode + to <varname>DeviceAllow=</varname>. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the details about <varname>DevicePolicy=</varname> or <varname>DeviceAllow=</varname>. Also, see + <varname>PrivateDevices=</varname> below, as it may change the setting of + <varname>DevicePolicy=</varname>.</para> + + <para>Units making use of <varname>RootImage=</varname> automatically gain an + <varname>After=</varname> dependency on <filename>systemd-udevd.service</filename>.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootImageOptions=</varname></term> + + <listitem><para>Takes a comma-separated list of mount options that will be used on disk images specified by + <varname>RootImage=</varname>. Optionally a partition name can be prefixed, followed by colon, in + case the image has multiple partitions, otherwise partition name <literal>root</literal> is implied. + Options for multiple partitions can be specified in a single line with space separators. Assigning an empty + string removes previous assignments. Duplicated options are ignored. For a list of valid mount options, please + refer to + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para>Valid partition names follow the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable + Partitions Specification</ulink>.</para> + + <table> + <title>Accepted partition names</title> + + <tgroup cols='1'> + <colspec colname='partition' /> + <thead> + <row> + <entry>Partition Name</entry> + </row> + </thead> + <tbody> + <row> + <entry>root</entry> + </row> + <row> + <entry>root-secondary</entry> + </row> + <row> + <entry>home</entry> + </row> + <row> + <entry>srv</entry> + </row> + <row> + <entry>esp</entry> + </row> + <row> + <entry>xbootldr</entry> + </row> + <row> + <entry>tmp</entry> + </row> + <row> + <entry>var</entry> + </row> + <row> + <entry>usr</entry> + </row> + </tbody> + </tgroup> + </table> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootHash=</varname></term> + + <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file + containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity, + if the used image contains the appropriate integrity data (see above) or if <varname>RootVerity=</varname> is used. + The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 + formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but + the image file carries the <literal>user.verity.roothash</literal> extended file attribute (see <citerefentry + project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root + hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or + is not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is + found next to the image file, bearing otherwise the same name (except if the image has the + <filename>.raw</filename> suffix, in which case the root hash file must not have it in its name), the root hash + is read from it and automatically used, also as formatted hexadecimal characters.</para> + + <para>If the disk image contains a separate <filename>/usr/</filename> partition it may also be + Verity protected, in which case the root hash may configured via an extended attribute + <literal>user.verity.usrhash</literal> or a <filename>.usrhash</filename> file adjacent to the disk + image. There's currently no option to configure the root hash for the <filename>/usr/</filename> file + system via the unit file directly.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootHashSignature=</varname></term> + + <listitem><para>Takes a PKCS7 signature of the <varname>RootHash=</varname> option as a path to a + DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed + by <literal>base64:</literal>. The dm-verity volume will only be opened if the signature of the root + hash is valid and signed by a public key present in the kernel keyring. If this option is not + specified, but a file with the <filename>.roothash.p7s</filename> suffix is found next to the image + file, bearing otherwise the same name (except if the image has the <filename>.raw</filename> suffix, + in which case the signature file must not have it in its name), the signature is read from it and + automatically used.</para> + + <para>If the disk image contains a separate <filename>/usr/</filename> partition it may also be + Verity protected, in which case the signature for the root hash may configured via a + <filename>.usrhash.p7s</filename> file adjacent to the disk image. There's currently no option to + configure the root hash signature for the <filename>/usr/</filename> via the unit file + directly.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootVerity=</varname></term> + + <listitem><para>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks + using dm-verity, if <varname>RootImage=</varname> is used and a root-hash is passed and if the used image itself + does not contains the integrity data. The integrity data must be matched by the root hash. If this option is not + specified, but a file with the <filename>.verity</filename> suffix is found next to the image file, bearing otherwise + the same name (except if the image has the <filename>.raw</filename> suffix, in which case the verity data file must + not have it in its name), the verity data is read from it and automatically used.</para> + + <para>This option is supported only for disk images that contain a single file system, without an + enveloping partition table. Images that contain a GPT partition table should instead include both + root file system and matching Verity data in the same image, implementing the <ulink + url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partition Specification</ulink>.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MountAPIVFS=</varname></term> + + <listitem><para>Takes a boolean argument. If on, a private mount namespace for the unit's processes is created + and the API file systems <filename>/proc/</filename>, <filename>/sys/</filename>, and <filename>/dev/</filename> + are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in + conjunction with <varname>RootDirectory=</varname>/<varname>RootImage=</varname> as these three mounts are + generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace + will be a 1:1 copy of the host's, and include these three mounts. Note that the <filename>/dev/</filename> file + system of the host is bind mounted if this option is used without <varname>PrivateDevices=</varname>. To run + the service with a private, minimal version of <filename>/dev/</filename>, combine this option with + <varname>PrivateDevices=</varname>.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectProc=</varname></term> + + <listitem><para>Takes one of <literal>noaccess</literal>, <literal>invisible</literal>, + <literal>ptraceable</literal> or <literal>default</literal> (which it defaults to). When set, this + controls the <literal>hidepid=</literal> mount option of the <literal>procfs</literal> instance for + the unit that controls which directories with process metainformation + (<filename>/proc/<replaceable>PID</replaceable></filename>) are visible and accessible: when set to + <literal>noaccess</literal> the ability to access most of other users' process metadata in + <filename>/proc/</filename> is taken away for processes of the service. When set to + <literal>invisible</literal> processes owned by other users are hidden from + <filename>/proc/</filename>. If <literal>ptraceable</literal> all processes that cannot be + <function>ptrace()</function>'ed by a process are hidden to it. If <literal>default</literal> no + restrictions on <filename>/proc/</filename> access or visibility are made. For further details see + <ulink url="https://www.kernel.org/doc/html/latest/filesystems/proc.html#mount-options">The /proc + Filesystem</ulink>. It is generally recommended to run most system services with this option set to + <literal>invisible</literal>. This option is implemented via file system namespacing, and thus cannot + be used with services that shall be able to install mount points in the host file system + hierarchy. It also cannot be used for services that need to access metainformation about other users' + processes. This option implies <varname>MountAPIVFS=</varname>.</para> + + <para>If the kernel doesn't support per-mount point <option>hidepid=</option> mount options this + setting remains without effect, and the unit's processes will be able to access and see other process + as if the option was not used.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProcSubset=</varname></term> + + <listitem><para>Takes one of <literal>all</literal> (the default) and <literal>pid</literal>. If + the latter all files and directories not directly associated with process management and introspection + are made invisible in the <filename>/proc/</filename> file system configured for the unit's + processes. This controls the <literal>subset=</literal> mount option of the <literal>procfs</literal> + instance for the unit. For further details see <ulink + url="https://www.kernel.org/doc/html/latest/filesystems/proc.html#mount-options">The /proc + Filesystem</ulink>. Note that Linux exposes various kernel APIs via <filename>/proc/</filename>, + which are made unavailable with this setting. Since these APIs are used frequently this option is + useful only in a few, specific cases, and is not suitable for most non-trivial programs.</para> + + <para>Much like <varname>ProtectProc=</varname> above, this is implemented via file system mount + namespacing, and hence the same restrictions apply: it is only available to system services, it + disables mount propagation to the host mount table, and it implies + <varname>MountAPIVFS=</varname>. Also, like <varname>ProtectProc=</varname> this setting is gracefully + disabled if the used kernel does not support the <literal>subset=</literal> mount option of + <literal>procfs</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>BindPaths=</varname></term> + <term><varname>BindReadOnlyPaths=</varname></term> + + <listitem><para>Configures unit-specific bind mounts. A bind mount makes a particular file or directory + available at an additional place in the unit's view of the file system. Any bind mounts created with this + option are specific to the unit, and are not visible in the host's mount table. This option expects a + whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of + source path, destination path and option string, where the latter two are optional. If only a source path is + specified the source and destination is taken to be the same. The option string may be either + <literal>rbind</literal> or <literal>norbind</literal> for configuring a recursive or non-recursive bind + mount. If the destination path is omitted, the option string must be omitted too. + Each bind mount definition may be prefixed with <literal>-</literal>, in which case it will be ignored + when its source path does not exist.</para> + + <para><varname>BindPaths=</varname> creates regular writable bind mounts (unless the source file system mount + is already marked read-only), while <varname>BindReadOnlyPaths=</varname> creates read-only bind mounts. These + settings may be used more than once, each usage appends to the unit's list of bind mounts. If the empty string + is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note + that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is + used.</para> + + <para>This option is particularly useful when <varname>RootDirectory=</varname>/<varname>RootImage=</varname> + 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> + + <varlistentry> + <term><varname>MountImages=</varname></term> + + <listitem><para>This setting is similar to <varname>RootImage=</varname> in that it mounts a file + system hierarchy from a block device node or loopback file, but the destination directory can be + specified as well as mount options. This option expects a whitespace separated list of mount + definitions. Each definition consists of a colon-separated tuple of source path and destination + definitions, optionally followed by another colon and a list of mount options.</para> + + <para>Mount options may be defined as a single comma-separated list of options, in which case they + will be implicitly applied to the root partition on the image, or a series of colon-separated tuples + of partition name and mount options. Valid partition names and mount options are the same as for + <varname>RootImageOptions=</varname> setting described above.</para> + + <para>Each mount definition may be prefixed with <literal>-</literal>, in which case it will be + ignored when its source path does not exist. The source argument is a path to a block device node or + regular file. If source or destination contain a <literal>:</literal>, it needs to be escaped as + <literal>\:</literal>. The device node or file system image file needs to follow the same rules as + specified for <varname>RootImage=</varname>. Any mounts created with this option are specific to the + unit, and are not visible in the host's mount table.</para> + + <para>These settings may be used more than once, each usage appends to the unit's list of mount + paths. If the empty string is assigned, the entire list of mount paths defined prior to this is + reset.</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.</para> + + <para>When <varname>DevicePolicy=</varname> is set to <literal>closed</literal> or + <literal>strict</literal>, or set to <literal>auto</literal> and <varname>DeviceAllow=</varname> is + set, then this setting adds <filename>/dev/loop-control</filename> with <constant>rw</constant> mode, + <literal>block-loop</literal> and <literal>block-blkext</literal> with <constant>rwm</constant> mode + to <varname>DeviceAllow=</varname>. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the details about <varname>DevicePolicy=</varname> or <varname>DeviceAllow=</varname>. Also, see + <varname>PrivateDevices=</varname> below, as it may change the setting of + <varname>DevicePolicy=</varname>.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Credentials</title> + + <xi:include href="system-only.xml" xpointer="plural"/> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>User=</varname></term> + <term><varname>Group=</varname></term> + + <listitem><para>Set the UNIX user or group that the processes are executed as, respectively. Takes a single + user or group name, or a numeric ID as argument. For system services (services run by the system service + manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of + <command>systemd --user</command>), the default is <literal>root</literal>, but <varname>User=</varname> may be + used to specify a different user. For user services of any other user, switching user identity is not + permitted, hence the only valid setting is the same user the user's service manager is running as. If no group + is set, the default group of the user is used. This setting does not affect commands whose command line is + prefixed with <literal>+</literal>.</para> + + <para>Note that this enforces only weak restrictions on the user/group name syntax, but will generate + warnings in many cases where user/group names do not adhere to the following rules: the specified + name should consist only of the characters a-z, A-Z, 0-9, <literal>_</literal> and + <literal>-</literal>, except for the first character which must be one of a-z, A-Z and + <literal>_</literal> (i.e. digits and <literal>-</literal> are not permitted as first character). The + user/group name must have at least one character, and at most 31. These restrictions are made in + order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux + systems. For further details on the names accepted and the names warned about see <ulink + url="https://systemd.io/USER_NAMES">User/Group Name Syntax</ulink>.</para> + + <para>When used in conjunction with <varname>DynamicUser=</varname> the user/group name specified is + dynamically allocated at the time the service is started, and released at the time the service is + stopped — unless it is already allocated statically (see below). If <varname>DynamicUser=</varname> + is not used the 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. If the user does not exist by then + program invocation will fail.</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> + <term><varname>DynamicUser=</varname></term> + + <listitem><para>Takes a boolean parameter. If set, a UNIX user and group pair is allocated + dynamically when the unit is started, and released as soon as it is stopped. The user and group will + not be added to <filename>/etc/passwd</filename> or <filename>/etc/group</filename>, but are managed + transiently during runtime. The + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> glibc + NSS module provides integration of these dynamic users/groups into the system's user and group + databases. The user and group name to use may be configured via <varname>User=</varname> and + <varname>Group=</varname> (see above). If these options are not used and dynamic user/group + allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the + unit name. If the unit name without the type suffix qualifies as valid user name it is used directly, + otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the + configured name already exists, it is used and no dynamic user/group is allocated. Note that if + <varname>User=</varname> is specified and the static group with the name exists, then it is required + that the static user with the name already exists. Similarly, if <varname>Group=</varname> is + specified and the static user with the name exists, then it is required that the static group with + the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is + recommended to avoid this range for regular system or login users. At any point in time each UID/GID + from this range is only assigned to zero or one dynamically allocated users/groups in use. However, + UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as + 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> 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 allow-listed using <varname>ReadWritePaths=</varname>, but care must be taken so that + UID/GID recycling doesn't create security issues involving files created by the service. Use + <varname>RuntimeDirectory=</varname> (see below) in order to assign a writable runtime directory to a + service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use + <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname> and + <varname>LogsDirectory=</varname> in order to assign a set of writable directories for specific + purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see + below). If this option is enabled, care should be taken that the unit's processes do not get access + to directories outside of these explicitly configured and managed ones. Specifically, do not use + <varname>BindPaths=</varname> and be careful with <constant>AF_UNIX</constant> file descriptor + passing for directory file descriptors, as this would permit processes to create files or directories + owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the + service. Defaults to off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SupplementaryGroups=</varname></term> + + <listitem><para>Sets the supplementary Unix groups the processes are executed as. This takes a space-separated + list of group names or IDs. This option may be specified more than once, in which case all listed groups are + set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and + all assignments prior to this one will have no effect. In any way, this option does not override, but extends + the list of supplementary groups configured in the system group database for the user. This does not affect + commands prefixed with <literal>+</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PAMName=</varname></term> + + <listitem><para>Sets the PAM service name to set up a session as. If set, the executed process will be + registered as a PAM session under the specified service name. This is only useful in conjunction with the + <varname>User=</varname> setting, and is otherwise ignored. If not set, no PAM session will be opened for the + executed processes. See <citerefentry + project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + details.</para> + + <para>Note that for each unit making use of this option a PAM session handler process will be maintained as + part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can be + taken when the unit and hence the PAM session terminates. This process is named <literal>(sd-pam)</literal> and + is an immediate child process of the unit's main process.</para> + + <para>Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the + main unit process will be migrated to its own session scope unit when it is activated. This process will hence + be associated with two units: the unit it was originally started from (and for which + <varname>PAMName=</varname> was configured), and the session scope unit. Any child processes of that process + will however be associated with the session scope unit only. This has implications when used in combination + with <varname>NotifyAccess=</varname><option>all</option>, as these child processes will not be able to affect + changes in the original unit through notification messages. These messages will be considered belonging to the + session scope unit and not the original unit. It is hence not recommended to use <varname>PAMName=</varname> in + combination with <varname>NotifyAccess=</varname><option>all</option>.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Capabilities</title> + + <xi:include href="system-only.xml" xpointer="plural"/> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>CapabilityBoundingSet=</varname></term> + + <listitem><para>Controls which capabilities to include in the capability bounding set for the + executed process. See <citerefentry + project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details. Takes a whitespace-separated list of capability names, + e.g. <constant>CAP_SYS_ADMIN</constant>, <constant>CAP_DAC_OVERRIDE</constant>, + <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will be included in the bounding set, all + others are removed. If the list of capabilities is prefixed with <literal>~</literal>, all but the + listed capabilities will be included, the effect of the assignment inverted. Note that this option + also affects the respective capabilities in the effective, permitted and inheritable capability + sets. If this option is not used, the capability bounding set is not modified on process execution, + hence no limits on the capabilities of the process are enforced. This option may appear more than + once, in which case the bounding sets are merged by <constant>OR</constant>, or by + <constant>AND</constant> if the lines are prefixed with <literal>~</literal> (see below). If the + empty string is assigned to this option, the bounding set is reset to the empty capability set, and + all prior settings have no effect. If set to <literal>~</literal> (without any further argument), + the bounding set is reset to the full set of available capabilities, also undoing any previous + settings. This does not affect commands prefixed with <literal>+</literal>.</para> + + <para>Use + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>capability</command> command to retrieve a list of capabilities defined on the local + system.</para> + + <para>Example: if a unit has the following, + <programlisting>CapabilityBoundingSet=CAP_A CAP_B +CapabilityBoundingSet=CAP_B CAP_C</programlisting> + then <constant index='false'>CAP_A</constant>, <constant index='false'>CAP_B</constant>, and + <constant index='false'>CAP_C</constant> are set. If the second line is prefixed with + <literal>~</literal>, e.g., + <programlisting>CapabilityBoundingSet=CAP_A CAP_B +CapabilityBoundingSet=~CAP_B CAP_C</programlisting> + then, only <constant index='false'>CAP_A</constant> is set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>AmbientCapabilities=</varname></term> + + <listitem><para>Controls which capabilities to include in the ambient capability set for the executed + process. Takes a whitespace-separated list of capability names, e.g. <constant>CAP_SYS_ADMIN</constant>, + <constant>CAP_DAC_OVERRIDE</constant>, <constant>CAP_SYS_PTRACE</constant>. This option may appear more than + once in which case the ambient capability sets are merged (see the above examples in + <varname>CapabilityBoundingSet=</varname>). If the list of capabilities is prefixed with <literal>~</literal>, + all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is + assigned to this option, the ambient capability set is reset to the empty capability set, and all prior + settings have no effect. If set to <literal>~</literal> (without any further argument), the ambient capability + set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding + capabilities to ambient capability set adds them to the process's inherited capability set. </para><para> + Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to + give it some capabilities. Note that in this case option <constant>keep-caps</constant> is automatically added + to <varname>SecureBits=</varname> to retain the capabilities over the user + change. <varname>AmbientCapabilities=</varname> does not affect commands prefixed with + <literal>+</literal>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Security</title> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>NoNewPrivileges=</varname></term> + + <listitem><para>Takes a boolean argument. If true, ensures that the service process and all its + children can never gain new privileges through <function>execve()</function> (e.g. via setuid or + setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that + a process and its children can never elevate privileges again. Defaults to false, but certain + settings override this and ignore the value of this setting. This is the case when + <varname>SystemCallFilter=</varname>, <varname>SystemCallArchitectures=</varname>, + <varname>RestrictAddressFamilies=</varname>, <varname>RestrictNamespaces=</varname>, + <varname>PrivateDevices=</varname>, <varname>ProtectKernelTunables=</varname>, + <varname>ProtectKernelModules=</varname>, <varname>ProtectKernelLogs=</varname>, + <varname>ProtectClock=</varname>, <varname>MemoryDenyWriteExecute=</varname>, + <varname>RestrictRealtime=</varname>, <varname>RestrictSUIDSGID=</varname>, <varname>DynamicUser=</varname> + or <varname>LockPersonality=</varname> are specified. Note that even if this setting is overridden by them, + <command>systemctl show</command> shows the original value of this setting. + Also see <ulink url="https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html">No New Privileges + Flag</ulink>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SecureBits=</varname></term> + + <listitem><para>Controls the secure bits set for the executed process. Takes a space-separated combination of + options from the following list: <option>keep-caps</option>, <option>keep-caps-locked</option>, + <option>no-setuid-fixup</option>, <option>no-setuid-fixup-locked</option>, <option>noroot</option>, and + <option>noroot-locked</option>. This option may appear more than once, in which case the secure bits are + ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands + prefixed with <literal>+</literal>. See <citerefentry + project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Mandatory Access Control</title> + + <xi:include href="system-only.xml" xpointer="plural"/> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>SELinuxContext=</varname></term> + + <listitem><para>Set the SELinux security context of the executed process. If set, this will override the + automated domain transition. However, the policy still needs to authorize the transition. This directive is + ignored if SELinux is disabled. If prefixed by <literal>-</literal>, all errors will be ignored. This does not + affect commands prefixed with <literal>+</literal>. See <citerefentry + project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>AppArmorProfile=</varname></term> + + <listitem><para>Takes a profile name as argument. The process executed by the unit will switch to + this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If + prefixed by <literal>-</literal>, all errors will be ignored. This setting has no effect if AppArmor + is not enabled. This setting does not affect commands prefixed with <literal>+</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SmackProcessLabel=</varname></term> + + <listitem><para>Takes a <option>SMACK64</option> security label as argument. The process executed by the unit + will be started under this label and SMACK will decide whether the process is allowed to run or not, based on + it. The process will continue to run under the label specified here unless the executable has its own + <option>SMACK64EXEC</option> label, in which case the process will transition to run under that label. When not + specified, the label that systemd is running under is used. This directive is ignored if SMACK is + disabled.</para> + + <para>The value may be prefixed by <literal>-</literal>, in which case all errors will be ignored. An empty + value may be specified to unset previous assignments. This does not affect commands prefixed with + <literal>+</literal>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Process Properties</title> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>LimitCPU=</varname></term> + <term><varname>LimitFSIZE=</varname></term> + <term><varname>LimitDATA=</varname></term> + <term><varname>LimitSTACK=</varname></term> + <term><varname>LimitCORE=</varname></term> + <term><varname>LimitRSS=</varname></term> + <term><varname>LimitNOFILE=</varname></term> + <term><varname>LimitAS=</varname></term> + <term><varname>LimitNPROC=</varname></term> + <term><varname>LimitMEMLOCK=</varname></term> + <term><varname>LimitLOCKS=</varname></term> + <term><varname>LimitSIGPENDING=</varname></term> + <term><varname>LimitMSGQUEUE=</varname></term> + <term><varname>LimitNICE=</varname></term> + <term><varname>LimitRTPRIO=</varname></term> + <term><varname>LimitRTTIME=</varname></term> + + <listitem><para>Set soft and hard limits on various resources for executed processes. See + <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details on the resource limit concept. Resource limits may be specified in two formats: either as + single value to set a specific soft and hard limit to the same value, or as colon-separated pair + <option>soft:hard</option> to set both limits individually (e.g. <literal>LimitAS=4G:16G</literal>). + Use the string <option>infinity</option> to configure no limit on a specific resource. The + multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits + measured in bytes (e.g. <literal>LimitAS=16G</literal>). For the limits referring to time values, the + usual time units ms, s, min, h and so on may be used (see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details). Note that if no time unit is specified for <varname>LimitCPU=</varname> the default unit of + seconds is implied, while for <varname>LimitRTTIME=</varname> the default unit of microseconds is + implied. Also, note that the effective granularity of the limits might influence their + enforcement. For example, time limits specified for <varname>LimitCPU=</varname> will be rounded up + implicitly to multiples of 1s. For <varname>LimitNICE=</varname> the value may be specified in two + syntaxes: if prefixed with <literal>+</literal> or <literal>-</literal>, the value is understood as + regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as + raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</para> + + <para>Note that most process resource limits configured with these options are per-process, and + processes may fork in order to acquire a new set of resources that are accounted independently of the + original process, and may thus escape limits set. Also note that <varname>LimitRSS=</varname> is not + implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource + controls listed in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + over these per-process limits, as they apply to services as a whole, may be altered dynamically at + runtime, and are generally more expressive. For example, <varname>MemoryMax=</varname> is a more + powerful (and working) replacement for <varname>LimitRSS=</varname>.</para> + + <para>Resource limits not configured explicitly for a unit default to the value configured in the various + <varname>DefaultLimitCPU=</varname>, <varname>DefaultLimitFSIZE=</varname>, … options available in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and – + if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user + services, see below).</para> + + <para>For system units these resource limits may be chosen freely. When these settings are configured + in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be + used to raise the limits above those set for the user manager itself when it was first invoked, as + the user's service manager generally lacks the privileges to do so. In user context these + configuration options are hence only useful to lower the limits passed in or to raise the soft limit + to the maximum of the hard limit as configured for the user. To raise the user's limits further, the + available configuration mechanisms differ between operating systems, but typically require + privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by + setting limits on the system service encapsulating the user's service manager, i.e. the user's + instance of <filename>user@.service</filename>. After making such changes, make sure to restart the + user's service manager.</para> + + <table> + <title>Resource limit directives, their equivalent <command>ulimit</command> shell commands and the unit used</title> + + <tgroup cols='3'> + <colspec colname='directive' /> + <colspec colname='equivalent' /> + <colspec colname='unit' /> + <thead> + <row> + <entry>Directive</entry> + <entry><command>ulimit</command> equivalent</entry> + <entry>Unit</entry> + </row> + </thead> + <tbody> + <row> + <entry>LimitCPU=</entry> + <entry>ulimit -t</entry> + <entry>Seconds</entry> + </row> + <row> + <entry>LimitFSIZE=</entry> + <entry>ulimit -f</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitDATA=</entry> + <entry>ulimit -d</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitSTACK=</entry> + <entry>ulimit -s</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitCORE=</entry> + <entry>ulimit -c</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitRSS=</entry> + <entry>ulimit -m</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitNOFILE=</entry> + <entry>ulimit -n</entry> + <entry>Number of File Descriptors</entry> + </row> + <row> + <entry>LimitAS=</entry> + <entry>ulimit -v</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitNPROC=</entry> + <entry>ulimit -u</entry> + <entry>Number of Processes</entry> + </row> + <row> + <entry>LimitMEMLOCK=</entry> + <entry>ulimit -l</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitLOCKS=</entry> + <entry>ulimit -x</entry> + <entry>Number of Locks</entry> + </row> + <row> + <entry>LimitSIGPENDING=</entry> + <entry>ulimit -i</entry> + <entry>Number of Queued Signals</entry> + </row> + <row> + <entry>LimitMSGQUEUE=</entry> + <entry>ulimit -q</entry> + <entry>Bytes</entry> + </row> + <row> + <entry>LimitNICE=</entry> + <entry>ulimit -e</entry> + <entry>Nice Level</entry> + </row> + <row> + <entry>LimitRTPRIO=</entry> + <entry>ulimit -r</entry> + <entry>Realtime Priority</entry> + </row> + <row> + <entry>LimitRTTIME=</entry> + <entry>No equivalent</entry> + <entry>Microseconds</entry> + </row> + </tbody> + </tgroup> + </table></listitem> + </varlistentry> + + <varlistentry> + <term><varname>UMask=</varname></term> + + <listitem><para>Controls the file mode creation mask. Takes an access mode in octal notation. See + <citerefentry><refentrytitle>umask</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details. Defaults to 0022 for system units. For user units the default value is inherited from the + per-user service manager (whose default is in turn inherited from the system service manager, and + thus typically also is 0022 — unless overridden by a PAM module). In order to change the per-user mask + for all user services, consider setting the <varname>UMask=</varname> setting of the user's + <filename>user@.service</filename> system service instance. The per-user umask may also be set via + the <varname>umask</varname> field of a user's <ulink url="https://systemd.io/USER_RECORD">JSON User + Record</ulink> (for users managed by + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + this field may be controlled via <command>homectl --umask=</command>). It may also be set via a PAM + module, such as <citerefentry + project='man-pages'><refentrytitle>pam_umask</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CoredumpFilter=</varname></term> + + <listitem><para>Controls which types of memory mappings will be saved if the process dumps core + (using the <filename>/proc/<replaceable>pid</replaceable>/coredump_filter</filename> file). Takes a + whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping + type names are <constant>private-anonymous</constant>, <constant>shared-anonymous</constant>, + <constant>private-file-backed</constant>, <constant>shared-file-backed</constant>, + <constant>elf-headers</constant>, <constant>private-huge</constant>, + <constant>shared-huge</constant>, <constant>private-dax</constant>, <constant>shared-dax</constant>, + and the special values <constant>all</constant> (all types) and <constant>default</constant> (the + kernel default of <literal><constant>private-anonymous</constant> + <constant>shared-anonymous</constant> <constant>elf-headers</constant> + <constant>private-huge</constant></literal>). See + <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the meaning of the mapping types. When specified multiple times, all specified masks are + ORed. When not set, or if the empty value is assigned, the inherited value is not changed.</para> + + <example> + <title>Add DAX pages to the dump filter</title> + + <programlisting>CoredumpFilter=default private-dax shared-dax</programlisting> + </example> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>KeyringMode=</varname></term> + + <listitem><para>Controls how the kernel session keyring is set up for the service (see <citerefentry + project='man-pages'><refentrytitle>session-keyring</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details on the session keyring). Takes one of <option>inherit</option>, <option>private</option>, + <option>shared</option>. If set to <option>inherit</option> no special keyring setup is done, and the kernel's + default behaviour is applied. If <option>private</option> is used a new session keyring is allocated when a + service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for + system services, as this ensures that multiple services running under the same system user ID (in particular + the root user) do not share their key material among each other. If <option>shared</option> is used a new + session keyring is allocated as for <option>private</option>, but the user keyring of the user configured with + <varname>User=</varname> is linked into it, so that keys assigned to the user may be requested by the unit's + processes. In this modes multiple units running processes under the same user ID may share key material. Unless + <option>inherit</option> is selected the unique invocation ID for the unit (see below) is added as a protected + key by the name <literal>invocation_id</literal> to the newly created session keyring. Defaults to + <option>private</option> for services of the system service manager and to <option>inherit</option> for + non-service units and for services of the user service manager.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OOMScoreAdjust=</varname></term> + + <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> + <term><varname>TimerSlackNSec=</varname></term> + <listitem><para>Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the + accuracy of wake-ups triggered by timers. See + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for more + information. Note that in contrast to most other time span definitions this parameter takes an integer value in + nano-seconds if no unit is specified. The usual time units are understood too.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Personality=</varname></term> + + <listitem><para>Controls which kernel architecture <citerefentry + project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> shall report, + when invoked by unit processes. Takes one of the architecture identifiers <constant>x86</constant>, + <constant>x86-64</constant>, <constant>ppc</constant>, <constant>ppc-le</constant>, <constant>ppc64</constant>, + <constant>ppc64-le</constant>, <constant>s390</constant> or <constant>s390x</constant>. Which personality + architectures are supported depends on the system architecture. Usually the 64bit versions of the various + system architectures support their immediate 32bit personality architecture counterpart, but no others. For + example, <constant>x86-64</constant> systems support the <constant>x86-64</constant> and + <constant>x86</constant> personalities but no others. The personality feature is useful when running 32-bit + services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the + personality of the host system's kernel.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>IgnoreSIGPIPE=</varname></term> + + <listitem><para>Takes a boolean argument. If true, causes <constant>SIGPIPE</constant> to be ignored in the + executed process. Defaults to true because <constant>SIGPIPE</constant> generally is useful only in shell + pipelines.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Scheduling</title> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>Nice=</varname></term> + + <listitem><para>Sets the default nice level (scheduling priority) for executed processes. Takes an integer + between -20 (highest priority) and 19 (lowest priority). See + <citerefentry><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUSchedulingPolicy=</varname></term> + + <listitem><para>Sets the CPU scheduling policy for executed processes. Takes one of <option>other</option>, + <option>batch</option>, <option>idle</option>, <option>fifo</option> or <option>rr</option>. See + <citerefentry project='man-pages'><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUSchedulingPriority=</varname></term> + + <listitem><para>Sets the CPU scheduling priority for executed processes. The available priority range depends + on the selected CPU scheduling policy (see above). For real-time scheduling policies an integer between 1 + (lowest priority) and 99 (highest priority) can be used. See + <citerefentry project='man-pages'><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUSchedulingResetOnFork=</varname></term> + + <listitem><para>Takes a boolean argument. If true, elevated CPU scheduling priorities and policies + will be reset when the executed processes call + <citerefentry project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + and can hence not leak into child processes. See + <citerefentry project='man-pages'><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. Defaults to false.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUAffinity=</varname></term> + + <listitem><para>Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges + separated by either whitespace or commas. Alternatively, takes a special "numa" value in which case systemd + automatically derives allowed CPU range based on the value of <varname>NUMAMask=</varname> option. 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. See + <citerefentry project='man-pages'><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </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 project='man-pages'><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 or special "all" value which will include all available NUMA nodes in the mask. 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 + of the strings <option>none</option>, <option>realtime</option>, <option>best-effort</option> or + <option>idle</option>. If the empty string is assigned to this option, all prior assignments to both + <varname>IOSchedulingClass=</varname> and <varname>IOSchedulingPriority=</varname> have no effect. See + <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOSchedulingPriority=</varname></term> + + <listitem><para>Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest + priority) and 7 (lowest priority). The available priorities depend on the selected I/O scheduling class (see + above). If the empty string is assigned to this option, all prior assignments to both + <varname>IOSchedulingClass=</varname> and <varname>IOSchedulingPriority=</varname> have no effect. + See <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Sandboxing</title> + + <para>The following sandboxing options are an effective way to limit the exposure of the system towards the unit's + processes. It is recommended to turn on as many of these options for each unit as is possible without negatively + affecting the process' ability to operate. Note that many of these sandboxing features are gracefully turned off on + systems where the underlying security mechanism is not available. For example, <varname>ProtectSystem=</varname> + has no effect if the kernel is built without file system namespacing or if the service manager runs in a container + manager that makes file system namespacing unavailable to its payload. Similar, + <varname>RestrictRealtime=</varname> has no effect on systems that lack support for SECCOMP system call filtering, + or in containers where support for this is turned off.</para> + + <para>Also note that some sandboxing functionality is generally not available in user services (i.e. services run + by the per-user service manager). Specifically, the various settings requiring file system namespacing support + (such as <varname>ProtectSystem=</varname>) are not available, as the underlying kernel functionality is only + accessible to privileged processes. However, most namespacing settings, that will not work on their own in user + services, will work when used in conjunction with <varname>PrivateUsers=</varname><option>true</option>.</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>ProtectSystem=</varname></term> + + <listitem><para>Takes a boolean argument or the special values <literal>full</literal> or + <literal>strict</literal>. If true, mounts the <filename>/usr/</filename> and the boot loader + directories (<filename>/boot</filename> and <filename>/efi</filename>) read-only for processes + invoked by this unit. If set to <literal>full</literal>, the <filename>/etc/</filename> directory is + mounted read-only, too. If set to <literal>strict</literal> the entire file system hierarchy is + mounted read-only, except for the API file system subtrees <filename>/dev/</filename>, + <filename>/proc/</filename> and <filename>/sys/</filename> (protect these directories using + <varname>PrivateDevices=</varname>, <varname>ProtectKernelTunables=</varname>, + <varname>ProtectControlGroups=</varname>). This setting ensures that any modification of the vendor-supplied + operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is + recommended to enable this setting for all long-running services, unless they are involved with system updates + or need to modify the operating system in other ways. If this option is used, + <varname>ReadWritePaths=</varname> may be used to exclude specific directories from being made read-only. 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. Defaults to + off.</para></listitem> + </varlistentry> + + <varlistentry> + <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 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> 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> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RuntimeDirectory=</varname></term> + <term><varname>StateDirectory=</varname></term> + <term><varname>CacheDirectory=</varname></term> + <term><varname>LogsDirectory=</varname></term> + <term><varname>ConfigurationDirectory=</varname></term> + + <listitem><para>These options take a whitespace-separated list of directory names. The specified + directory names must be relative, and may not include <literal>..</literal>. If set, when the unit is + started, one or more directories by the specified names will be created (including their parents) + below the locations defined in the following table. Also, the corresponding environment variable will + be defined with the full paths of the directories. If multiple directories are set, then in the + environment variable the paths are concatenated with colon (<literal>:</literal>).</para> + <table> + <title>Automatic directory creation and environment variables</title> + <tgroup cols='4'> + <thead> + <row> + <entry>Directory</entry> + <entry>Below path for system units</entry> + <entry>Below path for user units</entry> + <entry>Environment variable set</entry> + </row> + </thead> + <tbody> + <row> + <entry><varname>RuntimeDirectory=</varname></entry> + <entry><filename>/run/</filename></entry> + <entry><varname>$XDG_RUNTIME_DIR</varname></entry> + <entry><varname>$RUNTIME_DIRECTORY</varname></entry> + </row> + <row> + <entry><varname>StateDirectory=</varname></entry> + <entry><filename>/var/lib/</filename></entry> + <entry><varname>$XDG_CONFIG_HOME</varname></entry> + <entry><varname>$STATE_DIRECTORY</varname></entry> + </row> + <row> + <entry><varname>CacheDirectory=</varname></entry> + <entry><filename>/var/cache/</filename></entry> + <entry><varname>$XDG_CACHE_HOME</varname></entry> + <entry><varname>$CACHE_DIRECTORY</varname></entry> + </row> + <row> + <entry><varname>LogsDirectory=</varname></entry> + <entry><filename>/var/log/</filename></entry> + <entry><varname>$XDG_CONFIG_HOME</varname><filename>/log/</filename></entry> + <entry><varname>$LOGS_DIRECTORY</varname></entry> + </row> + <row> + <entry><varname>ConfigurationDirectory=</varname></entry> + <entry><filename>/etc/</filename></entry> + <entry><varname>$XDG_CONFIG_HOME</varname></entry> + <entry><varname>$CONFIGURATION_DIRECTORY</varname></entry> + </row> + </tbody> + </tgroup> + </table> + + <para>In case of <varname>RuntimeDirectory=</varname> the innermost subdirectories are removed when + the unit is stopped. It is possible to preserve the specified directories in this case if + <varname>RuntimeDirectoryPreserve=</varname> is configured to <option>restart</option> or + <option>yes</option> (see below). The directories specified with <varname>StateDirectory=</varname>, + <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, + <varname>ConfigurationDirectory=</varname> are not removed when the unit is stopped.</para> + + <para>Except in case of <varname>ConfigurationDirectory=</varname>, the innermost specified directories will be + owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>. If the + specified directories already exist and their owning user or group do not match the configured ones, all files + and directories below the specified directories as well as the directories themselves will have their file + ownership recursively changed to match what is configured. As an optimization, if the specified directories are + already owned by the right user and group, files and directories below of them are left as-is, even if they do + not match what is requested. The innermost specified directories will have their access mode adjusted to the + what is specified in <varname>RuntimeDirectoryMode=</varname>, <varname>StateDirectoryMode=</varname>, + <varname>CacheDirectoryMode=</varname>, <varname>LogsDirectoryMode=</varname> and + <varname>ConfigurationDirectoryMode=</varname>.</para> + + <para>These options imply <varname>BindPaths=</varname> for the specified paths. When combined with + <varname>RootDirectory=</varname> or <varname>RootImage=</varname> these paths always reside on the host and + are mounted from there into the unit's file system namespace.</para> + + <para>If <varname>DynamicUser=</varname> is used in conjunction with + <varname>StateDirectory=</varname>, the logic for <varname>CacheDirectory=</varname> and + <varname>LogsDirectory=</varname> is slightly altered: the directories are created below + <filename>/var/lib/private</filename>, <filename>/var/cache/private</filename> and + <filename>/var/log/private</filename>, respectively, which are host directories made inaccessible to + unprivileged users, which ensures that access to these directories cannot be gained through dynamic + user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from + perspective of the host and from inside the unit, the relevant directories hence always appear + directly below <filename>/var/lib</filename>, <filename>/var/cache</filename> and + <filename>/var/log</filename>.</para> + + <para>Use <varname>RuntimeDirectory=</varname> to manage one or more runtime directories for the unit and bind + their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create + runtime directories in <filename>/run/</filename> due to lack of privileges, and to make sure the runtime + directory is cleaned up automatically after use. For runtime directories that require more complex or different + 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 index='false'>/run/foo</filename> (if it does not exist), + + <filename index='false'>/run/foo/bar</filename>, and <filename index='false'>/run/baz</filename>. The + directories <filename index='false'>/run/foo/bar</filename> and + <filename index='false'>/run/baz</filename> except <filename index='false'>/run/foo</filename> are + owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>, and removed + when the service is stopped.</para> + + <para>Example: if a system service unit has the following, + <programlisting>RuntimeDirectory=foo/bar +StateDirectory=aaa/bbb ccc</programlisting> + then the environment variable <literal>RUNTIME_DIRECTORY</literal> is set with <literal>/run/foo/bar</literal>, and + <literal>STATE_DIRECTORY</literal> is set with <literal>/var/lib/aaa/bbb:/var/lib/ccc</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RuntimeDirectoryMode=</varname></term> + <term><varname>StateDirectoryMode=</varname></term> + <term><varname>CacheDirectoryMode=</varname></term> + <term><varname>LogsDirectoryMode=</varname></term> + <term><varname>ConfigurationDirectoryMode=</varname></term> + + <listitem><para>Specifies the access mode of the directories specified in <varname>RuntimeDirectory=</varname>, + <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, or + <varname>ConfigurationDirectory=</varname>, respectively, as an octal number. Defaults to + <constant>0755</constant>. See "Permissions" in <citerefentry + project='man-pages'><refentrytitle>path_resolution</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a + discussion of the meaning of permission bits.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RuntimeDirectoryPreserve=</varname></term> + + <listitem><para>Takes a boolean argument or <option>restart</option>. If set to <option>no</option> (the + default), the directories specified in <varname>RuntimeDirectory=</varname> are always removed when the service + stops. If set to <option>restart</option> the directories are preserved when the service is both automatically + and manually restarted. Here, the automatic restart means the operation specified in + <varname>Restart=</varname>, and manual restart means the one triggered by <command>systemctl restart + foo.service</command>. If set to <option>yes</option>, then the directories are not removed when the service is + stopped. Note that since the runtime directory <filename>/run/</filename> is a mount point of + <literal>tmpfs</literal>, then for system services the directories specified in + <varname>RuntimeDirectory=</varname> are removed when the system is rebooted.</para></listitem> + </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 timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when + the timeout is reached, potentially leaving resources on disk.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReadWritePaths=</varname></term> + <term><varname>ReadOnlyPaths=</varname></term> + <term><varname>InaccessiblePaths=</varname></term> + + <listitem><para>Sets up a new file system namespace for executed processes. These options may be used + to limit access a process has to the file system. Each setting takes a space-separated list of paths + relative to the host's root directory (i.e. the system running the service manager). Note that if + paths contain symlinks, they are resolved relative to the root directory set with + <varname>RootDirectory=</varname>/<varname>RootImage=</varname>.</para> + + <para>Paths listed in <varname>ReadWritePaths=</varname> are accessible from within the namespace + with the same access modes as from outside of it. Paths listed in <varname>ReadOnlyPaths=</varname> + are accessible for reading only, writing will be refused even if the usual file access controls would + permit this. Nest <varname>ReadWritePaths=</varname> inside of <varname>ReadOnlyPaths=</varname> in + order to provide writable subdirectories within read-only directories. Use + <varname>ReadWritePaths=</varname> in order to allow-list specific paths for write access if + <varname>ProtectSystem=strict</varname> is used.</para> + + <para>Paths listed in <varname>InaccessiblePaths=</varname> will be made inaccessible for processes inside + the namespace along with everything below them in the file system hierarchy. This may be more restrictive than + desired, because it is not possible to nest <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname>, + <varname>BindPaths=</varname>, or <varname>BindReadOnlyPaths=</varname> inside it. For a more flexible option, + see <varname>TemporaryFileSystem=</varname>.</para> + + <para>Non-directory paths may be specified as well. These options may be specified more than once, + in which case all paths listed will have limited access from within the namespace. If the empty string is + assigned to this option, the specific list is reset, and all prior assignments have no effect.</para> + + <para>Paths in <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname> and + <varname>InaccessiblePaths=</varname> may be prefixed with <literal>-</literal>, in which case they will be + ignored when they do not exist. If prefixed with <literal>+</literal> the paths are taken relative to the root + directory of the unit, as configured with <varname>RootDirectory=</varname>/<varname>RootImage=</varname>, + instead of relative to the root directory of the host (see above). When combining <literal>-</literal> and + <literal>+</literal> on the same path make sure to specify <literal>-</literal> first, and <literal>+</literal> + second.</para> + + <para>Note that these settings will disconnect propagation of mounts from the unit's processes to the + host. This means that this setting may not be used for services which shall be able to install mount points in + the main mount namespace. For <varname>ReadWritePaths=</varname> and <varname>ReadOnlyPaths=</varname> + propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the + unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that + mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace, + i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated + below a path marked with <varname>ReadOnlyPaths=</varname>! Restricting access with these options hence does + not extend to submounts of a directory that are created later on. This means the lock-down offered by that + setting is not complete, and does not offer full protection. </para> + + <para>Note that the effect of these settings may be undone by privileged processes. In order to set up an + effective sandboxed environment for a unit it is thus recommended to combine these settings with either + <varname>CapabilityBoundingSet=~CAP_SYS_ADMIN</varname> or + <varname>SystemCallFilter=~@mount</varname>.</para> + + <xi:include href="system-only.xml" xpointer="plural"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TemporaryFileSystem=</varname></term> + + <listitem><para>Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file + system namespace is set up for executed processes, and a temporary file system is mounted on each mount point. + This option may be specified more than once, in which case temporary file systems are mounted on all listed mount + points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect. + Each mount point may optionally be suffixed with a colon (<literal>:</literal>) and mount options such as + <literal>size=10%</literal> or <literal>ro</literal>. By default, each temporary file system is mounted + with <literal>nodev,strictatime,mode=0755</literal>. These can be disabled by explicitly specifying the corresponding + mount options, e.g., <literal>dev</literal> or <literal>nostrictatime</literal>.</para> + + <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>:</para> + + <para>Example: if a unit has the following, + <programlisting>TemporaryFileSystem=/var:ro +BindReadOnlyPaths=/var/lib/systemd</programlisting> + then the invoked processes by the unit cannot see any files or directories under <filename>/var/</filename> except for + <filename>/var/lib/systemd</filename> or its contents.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateTmp=</varname></term> + + <listitem><para>Takes a boolean argument. If true, sets up a new file system namespace for the + executed processes and mounts private <filename>/tmp/</filename> and <filename>/var/tmp/</filename> + directories inside it that are not shared by processes outside of the namespace. This is useful to + secure access to temporary files of the process, but makes sharing between processes via + <filename>/tmp/</filename> or <filename>/var/tmp/</filename> impossible. If this is enabled, all + temporary files created by a service in these directories will be removed after the service is + stopped. Defaults to false. It is possible to run two or more units within the same private + <filename>/tmp/</filename> and <filename>/var/tmp/</filename> namespace by using the + <varname>JoinsNamespaceOf=</varname> directive, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. This setting is implied if <varname>DynamicUser=</varname> is set. For this setting the same + restrictions regarding mount propagation and privileges apply as for + <varname>ReadOnlyPaths=</varname> and related calls, see above. Enabling this setting has the side + effect of adding <varname>Requires=</varname> and <varname>After=</varname> dependencies on all mount + units necessary to access <filename>/tmp/</filename> and <filename>/var/tmp/</filename>. Moreover an + implicitly <varname>After=</varname> ordering on + <citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is added.</para> + + <para>Note that the implementation of this setting might be impossible (for example if mount namespaces are not + available), and the unit should be written in a way that does not solely rely on this setting for + security.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateDevices=</varname></term> + + <listitem><para>Takes a boolean argument. If true, sets up a new <filename>/dev/</filename> mount for the + executed processes and only adds API pseudo devices such as <filename>/dev/null</filename>, + <filename>/dev/zero</filename> or <filename>/dev/random</filename> (as well as the pseudo TTY subsystem) to it, + but no physical devices such as <filename>/dev/sda</filename>, system memory <filename>/dev/mem</filename>, + system ports <filename>/dev/port</filename> and others. This is useful to securely turn off physical device + access by the executed process. Defaults to false. Enabling this option will install a system call filter to + block low-level I/O system calls that are grouped in the <varname>@raw-io</varname> set, will also remove + <constant>CAP_MKNOD</constant> and <constant>CAP_SYS_RAWIO</constant> from the capability bounding set for the + unit (see above), and set <varname>DevicePolicy=closed</varname> (see + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details). Note that using this setting will disconnect propagation of mounts from the service to the host + (propagation in the opposite direction continues to work). This means that this setting may not be used for + services which shall be able to install mount points in the main mount namespace. The new + <filename>/dev/</filename> will be mounted read-only and 'noexec'. The latter may break old programs which try + to set up executable memory by using + <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> of + <filename>/dev/zero</filename> instead of using <constant>MAP_ANON</constant>. For this setting the same + restrictions regarding mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and + related calls, see above. If turned on and if running in user mode, or in system mode, but without the + <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>), + <varname>NoNewPrivileges=yes</varname> is implied.</para> + + <para>Note that the implementation of this setting might be impossible (for example if mount namespaces are not + available), and the unit should be written in a way that does not solely rely on this setting for + security.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateNetwork=</varname></term> + + <listitem><para>Takes a boolean argument. If true, sets up a new network namespace for the executed processes + and configures only the loopback network device <literal>lo</literal> inside it. No other network devices will + be available to the executed process. This is useful to turn off network access by the executed process. + Defaults to false. It is possible to run two or more units within the same private network namespace by using + the <varname>JoinsNamespaceOf=</varname> directive, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. Note that this option will disconnect all socket families from the host, including + <constant>AF_NETLINK</constant> and <constant>AF_UNIX</constant>. Effectively, for + <constant>AF_NETLINK</constant> this means that device configuration events received from + <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> are + not delivered to the unit's processes. And for <constant>AF_UNIX</constant> this has the effect that + <constant>AF_UNIX</constant> sockets in the abstract socket namespace of the host will become unavailable to + the unit's processes (however, those located in the file system will continue to be accessible).</para> + + <para>Note that the implementation of this setting might be impossible (for example if network namespaces are + not available), and the unit should be written in a way that does not solely rely on this setting for + security.</para> + + <para>When this option is used on a socket unit any sockets bound on behalf of this unit will be + bound within a private network namespace. This may be combined with + <varname>JoinsNamespaceOf=</varname> to listen on sockets inside of network namespaces of other + services.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NetworkNamespacePath=</varname></term> + + <listitem><para>Takes an absolute file system path refererring to a Linux network namespace + pseudo-file (i.e. a file like <filename>/proc/$PID/ns/net</filename> or a bind mount or symlink to + one). When set the invoked processes are added to the network namespace referenced by that path. The + path has to point to a valid namespace file at the moment the processes are forked off. If this + option is used <varname>PrivateNetwork=</varname> has no effect. If this option is used together with + <varname>JoinsNamespaceOf=</varname> then it only has an effect if this unit is started before any of + the listed units that have <varname>PrivateNetwork=</varname> or + <varname>NetworkNamespacePath=</varname> configured, as otherwise the network namespace of those + units is reused.</para> + + <para>When this option is used on a socket unit any sockets bound on behalf of this unit will be + bound within the specified network namespace.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateUsers=</varname></term> + + <listitem><para>Takes a boolean argument. If true, sets up a new user namespace for the executed processes and + configures a minimal user and group mapping, that maps the <literal>root</literal> user and group as well as + the unit's own user and group to themselves and everything else to the <literal>nobody</literal> user and + group. This is useful to securely detach the user and group databases used by the unit from the rest of the + system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and + other resources owned by users/groups not equaling <literal>root</literal> or the unit's own will stay visible + from within the unit but appear owned by the <literal>nobody</literal> user and group. If this mode is enabled, + all unit processes are run without privileges in the host user namespace (regardless if the unit's own + user/group is <literal>root</literal> or not). Specifically this means that the process will have zero process + capabilities on the host's user namespace, but full capabilities within the service's user namespace. Settings + such as <varname>CapabilityBoundingSet=</varname> will affect only the latter, and there's no way to acquire + additional capabilities in the host's user namespace. Defaults to off.</para> + + <para>When this setting is set up by a per-user instance of the service manager, the mapping of the + <literal>root</literal> user and group to itself is omitted (unless the user manager is root). + Additionally, in the per-user instance manager case, the + user namespace will be set up before most other namespaces. This means that combining + <varname>PrivateUsers=</varname><option>true</option> with other namespaces will enable use of features not + normally supported by the per-user instances of the service manager.</para> + + <para>This setting is particularly useful in conjunction with + <varname>RootDirectory=</varname>/<varname>RootImage=</varname>, as the need to synchronize the user and group + databases in the root directory and on the host is reduced, as the only users and groups who need to be matched + are <literal>root</literal>, <literal>nobody</literal> and the unit's own user and group.</para> + + <para>Note that the implementation of this setting might be impossible (for example if user namespaces are not + available), and the unit should be written in a way that does not solely rely on this setting for + security.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectHostname=</varname></term> + + <listitem><para>Takes a boolean argument. When set, sets up a new UTS namespace for the executed + processes. In addition, changing hostname or domainname is prevented. Defaults to off.</para> + + <para>Note that the implementation of this setting might be impossible (for example if UTS namespaces + are not available), and the unit should be written in a way that does not solely rely on this setting + for security.</para> + + <para>Note that when this option is enabled for a service hostname changes no longer propagate from + the system into the service, it is hence not suitable for services that need to take notice of system + hostname changes dynamically.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectClock=</varname></term> + + <listitem><para>Takes a boolean argument. If set, writes to the hardware clock or system clock will be denied. + It is recommended to turn this on for most services that do not need modify the clock. Defaults to off. Enabling + this option removes <constant>CAP_SYS_TIME</constant> and <constant>CAP_WAKE_ALARM</constant> from the + capability bounding set for this unit, installs a system call filter to block calls that can set the + clock, and <varname>DeviceAllow=char-rtc r</varname> is implied. This ensures <filename>/dev/rtc0</filename>, + <filename>/dev/rtc1</filename>, etc. are made read-only to the service. See + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the details about <varname>DeviceAllow=</varname>.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectKernelTunables=</varname></term> + + <listitem><para>Takes a boolean argument. If true, kernel variables accessible through + <filename>/proc/sys/</filename>, <filename>/sys/</filename>, <filename>/proc/sysrq-trigger</filename>, + <filename>/proc/latency_stats</filename>, <filename>/proc/acpi</filename>, + <filename>/proc/timer_stats</filename>, <filename>/proc/fs</filename> and <filename>/proc/irq</filename> will + be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at + boot-time, for example with the + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> mechanism. Few + services need to write to these at runtime; it is hence recommended to turn this on for most services. For this + setting the same restrictions regarding mount propagation and privileges apply as for + <varname>ReadOnlyPaths=</varname> and related calls, see above. Defaults to off. If turned on and if running + in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. services + for which <varname>User=</varname> is set), <varname>NoNewPrivileges=yes</varname> is implied. Note that this + option does not prevent indirect changes to kernel tunables effected by IPC calls to other processes. However, + <varname>InaccessiblePaths=</varname> may be used to make relevant IPC file system objects inaccessible. If + <varname>ProtectKernelTunables=</varname> is set, <varname>MountAPIVFS=yes</varname> is + implied.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectKernelModules=</varname></term> + + <listitem><para>Takes a boolean argument. If true, explicit module loading will be denied. This allows + module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services + that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option + removes <constant>CAP_SYS_MODULE</constant> from the capability bounding set for the unit, and installs a + system call filter to block module system calls, also <filename>/usr/lib/modules</filename> is made + inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for + <varname>ReadOnlyPaths=</varname> and related calls, see above. Note that limited automatic module loading due + to user configuration or kernel mapping tables might still happen as side effect of requested user operations, + both privileged and unprivileged. To disable module auto-load feature please see + <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + <constant>kernel.modules_disabled</constant> mechanism and + <filename>/proc/sys/kernel/modules_disabled</filename> documentation. If turned on and if running in user + mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting + <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectKernelLogs=</varname></term> + + <listitem><para>Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is + recommended to turn this on for most services that do not need to read from or write to the kernel log ring + buffer. Enabling this option removes <constant>CAP_SYSLOG</constant> from the capability bounding set for this + unit, and installs a system call filter to block the + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry> + system call (not to be confused with the libc API + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for userspace logging). The kernel exposes its log buffer to userspace via <filename>/dev/kmsg</filename> and + <filename>/proc/kmsg</filename>. If enabled, these are made inaccessible to all the processes in the unit.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProtectControlGroups=</varname></term> + + <listitem><para>Takes a boolean argument. If true, the Linux Control Groups (<citerefentry + project='man-pages'><refentrytitle>cgroups</refentrytitle><manvolnum>7</manvolnum></citerefentry>) hierarchies + accessible through <filename>/sys/fs/cgroup/</filename> will be made read-only to all processes of the + unit. Except for container managers no services should require write access to the control groups hierarchies; + it is hence recommended to turn this on for most services. For this setting the same restrictions regarding + mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and related calls, see + above. Defaults to off. If <varname>ProtectControlGroups=</varname> is set, <varname>MountAPIVFS=yes</varname> + is implied.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestrictAddressFamilies=</varname></term> + + <listitem><para>Restricts the set of socket address families accessible to the processes of this + unit. Takes a space-separated list of address family names to allow-list, such as + <constant>AF_UNIX</constant>, <constant>AF_INET</constant> or <constant>AF_INET6</constant>. When + prefixed with <constant>~</constant> the listed address families will be applied as deny list, + otherwise as allow list. Note that this restricts access to the <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum></citerefentry> + system call only. Sockets passed into the process by other means (for example, by using socket + activation with socket units, see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>) + are unaffected. Also, sockets created with <function>socketpair()</function> (which creates connected + AF_UNIX sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x, + mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored (but works correctly on other ABIs, + including x86-64). 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 option. Specifically, it is recommended to combine this option with + <varname>SystemCallArchitectures=native</varname> or similar. 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. By default, no + restrictions apply, all address families are accessible to processes. If assigned the empty string, + any 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 + network protocols, such as <constant>AF_PACKET</constant>. Note that in most cases, the local + <constant>AF_UNIX</constant> address family should be included in the configured allow list as it is frequently + used for local communication, including for + <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry> + logging.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestrictNamespaces=</varname></term> + + <listitem><para>Restricts access to Linux namespace functionality for the processes of this unit. For details + about Linux namespaces, see <citerefentry + project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Either + takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no + restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is + prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of + any combination of: <constant>cgroup</constant>, <constant>ipc</constant>, <constant>net</constant>, + <constant>mnt</constant>, <constant>pid</constant>, <constant>user</constant> and <constant>uts</constant>. Any + namespace type listed is made accessible to the unit's processes, access to namespace types not listed is + prohibited (allow-listing). By prepending the list with a single tilde character (<literal>~</literal>) the + effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are + permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied, + which is equivalent to false. This option may appear more than once, in which case the namespace types are + merged by <constant>OR</constant>, or by <constant>AND</constant> if the lines are prefixed with + <literal>~</literal> (see examples below). Internally, this setting limits access to the + <citerefentry><refentrytitle>unshare</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry><refentrytitle>clone</refentrytitle><manvolnum>2</manvolnum></citerefentry> and + <citerefentry><refentrytitle>setns</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls, taking + the specified flags parameters into account. Note that — if this option is used — in addition to restricting + creation and switching of the specified types of namespaces (or all of them, if true) access to the + <function>setns()</function> system call with a zero flags parameter is prohibited. This setting is only + supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390 + and s390x, and enforces no restrictions on other architectures. If running in user mode, or in system mode, but + without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>), + <varname>NoNewPrivileges=yes</varname> is implied.</para> + + <para>Example: if a unit has the following, + <programlisting>RestrictNamespaces=cgroup ipc +RestrictNamespaces=cgroup net</programlisting> + then <constant>cgroup</constant>, <constant>ipc</constant>, and <constant>net</constant> are set. + If the second line is prefixed with <literal>~</literal>, e.g., + <programlisting>RestrictNamespaces=cgroup ipc +RestrictNamespaces=~cgroup net</programlisting> + then, only <constant>ipc</constant> is set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LockPersonality=</varname></term> + + <listitem><para>Takes a boolean argument. If set, locks down the <citerefentry + project='man-pages'><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry> system + call so that the kernel execution domain may not be changed from the default or the personality selected with + <varname>Personality=</varname> directive. This may be useful to improve security, because odd personality + emulations may be poorly tested and source of vulnerabilities. If running in user mode, or in system mode, but + without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>), + <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryDenyWriteExecute=</varname></term> + + <listitem><para>Takes a boolean argument. If set, attempts to create memory mappings that are writable and + executable at the same time, or to change existing memory mappings to become executable, or mapping shared + memory segments as executable are prohibited. Specifically, a system call filter is added that rejects + <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls with both + <constant>PROT_EXEC</constant> and <constant>PROT_WRITE</constant> set, + <citerefentry><refentrytitle>mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry> or + <citerefentry><refentrytitle>pkey_mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls + with <constant>PROT_EXEC</constant> set and + <citerefentry><refentrytitle>shmat</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls with + <constant>SHM_EXEC</constant> set. Note that this option is incompatible with programs and libraries that + generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code + "trampoline" feature of various C compilers. This option improves service security, as it makes harder for + software exploits to change running code dynamically. However, the protection can be circumvented, if + the service can write to a filesystem, which is not mounted with <constant>noexec</constant> (such as + <filename>/dev/shm</filename>), or it can use <function>memfd_create()</function>. This can be + prevented by making such file systems inaccessible to the service + (e.g. <varname>InaccessiblePaths=/dev/shm</varname>) and installing further system call filters + (<varname>SystemCallFilter=~memfd_create</varname>). Note that this feature is fully available on + x86-64, and partially on x86. Specifically, the <function>shmat()</function> protection is not + available on x86. 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 option. Specifically, it is recommended to combine this option with + <varname>SystemCallArchitectures=native</varname> or similar. If running in user mode, or in system + mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting + <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is implied.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestrictRealtime=</varname></term> + + <listitem><para>Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of + the unit are refused. This restricts access to realtime task scheduling policies such as + <constant>SCHED_FIFO</constant>, <constant>SCHED_RR</constant> or <constant>SCHED_DEADLINE</constant>. See + <citerefentry project='man-pages'><refentrytitle>sched</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about these scheduling policies. If running in user mode, or in system mode, but without the + <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting <varname>User=</varname>), + <varname>NoNewPrivileges=yes</varname> is implied. Realtime scheduling policies may be used to monopolize CPU + time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service + situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs + that actually require them. Defaults to off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestrictSUIDSGID=</varname></term> + + <listitem><para>Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or + set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see + <citerefentry + project='man-pages'><refentrytitle>inode</refentrytitle><manvolnum>7</manvolnum></citerefentry>). If + running in user mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> + capability (e.g. setting <varname>User=</varname>), <varname>NoNewPrivileges=yes</varname> is + implied. As the SUID/SGID bits are mechanisms to elevate privileges, and allows users to acquire the + identity of other users, it is recommended to restrict creation of SUID/SGID files to the few + programs that actually require them. Note that this restricts marking of any type of file system + object with these bits, including both regular files and directories (where the SGID is a different + meaning than for files, see documentation). This option is implied if <varname>DynamicUser=</varname> + is enabled. Defaults to off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemoveIPC=</varname></term> + + <listitem><para>Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and + group the processes of this unit are run as are removed when the unit is stopped. This setting only has an + effect if at least one of <varname>User=</varname>, <varname>Group=</varname> and + <varname>DynamicUser=</varname> are used. It has no effect on IPC objects owned by the root user. Specifically, + this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If + multiple units use the same user or group the IPC objects are removed when the last of these units is + stopped. This setting is implied if <varname>DynamicUser=</varname> is set.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateMounts=</varname></term> + + <listitem><para>Takes a boolean parameter. If set, the processes of this unit will be run in their own private + file system (mount) namespace with all mount propagation from the processes towards the host's main file system + namespace turned off. This means any file system mount points established or removed by the unit's processes + will be private to them and not be visible to the host. However, file system mount points established or + removed on the host will be propagated to the unit's processes. See <citerefentry + project='man-pages'><refentrytitle>mount_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details on file system namespaces. Defaults to off.</para> + + <para>When turned on, this executes three operations for each invoked process: a new + <constant>CLONE_NEWNS</constant> namespace is created, after which all existing mounts are remounted to + <constant>MS_SLAVE</constant> to disable propagation from the unit's processes to the host (but leaving + propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation + mode configured with <varname>MountFlags=</varname>, see below.</para> + + <para>File system namespaces are set up individually for each process forked off by the service manager. Mounts + established in the namespace of the process created by <varname>ExecStartPre=</varname> will hence be cleaned + up automatically as soon as that process exits and will not be available to subsequent processes forked off for + <varname>ExecStart=</varname> (and similar applies to the various other commands configured for + units). Similarly, <varname>JoinsNamespaceOf=</varname> does not permit sharing kernel mount namespaces between + units, it only enables sharing of the <filename>/tmp/</filename> and <filename>/var/tmp/</filename> + directories.</para> + + <para>Other file system namespace unit settings — <varname>PrivateMounts=</varname>, + <varname>PrivateTmp=</varname>, <varname>PrivateDevices=</varname>, <varname>ProtectSystem=</varname>, + <varname>ProtectHome=</varname>, <varname>ReadOnlyPaths=</varname>, <varname>InaccessiblePaths=</varname>, + <varname>ReadWritePaths=</varname>, … — also enable file system namespacing in a fashion equivalent to this + option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are + used.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MountFlags=</varname></term> + + <listitem><para>Takes a mount propagation setting: <option>shared</option>, <option>slave</option> or + <option>private</option>, which controls whether file system mount points in the file system namespaces set up + for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details on mount propagation, and the three propagation flags in particular.</para> + + <para>This setting only controls the <emphasis>final</emphasis> propagation setting in effect on all mount + points of the file system namespace created for each process of this unit. Other file system namespacing unit + settings (see the discussion in <varname>PrivateMounts=</varname> above) will implicitly disable mount and + unmount propagation from the unit's processes towards the host by changing the propagation setting of all mount + points in the unit's file system namespace to <option>slave</option> first. Setting this option to + <option>shared</option> does not reestablish propagation in that case.</para> + + <para>If not set – but file system namespaces are enabled through another file system namespace unit setting – + <option>shared</option> mount propagation is used, but — as mentioned — as <option>slave</option> is applied + first, propagation from the unit's processes to the host is still turned off.</para> + + <para>It is not recommended to use <option>private</option> mount propagation for units, as this means + temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked + off processes, as unmount propagation events won't be received by the file system namespace of the unit.</para> + + <para>Usually, it is best to leave this setting unmodified, and use higher level file system namespacing + options instead, in particular <varname>PrivateMounts=</varname>, see above.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>System Call Filtering</title> + <variablelist class='unit-directives'> + + <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 (allow-listing). (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 (deny-listing). Deny-listed 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 deny-listed system call is triggered, instead of + terminating the processes immediately. Special setting <literal>kill</literal> can be used to + explicitly specify killing. 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 allow-listed 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 + option. Specifically, it is recommended to combine this option with + <varname>SystemCallArchitectures=native</varname> or similar.</para> + + <para>Note that strict system call filters may impact execution and error handling code paths of the service + invocation. Specifically, access to the <function>execve()</function> system call is required for the execution + of the service binary — if it is blocked service invocation will necessarily fail. Also, if execution of the + service binary fails for some reason (for example: missing service executable), the error handling logic might + require access to an additional set of system calls in order to process and log this failure correctly. It + might be necessary to temporarily disable system call filters in order to simplify debugging of such + failures.</para> + + <para>If you specify both types of this option (i.e. allow-listing and deny-listing), the first + encountered will take precedence and will dictate the default action (termination or approval of a + system call). Then the next occurrences of this option will add or delete the listed system calls + from the set of the filtered system calls, depending of its type and the default action. (For + example, if you have started with an allow list rule for <function>read()</function> and + <function>write()</function>, and right after it add a deny list rule for <function>write()</function>, + then <function>write()</function> will be removed from the set.)</para> + + <para>As the number of possible system calls is large, predefined sets of system calls are provided. A set + starts with <literal>@</literal> character, followed by name of the set. + + <table> + <title>Currently predefined system call sets</title> + + <tgroup cols='2'> + <colspec colname='set' /> + <colspec colname='description' /> + <thead> + <row> + <entry>Set</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>@aio</entry> + <entry>Asynchronous I/O (<citerefentry project='man-pages'><refentrytitle>io_setup</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>io_submit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry> + </row> + <row> + <entry>@basic-io</entry> + <entry>System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (<citerefentry project='man-pages'><refentrytitle>read</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>write</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry> + </row> + <row> + <entry>@chown</entry> + <entry>Changing file ownership (<citerefentry project='man-pages'><refentrytitle>chown</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>fchownat</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry> + </row> + <row> + <entry>@clock</entry> + <entry>System calls for changing the system clock (<citerefentry project='man-pages'><refentrytitle>adjtimex</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>settimeofday</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry> + </row> + <row> + <entry>@cpu-emulation</entry> + <entry>System calls for CPU emulation functionality (<citerefentry project='man-pages'><refentrytitle>vm86</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry> + </row> + <row> + <entry>@debug</entry> + <entry>Debugging, performance monitoring and tracing functionality (<citerefentry project='man-pages'><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>perf_event_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry> + </row> + <row> + <entry>@file-system</entry> + <entry>File system operations: opening, creating files and directories for read and write, renaming and removing them, reading file properties, or creating hard and symbolic links</entry> + </row> + <row> + <entry>@io-event</entry> + <entry>Event loop system calls (<citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>eventfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry> + </row> + <row> + <entry>@ipc</entry> + <entry>Pipes, SysV IPC, POSIX Message Queues and other IPC (<citerefentry project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>svipc</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry>@keyring</entry> + <entry>Kernel keyring access (<citerefentry project='man-pages'><refentrytitle>keyctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry> + </row> + <row> + <entry>@memlock</entry> + <entry>Locking of memory in RAM (<citerefentry project='man-pages'><refentrytitle>mlock</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>mlockall</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry> + </row> + <row> + <entry>@module</entry> + <entry>Loading and unloading of kernel modules (<citerefentry project='man-pages'><refentrytitle>init_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>delete_module</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry> + </row> + <row> + <entry>@mount</entry> + <entry>Mounting and unmounting of file systems (<citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry> + </row> + <row> + <entry>@network-io</entry> + <entry>Socket I/O (including local AF_UNIX): <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry></entry> + </row> + <row> + <entry>@obsolete</entry> + <entry>Unusual, obsolete or unimplemented (<citerefentry project='man-pages'><refentrytitle>create_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>gtty</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry> + </row> + <row> + <entry>@privileged</entry> + <entry>All system calls which need super-user capabilities (<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry>@process</entry> + <entry>Process control, execution, namespacing operations (<citerefentry project='man-pages'><refentrytitle>clone</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>, …)</entry> + </row> + <row> + <entry>@raw-io</entry> + <entry>Raw I/O port access (<citerefentry project='man-pages'><refentrytitle>ioperm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>iopl</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>pciconfig_read()</function>, …)</entry> + </row> + <row> + <entry>@reboot</entry> + <entry>System calls for rebooting and reboot preparation (<citerefentry project='man-pages'><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>kexec()</function>, …)</entry> + </row> + <row> + <entry>@resources</entry> + <entry>System calls for changing resource limits, memory and scheduling parameters (<citerefentry project='man-pages'><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry> + </row> + <row> + <entry>@setuid</entry> + <entry>System calls for changing user ID and group ID credentials, (<citerefentry project='man-pages'><refentrytitle>setuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setgid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setresuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry> + </row> + <row> + <entry>@signal</entry> + <entry>System calls for manipulating and handling process signals (<citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry> + </row> + <row> + <entry>@swap</entry> + <entry>System calls for enabling/disabling swap devices (<citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>swapoff</refentrytitle><manvolnum>2</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry>@sync</entry> + <entry>Synchronizing files and memory to disk (<citerefentry project='man-pages'><refentrytitle>fsync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>msync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry> + </row> + <row> + <entry>@system-service</entry> + <entry>A reasonable set of system calls used by common system services, excluding any special purpose calls. This is the recommended starting point for allow-listing system calls for system services, as it contains what is typically needed by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: <literal>@clock</literal>, <literal>@mount</literal>, <literal>@swap</literal>, <literal>@reboot</literal>.</entry> + </row> + <row> + <entry>@timer</entry> + <entry>System calls for scheduling operations by time (<citerefentry project='man-pages'><refentrytitle>alarm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>timer_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry> + </row> + <row> + <entry>@known</entry> + <entry>All system calls defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated.</entry> + </row> + </tbody> + </tgroup> + </table> + + Note, that as new system calls are added to the kernel, additional system calls might be added to the groups + above. Contents of the sets may also change between systemd versions. In addition, the list of system calls + depends on the kernel version and architecture for which systemd was compiled. Use + <command>systemd-analyze syscall-filter</command> to list the actual list of system calls in each + filter.</para> + + <para>Generally, allow-listing system calls (rather than deny-listing) is the safer mode of + operation. It is recommended to enforce system call allow lists for all long-running system + services. Specifically, the following lines are a relatively safe basic choice for the majority of + system services:</para> + + <programlisting>[Service] +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 deny lists comprehensive requires constant work. It is thus recommended to use + allow-listing instead, which offers the benefit that new system calls are by default implicitly + blocked until the allow list 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>, + <varname>PrivateDevices=</varname>, <varname>ProtectSystem=</varname>, <varname>ProtectHome=</varname>, + <varname>ProtectKernelTunables=</varname>, <varname>ProtectControlGroups=</varname>, + <varname>ProtectKernelLogs=</varname>, <varname>ProtectClock=</varname>, <varname>ReadOnlyPaths=</varname>, + <varname>InaccessiblePaths=</varname> and <varname>ReadWritePaths=</varname>.</para></listitem> + </varlistentry> + + <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. 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 or the special + setting <literal>kill</literal> is assigned, the process will be terminated immediately when the + filter is triggered.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SystemCallArchitectures=</varname></term> + + <listitem><para>Takes a space-separated list of architecture identifiers to include in the system call + filter. The known architecture identifiers are the same as for <varname>ConditionArchitecture=</varname> + described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + as well as <constant>x32</constant>, <constant>mips64-n32</constant>, <constant>mips64-le-n32</constant>, and + the special identifier <constant>native</constant>. The special identifier <constant>native</constant> + implicitly maps to the native architecture of the system (or more precisely: to the architecture the system + manager is compiled for). 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. By default, this option is set to the empty list, i.e. no + filtering is applied.</para> + + <para>If this setting is used, processes of this unit will only be permitted to call native system calls, and + system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated + as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on + x32.</para> + + <para>System call filtering is not equally effective on all architectures. For example, on x86 + filtering of network socket-related calls is not possible, due to ABI limitations — a limitation that x86-64 + does not have, however. On systems supporting multiple ABIs at the same time — such as x86/x86-64 — it is hence + recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to + circumvent the restrictions applied to the native ABI of the system. In particular, setting + <varname>SystemCallArchitectures=native</varname> is a good choice for disabling non-native ABIs.</para> + + <para>System call architectures may also be restricted system-wide via the + <varname>SystemCallArchitectures=</varname> option in the global configuration. See + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SystemCallLog=</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 for the listed ones will be logged. If the first + character of the list is <literal>~</literal>, the effect is inverted: all system calls except the + listed system calls will be logged. 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 auditing or setting up a + minimal sandboxing environment. 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> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>Environment=</varname></term> + + <listitem><para>Sets environment variables for executed processes. Takes a space-separated list of + variable assignments. This option may be specified more than once, in which case all listed variables + will be set. If the same variable is set twice, the later setting will override the earlier + setting. If the empty string is assigned to this option, the list of environment variables is reset, + all prior assignments have no effect. Variable expansion is not performed inside the strings, + however, specifier expansion is possible. The <literal>$</literal> character has no special + meaning. If you need to assign a value containing spaces or the equals sign to a variable, use double + quotes (") for the assignment.</para> + + <para>The names of the variables can contain ASCII letters, digits, and the underscore + character. Variable names cannot be empty or start with a digit. In variable values, most characters + are allowed, but non-printable characters are currently rejected.</para> + + <para>Example: + <programlisting>Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"</programlisting> + gives three variables <literal>VAR1</literal>, + <literal>VAR2</literal>, <literal>VAR3</literal> + with the values <literal>word1 word2</literal>, + <literal>word3</literal>, <literal>$word 5 6</literal>. + </para> + + <para> + See <citerefentry + project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details + about environment variables.</para> + + <para>Note that environment variables are not suitable for passing secrets (such as passwords, key + material, …) to service processes. Environment variables set for a unit are exposed to unprivileged + clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover, + environment variables are propagated down the process tree, including across security boundaries + (such as setuid/setgid executables), and hence might leak to processes that should not have access to + the secret data. Use <varname>LoadCredential=</varname> (see below) to pass data to unit processes + securely.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EnvironmentFile=</varname></term> + + <listitem><para>Similar to <varname>Environment=</varname> but reads the environment variables from a text + file. The text file should contain new-line-separated variable assignments. Empty lines, lines without an + <literal>=</literal> separator, or lines starting with ; or # will be ignored, which may be used for + commenting. A line ending with a backslash will be concatenated with the following one, allowing multiline + variable definitions. The parser strips leading and trailing whitespace from the values of assignments, unless + you use double quotes (").</para> + + <para><ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C escapes</ulink> + are supported, but not + <ulink url="https://en.wikipedia.org/wiki/Control_character#In_ASCII">most control characters</ulink>. + <literal>\t</literal> and <literal>\n</literal> can be used to insert tabs and newlines within + <varname>EnvironmentFile=</varname>.</para> + + <para>The argument passed should be an absolute filename or wildcard expression, optionally prefixed with + <literal>-</literal>, which indicates that if the file does not exist, it will not be read and no error or + warning message is logged. This option may be specified more than once in which case all specified files are + read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments + have no effect.</para> + + <para>The files listed with this directive will be read shortly before the process is executed (more + specifically, after all processes from a previous unit state terminated. This means you can generate these + files in one unit state, and read it with this option in the next. The files are read from the file + system of the service manager, before any file system changes like bind mounts take place).</para> + + <para>Settings from these files override settings made with <varname>Environment=</varname>. If the same + variable is set twice from these files, the files will be read in the order they are specified and the later + setting will override the earlier setting.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PassEnvironment=</varname></term> + + <listitem><para>Pass environment variables set for the system service manager to executed processes. Takes a + space-separated list of variable names. This option may be specified more than once, in which case all listed + variables will be passed. If the empty string is assigned to this option, the list of environment variables to + pass is reset, all prior assignments have no effect. Variables specified that are not set for the system + manager will not be passed and will be silently ignored. Note that this option is only relevant for the system + service manager, as system services by default do not automatically inherit any environment variables set for + the service manager itself. However, in case of the user service manager all environment variables are passed + to the executed processes anyway, hence this option is without effect for the user service manager.</para> + + <para>Variables set for invoked processes due to this setting are subject to being overridden by those + configured with <varname>Environment=</varname> or <varname>EnvironmentFile=</varname>.</para> + + <para><ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C escapes</ulink> + are supported, but not + <ulink url="https://en.wikipedia.org/wiki/Control_character#In_ASCII">most control characters</ulink>. + <literal>\t</literal> and <literal>\n</literal> can be used to insert tabs and newlines within + <varname>EnvironmentFile=</varname>.</para> + + <para>Example: + <programlisting>PassEnvironment=VAR1 VAR2 VAR3</programlisting> + passes three variables <literal>VAR1</literal>, + <literal>VAR2</literal>, <literal>VAR3</literal> + with the values set for those variables in PID1.</para> + + <para> + See <citerefentry + project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details + about environment variables.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>UnsetEnvironment=</varname></term> + + <listitem><para>Explicitly unset environment variable assignments that would normally be passed from the + service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable + assignments. This option may be specified more than once, in which case all listed variables/assignments will + be unset. If the empty string is assigned to this option, the list of environment variables/assignments to + unset is reset. If a variable assignment is specified (that is: a variable name, followed by + <literal>=</literal>, followed by its value), then any environment variable matching this precise assignment is + removed. If a variable name is specified (that is a variable name without any following <literal>=</literal> or + value), then any assignment matching the variable name, regardless of its value is removed. Note that the + effect of <varname>UnsetEnvironment=</varname> is applied as final step when the environment list passed to + executed processes is compiled. That means it may undo assignments from any configuration source, including + assignments made through <varname>Environment=</varname> or <varname>EnvironmentFile=</varname>, inherited from + the system manager's global set of environment variables, inherited via <varname>PassEnvironment=</varname>, + set by the service manager itself (such as <varname>$NOTIFY_SOCKET</varname> and such), or set by a PAM module + (in case <varname>PAMName=</varname> is used).</para> + + <para>See "Environment Variables in Spawned Processes" below for a description of how those + settings combine to form the inherited environment. See <citerefentry + project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for general + information about environment variables.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Logging and Standard Input/Output</title> + + <variablelist class='unit-directives'> + <varlistentry> + + <term><varname>StandardInput=</varname></term> + + <listitem><para>Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one + of <option>null</option>, <option>tty</option>, <option>tty-force</option>, <option>tty-fail</option>, + <option>data</option>, <option>file:<replaceable>path</replaceable></option>, <option>socket</option> or + <option>fd:<replaceable>name</replaceable></option>.</para> + + <para>If <option>null</option> is selected, standard input will be connected to <filename>/dev/null</filename>, + i.e. all read attempts by the process will result in immediate EOF.</para> + + <para>If <option>tty</option> is selected, standard input is connected to a TTY (as configured by + <varname>TTYPath=</varname>, see below) and the executed process becomes the controlling process of the + terminal. If the terminal is already being controlled by another process, the executed process waits until the + current controlling process releases the terminal.</para> + + <para><option>tty-force</option> is similar to <option>tty</option>, but the executed process is forcefully and + immediately made the controlling process of the terminal, potentially removing previous controlling processes + from the terminal.</para> + + <para><option>tty-fail</option> is similar to <option>tty</option>, but if the terminal already has a + controlling process start-up of the executed process fails.</para> + + <para>The <option>data</option> option may be used to configure arbitrary textual or binary data to pass via + standard input to the executed process. The data to pass is configured via + <varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> (see below). Note that the actual + file descriptor type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available + privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by + EOF.</para> + + <para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file + system object to standard input. An absolute path following the <literal>:</literal> character is expected, + which may refer to a regular file, a FIFO or special file. If an <constant>AF_UNIX</constant> socket in the + file system is specified, a stream socket is connected to it. The latter is useful for connecting standard + input of processes to arbitrary system services.</para> + + <para>The <option>socket</option> option is valid in socket-activated services only, and requires the relevant + socket unit file (see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details) + to have <varname>Accept=yes</varname> set, or to specify a single socket only. If this option is set, standard + input will be connected to the socket the service was activated from, which is primarily useful for + compatibility with daemons designed for use with the traditional <citerefentry + project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> socket activation + daemon.</para> + + <para>The <option>fd:<replaceable>name</replaceable></option> option connects standard input to a specific, + named file descriptor provided by a socket unit. The name may be specified as part of this option, following a + <literal>:</literal> character (e.g. <literal>fd:foobar</literal>). If no name is specified, the name + <literal>stdin</literal> is implied (i.e. <literal>fd</literal> is equivalent to <literal>fd:stdin</literal>). + At least one socket unit defining the specified name must be provided via the <varname>Sockets=</varname> + option, and the file descriptor name may differ from the name of its containing socket unit. If multiple + matches are found, the first one will be used. See <varname>FileDescriptorName=</varname> in + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more + details about named file descriptors and their ordering.</para> + + <para>This setting defaults to <option>null</option>.</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>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> + + <para><option>null</option> connects standard output to <filename>/dev/null</filename>, i.e. everything written + to it will be lost.</para> + + <para><option>tty</option> connects standard output to a tty (as configured via <varname>TTYPath=</varname>, + 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 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> 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 + <varname>StandardInput=</varname>, see above. If <replaceable>path</replaceable> refers to a regular file + on the filesystem, it is opened (created if it doesn't exist yet) for writing at the beginning of the file, + but without truncating it. + If standard input and output are directed to the same file path, it is opened only once, for reading as well + as writing and duplicated. This is particularly useful when the specified path refers to an + <constant>AF_UNIX</constant> socket in the file system, as in that case only a + single stream connection is created for both input and output.</para> + + <para><option>append:<replaceable>path</replaceable></option> is similar to + <option>file:<replaceable>path</replaceable></option> above, but it opens the file in append mode. + </para> + + <para><option>socket</option> connects standard output to a socket acquired via socket activation. The + semantics are similar to the same option of <varname>StandardInput=</varname>, see above.</para> + + <para>The <option>fd:<replaceable>name</replaceable></option> option connects standard output to a specific, + named file descriptor provided by a socket unit. A name may be specified as part of this option, following a + <literal>:</literal> character (e.g. <literal>fd:foobar</literal>). If no name is specified, the name + <literal>stdout</literal> is implied (i.e. <literal>fd</literal> is equivalent to + <literal>fd:stdout</literal>). At least one socket unit defining the specified name must be provided via the + <varname>Sockets=</varname> option, and the file descriptor name may differ from the name of its containing + socket unit. If multiple matches are found, the first one will be used. See + <varname>FileDescriptorName=</varname> in + <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 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 + defaults to <option>journal</option>. Note that setting this parameter might result in additional dependencies + to be added to the unit (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>StandardError=</varname></term> + + <listitem><para>Controls where file descriptor 2 (stderr) of the executed processes is connected to. The + available options are identical to those of <varname>StandardOutput=</varname>, with some exceptions: if set to + <option>inherit</option> the file descriptor used for standard output is duplicated for standard error, while + <option>fd:<replaceable>name</replaceable></option> will use a default file descriptor name of + <literal>stderr</literal>.</para> + + <para>This setting defaults to the value set with <varname>DefaultStandardError=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, which + defaults to <option>inherit</option>. Note that setting this parameter might result in additional dependencies + to be added to the unit (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>StandardInputText=</varname></term> + <term><varname>StandardInputData=</varname></term> + + <listitem><para>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the + executed processes. These settings have no effect unless <varname>StandardInput=</varname> is set to + <option>data</option>. Use this option to embed process input data directly in the unit file.</para> + + <para><varname>StandardInputText=</varname> accepts arbitrary textual data. C-style escapes for special + characters as well as the usual <literal>%</literal>-specifiers are resolved. Each time this setting is used + the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use + appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured + with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an + empty line, add an additional <literal>\n</literal> to the end or beginning of a line).</para> + + <para><varname>StandardInputData=</varname> accepts arbitrary binary data, encoded in <ulink + url="https://tools.ietf.org/html/rfc2045#section-6.8">Base64</ulink>. No escape sequences or specifiers are + resolved. Any whitespace in the encoded version is ignored during decoding.</para> + + <para>Note that <varname>StandardInputText=</varname> and <varname>StandardInputData=</varname> operate on the + same data buffer, and may be mixed in order to configure both binary and textual data for the same input + stream. The textual or binary data is joined strictly in the order the settings appear in the unit + file. Assigning an empty string to either will reset the data buffer.</para> + + <para>Please keep in mind that in order to maintain readability long unit file settings may be split into + multiple lines, by suffixing each line (except for the last) with a <literal>\</literal> character (see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details). This is particularly useful for large data configured with these two options. Example:</para> + + <programlisting>… +StandardInput=data +StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \ + LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \ + dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \ + enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \ + SWNrZSEK +…</programlisting></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LogLevelMax=</varname></term> + + <listitem><para>Configures filtering by log level of log messages generated by this unit. Takes a + <command>syslog</command> log level, one of <option>emerg</option> (lowest log level, only highest priority + messages), <option>alert</option>, <option>crit</option>, <option>err</option>, <option>warning</option>, + <option>notice</option>, <option>info</option>, <option>debug</option> (highest log level, also lowest priority + messages). See <citerefentry + project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details. By default no filtering is applied (i.e. the default maximum log level is <option>debug</option>). Use + this option to configure the logging system to drop log messages of a specific service above the specified + level. For example, set <varname>LogLevelMax=</varname><option>info</option> in order to turn off debug logging + of a particularly chatty unit. Note that the configured level is applied to any log messages written by any + of the processes belonging to this unit, sent via any supported logging protocol. The filtering is applied + early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass + through this filter successfully might still be dropped by filters applied at a later stage in the logging + subsystem. For example, <varname>MaxLevelStore=</varname> configured in + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> might + prohibit messages of higher log levels to be stored on disk, even though the per-unit + <varname>LogLevelMax=</varname> permitted it to be processed.</para></listitem> + </varlistentry> + + <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 ("). <!-- " 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> + <term><varname>LogRateLimitIntervalSec=</varname></term> + <term><varname>LogRateLimitBurst=</varname></term> + + <listitem><para>Configures the rate limiting that is applied to messages generated by this unit. If, in the + time interval defined by <varname>LogRateLimitIntervalSec=</varname>, more messages than specified in + <varname>LogRateLimitBurst=</varname> are logged by a service, all further messages within the interval are + dropped until the interval is over. A message about the number of dropped messages is generated. The time + specification for <varname>LogRateLimitIntervalSec=</varname> may be specified in the following units: "s", + "min", "h", "ms", "us" (see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details). + The default settings are set by <varname>RateLimitIntervalSec=</varname> and <varname>RateLimitBurst=</varname> + configured in <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LogNamespace=</varname></term> + + <listitem><para>Run the unit's processes in the specified journal namespace. Expects a short + user-defined string identifying the namespace. If not used the processes of the service are run in + the default journal namespace, i.e. their log stream is collected and processed by + <filename>systemd-journald.service</filename>. If this option is used any log data generated by + processes of this unit (regardless if via the <function>syslog()</function>, journal native logging + or stdout/stderr logging) is collected and processed by an instance of the + <filename>systemd-journald@.service</filename> template unit, which manages the specified + namespace. The log data is stored in a data store independent from the default log namespace's data + store. See + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details about journal namespaces.</para> + + <para>Internally, journal namespaces are implemented through Linux mount namespacing and + over-mounting the directory that contains the relevant <constant>AF_UNIX</constant> sockets used for + logging in the unit's mount namespace. Since mount namespaces are used this setting disconnects + propagation of mounts from the unit's processes to the host, similar to how + <varname>ReadOnlyPaths=</varname> and similar settings (see above) work. Journal namespaces may hence + not be used for services that need to establish mount points on the host.</para> + + <para>When this option is used the unit will automatically gain ordering and requirement dependencies + on the two socket units associated with the <filename>systemd-journald@.service</filename> instance + so that they are automatically established prior to the unit starting up. Note that when this option + is used log output of this service does not appear in the regular + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + output, unless the <option>--namespace=</option> option is used.</para> + + <xi:include href="system-only.xml" xpointer="singular"/></listitem> + </varlistentry> + + <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> 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> + <term><varname>SyslogFacility=</varname></term> + + <listitem><para>Sets the <command>syslog</command> facility identifier to use when logging. One of + <option>kern</option>, <option>user</option>, <option>mail</option>, <option>daemon</option>, + <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> 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> + <term><varname>SyslogLevel=</varname></term> + + <listitem><para>The default <command>syslog</command> log level to use when logging to the logging system or + the kernel log buffer. One of <option>emerg</option>, <option>alert</option>, <option>crit</option>, + <option>err</option>, <option>warning</option>, <option>notice</option>, <option>info</option>, + <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> 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 + interpretation of these prefixes may be disabled with <varname>SyslogLevelPrefix=</varname>, see below. For + details, see <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + Defaults to <option>info</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <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> 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> + + <varlistentry> + <term><varname>TTYPath=</varname></term> + + <listitem><para>Sets the terminal device node to use if standard input, output, or error are connected to a TTY + (see above). Defaults to <filename>/dev/console</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TTYReset=</varname></term> + + <listitem><para>Reset the terminal device specified with <varname>TTYPath=</varname> before and after + execution. Defaults to <literal>no</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TTYVHangup=</varname></term> + + <listitem><para>Disconnect all clients which have opened the terminal device specified with + <varname>TTYPath=</varname> before and after execution. Defaults to <literal>no</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TTYVTDisallocate=</varname></term> + + <listitem><para>If the terminal device specified with <varname>TTYPath=</varname> is a virtual console + terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback + buffer is cleared. Defaults to <literal>no</literal>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Credentials</title> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>LoadCredential=</varname><replaceable>ID</replaceable>:<replaceable>PATH</replaceable></term> + + <listitem><para>Pass a credential to the unit. Credentials are limited-size binary or textual objects + that may be passed to unit processes. They are primarily used for passing cryptographic keys (both + public and private) or certificates, user account information or identity information from host to + services. The data is accessible from the unit's processes via the file system, at a read-only + location that (if possible and permitted) is backed by non-swappable memory. The data is only + accessible to the user associated with the unit, via the + <varname>User=</varname>/<varname>DynamicUser=</varname> settings (as well as the superuser). When + available, the location of credentials is exported as the <varname>$CREDENTIALS_DIRECTORY</varname> + environment variable to the unit's processes.</para> + + <para>The <varname>LoadCredential=</varname> setting takes a textual ID to use as name for a + credential plus a file system path. The ID must be a short ASCII string suitable as filename in the + filesystem, and may be chosen freely by the user. If the specified path is absolute it is opened as + regular file and the credential data is read from it. If the absolute path refers to an + <constant>AF_UNIX</constant> stream socket in the file system a connection is made to it (only once + at unit start-up) and the credential data read from the connection, providing an easy IPC integration + point for dynamically providing credentials from other services. If the specified path is not + absolute and itself qualifies as valid credential identifier it is understood to refer to a + credential that the service manager itself received via the <varname>$CREDENTIALS_DIRECTORY</varname> + environment variable, which may be used to propagate credentials from an invoking environment (e.g. a + container manager that invoked the service manager) into a service. The contents of the file/socket + may be arbitrary binary or textual data, including newline characters and <constant>NUL</constant> + bytes. This option may be used multiple times, each time defining an additional credential to pass to + the unit.</para> + + <para>The credential files/IPC sockets must be accessible to the service manager, but don't have to + be directly accessible to the unit's processes: the credential data is read and copied into separate, + read-only copies for the unit that are accessible to appropriately privileged processes. This is + particularly useful in combination with <varname>DynamicUser=</varname> as this way privileged data + can be made available to processes running under a dynamic UID (i.e. not a previously known one) + without having to open up access to all users.</para> + + <para>In order to reference the path a credential may be read from within a + <varname>ExecStart=</varname> command line use <literal>${CREDENTIALS_DIRECTORY}/mycred</literal>, + e.g. <literal>ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred</literal>.</para> + + <para>Currently, an accumulated credential size limit of 1M bytes per unit is + enforced.</para> + + <para>If referencing an <constant>AF_UNIX</constant> stream socket to connect to, the connection will + originate from an abstract namespace socket, that includes information about the unit and the + credential ID in its socket name. Use <citerefentry + project='man-pages'><refentrytitle>getpeername</refentrytitle><manvolnum>2</manvolnum></citerefentry> + to query this information. The returned socket name is formatted as <constant>NUL</constant> + <replaceable>RANDOM</replaceable> <literal>/unit/</literal> <replaceable>UNIT</replaceable> + <literal>/</literal> <replaceable>ID</replaceable>, i.e. a <constant>NUL</constant> byte (as required + for abstract namespace socket names), followed by a random string (consisting of alphadecimal + characters), followed by the literal string <literal>/unit/</literal>, followed by the requesting + unit name, followed by the literal character <literal>/</literal>, followed by the textual credential + ID requested. Example: <literal>\0adf9d86b6eda275e/unit/foobar.service/credx</literal> in case the + credential <literal>credx</literal> is requested for a unit <literal>foobar.service</literal>. This + functionality is useful for using a single listening socket to serve credentials to multiple + consumers.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SetCredential=</varname><replaceable>ID</replaceable>:<replaceable>VALUE</replaceable></term> + + <listitem><para>The <varname>SetCredential=</varname> setting is similar to + <varname>LoadCredential=</varname> but accepts a literal value to use as data for the credential, + instead of a file system path to read the data from. Do not use this option for data that is supposed + to be secret, as it is accessible to unprivileged processes via IPC. It's only safe to use this for + user IDs, public key material and similar non-sensitive data. For everything else use + <varname>LoadCredential=</varname>. In order to embed binary data into the credential data use + C-style escaping (i.e. <literal>\n</literal> to embed a newline, or <literal>\x00</literal> to embed + a <constant>NUL</constant> byte).</para> + + <para>If a credential of the same ID is listed in both <varname>LoadCredential=</varname> and + <varname>SetCredential=</varname>, the latter will act as default if the former cannot be + retrieved. In this case not being able to retrieve the credential from the path specified in + <varname>LoadCredential=</varname> is not considered fatal.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>System V Compatibility</title> + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>UtmpIdentifier=</varname></term> + + <listitem><para>Takes a four character identifier string for an <citerefentry + project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry> and wtmp entry + for this service. This should only be set for services such as <command>getty</command> implementations (such + as <citerefentry + project='die-net'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>) where utmp/wtmp + entries must be created and cleared before and after execution, or for services that shall be executed as if + they were run by a <command>getty</command> process (see below). If the configured string is longer than four + characters, it is truncated and the terminal four characters are used. This setting interprets %I style string + replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this + service.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>UtmpMode=</varname></term> + + <listitem><para>Takes one of <literal>init</literal>, <literal>login</literal> or <literal>user</literal>. If + <varname>UtmpIdentifier=</varname> is set, controls which type of <citerefentry + project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>/wtmp entries + for this service are generated. This setting has no effect unless <varname>UtmpIdentifier=</varname> is set + too. If <literal>init</literal> is set, only an <constant>INIT_PROCESS</constant> entry is generated and the + invoked process must implement a <command>getty</command>-compatible utmp/wtmp logic. If + <literal>login</literal> is set, first an <constant>INIT_PROCESS</constant> entry, followed by a + <constant>LOGIN_PROCESS</constant> entry is generated. In this case, the invoked process must implement a + <citerefentry + project='die-net'><refentrytitle>login</refentrytitle><manvolnum>1</manvolnum></citerefentry>-compatible + utmp/wtmp logic. If <literal>user</literal> is set, first an <constant>INIT_PROCESS</constant> entry, then a + <constant>LOGIN_PROCESS</constant> entry and finally a <constant>USER_PROCESS</constant> entry is + generated. In this case, the invoked process may be any process that is suitable to be run as session + leader. Defaults to <literal>init</literal>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Environment Variables in Spawned Processes</title> + + <para>Processes started by the service manager are executed with an environment variable block assembled from + multiple sources. Processes started by the system service manager generally do not inherit environment variables + set for the service manager itself (but this may be altered via <varname>PassEnvironment=</varname>), but processes + started by the user service manager instances generally do inherit all environment variables set for the service + manager itself.</para> + + <para>For each invoked process the list of environment variables set is compiled from the following sources:</para> + + <itemizedlist> + <listitem><para>Variables globally configured for the service manager, using the + <varname>DefaultEnvironment=</varname> setting in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + the kernel command line option <varname>systemd.setenv=</varname> understood by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, or via + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + <command>set-environment</command> verb.</para></listitem> + + <listitem><para>Variables defined by the service manager itself (see the list below).</para></listitem> + + <listitem><para>Variables set in the service manager's own environment variable block (subject to + <varname>PassEnvironment=</varname> for the system service manager).</para></listitem> + + <listitem><para>Variables set via <varname>Environment=</varname> in the unit file.</para></listitem> + + <listitem><para>Variables read from files specified via <varname>EnvironmentFile=</varname> in the unit + file.</para></listitem> + + <listitem><para>Variables set by any PAM modules in case <varname>PAMName=</varname> is in effect, + cf. <citerefentry + project='man-pages'><refentrytitle>pam_env</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + </itemizedlist> + + <para>If the same environment variable is set by multiple of these sources, the later source — according + to the order of the list above — wins. Note that as the final step all variables listed in + <varname>UnsetEnvironment=</varname> are removed from the compiled environment variable list, immediately + before it is passed to the executed process.</para> + + <para>The general philosophy is to expose a small curated list of environment variables to processes. + Services started by the system manager (PID 1) will be started, without additional service-specific + configuration, with just a few environment variables. The user manager inherits environment variables as + any other system service, but in addition may receive additional environment variables from PAM, and, + typically, additional imported variables when the user starts a graphical session. It is recommended to + keep the environment blocks in both the system and user managers managers lean.</para> + + <para>Hint: <command>systemd-run -P env</command> and <command>systemd-run --user -P env</command> print + the effective system and user service environment blocks.</para> + + <refsect2> + <title>Environment Variables Set or Propagated by the Service Manager</title> + + <para>The following environment variables are propagated by the service manager or generated internally + for each invoked process:</para> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$PATH</varname></term> + + <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 <filename>/usr/</filename>" + (<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, a different path may be configured by the distribution. It is recommended to + not rely on the order of entries, and have only one program with a given name in + <varname>$PATH</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$LANG</varname></term> + + <listitem><para>Locale. Can be set in <citerefentry + project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + or on the kernel command line (see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> and + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$USER</varname></term> + <term><varname>$LOGNAME</varname></term> + <term><varname>$HOME</varname></term> + <term><varname>$SHELL</varname></term> + + <listitem><para>User name (twice), home directory, and the + login shell. The variables are set for the units that have + <varname>User=</varname> set, which includes user + <command>systemd</command> instances. See + <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$INVOCATION_ID</varname></term> + + <listitem><para>Contains a randomized, unique 128bit ID identifying each runtime cycle of the unit, formatted + as 32 character hexadecimal string. A new ID is assigned each time the unit changes from an inactive state into + an activating or active state, and may be used to identify this specific runtime cycle, in particular in data + stored offline, such as the journal. The same ID is passed to all processes run as part of the + unit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_RUNTIME_DIR</varname></term> + + <listitem><para>The directory to use for runtime objects (such as IPC objects) and volatile state. Set for all + services run by the user <command>systemd</command> instance, as well as any system services that use + <varname>PAMName=</varname> with a PAM stack that includes <command>pam_systemd</command>. See below and + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more + information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$RUNTIME_DIRECTORY</varname></term> + <term><varname>$STATE_DIRECTORY</varname></term> + <term><varname>$CACHE_DIRECTORY</varname></term> + <term><varname>$LOGS_DIRECTORY</varname></term> + <term><varname>$CONFIGURATION_DIRECTORY</varname></term> + + <listitem><para>Absolute paths to the directories defined with + <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>, + <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, and + <varname>ConfigurationDirectory=</varname> when those settings are used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>$CREDENTIALS_DIRECTORY</varname></term> + + <listitem><para>An absolute path to the per-unit directory with credentials configured via + <varname>LoadCredential=</varname>/<varname>SetCredential=</varname>. The directory is marked + read-only and is placed in unswappable memory (if supported and permitted), and is only accessible to + the UID associated with the unit via <varname>User=</varname> or <varname>DynamicUser=</varname> (and + the superuser).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$MAINPID</varname></term> + + <listitem><para>The PID of the unit's main process if it is + known. This is only set for control processes as invoked by + <varname>ExecReload=</varname> and similar. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$MANAGERPID</varname></term> + + <listitem><para>The PID of the user <command>systemd</command> + instance, set for processes spawned by it. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$LISTEN_FDS</varname></term> + <term><varname>$LISTEN_PID</varname></term> + <term><varname>$LISTEN_FDNAMES</varname></term> + + <listitem><para>Information about file descriptors passed to a + service for socket activation. See + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$NOTIFY_SOCKET</varname></term> + + <listitem><para>The socket + <function>sd_notify()</function> talks to. See + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$WATCHDOG_PID</varname></term> + <term><varname>$WATCHDOG_USEC</varname></term> + + <listitem><para>Information about watchdog keep-alive notifications. See + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$TERM</varname></term> + + <listitem><para>Terminal type, set only for units connected to + a terminal (<varname>StandardInput=tty</varname>, + <varname>StandardOutput=tty</varname>, or + <varname>StandardError=tty</varname>). See + <citerefentry project='man-pages'><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$LOG_NAMESPACE</varname></term> + + <listitem><para>Contains the name of the selected logging namespace when the + <varname>LogNamespace=</varname> service setting is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$JOURNAL_STREAM</varname></term> + + <listitem><para>If the standard output or standard error output of the executed processes are connected to the + journal (for example, by setting <varname>StandardError=journal</varname>) <varname>$JOURNAL_STREAM</varname> + contains the device and inode numbers of the connection file descriptor, formatted in decimal, separated by a + colon (<literal>:</literal>). This permits invoked processes to safely detect whether their standard output or + standard error output are connected to the journal. The device and inode numbers of the file descriptors should + be compared with the values set in the environment variable to determine whether the process output is still + connected to the journal. Note that it is generally not sufficient to only check whether + <varname>$JOURNAL_STREAM</varname> is set at all as services might invoke external processes replacing their + standard output or standard error output, without unsetting the environment variable.</para> + + <para>If both standard output and standard error of the executed processes are connected to the journal via a + stream socket, this environment variable will contain information about the standard error stream, as that's + usually the preferred destination for log data. (Note that typically the same stream is used for both standard + output and standard error, hence very likely the environment variable contains device and inode information + matching both stream file descriptors.)</para> + + <para>This environment variable is primarily useful to allow services to optionally upgrade their used log + protocol to the native journal protocol (using + <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and other + functions) if their standard output or standard error output is connected to the journal anyway, thus enabling + delivery of structured metadata along with logged messages.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SERVICE_RESULT</varname></term> + + <listitem><para>Only defined for the service unit type, this environment variable is passed to all + <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> processes, and encodes the service + "result". Currently, the following values are defined:</para> + + <table> + <title>Defined <varname>$SERVICE_RESULT</varname> values</title> + <tgroup cols='2'> + <colspec colname='result'/> + <colspec colname='meaning'/> + <thead> + <row> + <entry>Value</entry> + <entry>Meaning</entry> + </row> + </thead> + + <tbody> + <row> + <entry><literal>success</literal></entry> + <entry>The service ran successfully and exited cleanly.</entry> + </row> + <row> + <entry><literal>protocol</literal></entry> + <entry>A protocol violation occurred: the service did not take the steps required by its unit configuration (specifically what is configured in its <varname>Type=</varname> setting).</entry> + </row> + <row> + <entry><literal>timeout</literal></entry> + <entry>One of the steps timed out.</entry> + </row> + <row> + <entry><literal>exit-code</literal></entry> + <entry>Service process exited with a non-zero exit code; see <varname>$EXIT_CODE</varname> below for the actual exit code returned.</entry> + </row> + <row> + <entry><literal>signal</literal></entry> + <entry>A service process was terminated abnormally by a signal, without dumping core. See <varname>$EXIT_CODE</varname> below for the actual signal causing the termination.</entry> + </row> + <row> + <entry><literal>core-dump</literal></entry> + <entry>A service process terminated abnormally with a signal and dumped core. See <varname>$EXIT_CODE</varname> below for the signal causing the termination.</entry> + </row> + <row> + <entry><literal>watchdog</literal></entry> + <entry>Watchdog keep-alive ping was enabled for the service, but the deadline was missed.</entry> + </row> + <row> + <entry><literal>start-limit-hit</literal></entry> + <entry>A start limit was defined for the unit and it was hit, causing the unit to fail to start. See <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> for details.</entry> + </row> + <row> + <entry><literal>resources</literal></entry> + <entry>A catch-all condition in case a system operation failed.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>This environment variable is useful to monitor failure or successful termination of a service. Even + though this variable is available in both <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>, it + is usually a better choice to place monitoring tools in the latter, as the former is only invoked for services + that managed to start up correctly, and the latter covers both services that failed during their start-up and + those which failed during their runtime.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$EXIT_CODE</varname></term> + <term><varname>$EXIT_STATUS</varname></term> + + <listitem><para>Only defined for the service unit type, these environment variables are passed to all + <varname>ExecStop=</varname>, <varname>ExecStopPost=</varname> processes and contain exit status/code + information of the main process of the service. For the precise definition of the exit code and status, see + <citerefentry><refentrytitle>wait</refentrytitle><manvolnum>2</manvolnum></citerefentry>. <varname>$EXIT_CODE</varname> + is one of <literal>exited</literal>, <literal>killed</literal>, + <literal>dumped</literal>. <varname>$EXIT_STATUS</varname> contains the numeric exit code formatted as string + if <varname>$EXIT_CODE</varname> is <literal>exited</literal>, and the signal name in all other cases. Note + that these environment variables are only set if the service manager succeeded to start and identify the main + process of the service.</para> + + <table> + <title>Summary of possible service result variable values</title> + <tgroup cols='3'> + <colspec colname='result' /> + <colspec colname='code' /> + <colspec colname='status' /> + <thead> + <row> + <entry><varname>$SERVICE_RESULT</varname></entry> + <entry><varname>$EXIT_CODE</varname></entry> + <entry><varname>$EXIT_STATUS</varname></entry> + </row> + </thead> + + <tbody> + <row> + <entry morerows="1" valign="top"><literal>success</literal></entry> + <entry valign="top"><literal>killed</literal></entry> + <entry><literal>HUP</literal>, <literal>INT</literal>, <literal>TERM</literal>, <literal>PIPE</literal></entry> + </row> + <row> + <entry valign="top"><literal>exited</literal></entry> + <entry><literal>0</literal></entry> + </row> + <row> + <entry morerows="1" valign="top"><literal>protocol</literal></entry> + <entry valign="top">not set</entry> + <entry>not set</entry> + </row> + <row> + <entry><literal>exited</literal></entry> + <entry><literal>0</literal></entry> + </row> + <row> + <entry morerows="1" valign="top"><literal>timeout</literal></entry> + <entry valign="top"><literal>killed</literal></entry> + <entry><literal>TERM</literal>, <literal>KILL</literal></entry> + </row> + <row> + <entry valign="top"><literal>exited</literal></entry> + <entry><literal>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal + >3</literal>, …, <literal>255</literal></entry> + </row> + <row> + <entry valign="top"><literal>exit-code</literal></entry> + <entry valign="top"><literal>exited</literal></entry> + <entry><literal>1</literal>, <literal>2</literal>, <literal + >3</literal>, …, <literal>255</literal></entry> + </row> + <row> + <entry valign="top"><literal>signal</literal></entry> + <entry valign="top"><literal>killed</literal></entry> + <entry><literal>HUP</literal>, <literal>INT</literal>, <literal>KILL</literal>, …</entry> + </row> + <row> + <entry valign="top"><literal>core-dump</literal></entry> + <entry valign="top"><literal>dumped</literal></entry> + <entry><literal>ABRT</literal>, <literal>SEGV</literal>, <literal>QUIT</literal>, …</entry> + </row> + <row> + <entry morerows="2" valign="top"><literal>watchdog</literal></entry> + <entry><literal>dumped</literal></entry> + <entry><literal>ABRT</literal></entry> + </row> + <row> + <entry><literal>killed</literal></entry> + <entry><literal>TERM</literal>, <literal>KILL</literal></entry> + </row> + <row> + <entry><literal>exited</literal></entry> + <entry><literal>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal + >3</literal>, …, <literal>255</literal></entry> + </row> + <row> + <entry valign="top"><literal>exec-condition</literal></entry> + <entry><literal>exited</literal></entry> + <entry><literal>1</literal>, <literal>2</literal>, <literal>3</literal>, <literal + >4</literal>, …, <literal>254</literal></entry> + </row> + <row> + <entry valign="top"><literal>oom-kill</literal></entry> + <entry valign="top"><literal>killed</literal></entry> + <entry><literal>TERM</literal>, <literal>KILL</literal></entry> + </row> + <row> + <entry><literal>start-limit-hit</literal></entry> + <entry>not set</entry> + <entry>not set</entry> + </row> + <row> + <entry><literal>resources</literal></entry> + <entry>any of the above</entry> + <entry>any of the above</entry> + </row> + <row> + <entry namest="results" nameend="status">Note: the process may be also terminated by a signal not sent by systemd. In particular the process may send an arbitrary signal to itself in a handler for any of the non-maskable signals. Nevertheless, in the <literal>timeout</literal> and <literal>watchdog</literal> rows above only the signals that systemd sends have been included. Moreover, using <varname>SuccessExitStatus=</varname> additional exit statuses may be declared to indicate clean termination, which is not reflected by this table.</entry> + </row> + </tbody> + </tgroup> + </table></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$PIDFILE</varname></term> + + <listitem><para>The path to the configured PID file, in case the process is forked off on behalf of + a service that uses the <varname>PIDFile=</varname> setting, see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. Service code may use this environment variable to automatically generate a PID file at + the location configured in the unit file. This field is set to an absolute path in the file + system.</para></listitem> + </varlistentry> + + </variablelist> + + <para>For system services, when <varname>PAMName=</varname> is enabled and <command>pam_systemd</command> is part + of the selected PAM stack, additional environment variables defined by systemd may be set for + services. Specifically, these are <varname>$XDG_SEAT</varname>, <varname>$XDG_VTNR</varname>, see + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details.</para> + </refsect2> + + </refsect1> + + <refsect1> + <title>Process Exit Codes</title> + + <para>When invoking a unit process the service manager possibly fails to apply the execution parameters configured + with the settings above. In that case the already created service process will exit with a non-zero exit code + before the configured command line is executed. (Or in other words, the child process possibly exits with these + error codes, after having been created by the <citerefentry + project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, but + before the matching <citerefentry + project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call is + called.) Specifically, exit codes defined by the C library, by the LSB specification and by the systemd service + manager itself are used.</para> + + <para>The following basic service exit codes are defined by the C library.</para> + + <table> + <title>Basic C library exit codes</title> + <tgroup cols='3'> + <thead> + <row> + <entry>Exit Code</entry> + <entry>Symbolic Name</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>0</entry> + <entry><constant>EXIT_SUCCESS</constant></entry> + <entry>Generic success code.</entry> + </row> + <row> + <entry>1</entry> + <entry><constant>EXIT_FAILURE</constant></entry> + <entry>Generic failure or unspecified error.</entry> + </row> + </tbody> + </tgroup> + </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>. + </para> + + <table> + <title>LSB service exit codes</title> + <tgroup cols='3'> + <thead> + <row> + <entry>Exit Code</entry> + <entry>Symbolic Name</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>2</entry> + <entry><constant>EXIT_INVALIDARGUMENT</constant></entry> + <entry>Invalid or excess arguments.</entry> + </row> + <row> + <entry>3</entry> + <entry><constant>EXIT_NOTIMPLEMENTED</constant></entry> + <entry>Unimplemented feature.</entry> + </row> + <row> + <entry>4</entry> + <entry><constant>EXIT_NOPERMISSION</constant></entry> + <entry>The user has insufficient privileges.</entry> + </row> + <row> + <entry>5</entry> + <entry><constant>EXIT_NOTINSTALLED</constant></entry> + <entry>The program is not installed.</entry> + </row> + <row> + <entry>6</entry> + <entry><constant>EXIT_NOTCONFIGURED</constant></entry> + <entry>The program is not configured.</entry> + </row> + <row> + <entry>7</entry> + <entry><constant>EXIT_NOTRUNNING</constant></entry> + <entry>The program is not running.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + The LSB specification suggests that error codes 200 and above are reserved for implementations. Some of them are + used by the service manager to indicate problems during process invocation: + </para> + <table> + <title>systemd-specific exit codes</title> + <tgroup cols='3'> + <thead> + <row> + <entry>Exit Code</entry> + <entry>Symbolic Name</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>200</entry> + <entry><constant>EXIT_CHDIR</constant></entry> + <entry>Changing to the requested working directory failed. See <varname>WorkingDirectory=</varname> above.</entry> + </row> + <row> + <entry>201</entry> + <entry><constant>EXIT_NICE</constant></entry> + <entry>Failed to set up process scheduling priority (nice level). See <varname>Nice=</varname> above.</entry> + </row> + <row> + <entry>202</entry> + <entry><constant>EXIT_FDS</constant></entry> + <entry>Failed to close unwanted file descriptors, or to adjust passed file descriptors.</entry> + </row> + <row> + <entry>203</entry> + <entry><constant>EXIT_EXEC</constant></entry> + <entry>The actual process execution failed (specifically, the <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call). Most likely this is caused by a missing or non-accessible executable file.</entry> + </row> + <row> + <entry>204</entry> + <entry><constant>EXIT_MEMORY</constant></entry> + <entry>Failed to perform an action due to memory shortage.</entry> + </row> + <row> + <entry>205</entry> + <entry><constant>EXIT_LIMITS</constant></entry> + <entry>Failed to adjust resource limits. See <varname>LimitCPU=</varname> and related settings above.</entry> + </row> + <row> + <entry>206</entry> + <entry><constant>EXIT_OOM_ADJUST</constant></entry> + <entry>Failed to adjust the OOM setting. See <varname>OOMScoreAdjust=</varname> above.</entry> + </row> + <row> + <entry>207</entry> + <entry><constant>EXIT_SIGNAL_MASK</constant></entry> + <entry>Failed to set process signal mask.</entry> + </row> + <row> + <entry>208</entry> + <entry><constant>EXIT_STDIN</constant></entry> + <entry>Failed to set up standard input. See <varname>StandardInput=</varname> above.</entry> + </row> + <row> + <entry>209</entry> + <entry><constant>EXIT_STDOUT</constant></entry> + <entry>Failed to set up standard output. See <varname>StandardOutput=</varname> above.</entry> + </row> + <row> + <entry>210</entry> + <entry><constant>EXIT_CHROOT</constant></entry> + <entry>Failed to change root directory (<citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>). See <varname>RootDirectory=</varname>/<varname>RootImage=</varname> above.</entry> + </row> + <row> + <entry>211</entry> + <entry><constant>EXIT_IOPRIO</constant></entry> + <entry>Failed to set up IO scheduling priority. See <varname>IOSchedulingClass=</varname>/<varname>IOSchedulingPriority=</varname> above.</entry> + </row> + <row> + <entry>212</entry> + <entry><constant>EXIT_TIMERSLACK</constant></entry> + <entry>Failed to set up timer slack. See <varname>TimerSlackNSec=</varname> above.</entry> + </row> + <row> + <entry>213</entry> + <entry><constant>EXIT_SECUREBITS</constant></entry> + <entry>Failed to set process secure bits. See <varname>SecureBits=</varname> above.</entry> + </row> + <row> + <entry>214</entry> + <entry><constant>EXIT_SETSCHEDULER</constant></entry> + <entry>Failed to set up CPU scheduling. See <varname>CPUSchedulingPolicy=</varname>/<varname>CPUSchedulingPriority=</varname> above.</entry> + </row> + <row> + <entry>215</entry> + <entry><constant>EXIT_CPUAFFINITY</constant></entry> + <entry>Failed to set up CPU affinity. See <varname>CPUAffinity=</varname> above.</entry> + </row> + <row> + <entry>216</entry> + <entry><constant>EXIT_GROUP</constant></entry> + <entry>Failed to determine or change group credentials. See <varname>Group=</varname>/<varname>SupplementaryGroups=</varname> above.</entry> + </row> + <row> + <entry>217</entry> + <entry><constant>EXIT_USER</constant></entry> + <entry>Failed to determine or change user credentials, or to set up user namespacing. See <varname>User=</varname>/<varname>PrivateUsers=</varname> above.</entry> + </row> + <row> + <entry>218</entry> + <entry><constant>EXIT_CAPABILITIES</constant></entry> + <entry>Failed to drop capabilities, or apply ambient capabilities. See <varname>CapabilityBoundingSet=</varname>/<varname>AmbientCapabilities=</varname> above.</entry> + </row> + <row> + <entry>219</entry> + <entry><constant>EXIT_CGROUP</constant></entry> + <entry>Setting up the service control group failed.</entry> + </row> + <row> + <entry>220</entry> + <entry><constant>EXIT_SETSID</constant></entry> + <entry>Failed to create new process session.</entry> + </row> + <row> + <entry>221</entry> + <entry><constant>EXIT_CONFIRM</constant></entry> + <entry>Execution has been cancelled by the user. See the <varname>systemd.confirm_spawn=</varname> kernel command line setting on <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details.</entry> + </row> + <row> + <entry>222</entry> + <entry><constant>EXIT_STDERR</constant></entry> + <entry>Failed to set up standard error output. See <varname>StandardError=</varname> above.</entry> + </row> + <row> + <entry>224</entry> + <entry><constant>EXIT_PAM</constant></entry> + <entry>Failed to set up PAM session. See <varname>PAMName=</varname> above.</entry> + </row> + <row> + <entry>225</entry> + <entry><constant>EXIT_NETWORK</constant></entry> + <entry>Failed to set up network namespacing. See <varname>PrivateNetwork=</varname> above.</entry> + </row> + <row> + <entry>226</entry> + <entry><constant>EXIT_NAMESPACE</constant></entry> + <entry>Failed to set up mount namespacing. See <varname>ReadOnlyPaths=</varname> and related settings above.</entry> + </row> + <row> + <entry>227</entry> + <entry><constant>EXIT_NO_NEW_PRIVILEGES</constant></entry> + <entry>Failed to disable new privileges. See <varname>NoNewPrivileges=yes</varname> above.</entry> + </row> + <row> + <entry>228</entry> + <entry><constant>EXIT_SECCOMP</constant></entry> + <entry>Failed to apply system call filters. See <varname>SystemCallFilter=</varname> and related settings above.</entry> + </row> + <row> + <entry>229</entry> + <entry><constant>EXIT_SELINUX_CONTEXT</constant></entry> + <entry>Determining or changing SELinux context failed. See <varname>SELinuxContext=</varname> above.</entry> + </row> + <row> + <entry>230</entry> + <entry><constant>EXIT_PERSONALITY</constant></entry> + <entry>Failed to set up an execution domain (personality). See <varname>Personality=</varname> above.</entry> + </row> + <row> + <entry>231</entry> + <entry><constant>EXIT_APPARMOR_PROFILE</constant></entry> + <entry>Failed to prepare changing AppArmor profile. See <varname>AppArmorProfile=</varname> above.</entry> + </row> + <row> + <entry>232</entry> + <entry><constant>EXIT_ADDRESS_FAMILIES</constant></entry> + <entry>Failed to restrict address families. See <varname>RestrictAddressFamilies=</varname> above.</entry> + </row> + <row> + <entry>233</entry> + <entry><constant>EXIT_RUNTIME_DIRECTORY</constant></entry> + <entry>Setting up runtime directory failed. See <varname>RuntimeDirectory=</varname> and related settings above.</entry> + </row> + <row> + <entry>235</entry> + <entry><constant>EXIT_CHOWN</constant></entry> + <entry>Failed to adjust socket ownership. Used for socket units only.</entry> + </row> + <row> + <entry>236</entry> + <entry><constant>EXIT_SMACK_PROCESS_LABEL</constant></entry> + <entry>Failed to set SMACK label. See <varname>SmackProcessLabel=</varname> above.</entry> + </row> + <row> + <entry>237</entry> + <entry><constant>EXIT_KEYRING</constant></entry> + <entry>Failed to set up kernel keyring.</entry> + </row> + <row> + <entry>238</entry> + <entry><constant>EXIT_STATE_DIRECTORY</constant></entry> + <entry>Failed to set up unit's state directory. See <varname>StateDirectory=</varname> above.</entry> + </row> + <row> + <entry>239</entry> + <entry><constant>EXIT_CACHE_DIRECTORY</constant></entry> + <entry>Failed to set up unit's cache directory. See <varname>CacheDirectory=</varname> above.</entry> + </row> + <row> + <entry>240</entry> + <entry><constant>EXIT_LOGS_DIRECTORY</constant></entry> + <entry>Failed to set up unit's logging directory. See <varname>LogsDirectory=</varname> above.</entry> + </row> + <row> + <entry>241</entry> + <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> + <row> + <entry>243</entry> + <entry><constant>EXIT_CREDENTIALS</constant></entry> + <entry>Failed to set up unit's credentials. See <varname>LoadCredential=</varname> and <varname>SetCredential=</varname> above.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Finally, the BSD operating systems define a set of exit codes, typically defined on Linux systems too:</para> + + <table> + <title>BSD exit codes</title> + <tgroup cols='3'> + <thead> + <row> + <entry>Exit Code</entry> + <entry>Symbolic Name</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>64</entry> + <entry><constant>EX_USAGE</constant></entry> + <entry>Command line usage error</entry> + </row> + <row> + <entry>65</entry> + <entry><constant>EX_DATAERR</constant></entry> + <entry>Data format error</entry> + </row> + <row> + <entry>66</entry> + <entry><constant>EX_NOINPUT</constant></entry> + <entry>Cannot open input</entry> + </row> + <row> + <entry>67</entry> + <entry><constant>EX_NOUSER</constant></entry> + <entry>Addressee unknown</entry> + </row> + <row> + <entry>68</entry> + <entry><constant>EX_NOHOST</constant></entry> + <entry>Host name unknown</entry> + </row> + <row> + <entry>69</entry> + <entry><constant>EX_UNAVAILABLE</constant></entry> + <entry>Service unavailable</entry> + </row> + <row> + <entry>70</entry> + <entry><constant>EX_SOFTWARE</constant></entry> + <entry>internal software error</entry> + </row> + <row> + <entry>71</entry> + <entry><constant>EX_OSERR</constant></entry> + <entry>System error (e.g., can't fork)</entry> + </row> + <row> + <entry>72</entry> + <entry><constant>EX_OSFILE</constant></entry> + <entry>Critical OS file missing</entry> + </row> + <row> + <entry>73</entry> + <entry><constant>EX_CANTCREAT</constant></entry> + <entry>Can't create (user) output file</entry> + </row> + <row> + <entry>74</entry> + <entry><constant>EX_IOERR</constant></entry> + <entry>Input/output error</entry> + </row> + <row> + <entry>75</entry> + <entry><constant>EX_TEMPFAIL</constant></entry> + <entry>Temporary failure; user is invited to retry</entry> + </row> + <row> + <entry>76</entry> + <entry><constant>EX_PROTOCOL</constant></entry> + <entry>Remote error in protocol</entry> + </row> + <row> + <entry>77</entry> + <entry><constant>EX_NOPERM</constant></entry> + <entry>Permission denied</entry> + </row> + <row> + <entry>78</entry> + <entry><constant>EX_CONFIG</constant></entry> + <entry>Configuration error</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml new file mode 100644 index 0000000..b1936be --- /dev/null +++ b/man/systemd.generator.xml @@ -0,0 +1,319 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.generator"> + <refentryinfo> + <title>systemd.generator</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.generator</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.generator</refname> + <refpurpose>systemd unit generators</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command index='false'>/path/to/generator</command> + <arg choice="plain"><replaceable>normal-dir</replaceable></arg> + <arg choice="plain"><replaceable>early-dir</replaceable></arg> + <arg choice="plain"><replaceable>late-dir</replaceable></arg> + </cmdsynopsis> + + <para> + <literallayout><filename>/run/systemd/system-generators/*</filename> +<filename>/etc/systemd/system-generators/*</filename> +<filename>/usr/local/lib/systemd/system-generators/*</filename> +<filename>&systemgeneratordir;/*</filename></literallayout> + </para> + + <para> + <literallayout><filename>/run/systemd/user-generators/*</filename> +<filename>/etc/systemd/user-generators/*</filename> +<filename>/usr/local/lib/systemd/user-generators/*</filename> +<filename>&usergeneratordir;/*</filename></literallayout> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + <para>Generators are small executables that live in + <filename>&systemgeneratordir;/</filename> and other directories listed above. + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will execute those binaries very early at bootup and at configuration reload time + — before unit files are loaded. Their main purpose is to convert configuration + that is not native into dynamically generated unit files.</para> + + <para>Each generator is called with three directory paths that are to be used for + generator output. In these three directories, generators may dynamically generate + unit files (regular ones, instances, as well as templates), unit file + <filename>.d/</filename> drop-ins, and create symbolic links to unit files to add + additional dependencies, create aliases, or instantiate existing templates. Those + directories are included in the unit load path of + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + allowing generated configuration to extend or override existing + definitions.</para> + + <para>Directory paths for generator output differ by priority: + <filename>…/generator.early</filename> has priority higher than the admin + configuration in <filename>/etc/</filename>, while + <filename>…/generator</filename> has lower priority than + <filename>/etc/</filename> but higher than vendor configuration in + <filename>/usr/</filename>, and <filename>…/generator.late</filename> has priority + lower than all other configuration. See the next section and the discussion of + unit load paths and unit overriding in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>Generators are loaded from a set of paths determined during + compilation, as listed above. System and user generators are loaded + from directories with names ending in + <filename>system-generators/</filename> and + <filename>user-generators/</filename>, respectively. Generators + found in directories listed earlier override the ones with the + same name in directories lower in the list. A symlink to + <filename>/dev/null</filename> or an empty file can be used to + mask a generator, thereby preventing it from running. Please note + that the order of the two directories with the highest priority is + reversed with respect to the unit load path, and generators in + <filename>/run/</filename> overwrite those in + <filename>/etc/</filename>.</para> + + <para>After installing new generators or updating the + configuration, <command>systemctl daemon-reload</command> may be + executed. This will delete the previous configuration created by + generators, re-run all generators, and cause + <command>systemd</command> to reload units from disk. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for more information. + </para> + </refsect1> + + <refsect1> + <title>Output directories</title> + + <para>Generators are invoked with three arguments: paths to directories where + generators can place their generated unit files or symlinks. By default those + paths are runtime directories that are included in the search path of + <command>systemd</command>, but a generator may be called with different paths + for debugging purposes.</para> + + <orderedlist> + <listitem> + <para><parameter>normal-dir</parameter></para> + <para>In normal use this is <filename>/run/systemd/generator</filename> in + case of the system generators and + <filename>$XDG_RUNTIME_DIR/generator</filename> in case of the user + generators. Unit files placed in this directory take precedence over vendor + unit configuration but not over native user/administrator unit configuration. + </para> + </listitem> + + <listitem> + <para><parameter>early-dir</parameter></para> + <para>In normal use this is <filename>/run/systemd/generator.early</filename> + in case of the system generators and + <filename>$XDG_RUNTIME_DIR/generator.early</filename> in case of the user + generators. Unit files placed in this directory override unit files in + <filename>/usr/</filename>, <filename>/run/</filename> and + <filename>/etc/</filename>. This means that unit files placed in this + directory take precedence over all normal configuration, both vendor and + user/administrator.</para> + </listitem> + + <listitem> + <para><parameter>late-dir</parameter></para> + <para>In normal use this is <filename>/run/systemd/generator.late</filename> + in case of the system generators and + <filename>$XDG_RUNTIME_DIR/generator.late</filename> in case of the user + generators. This directory may be used to extend the unit file tree without + overriding any other unit files. Any native configuration files supplied by + the vendor or user/administrator take precedence.</para> + </listitem> + </orderedlist> + </refsect1> + + <refsect1> + <title>Notes about writing generators</title> + + <itemizedlist> + <listitem> + <para>All generators are executed in parallel. That means all executables are + started at the very same time and need to be able to cope with this + parallelism. + </para> + </listitem> + + <listitem> + <para>Generators are run very early at boot and cannot rely on any external + services. They may not talk to any other process. That includes simple things + such as logging to + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + or <command>systemd</command> itself (this means: no + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)! + Non-essential file systems like <filename>/var/</filename> and + <filename>/home/</filename> are mounted after generators have run. Generators + can however rely on the most basic kernel functionality to be available, + including a mounted <filename>/sys/</filename>, <filename>/proc/</filename>, + <filename>/dev/</filename>, <filename>/usr/</filename>. + </para> + </listitem> + + <listitem> + <para>Units written by generators are removed when the configuration is + reloaded. That means the lifetime of the generated units is closely bound to + the reload cycles of <command>systemd</command> itself.</para> + </listitem> + + <listitem> + <para>Generators should only be used to generate unit files and symlinks to + them, not any other kind of configuration. Due to the lifecycle logic + mentioned above, generators are not a good fit to generate dynamic + configuration for other services. If you need to generate dynamic + configuration for other services, do so in normal services you order before + the service in question.</para> + </listitem> + + <listitem> + <para>Since + <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + + is not available (see above), log messages have to be written to + <filename>/dev/kmsg</filename> instead.</para> + </listitem> + + <listitem> + <para>The generator should always include its own name in a comment at the top of the generated file, + so that the user can easily figure out which component created or amended a particular unit.</para> + + <para>The <varname>SourcePath=</varname> directive should be used in generated files to specify the + source configuration file they are generated from. This makes things more easily understood by the + user and also has the benefit that systemd can warn the user about configuration files that changed + on disk but have not been read yet by systemd. The <varname>SourcePath=</varname> value does not have + to be a file in a physical filesystem. For example, in the common case of the generator looking at + the kernel command line, <option>SourcePath=/proc/cmdline</option> should be used.</para> + </listitem> + + <listitem> + <para>Generators may write out dynamic unit files or just hook unit files + into other units with the usual <filename>.wants/</filename> or + <filename>.requires/</filename> symlinks. Often, it is nicer to simply + instantiate a template unit file from <filename>/usr/</filename> with a + generator instead of writing out entirely dynamic unit files. Of course, this + works only if a single parameter is to be used.</para> + </listitem> + + <listitem> + <para>If you are careful, you can implement generators in shell scripts. We + do recommend C code however, since generators are executed synchronously and + hence delay the entire boot if they are slow.</para> + </listitem> + + <listitem> + <para>Regarding overriding semantics: there are two rules we try to follow + when thinking about the overriding semantics:</para> + + <orderedlist numeration="lowerroman"> + <listitem> + <para>User configuration should override vendor configuration. This + (mostly) means that stuff from <filename>/etc/</filename> should override + stuff from <filename>/usr/</filename>.</para> + </listitem> + + <listitem> + <para>Native configuration should override non-native configuration. This + (mostly) means that stuff you generate should never override native unit + files for the same purpose.</para> + </listitem> + </orderedlist> + + <para>Of these two rules the first rule is probably the more important one + and breaks the second one sometimes. Hence, when deciding whether to use + argv[1], argv[2], or argv[3], your default choice should probably be + argv[1].</para> + </listitem> + + <listitem> + <para>Instead of heading off now and writing all kind of generators for + legacy configuration file formats, please think twice! It is often a better + idea to just deprecate old stuff instead of keeping it artificially alive. + </para> + </listitem> + </itemizedlist> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>systemd-fstab-generator</title> + + <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + converts <filename>/etc/fstab</filename> into native mount units. It uses + argv[1] as location to place the generated unit files in order to allow the + user to override <filename>/etc/fstab</filename> with their own native unit + files, but also to ensure that <filename>/etc/fstab</filename> overrides any + vendor default from <filename>/usr/</filename>.</para> + + <para>After editing <filename>/etc/fstab</filename>, the user should invoke + <command>systemctl daemon-reload</command>. This will re-run all generators and + cause <command>systemd</command> to reload units from disk. To actually mount + new directories added to <filename>fstab</filename>, <command>systemctl start + <replaceable>/path/to/mountpoint</replaceable></command> or <command>systemctl + start local-fs.target</command> may be used.</para> + </example> + + <example> + <title>systemd-system-update-generator</title> + + <para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + temporarily redirects <filename>default.target</filename> to + <filename>system-update.target</filename>, if a system update is + scheduled. Since this needs to override the default user configuration for + <filename>default.target</filename>, it uses argv[2]. For details about this + logic, see + <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </example> + + <example> + <title>Debugging a generator</title> + + <programlisting>dir=$(mktemp -d) +SYSTEMD_LOG_LEVEL=debug &systemgeneratordir;/systemd-fstab-generator \ + "$dir" "$dir" "$dir" +find $dir</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-rc-local-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml new file mode 100644 index 0000000..578e074 --- /dev/null +++ b/man/systemd.journal-fields.xml @@ -0,0 +1,586 @@ +<?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-or-later --> + +<refentry id="systemd.journal-fields"> + + <refentryinfo> + <title>systemd.journal-fields</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.journal-fields</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.journal-fields</refname> + <refpurpose>Special journal fields</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>Entries in the journal (as written by + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>) + resemble a UNIX process environment block in syntax but with fields that may include binary data. + Primarily, fields are formatted UTF-8 text strings, and binary encoding is used only where formatting as + UTF-8 text strings makes little sense. New fields may freely be defined by applications, but a few fields + have special meanings. All fields with special meanings are optional. In some cases, fields may appear + more than once per entry.</para> + </refsect1> + + <refsect1> + <title>User Journal Fields</title> + + <para>User fields are fields that are directly passed from clients + and stored in the journal.</para> + + <variablelist class='journal-directives'> + <varlistentry> + <term><varname>MESSAGE=</varname></term> + <listitem> + <para>The human-readable message string for this entry. This + is supposed to be the primary text shown to the user. It is + usually not translated (but might be in some cases), and is + not supposed to be parsed for metadata.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MESSAGE_ID=</varname></term> + <listitem> + <para>A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This + should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or + suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted + differently. Developers can generate a new ID for this purpose with <command>systemd-id128 new</command>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PRIORITY=</varname></term> + <listitem> + <para>A priority value between 0 (<literal>emerg</literal>) + and 7 (<literal>debug</literal>) formatted as a decimal + string. This field is compatible with syslog's priority + concept.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CODE_FILE=</varname></term> + <term><varname>CODE_LINE=</varname></term> + <term><varname>CODE_FUNC=</varname></term> + <listitem> + <para>The code location generating this message, if known. + Contains the source filename, the line number and the + function name.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ERRNO=</varname></term> + <listitem> + <para>The low-level Unix error number causing this entry, if + any. Contains the numeric value of + <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> + formatted as a decimal string.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>INVOCATION_ID=</varname></term> + <term><varname>USER_INVOCATION_ID=</varname></term> + <listitem> + <para>A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from + <varname>_SYSTEMD_INVOCATION_ID</varname> in that it is only used for messages coming from systemd code + (e.g. logs from the system/user manager or from forked processes performing systemd-related setup).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYSLOG_FACILITY=</varname></term> + <term><varname>SYSLOG_IDENTIFIER=</varname></term> + <term><varname>SYSLOG_PID=</varname></term> + <term><varname>SYSLOG_TIMESTAMP=</varname></term> + <listitem> + <para>Syslog compatibility fields containing the facility (formatted as + decimal string), the identifier string (i.e. "tag"), the client PID, and + the timestamp as specified in the original datagram. (Note that the tag is + 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> + + <varlistentry> + <term><varname>SYSLOG_RAW=</varname></term> + <listitem> + <para>The original contents of the syslog line as received in the syslog + datagram. This field is only included if the <varname>MESSAGE=</varname> + field was modified compared to the original payload or the timestamp could + not be located properly and is not included in + <varname>SYSLOG_TIMESTAMP=</varname>. Message truncation occurs when when + the message contains leading or trailing whitespace (trailing and leading + whitespace is stripped), or it contains an embedded + <constant>NUL</constant> byte (the <constant>NUL</constant> byte and + anything after it is not included). Thus, the original syslog line is + either stored as <varname>SYSLOG_RAW=</varname> or it can be recreated + based on the stored priority and facility, timestamp, identifier, and the + message payload in <varname>MESSAGE=</varname>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DOCUMENTATION=</varname></term> + <listitem> + <para>A documentation URL with further information about the topic of the log message. Tools such + as <command>journalctl</command> will include a hyperlink to an URL specified this way in their + output. Should be a <literal>http://</literal>, <literal>https://</literal>, + <literal>file:/</literal>, <literal>man:</literal> or <literal>info:</literal> URL.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TID=</varname></term> + <listitem> + <para>The numeric thread ID (TID) the log message originates from.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Trusted Journal Fields</title> + + <para>Fields prefixed with an underscore are trusted fields, i.e. + fields that are implicitly added by the journal and cannot be + altered by client code.</para> + + <variablelist class='journal-directives'> + <varlistentry> + <term><varname>_PID=</varname></term> + <term><varname>_UID=</varname></term> + <term><varname>_GID=</varname></term> + <listitem> + <para>The process, user, and group ID of the process the + journal entry originates from formatted as a decimal + string. Note that entries obtained via <literal>stdout</literal> or + <literal>stderr</literal> of forked processes will contain credentials valid for a parent + process (that initiated the connection to <command>systemd-journald</command>).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_COMM=</varname></term> + <term><varname>_EXE=</varname></term> + <term><varname>_CMDLINE=</varname></term> + <listitem> + <para>The name, the executable path, and the command line of + the process the journal entry originates from.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_CAP_EFFECTIVE=</varname></term> + <listitem> + <para>The effective + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + of the process the journal entry originates from.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_AUDIT_SESSION=</varname></term> + <term><varname>_AUDIT_LOGINUID=</varname></term> + <listitem> + <para>The session and login UID of the process the journal + entry originates from, as maintained by the kernel audit + subsystem.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_SYSTEMD_CGROUP=</varname></term> + <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> + + <listitem> + <para>The control group path in the systemd hierarchy, the systemd slice unit name, the systemd + unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and + the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry + originates from.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_SELINUX_CONTEXT=</varname></term> + <listitem> + <para>The SELinux security context (label) of the process + the journal entry originates from.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term> + <listitem> + <para>The earliest trusted timestamp of the message, if any + is known that is different from the reception time of the + journal. This is the time in microseconds since the epoch + UTC, formatted as a decimal string.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_BOOT_ID=</varname></term> + <listitem> + <para>The kernel boot ID for the boot the message was + generated in, formatted as a 128-bit hexadecimal + string.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_MACHINE_ID=</varname></term> + <listitem> + <para>The machine ID of the originating host, as available + in + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_SYSTEMD_INVOCATION_ID=</varname></term> + <listitem> + <para>The invocation ID for the runtime cycle of the unit + the message was generated in, as available to processes + of the unit in <varname>$INVOCATION_ID</varname> (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_HOSTNAME=</varname></term> + <listitem> + <para>The name of the originating host.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>_TRANSPORT=</varname></term> + <listitem> + <para>How the entry was received by the journal service. + Valid transports are: + </para> + <variablelist> + <varlistentry> + <term> + <option>audit</option> + </term> + <listitem> + <para>for those read from the kernel audit subsystem + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>driver</option> + </term> + <listitem> + <para>for internally generated messages + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>syslog</option> + </term> + <listitem> + <para>for those received via the local syslog socket + with the syslog protocol + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>journal</option> + </term> + <listitem> + <para>for those received via the native journal + protocol + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>stdout</option> + </term> + <listitem> + <para>for those read from a service's standard output + or error output + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>kernel</option> + </term> + <listitem> + <para>for those read from the kernel + </para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_STREAM_ID=</varname></term> + <listitem> + <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: specifies a randomized 128bit ID assigned + to the stream connection when it was first created. This ID is useful to reconstruct individual log streams + from the log records: all log records carrying the same stream ID originate from the same stream.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_LINE_BREAK=</varname></term> + <listitem> + <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: indicates that the log message + in the standard output/error stream was not terminated with a normal newline character + (<literal>\n</literal>, i.e. ASCII 10). Specifically, when set this field is one of + <option>nul</option> (in case the line was terminated by a <constant>NUL</constant> byte), <option>line-max</option> (in + case the maximum log line length was reached, as configured with <varname>LineMax=</varname> in + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>), + <option>eof</option> (if this was the last log record of a stream and the stream ended without a + final newline character), or <option>pid-change</option> (if the process which generated the log + output changed in the middle of a line). Note that this record is not generated when a normal + newline character was used for marking the log line end.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_NAMESPACE=</varname></term> + + <listitem><para>If this file was written by a <command>systemd-journald</command> instance managing a + journal namespace that is not the default, this field contains the namespace identifier. See + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details about journal namespaces.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Kernel Journal Fields</title> + + <para>Kernel fields are fields that are used by messages + originating in the kernel and stored in the journal.</para> + + <variablelist class='journal-directives'> + <varlistentry> + <term><varname>_KERNEL_DEVICE=</varname></term> + <listitem> + <para>The kernel device name. If the entry is associated to a block device, contains the major and + minor numbers of the device node, separated by <literal>:</literal> and prefixed by + <literal>b</literal>. Similarly for character devices, but prefixed by <literal>c</literal>. For + network devices, this is the interface index prefixed by <literal>n</literal>. For all other + devices, this is the subsystem name prefixed by <literal>+</literal>, followed by + <literal>:</literal>, followed by the kernel device name.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_KERNEL_SUBSYSTEM=</varname></term> + <listitem> + <para>The kernel subsystem name.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_UDEV_SYSNAME=</varname></term> + <listitem> + <para>The kernel device name as it shows up in the device + tree below <filename>/sys/</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_UDEV_DEVNODE=</varname></term> + <listitem> + <para>The device node path of this device in + <filename>/dev/</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>_UDEV_DEVLINK=</varname></term> + <listitem> + <para>Additional symlink names pointing to the device node + in <filename>/dev/</filename>. This field is frequently set + more than once per entry.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Fields to log on behalf of a different program</title> + + <para>Fields in this section are used by programs to specify that + they are logging on behalf of another program or unit. + </para> + + <para>Fields used by the <command>systemd-coredump</command> + coredump kernel helper: + </para> + + <variablelist class='journal-directives'> + <varlistentry> + <term><varname>COREDUMP_UNIT=</varname></term> + <term><varname>COREDUMP_USER_UNIT=</varname></term> + <listitem> + <para>Used to annotate messages containing coredumps from + system and session units. See + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + </variablelist> + + <para>Privileged programs (currently UID 0) may attach + <varname>OBJECT_PID=</varname> to a message. This will instruct + <command>systemd-journald</command> to attach additional fields on + behalf of the caller:</para> + + <variablelist class='journal-directives'> + <varlistentry> + <term><varname>OBJECT_PID=<replaceable>PID</replaceable></varname></term> + <listitem> + <para>PID of the program that this message pertains to. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>OBJECT_UID=</varname></term> + <term><varname>OBJECT_GID=</varname></term> + <term><varname>OBJECT_COMM=</varname></term> + <term><varname>OBJECT_EXE=</varname></term> + <term><varname>OBJECT_CMDLINE=</varname></term> + <term><varname>OBJECT_AUDIT_SESSION=</varname></term> + <term><varname>OBJECT_AUDIT_LOGINUID=</varname></term> + <term><varname>OBJECT_SYSTEMD_CGROUP=</varname></term> + <term><varname>OBJECT_SYSTEMD_SESSION=</varname></term> + <term><varname>OBJECT_SYSTEMD_OWNER_UID=</varname></term> + <term><varname>OBJECT_SYSTEMD_UNIT=</varname></term> + <term><varname>OBJECT_SYSTEMD_USER_UNIT=</varname></term> + <listitem> + <para>These are additional fields added automatically by + <command>systemd-journald</command>. Their meaning is the + same as + <varname>_UID=</varname>, + <varname>_GID=</varname>, + <varname>_COMM=</varname>, + <varname>_EXE=</varname>, + <varname>_CMDLINE=</varname>, + <varname>_AUDIT_SESSION=</varname>, + <varname>_AUDIT_LOGINUID=</varname>, + <varname>_SYSTEMD_CGROUP=</varname>, + <varname>_SYSTEMD_SESSION=</varname>, + <varname>_SYSTEMD_UNIT=</varname>, + <varname>_SYSTEMD_USER_UNIT=</varname>, and + <varname>_SYSTEMD_OWNER_UID=</varname> + as described above, except that the process identified by + <replaceable>PID</replaceable> is described, instead of the + process which logged the message.</para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>Address Fields</title> + + <para>During serialization into external formats, such as the + <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/export">Journal + Export Format</ulink> or the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/json">Journal + JSON Format</ulink>, the addresses of journal entries are + serialized into fields prefixed with double underscores. Note that + these are not proper fields when stored in the journal but for + addressing metadata of entries. They cannot be written as part of + structured log entries via calls such as + <citerefentry><refentrytitle>sd_journal_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + They may also not be used as matches for + <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + </para> + + <variablelist class='journal-directives'> + <varlistentry> + <term><varname>__CURSOR=</varname></term> + <listitem> + <para>The cursor for the entry. A cursor is an opaque text + string that uniquely describes the position of an entry in + the journal and is portable across machines, platforms and + journal files. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>__REALTIME_TIMESTAMP=</varname></term> + <listitem> + <para>The wallclock time + (<constant>CLOCK_REALTIME</constant>) at the point in time + the entry was received by the journal, in microseconds since + the epoch UTC, formatted as a decimal string. This has + different properties from + <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is + usually a bit later but more likely to be monotonic. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>__MONOTONIC_TIMESTAMP=</varname></term> + <listitem> + <para>The monotonic time + (<constant>CLOCK_MONOTONIC</constant>) at the point in time + the entry was received by the journal in microseconds, + formatted as a decimal string. To be useful as an address + for the entry, this should be combined with the boot ID in + <literal>_BOOT_ID=</literal>. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml new file mode 100644 index 0000000..57eb640 --- /dev/null +++ b/man/systemd.kill.xml @@ -0,0 +1,188 @@ +<?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-or-later --> + +<refentry id="systemd.kill"> + <refentryinfo> + <title>systemd.kill</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.kill</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.kill</refname> + <refpurpose>Process killing procedure + configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>service</replaceable>.service</filename>, + <filename><replaceable>socket</replaceable>.socket</filename>, + <filename><replaceable>mount</replaceable>.mount</filename>, + <filename><replaceable>swap</replaceable>.swap</filename>, + <filename><replaceable>scope</replaceable>.scope</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Unit configuration files for services, sockets, mount + points, swap devices and scopes share a subset of configuration + options which define the killing procedure of processes belonging + to the unit.</para> + + <para>This man page lists the configuration options shared by + these five unit types. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options shared by all unit configuration files, and + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information on the configuration file options specific to + each unit type.</para> + + <para>The kill procedure configuration options are configured in + the [Service], [Socket], [Mount] or [Swap] section, depending on + the unit type.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>KillMode=</varname></term> + <listitem><para>Specifies how processes of this unit shall be killed. One of + <option>control-group</option>, <option>mixed</option>, <option>process</option>, + <option>none</option>.</para> + + <para>If set to <option>control-group</option>, all remaining processes in the control group of this + unit will be killed on unit stop (for services: after the stop command is executed, as configured + with <varname>ExecStop=</varname>). If set to <option>mixed</option>, the + <constant>SIGTERM</constant> signal (see below) is sent to the main process while the subsequent + <constant>SIGKILL</constant> signal (see below) is sent to all remaining processes of the unit's + control group. If set to <option>process</option>, only the main process itself is killed (not + recommended!). If set to <option>none</option>, no process is killed (strongly recommended + against!). In this case, only the stop command will be 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 empty.</para> + + <para>Note that it is not recommended to set <varname>KillMode=</varname> to + <constant>process</constant> or even <constant>none</constant>, as this allows processes to escape + the service manager's lifecycle and resource management, and to remain running even while their + service is considered stopped and is assumed to not consume any resources.</para> + + <para>Processes will first be terminated via <constant>SIGTERM</constant> (unless the signal to send + is changed via <varname>KillSignal=</varname> or <varname>RestartKillSignal=</varname>). Optionally, + this is immediately followed by a <constant>SIGHUP</constant> (if enabled with + <varname>SendSIGHUP=</varname>). If processes still remain after the main process of a unit has + exited or the delay configured via the <varname>TimeoutStopSec=</varname> has passed, the termination + request is repeated with the <constant>SIGKILL</constant> signal or the signal specified via + <varname>FinalKillSignal=</varname> (unless this is disabled via the <varname>SendSIGKILL=</varname> + option). See <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for more information.</para> + + <para>Defaults to <option>control-group</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>KillSignal=</varname></term> + <listitem><para>Specifies which signal to use when stopping a service. This controls the signal that + is sent as first step of shutting down a unit (see above), and is usually followed by + <constant>SIGKILL</constant> (see above and below). For a list of valid signals, see + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + Defaults to <constant>SIGTERM</constant>.</para> + + <para>Note that, right after sending the signal specified in this setting, systemd will always send + <constant>SIGCONT</constant>, to ensure that even suspended tasks can be terminated cleanly.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestartKillSignal=</varname></term> + <listitem><para>Specifies which signal to use when restarting a service. The same as + <varname>KillSignal=</varname> described above, with the exception that this setting is used in a + restart job. Not set by default, and the value of <varname>KillSignal=</varname> is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendSIGHUP=</varname></term> + <listitem><para>Specifies whether to send + <constant>SIGHUP</constant> to remaining processes immediately + after sending the signal configured with + <varname>KillSignal=</varname>. This is useful to indicate to + shells and shell-like programs that their connection has been + severed. Takes a boolean value. Defaults to "no". + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendSIGKILL=</varname></term> + <listitem><para>Specifies whether to send + <constant>SIGKILL</constant> (or the signal specified by + <varname>FinalKillSignal=</varname>) to remaining processes + after a timeout, if the normal shutdown procedure left + processes of the service around. When disabled, a + <varname>KillMode=</varname> of <constant>control-group</constant> + or <constant>mixed</constant> service will not restart if + processes from prior services exist within the control group. + Takes a boolean value. Defaults to "yes". + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FinalKillSignal=</varname></term> + <listitem><para>Specifies which signal to send to remaining + processes after a timeout if <varname>SendSIGKILL=</varname> + is enabled. The signal configured here should be one that is + not typically caught and processed by services (<constant>SIGTERM</constant> + is not suitable). Developers can find it useful to use this to + generate a coredump to troubleshoot why a service did not + terminate upon receiving the initial <constant>SIGTERM</constant> + signal. This can be achieved by configuring <varname>LimitCORE=</varname> + and setting <varname>FinalKillSignal=</varname> to either + <constant>SIGQUIT</constant> or <constant>SIGABRT</constant>. + Defaults to <constant>SIGKILL</constant>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WatchdogSignal=</varname></term> + <listitem><para>Specifies which signal to use to terminate the + service when the watchdog timeout expires (enabled through + <varname>WatchdogSec=</varname>). Defaults to <constant>SIGABRT</constant>. + </para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.link.xml b/man/systemd.link.xml new file mode 100644 index 0000000..24271ea --- /dev/null +++ b/man/systemd.link.xml @@ -0,0 +1,889 @@ +<?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-or-later --> + +<refentry id="systemd.link"> + <refentryinfo> + <title>systemd.link</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.link</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.link</refname> + <refpurpose>Network device configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>link</replaceable>.link</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A plain ini-style text file that encodes configuration for matching network devices, used by + <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry> and in + particular its <command>net_setup_link</command> builtin. See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a + general description of the syntax.</para> + + <para>The link files are read from the files located in the system + network directory <filename>/usr/lib/systemd/network</filename>, + the volatile runtime network directory + <filename>/run/systemd/network</filename>, and the local + administration network directory + <filename>/etc/systemd/network</filename>. Link files must have + the extension <filename>.link</filename>; other extensions are + ignored. All link files are collectively sorted and processed in + lexical order, regardless of the directories in which they live. + However, files with identical filenames replace each other. Files + in <filename>/etc/</filename> have the highest priority, files in + <filename>/run/</filename> take precedence over files with the same + name in <filename>/usr/lib/</filename>. This can be used to + override a system-supplied link file with a local file if needed. + As a special case, an empty file (file size 0) or symlink with the + same name pointing to <filename>/dev/null</filename> disables the + configuration file entirely (it is "masked").</para> + + <para>The link file contains a [Match] section, which determines if a given link file may be applied to a + given device, as well as a [Link] section specifying how the device should be configured. The first (in + lexical order) of the link files that matches a given device is applied. Note that a default file + <filename>99-default.link</filename> is shipped by the system. Any user-supplied + <filename>.link</filename> should hence have a lexically earlier name to be considered at all.</para> + + <para>See <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + diagnosing problems with <filename>.link</filename> files.</para> + </refsect1> + + <refsect1> + <title>[Match] Section Options</title> + + <para>A link file is said to match a device if all matches specified by the + [Match] section are satisfied. When a link file does not contain valid settings + in [Match] 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'> + <!-- This list is reused in systemd.network(3), hence maintain a specific order: + 1. device matches shared between the two lists + 2. non-shared settings + 3. host matches shared between the two lists + --> + + <varlistentry id='mac-address'> + <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 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: + <programlisting>MACAddress=01:23:45:67:89:ab 00-11-22-33-44-55 AABB.CCDD.EEFF</programlisting></para> + </listitem> + </varlistentry> + + <varlistentry id='permanent-mac-address'> + <term><varname>PermanentMACAddress=</varname></term> + <listitem> + <para>A whitespace-separated list of hardware's permanent addresses. While + <varname>MACAddress=</varname> matches the device's current MAC address, this matches the + device's permanent MAC address, which may be different from the current one. Use full + colon-, hyphen- or dot-delimited hexadecimal. 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> + </listitem> + </varlistentry> + + <varlistentry id='path'> + <term><varname>Path=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching + the persistent path, as exposed by the udev property + <varname>ID_PATH</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry id='driver'> + <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>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. + If the list is prefixed with a "!", the test is inverted.</para> + </listitem> + </varlistentry> + + <varlistentry id='type'> + <term><varname>Type=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching the device type, as exposed by + <command>networkctl status</command>. If the list is prefixed with a "!", the test is inverted. + </para> + </listitem> + </varlistentry> + + <varlistentry id='property'> + <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>OriginalName=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching the device name, as exposed by the + udev property "INTERFACE". This cannot be used to match on names that have already been changed + from userspace. Caution is advised when matching on kernel-assigned names, as they are known to be + unstable between reboots.</para> + </listitem> + </varlistentry> + + <varlistentry id='host'> + <term><varname>Host=</varname></term> + <listitem> + <para>Matches against the hostname or machine ID of the host. See <varname>ConditionHost=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + + <varlistentry id='virtualization'> + <term><varname>Virtualization=</varname></term> + <listitem> + <para>Checks whether the system is executed in a virtualized environment and optionally test + whether it is a specific implementation. See <varname>ConditionVirtualization=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + + <varlistentry id='kernel-command-line'> + <term><varname>KernelCommandLine=</varname></term> + <listitem> + <para>Checks whether a specific kernel command line option is set. See + <varname>ConditionKernelCommandLine=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + + <varlistentry id='kernel-version'> + <term><varname>KernelVersion=</varname></term> + <listitem> + <para>Checks whether the kernel version (as reported by <command>uname -r</command>) matches a certain + expression. See <varname>ConditionKernelVersion=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + + <varlistentry id='architecture'> + <term><varname>Architecture=</varname></term> + <listitem> + <para>Checks whether the system is running on a specific architecture. See + <varname>ConditionArchitecture=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>[Link] Section Options</title> + + <para>The [Link] section accepts the following + keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Description=</varname></term> + <listitem> + <para>A description of the device.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Alias=</varname></term> + <listitem> + <para>The <varname>ifalias</varname> interface property is set to this value.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddressPolicy=</varname></term> + <listitem> + <para>The policy by which the MAC address should be set. The + available policies are: + </para> + + <variablelist> + <varlistentry> + <term><option>persistent</option></term> + <listitem> + <para>If the hardware has a persistent MAC address, as + most hardware should, and if it is used by the kernel, + nothing is done. Otherwise, a new MAC address is + generated which is guaranteed to be the same on every + boot for the given machine and the given device, but + which is otherwise random. This feature depends on ID_NET_NAME_* + properties to exist for the link. On hardware where these + properties are not set, the generation of a persistent MAC address + will fail.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>random</option></term> + <listitem> + <para>If the kernel is using a random MAC address, + nothing is done. Otherwise, a new address is randomly + generated each time the device appears, typically at + boot. Either way, the random address will have the + <literal>unicast</literal> and + <literal>locally administered</literal> bits set.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>none</option></term> + <listitem> + <para>Keeps the MAC address assigned by the kernel. Or use the MAC address specified in + <varname>MACAddress=</varname>.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>An empty string assignment is equivalent to setting <literal>none</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The interface MAC address to use. For this setting to take effect, + <varname>MACAddressPolicy=</varname> must either be unset, empty, or <literal>none</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>NamePolicy=</varname></term> + <listitem> + <para>An ordered, space-separated list of policies by which the interface name should be set. + <varname>NamePolicy=</varname> may be disabled by specifying <option>net.ifnames=0</option> on the + kernel command line. Each of the policies may fail, and the first successful one is used. The name + is not set directly, but is exported to udev as the property <option>ID_NET_NAME</option>, which + is, by default, used by a + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + rule to set <varname>NAME</varname>. The available policies are: + </para> + + <variablelist> + <varlistentry> + <term><option>kernel</option></term> + <listitem> + <para>If the kernel claims that the name it has set + for a device is predictable, then no renaming is + performed.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>database</option></term> + <listitem> + <para>The name is set based on entries in the udev's + Hardware Database with the key + <varname>ID_NET_NAME_FROM_DATABASE</varname>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>onboard</option></term> + <listitem> + <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> + <varlistentry> + <term><option>slot</option></term> + <listitem> + <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> + <varlistentry> + <term><option>path</option></term> + <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>. + See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>mac</option></term> + <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>. + See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>keep</option></term> + <listitem> + <para>If the device already had a name given by userspace (as part of creation of the device + or a rename), keep it.</para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>The interface name to use. This option has lower precedence than + <varname>NamePolicy=</varname>, so for this setting to take effect, <varname>NamePolicy=</varname> + must either be unset, empty, disabled, or all policies configured there must fail. Also see the + example below with <literal>Name=dmz0</literal>.</para> + + <para>Note that specifying a name that the kernel might use for another + interface (for example <literal>eth0</literal>) is dangerous because the + name assignment done by udev will race with the assignment done by the + kernel, and only one interface may use the name. Depending on the order of + operations, either udev or the kernel will win, making the naming + unpredictable. It is best to use some different prefix, for example + <literal>internal0</literal>/<literal>external0</literal> or + <literal>lan0</literal>/<literal>lan1</literal>/<literal>lan3</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AlternativeNamesPolicy=</varname></term> + <listitem> + <para>A space-separated list of policies by which the interface's alternative names + should be set. Each of the policies may fail, and all successful policies are used. The + available policies are <literal>database</literal>, <literal>onboard</literal>, + <literal>slot</literal>, <literal>path</literal>, and <literal>mac</literal>. If the + kernel does not support the alternative names, then this setting will be ignored. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AlternativeName=</varname></term> + <listitem> + <para>The alternative interface name to use. This option can be specified multiple times. + If the empty string is assigned to this option, the list is reset, and all prior assignments + have no effect. If the kernel does not support the alternative names, then this setting will + be ignored.</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.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>BitsPerSecond=</varname></term> + <listitem> + <para>The speed to set for the device, the value is rounded + down to the nearest Mbps. The usual suffixes K, M, G, are + supported and are understood to the base of 1000.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Duplex=</varname></term> + <listitem> + <para>The duplex mode to set for the device. The accepted values are <option>half</option> and + <option>full</option>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AutoNegotiation=</varname></term> + <listitem> + <para>Takes a boolean. If set to yes, automatic negotiation of transmission parameters is enabled. + Autonegotiation is a procedure by which two connected ethernet devices choose + common transmission parameters, such as speed, duplex mode, and flow control. + When unset, the kernel's default will be used.</para> + + <para>Note that if autonegotiation is enabled, speed and duplex settings are + read-only. If autonegotiation is disabled, speed and duplex settings are writable + if the driver supports multiple link modes.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>WakeOnLan=</varname></term> + <listitem> + <para>The Wake-on-LAN policy to set for the device. The + supported values are:</para> + + <variablelist> + <varlistentry> + <term><option>phy</option></term> + <listitem> + <para>Wake on PHY activity.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>unicast</option></term> + <listitem> + <para>Wake on unicast messages.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>multicast</option></term> + <listitem> + <para>Wake on multicast messages.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>broadcast</option></term> + <listitem> + <para>Wake on broadcast messages.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>arp</option></term> + <listitem> + <para>Wake on ARP.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>magic</option></term> + <listitem> + <para>Wake on receipt of a magic packet. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>secureon</option></term> + <listitem> + <para>Enable secureon(tm) password for MagicPacket(tm). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>off</option></term> + <listitem> + <para>Never wake.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>Defaults to <option>off</option>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Port=</varname></term> + <listitem> + <para>The port option is used to select the device port. The + supported values are:</para> + + <variablelist> + <varlistentry> + <term><option>tp</option></term> + <listitem> + <para>An Ethernet interface using Twisted-Pair cable as the medium.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>aui</option></term> + <listitem> + <para>Attachment Unit Interface (AUI). Normally used with hubs. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>bnc</option></term> + <listitem> + <para>An Ethernet interface using BNC connectors and co-axial cable.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>mii</option></term> + <listitem> + <para>An Ethernet interface using a Media Independent Interface (MII).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>fibre</option></term> + <listitem> + <para>An Ethernet interface using Optical Fibre as the medium.</para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Advertise=</varname></term> + <listitem> + <para>This sets what speeds and duplex modes of operation are advertised for auto-negotiation. + This implies <literal>AutoNegotiation=yes</literal>. The supported values are: + + <table> + <title>Supported advertise values</title> + <tgroup cols='3'> + <colspec colname='Advertise' /> + <colspec colname='Speed' /> + <colspec colname='Duplex Mode' /> + + <thead><row> + <entry>Advertise</entry> + <entry>Speed (Mbps)</entry> + <entry>Duplex Mode</entry> + </row></thead> + <tbody> + <row><entry><option>10baset-half</option></entry> + <entry>10</entry><entry>half</entry></row> + + <row><entry><option>10baset-full</option></entry> + <entry>10</entry><entry>full</entry></row> + + <row><entry><option>100baset-half</option></entry> + <entry>100</entry><entry>half</entry></row> + + <row><entry><option>100baset-full</option></entry> + <entry>100</entry><entry>full</entry></row> + + <row><entry><option>1000baset-half</option></entry> + <entry>1000</entry><entry>half</entry></row> + + <row><entry><option>1000baset-full</option></entry> + <entry>1000</entry><entry>full</entry></row> + + <row><entry><option>10000baset-full</option></entry> + <entry>10000</entry><entry>full</entry></row> + + <row><entry><option>2500basex-full</option></entry> + <entry>2500</entry><entry>full</entry></row> + + <row><entry><option>1000basekx-full</option></entry> + <entry>1000</entry><entry>full</entry></row> + + <row><entry><option>10000basekx4-full</option></entry> + <entry>10000</entry><entry>full</entry></row> + + <row><entry><option>10000basekr-full</option></entry> + <entry>10000</entry><entry>full</entry></row> + + <row><entry><option>10000baser-fec</option></entry> + <entry>10000</entry><entry>full</entry></row> + + <row><entry><option>20000basemld2-full</option></entry> + <entry>20000</entry><entry>full</entry></row> + + <row><entry><option>20000basekr2-full</option></entry> + <entry>20000</entry><entry>full</entry></row> + </tbody> + </tgroup> + </table> + + By default this is unset, i.e. all possible modes will be advertised. + This option may be specified more than once, in which case all specified speeds and modes are advertised. + If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ReceiveChecksumOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the hardware offload for checksumming of ingress + network packets is enabled. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TransmitChecksumOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the hardware offload for checksumming of egress + network packets is enabled. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TCPSegmentationOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the TCP Segmentation Offload (TSO) is enabled. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TCP6SegmentationOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the TCP6 Segmentation Offload (tx-tcp6-segmentation) is enabled. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GenericSegmentationOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the Generic Segmentation Offload (GSO) is enabled. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GenericReceiveOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the Generic Receive Offload (GRO) is enabled. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LargeReceiveOffload=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the Large Receive Offload (LRO) is enabled. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RxChannels=</varname></term> + <listitem> + <para>Sets the number of receive channels (a number between 1 and 4294967295) .</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TxChannels=</varname></term> + <listitem> + <para>Sets the number of transmit channels (a number between 1 and 4294967295).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>OtherChannels=</varname></term> + <listitem> + <para>Sets the number of other channels (a number between 1 and 4294967295).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>CombinedChannels=</varname></term> + <listitem> + <para>Sets the number of combined set channels (a number between 1 and 4294967295).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RxBufferSize=</varname></term> + <listitem> + <para>Takes an integer. Specifies the maximum number of pending packets in the NIC receive buffer. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RxMiniBufferSize=</varname></term> + <listitem> + <para>Takes an integer. Specifies the maximum number of pending packets in the NIC mini receive buffer. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RxJumboBufferSize=</varname></term> + <listitem> + <para>Takes an integer. Specifies the maximum number of pending packets in the NIC jumbo receive buffer. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TxBufferSize=</varname></term> + <listitem> + <para>Takes an integer. Specifies the maximum number of pending packets in the NIC transmit buffer. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RxFlowControl=</varname></term> + <listitem> + <para>Takes a boolean. When set, enables the receive flow control, also known as the ethernet + receive PAUSE message (generate and send ethernet PAUSE frames). When unset, the kernel's + default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TxFlowControl=</varname></term> + <listitem> + <para>Takes a boolean. When set, enables the transmit flow control, also known as the ethernet + transmit PAUSE message (respond to received ethernet PAUSE frames). When unset, the kernel's + default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AutoNegotiationFlowControl=</varname></term> + <listitem> + <para>Takes a boolean. When set, the auto negotiation enables the interface to exchange state + advertisements with the connected peer so that the two devices can agree on the ethernet + PAUSE configuration. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>/usr/lib/systemd/network/99-default.link</title> + + <para>The link file <filename>99-default.link</filename> that is + shipped with systemd defines the default naming policy for + links.</para> + + <programlisting>[Link] +NamePolicy=kernel database onboard slot path +MACAddressPolicy=persistent</programlisting> + </example> + + <example> + <title>/etc/systemd/network/10-dmz.link</title> + + <para>This example assigns the fixed name <literal>dmz0</literal> to the interface with the MAC address + 00:a0:de:63:7a:e6:</para> + + <programlisting>[Match] +MACAddress=00:a0:de:63:7a:e6 + +[Link] +Name=dmz0</programlisting> + + <para><varname>NamePolicy=</varname> is not set, so <varname>Name=</varname> takes effect. We use the + <literal>10-</literal> prefix to order this file early in the list. Note that it needs to be before + <literal>99-link</literal>, i.e. it needs a numerical prefix, to have any effect at all.</para> + </example> + + <example> + <title>Debugging <varname>NamePolicy=</varname> assignments</title> + + <programlisting>$ sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/hub0 +… +Parsed configuration file /usr/lib/systemd/network/99-default.link +Parsed configuration file /etc/systemd/network/10-eth0.link +ID_NET_DRIVER=cdc_ether +Config file /etc/systemd/network/10-eth0.link applies to device hub0 +link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. +hub0: Device has name_assign_type=4 +Using default interface naming scheme 'v240'. +hub0: Policies didn't yield a name, using specified Name=hub0. +ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link +ID_NET_NAME=hub0 +…</programlisting> + + <para>Explicit <varname>Name=</varname> configuration wins in this case.</para> + + <programlisting>sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/enp0s31f6 +… +Parsed configuration file /usr/lib/systemd/network/99-default.link +Parsed configuration file /etc/systemd/network/10-eth0.link +Created link configuration context. +ID_NET_DRIVER=e1000e +Config file /usr/lib/systemd/network/99-default.link applies to device enp0s31f6 +link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. +enp0s31f6: Device has name_assign_type=4 +Using default interface naming scheme 'v240'. +enp0s31f6: Policy *keep*: keeping existing userspace name +enp0s31f6: Device has addr_assign_type=0 +enp0s31f6: MAC on the device already matches policy *persistent* +ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link +… +</programlisting> + + <para>In this case, the interface was already renamed, so the <option>keep</option> policy specified as + the first option in <filename index="false">99-default.link</filename> means that the existing name is + preserved. If <option>keep</option> was removed, or if were in boot before the renaming has happened, + we might get the following instead:</para> + + <programlisting>enp0s31f6: Policy *path* yields "enp0s31f6". +enp0s31f6: Device has addr_assign_type=0 +enp0s31f6: MAC on the device already matches policy *persistent* +ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link +ID_NET_NAME=enp0s31f6 +… +</programlisting> + + <para>Please note that the details of output are subject to change.</para> + </example> + + <example> + <title>/etc/systemd/network/10-internet.link</title> + + <para>This example assigns the fixed name + <literal>internet0</literal> to the interface with the device + path <literal>pci-0000:00:1a.0-*</literal>:</para> + + <programlisting>[Match] +Path=pci-0000:00:1a.0-* + +[Link] +Name=internet0</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-wireless.link</title> + + <para>Here's an overly complex example that shows the use of a large number of [Match] and [Link] settings.</para> + + <programlisting>[Match] +MACAddress=12:34:56:78:9a:bc +Driver=brcmsmac +Path=pci-0000:02:00.0-* +Type=wlan +Virtualization=no +Host=my-laptop +Architecture=x86-64 + +[Link] +Name=wireless0 +MTUBytes=1450 +BitsPerSecond=10M +WakeOnLan=magic +MACAddress=cb:a9:87:65:43:21</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry> + <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum> + </citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml new file mode 100644 index 0000000..8b71c96 --- /dev/null +++ b/man/systemd.mount.xml @@ -0,0 +1,597 @@ +<?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-or-later --> + +<refentry id="systemd.mount"> + <refentryinfo> + <title>systemd.mount</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.mount</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.mount</refname> + <refpurpose>Mount unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>mount</replaceable>.mount</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.mount</literal> encodes information about a file system + mount point controlled and supervised by systemd.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The mount specific configuration options are + configured in the [Mount] section.</para> + + <para>Additional options are listed in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the execution environment the + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> + program is executed in, and in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the way the processes are terminated, and in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which configure resource control settings for the processes of the + service.</para> + + <para>Note that the options <varname>User=</varname> and + <varname>Group=</varname> are not useful for mount units. + systemd passes two parameters to + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>; + the values of <varname>What=</varname> and <varname>Where=</varname>. + When invoked in this way, + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> + does not read any options from <filename>/etc/fstab</filename>, and + must be run as UID 0.</para> + + <para>Mount units must be named after the mount point directories they control. Example: the mount point <filename + index="false">/home/lennart</filename> must be configured in a unit file <filename>home-lennart.mount</filename>. + For details about the escaping logic used to convert a file system path to a unit name, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note that mount + units cannot be templated, nor is possible to add multiple names to a mount unit by creating additional symlinks to + it.</para> + + <para>Optionally, a mount unit may be accompanied by an automount + unit, to allow on-demand or parallelized mounting. See + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>Mount points created at runtime (independently of unit files + or <filename>/etc/fstab</filename>) will be monitored by systemd + and appear like any other mount unit in systemd. See + <filename>/proc/self/mountinfo</filename> description in + <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>Some file systems have special semantics as API file systems + for kernel-to-userspace and userspace-to-userspace interfaces. Some + of them may not be changed via mount units, and cannot be + disabled. For a longer discussion see <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems">API + File Systems</ulink>.</para> + + <para>The + <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry> command + allows creating <filename>.mount</filename> and <filename>.automount</filename> units dynamically and + transiently from the command line.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>If a mount unit is beneath another mount unit in the file + system hierarchy, both a requirement dependency and an ordering + dependency between both units are created automatically.</para></listitem> + + <listitem><para>Block device backed file systems automatically gain + <varname>BindsTo=</varname> and <varname>After=</varname> type + dependencies on the device unit encapsulating the block + device (see below).</para></listitem> + + <listitem><para>If traditional file system quota is enabled for a mount + unit, automatic <varname>Wants=</varname> and + <varname>Before=</varname> dependencies on + <filename>systemd-quotacheck.service</filename> and + <filename>quotaon.service</filename> are added.</para></listitem> + + <listitem><para>Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </itemizedlist> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>All mount units acquire automatic <varname>Before=</varname> and <varname>Conflicts=</varname> on + <filename>umount.target</filename> in order to be stopped during shutdown.</para></listitem> + + <listitem><para>Mount units referring to local file systems automatically gain + an <varname>After=</varname> dependency on <filename>local-fs-pre.target</filename>, and a + <varname>Before=</varname> dependency on <filename>local-fs.target</filename> unless + <option>nofail</option> mount option is set.</para></listitem> + + <listitem><para>Network mount units + automatically acquire <varname>After=</varname> dependencies on <filename>remote-fs-pre.target</filename>, + <filename>network.target</filename> and <filename>network-online.target</filename>, and gain a + <varname>Before=</varname> dependency on <filename>remote-fs.target</filename> unless + <option>nofail</option> mount option is set. Towards the latter a + <varname>Wants=</varname> unit is added as well.</para></listitem> + </itemizedlist> + + <para>Mount units referring to local and network file systems are distinguished by their file system type + specification. In some cases this is not sufficient (for example network block device based mounts, such as + iSCSI), in which case <option>_netdev</option> may be added to the mount option string of the unit, which forces + systemd to consider the mount unit a network mount.</para> + </refsect2> + </refsect1> + + <refsect1> + <title><filename>fstab</filename></title> + + <para>Mount units may either be configured via unit files, or via + <filename>/etc/fstab</filename> (see + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details). Mounts listed in <filename>/etc/fstab</filename> + will be converted into native units dynamically at boot and when + the configuration of the system manager is reloaded. In general, + configuring mount points through <filename>/etc/fstab</filename> + is the preferred approach. See + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details about the conversion.</para> + + <para>The NFS mount option <option>bg</option> for NFS background mounts + as documented in <citerefentry project='man-pages'><refentrytitle>nfs</refentrytitle><manvolnum>5</manvolnum></citerefentry> + is detected by <command>systemd-fstab-generator</command> and the options + are transformed so that systemd fulfills the job-control implications of + that option. Specifically <command>systemd-fstab-generator</command> acts + as though <literal>x-systemd.mount-timeout=infinity,retry=10000</literal> was + prepended to the option list, and <literal>fg,nofail</literal> was appended. + Depending on specific requirements, it may be appropriate to provide some of + these options explicitly, or to make use of the + <literal>x-systemd.automount</literal> option described below instead + of using <literal>bg</literal>.</para> + + <para>When reading <filename>/etc/fstab</filename> a few special + 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> + below), from either <filename>local-fs.target</filename> or + <filename>remote-fs.target</filename>, depending whether the file + system is local or remote.</para> + + <variablelist class='fstab-options'> + + <varlistentry> + <term><option>x-systemd.requires=</option></term> + + <listitem><para>Configures a <varname>Requires=</varname> and + an <varname>After=</varname> dependency between the created + mount unit and another systemd unit, such as a device or mount + unit. The argument should be a unit name, or an absolute path + to a device node or mount point. This option may be specified + more than once. This option is particularly useful for mount + point declarations that need an additional device to be around + (such as an external journal device for journal file systems) + or an additional mount to be in place (such as an overlay file + system that merges multiple mount points). See + <varname>After=</varname> and <varname>Requires=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>Note that this option always applies to the created mount unit + only regardless whether <option>x-systemd.automount</option> has been + specified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.before=</option></term> + <term><option>x-systemd.after=</option></term> + + <listitem><para>In the created mount unit, configures a + <varname>Before=</varname> or <varname>After=</varname> + dependency on another systemd unit, such as a mount unit. + The argument should be a unit name or an absolute path + to a mount point. This option may be specified more than once. + This option is particularly useful for mount point declarations + with <option>nofail</option> option that are mounted + asynchronously but need to be mounted before or after some unit + start, for example, before <filename>local-fs.target</filename> + unit. + See <varname>Before=</varname> and <varname>After=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>Note that these options always apply to the created mount unit + only regardless whether <option>x-systemd.automount</option> has been + specified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.wanted-by=</option></term> + <term><option>x-systemd.required-by=</option></term> + + <listitem><para>In the created mount unit, configures a + <varname>WantedBy=</varname> or <varname>RequiredBy=</varname> + dependency on another unit. This option may be + specified more than once. If this is specified, the normal + automatic dependencies on the created mount unit, e.g., + <filename>local-fs.target</filename>, are not automatically + created. See <varname>WantedBy=</varname> and <varname>RequiredBy=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.requires-mounts-for=</option></term> + + <listitem><para>Configures a + <varname>RequiresMountsFor=</varname> dependency between the + created mount unit and other mount units. The argument must be + an absolute path. This option may be specified more than once. + See <varname>RequiresMountsFor=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.device-bound</option></term> + + <listitem><para>The block device backed file system will be upgraded + to <varname>BindsTo=</varname> dependency. This option is only useful + when mounting file systems manually with + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> + as the default dependency in this case is <varname>Requires=</varname>. + This option is already implied by entries in <filename>/etc/fstab</filename> + or by mount units. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.automount</option></term> + + <listitem><para>An automount unit will be created for the file + system. See + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.idle-timeout=</option></term> + + <listitem><para>Configures the idle timeout of the + automount unit. See <varname>TimeoutIdleSec=</varname> in + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para></listitem> + </varlistentry> + + <varlistentry id='device-timeout'> + <term><option>x-systemd.device-timeout=</option></term> + + <listitem><para>Configure how long systemd should wait for a + device to show up before giving up on an entry from + <filename>/etc/fstab</filename>. Specify a time in seconds or + explicitly append a unit such as <literal>s</literal>, + <literal>min</literal>, <literal>h</literal>, + <literal>ms</literal>.</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> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.mount-timeout=</option></term> + + <listitem><para>Configure how long systemd should wait for the + mount command to finish before giving up on an entry from + <filename>/etc/fstab</filename>. Specify a time in seconds or + explicitly append a unit such as <literal>s</literal>, + <literal>min</literal>, <literal>h</literal>, + <literal>ms</literal>.</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> + + <para>See <varname>TimeoutSec=</varname> below for + details.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.makefs</option></term> + + <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 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> + + <para>See + <citerefentry><refentrytitle>systemd-makefs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <para><citerefentry project='man-pages'><refentrytitle>wipefs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + may be used to remove any signatures from a block device to force + <option>x-systemd.makefs</option> to reinitialize the device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.growfs</option></term> + + <listitem><para>The file system will be grown to occupy the full block + device. If the file system is already at maximum size, no action will + be performed. It is hence expected that this option remains set even after + the file system has been grown. Only certain file system types are supported, + see + <citerefentry><refentrytitle>systemd-makefs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details.</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></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.rw-only</option></term> + + <listitem><para>If a mount operation fails to mount the file system + read-write, it normally tries mounting the file system read-only instead. + This option disables that behaviour, and causes the mount to fail + immediately instead. This option is translated into the + <varname>ReadWriteOnly=</varname> setting in a unit file.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>_netdev</option></term> + + <listitem><para>Normally the file system type is used to determine if a + mount is a "network mount", i.e. if it should only be started after the + network is available. Using this option overrides this detection and + specifies that the mount requires network.</para> + + <para>Network mount units are ordered between <filename>remote-fs-pre.target</filename> + and <filename>remote-fs.target</filename>, instead of + <filename>local-fs-pre.target</filename> and <filename>local-fs.target</filename>. + They also pull in <filename>network-online.target</filename> and are ordered after + it and <filename>network.target</filename>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>noauto</option></term> + <term><option>auto</option></term> + + <listitem><para>With <option>noauto</option>, the mount unit will not be added as a dependency for + <filename>local-fs.target</filename> or <filename>remote-fs.target</filename>. This means that it will not be + mounted automatically during boot, unless it is pulled in by some other unit. The <option>auto</option> option + has the opposite meaning and is the default. Note that the <option>noauto</option> option has an effect on the + mount unit itself only — if <option>x-systemd.automount</option> is used (see above), then the matching + automount unit will still be pulled in by these targets.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>nofail</option></term> + + <listitem><para>With <option>nofail</option>, this mount will be only wanted, not required, by + <filename>local-fs.target</filename> or <filename>remote-fs.target</filename>. Moreover the mount unit is not + ordered before these target units. This means that the boot will continue without waiting for the mount unit + and regardless whether the mount point can be mounted successfully.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>x-initrd.mount</option></term> + + <listitem><para>An additional filesystem to be mounted in the + initramfs. See <filename>initrd-fs.target</filename> + description in + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + + <para>If a mount point is configured in both + <filename>/etc/fstab</filename> and a unit file that is stored + below <filename>/usr/</filename>, the former will take precedence. + If the unit file is stored below <filename>/etc/</filename>, it + will take precedence. This means: native unit files take + precedence over traditional configuration files, but this is + superseded by the rule that configuration in + <filename>/etc/</filename> will always take precedence over + configuration in <filename>/usr/</filename>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Mount files must include a [Mount] section, which carries + information about the file system mount points it supervises. A + number of options that may be used in this section are shared with + other unit types. These options are documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The options specific to the [Mount] section of mount units are the + following:</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>What=</varname></term> + <listitem><para>Takes an absolute path of a device node, file or other resource to mount. See + <citerefentry + project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + details. If this refers to a device node, a dependency on the respective device unit is automatically + created. (See + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information.) This option is mandatory. Note that the usual specifier expansion is applied + to this setting, literal percent characters should hence be written as <literal + class='specifiers'>%%</literal>. If this mount is a bind mount and the specified path does not exist + yet it is created as directory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Where=</varname></term> + <listitem><para>Takes an absolute path of a file or directory for the mount point; in particular, the + destination cannot be a symbolic link. If the mount point does not exist at the time of mounting, it + is created as directory. This string must be reflected in the unit filename. (See above.) This option + is mandatory.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Type=</varname></term> + <listitem><para>Takes a string for the file system type. See + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details. This setting is optional.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Options=</varname></term> + + <listitem><para>Mount options to use when mounting. This takes a comma-separated list of options. This setting + is optional. Note that the usual specifier expansion is applied to this setting, literal percent characters + should hence be written as <literal class='specifiers'>%%</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SloppyOptions=</varname></term> + + <listitem><para>Takes a boolean argument. If true, parsing of + the options specified in <varname>Options=</varname> is + relaxed, and unknown mount options are tolerated. This + corresponds with + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <parameter>-s</parameter> switch. Defaults to + off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LazyUnmount=</varname></term> + + <listitem><para>Takes a boolean argument. If true, detach the + filesystem from the filesystem hierarchy at time of the unmount + operation, and clean up all references to the filesystem as + soon as they are not busy anymore. + This corresponds with + <citerefentry project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <parameter>-l</parameter> switch. Defaults to + off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReadWriteOnly=</varname></term> + + <listitem><para>Takes a boolean argument. If false, a mount + point that shall be mounted read-write but cannot be mounted + so is retried to be mounted read-only. If true the operation + will fail immediately after the read-write mount attempt did + not succeed. This corresponds with + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <parameter>-w</parameter> switch. Defaults to + off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ForceUnmount=</varname></term> + + <listitem><para>Takes a boolean argument. If true, force an + unmount (in case of an unreachable NFS system). + This corresponds with + <citerefentry project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <parameter>-f</parameter> switch. Defaults to + off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DirectoryMode=</varname></term> + <listitem><para>Directories of mount points (and any parent + directories) are automatically created if needed. This option + specifies the file system access mode used when creating these + directories. Takes an access mode in octal notation. Defaults + to 0755.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimeoutSec=</varname></term> + <listitem><para>Configures the time to wait for the mount + command to finish. If a command does not exit within the + configured time, the mount will be considered failed and be + shut down again. All commands still running will be terminated + forcibly via <constant>SIGTERM</constant>, and after another + delay of this time with <constant>SIGKILL</constant>. (See + <option>KillMode=</option> in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the timeout logic. The + default value is set from <varname>DefaultTimeoutStartSec=</varname> option in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + + <para>Check + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more settings.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.net-naming-scheme.xml b/man/systemd.net-naming-scheme.xml new file mode 100644 index 0000000..054de92 --- /dev/null +++ b/man/systemd.net-naming-scheme.xml @@ -0,0 +1,476 @@ +<?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-or-later --> + +<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 properties 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> + + <para>Note that while the concept of network interface naming schemes is primarily relevant in the + context of <filename>systemd-udevd.service</filename>, the + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + container manager also takes it into account when naming network interfaces, see below.</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 numeric 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 textual 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>v</constant><replaceable>slot</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 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><replaceable>prefix</replaceable> <constant>v</constant><replaceable>slot</replaceable></entry> + <entry>VIO slot number (IBM PowerVM)</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> + + <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.</para> + + <para>In some configurations a parent PCI bridge of a given network controller may be associated + with a slot. In such case we don't generate this device property to avoid possible naming conflicts.</para> + </listitem> + </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 (which may be chosen at system boot-up time via + the <varname>net.naming-scheme=</varname> kernel command line switch, see above:</para> + + <variablelist> + <varlistentry> + <term><constant>v238</constant></term> + + <listitem><para>This is the naming scheme 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 index="false">.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 index="false">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> + + <varlistentry> + <term><constant>v245</constant></term> + + <listitem><para>When + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + derives the name for the host side of the network interface created with + <option>--network-veth</option> from the container name it previously simply truncated the result + at 15 characters if longer (since that's the maximum length for network interface names). From now + on, for any interface name that would be longer than 15 characters the last 4 characters are set to + a 24bit hash value of the full interface name. This way network interface name collisions between + multiple similarly named containers (who only differ in container name suffix) should be less + likely (but still possible, since the 24bit hash value is very small).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>v247</constant></term> + + <listitem><para>If the PCI slot is associated with PCI bridge and that has multiple child network + controllers then all of them might derive the same value of <varname>ID_NET_NAME_SLOT</varname> + property. That could cause naming conflict if the property is selected as a device name. Now, we detect the + situation, slot - bridge relation, and we don't produce the <varname>ID_NET_NAME_SLOT</varname> property to + avoid possible naming conflict.</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://systemd.io/PREDICTABLE_INTERFACE_NAMES">Predictable Network Interface Names</ulink>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml new file mode 100644 index 0000000..ddda14d --- /dev/null +++ b/man/systemd.netdev.xml @@ -0,0 +1,2203 @@ +<?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-or-later --> + +<refentry id="systemd.netdev" conditional='ENABLE_NETWORKD'> + + <refentryinfo> + <title>systemd.network</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.netdev</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.netdev</refname> + <refpurpose>Virtual Network Device configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>netdev</replaceable>.netdev</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A plain ini-style text file that encodes configuration about a virtual network device, used by + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + See <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + + <para>The main Virtual Network Device file must have the extension <filename>.netdev</filename>; + other extensions are ignored. Virtual network devices are created as soon as networkd is + started. If a netdev with the specified name already exists, networkd will use that as-is rather + than create its own. Note that the settings of the pre-existing netdev will not be changed by + networkd.</para> + + <para>The <filename>.netdev</filename> files are read from the files located in the system + network directory <filename>/usr/lib/systemd/network</filename>, the volatile runtime network + directory <filename>/run/systemd/network</filename> and the local administration network + directory <filename>/etc/systemd/network</filename>. All configuration files are collectively + sorted and processed in lexical order, regardless of the directories in which they live. + However, files with identical filenames replace each other. Files in <filename>/etc/</filename> + have the highest priority, files in <filename>/run/</filename> take precedence over files with + the same name in <filename>/usr/lib/</filename>. This can be used to override a system-supplied + configuration file with a local file if needed. As a special case, an empty file (file size 0) + or symlink with the same name pointing to <filename>/dev/null</filename> disables the + configuration file entirely (it is "masked").</para> + + <para>Along with the netdev file <filename>foo.netdev</filename>, a "drop-in" directory + <filename>foo.netdev.d/</filename> may exist. All files with the suffix <literal>.conf</literal> + from this directory will be parsed after the file itself is parsed. This is useful to alter or + add configuration settings, without having to modify the main configuration file. Each drop-in + file must have appropriate section headers.</para> + + <para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal> + directories can be placed in <filename>/usr/lib/systemd/network</filename> or + <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. (Of course, since + <filename>/run/</filename> is temporary and <filename>/usr/lib/</filename> is for vendors, it is + unlikely drop-ins should be used in either of those places.)</para> + </refsect1> + + <refsect1> + <title>Supported netdev kinds</title> + + <para>The following kinds of virtual network devices may be + configured in <filename>.netdev</filename> files:</para> + + <table> + <title>Supported kinds of virtual network devices</title> + + <tgroup cols='2'> + <colspec colname='kind' /> + <colspec colname='explanation' /> + <thead><row> + <entry>Kind</entry> + <entry>Description</entry> + </row></thead> + <tbody> + <row><entry><varname>bond</varname></entry> + <entry>A bond device is an aggregation of all its slave devices. See <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">Linux Ethernet Bonding Driver HOWTO</ulink> for details.</entry></row> + + <row><entry><varname>bridge</varname></entry> + <entry>A bridge device is a software switch, and each of its slave devices and the bridge itself are ports of the switch.</entry></row> + + <row><entry><varname>dummy</varname></entry> + <entry>A dummy device drops all packets sent to it.</entry></row> + + <row><entry><varname>gre</varname></entry> + <entry>A Level 3 GRE tunnel over IPv4. See <ulink url="https://tools.ietf.org/html/rfc2784">RFC 2784</ulink> for details.</entry></row> + + <row><entry><varname>gretap</varname></entry> + <entry>A Level 2 GRE tunnel over IPv4.</entry></row> + + <row><entry><varname>erspan</varname></entry> + <entry>ERSPAN mirrors traffic on one or more source ports and delivers the mirrored traffic to one or more destination ports on another switch. The traffic is encapsulated in generic routing encapsulation (GRE) and is therefore routable across a layer 3 network between the source switch and the destination switch.</entry></row> + + <row><entry><varname>ip6gre</varname></entry> + <entry>A Level 3 GRE tunnel over IPv6.</entry></row> + + <row><entry><varname>ip6tnl</varname></entry> + <entry>An IPv4 or IPv6 tunnel over IPv6</entry></row> + + <row><entry><varname>ip6gretap</varname></entry> + <entry>A Level 2 GRE tunnel over IPv6.</entry></row> + + <row><entry><varname>ipip</varname></entry> + <entry>An IPv4 over IPv4 tunnel.</entry></row> + + <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> + + <row><entry><varname>macvtap</varname></entry> + <entry>A macvtap device is a stacked device which receives packets from its underlying device based on MAC address filtering.</entry></row> + + <row><entry><varname>sit</varname></entry> + <entry>An IPv6 over IPv4 tunnel.</entry></row> + + <row><entry><varname>tap</varname></entry> + <entry>A persistent Level 2 tunnel between a network device and a device node.</entry></row> + + <row><entry><varname>tun</varname></entry> + <entry>A persistent Level 3 tunnel between a network device and a device node.</entry></row> + + <row><entry><varname>veth</varname></entry> + <entry>An Ethernet tunnel between a pair of network devices.</entry></row> + + <row><entry><varname>vlan</varname></entry> + <entry>A VLAN is a stacked device which receives packets from its underlying device based on VLAN tagging. See <ulink url="http://www.ieee802.org/1/pages/802.1Q.html">IEEE 802.1Q</ulink> for details.</entry></row> + + <row><entry><varname>vti</varname></entry> + <entry>An IPv4 over IPSec tunnel.</entry></row> + + <row><entry><varname>vti6</varname></entry> + <entry>An IPv6 over IPSec tunnel.</entry></row> + + <row><entry><varname>vxlan</varname></entry> + <entry>A virtual extensible LAN (vxlan), for connecting Cloud computing deployments.</entry></row> + + <row><entry><varname>geneve</varname></entry> + <entry>A GEneric NEtwork Virtualization Encapsulation (GENEVE) netdev driver.</entry></row> + + <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> + + <row><entry><varname>vcan</varname></entry> + <entry>The virtual CAN driver (vcan). Similar to the network loopback devices, vcan offers a virtual local CAN interface.</entry></row> + + <row><entry><varname>vxcan</varname></entry> + <entry>The virtual CAN tunnel driver (vxcan). Similar to the virtual ethernet driver veth, vxcan implements a local CAN traffic tunnel between two virtual CAN network devices. When creating a vxcan, two vxcan devices are created as pair. When one end receives the packet it appears on its pair and vice versa. The vxcan can be used for cross namespace communication. + </entry></row> + + <row><entry><varname>wireguard</varname></entry> + <entry>WireGuard Secure Network Tunnel.</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> + + <row><entry><varname>ifb</varname></entry> + <entry> The Intermediate Functional Block (ifb) pseudo network interface acts as a QoS concentrator for multiple different sources of traffic.</entry></row> + + <row><entry><varname>bareudp</varname></entry> + <entry> Bare UDP tunnels provide a generic L3 encapsulation support for tunnelling different L3 protocols like MPLS, IP etc. inside of an UDP tunnel.</entry></row> + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + <title>[Match] Section Options</title> + + <para>A virtual network device is only created if the + [Match] section matches the current + environment, or if the section is empty. The following keys are + accepted:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Host=</varname></term> + <listitem> + <para>Matches against the hostname or machine ID of the host. See + <literal>ConditionHost=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Virtualization=</varname></term> + <listitem> + <para>Checks whether the system is executed in a virtualized environment and optionally test + whether it is a specific implementation. See <literal>ConditionVirtualization=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KernelCommandLine=</varname></term> + <listitem> + <para>Checks whether a specific kernel command line option is set. See + <literal>ConditionKernelCommandLine=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KernelVersion=</varname></term> + <listitem> + <para>Checks whether the kernel version (as reported by <command>uname -r</command>) matches a + certain expression. See <literal>ConditionKernelVersion=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Architecture=</varname></term> + <listitem> + <para>Checks whether the system is running on a specific architecture. See + <literal>ConditionArchitecture=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated. + If an empty string is assigned, then previously assigned value is cleared. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[NetDev] Section Options</title> + + <para>The [NetDev] 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 setting is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Kind=</varname></term> + <listitem> + <para>The netdev kind. This setting 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 + [NetDev] section. Please specify it in [Link] 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 [NetDev] section is not + supported. Please specify it in [Link] 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> + <title>[Bridge] Section Options</title> + + <para>The [Bridge] 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>VLANProtocol=</varname></term> + <listitem> + <para>Allows setting the protocol used for VLAN filtering. Takes + <option>802.1q</option> or, + <option>802.1ad</option>, and defaults to unset and kernel's default is 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 changing bridge's multicast Internet Group Management Protocol (IGMP) version. + Takes an integer 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 [VLAN] 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 setting 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. When enabled, the VLAN reorder header is used and VLAN interfaces behave + like physical interfaces. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACVLAN] Section Options</title> + + <para>The [MACVLAN] section only applies for + netdevs of kind <literal>macvlan</literal>, and accepts the + following key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Mode=</varname></term> + <listitem> + <para>The MACVLAN mode to use. The supported options are + <literal>private</literal>, + <literal>vepa</literal>, + <literal>bridge</literal>, + <literal>passthru</literal>, and + <literal>source</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SourceMACAddress=</varname></term> + <listitem> + <para>A whitespace-separated list of remote hardware addresses allowed on the MACVLAN. This + option only has an effect in source mode. Use full colon-, hyphen- or dot-delimited + hexadecimal. 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. Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACVTAP] Section Options</title> + + <para>The [MACVTAP] section applies for netdevs of kind <literal>macvtap</literal> and accepts the same + keys as [MACVLAN].</para> + </refsect1> + + <refsect1> + <title>[IPVLAN] Section Options</title> + + <para>The [IPVLAN] section only applies for + netdevs of kind <literal>ipvlan</literal>, and accepts the + following key:</para> + + <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> + </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> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[IPVTAP] Section Options</title> + + <para>The [IPVTAP] section only applies for netdevs of kind <literal>ipvtap</literal> and accepts the + same keys as [IPVLAN].</para> + </refsect1> + + <refsect1> + <title>[VXLAN] Section Options</title> + + <para>The [VXLAN] section only applies for + netdevs of kind <literal>vxlan</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>VNI=</varname></term> + <listitem> + <para>The VXLAN Network Identifier (or VXLAN Segment ID). Takes a number in the range 1-16777215.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Remote=</varname></term> + <listitem> + <para>Configures destination IP address.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Local=</varname></term> + <listitem> + <para>Configures local IP address.</para> + </listitem> + </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> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TTL=</varname></term> + <listitem> + <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> + <term><varname>MacLearning=</varname></term> + <listitem> + <para>Takes a boolean. When true, enables dynamic MAC learning + to discover remote MAC addresses.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FDBAgeingSec=</varname></term> + <listitem> + <para>The lifetime of Forwarding Database entry learnt by + the kernel, in seconds.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MaximumFDBEntries=</varname></term> + <listitem> + <para>Configures maximum number of FDB entries.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ReduceARPProxy=</varname></term> + <listitem> + <para>Takes a boolean. When true, bridge-connected VXLAN tunnel + endpoint answers ARP requests from the local bridge on behalf + of remote Distributed Overlay Virtual Ethernet + <ulink url="https://en.wikipedia.org/wiki/Distributed_Overlay_Virtual_Ethernet"> + (DVOE)</ulink> clients. Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>L2MissNotification=</varname></term> + <listitem> + <para>Takes a boolean. When true, enables netlink LLADDR miss + notifications.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>L3MissNotification=</varname></term> + <listitem> + <para>Takes a boolean. When true, enables netlink IP address miss notifications.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RouteShortCircuit=</varname></term> + <listitem> + <para>Takes a boolean. When true, route short circuiting is turned + on.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDPChecksum=</varname></term> + <listitem> + <para>Takes a boolean. When true, transmitting UDP checksums when doing VXLAN/IPv4 is turned on.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDP6ZeroChecksumTx=</varname></term> + <listitem> + <para>Takes a boolean. When true, sending zero checksums in VXLAN/IPv6 is turned on.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDP6ZeroChecksumRx=</varname></term> + <listitem> + <para>Takes a boolean. When true, receiving zero checksums in VXLAN/IPv6 is turned on.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RemoteChecksumTx=</varname></term> + <listitem> + <para>Takes a boolean. When true, remote transmit checksum offload of VXLAN is turned on.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RemoteChecksumRx=</varname></term> + <listitem> + <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>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. If the destination port is not specified then + Linux kernel default will be used. Set to 4789 to get the IANA assigned value.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PortRange=</varname></term> + <listitem> + <para>Configures the source port range for the VXLAN. The kernel assigns the source UDP port based + on the flow to help the receiver to do load balancing. When this option is not set, the normal + range of local UDP ports is used.</para> + </listitem> + </varlistentry> + <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 setting 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 [GENEVE] section only applies for + netdevs of kind <literal>geneve</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>Specifies the Virtual Network Identifier (VNI) to use, a number between 0 and 16777215. This + field is mandatory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Remote=</varname></term> + <listitem> + <para>Specifies the unicast destination IP address to use in outgoing packets.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TOS=</varname></term> + <listitem> + <para>Specifies the TOS value to use in outgoing packets. Takes a number between 1 and 255.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TTL=</varname></term> + <listitem> + <para>Accepts the same values as in the [VXLAN] section, except that when unset + or set to 0, the kernel's default will be used, meaning that packet TTL will be set from + <filename>/proc/sys/net/ipv4/ip_default_ttl</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDPChecksum=</varname></term> + <listitem> + <para>Takes a boolean. When true, specifies that UDP checksum is calculated for transmitted packets + over IPv4.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDP6ZeroChecksumTx=</varname></term> + <listitem> + <para>Takes a boolean. When true, skip UDP checksum calculation for transmitted packets over IPv6.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDP6ZeroChecksumRx=</varname></term> + <listitem> + <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> + <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 as in [VXLAN] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Independent=</varname></term> + <listitem> + <para>Takes a boolean. When true, the vxlan interface is created without any underlying network + interface. Defaults to false, which means that a .network file that requests this tunnel using + <varname>Tunnel=</varname> is required for the tunnel to be created.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[BareUDP] Section Options</title> + + <para>The [BareUDP] section only applies for + netdevs of kind <literal>bareudp</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>DestinationPort=</varname></term> + <listitem> + <para>Specifies the destination UDP port (in range 1…65535). This is mandatory.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>EtherType=</varname></term> + <listitem> + <para>Specifies the L3 protocol. Takes one of <literal>ipv4</literal>, <literal>ipv6</literal>, <literal>mpls-uc</literal> + or <literal>mpls-mc</literal>. This is mandatory.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[L2TP] Section Options</title> + + <para>The [L2TP] section only applies for + netdevs of kind <literal>l2tp</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>TunnelId=</varname></term> + <listitem> + <para>Specifies the tunnel identifier. Takes an number in the range 1–4294967295. The value used + must match the <literal>PeerTunnelId=</literal> value being used at the peer. This setting is + compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PeerTunnelId=</varname></term> + <listitem> + <para>Specifies the peer tunnel id. Takes a number in the range 1—4294967295. The value used must + match the <literal>TunnelId=</literal> value being used at the peer. This setting is compulsory. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Remote=</varname></term> + <listitem> + <para>Specifies the IP address of the remote peer. This setting is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Local=</varname></term> + <listitem> + <para>Specifies the IP address of the local interface. Takes an IP address, or the special values + <literal>auto</literal>, <literal>static</literal>, or <literal>dynamic</literal>. When an address + is set, then the local interface must have the address. If <literal>auto</literal>, then one of the + addresses on the local interface is used. Similarly, if <literal>static</literal> or + <literal>dynamic</literal> is set, then one of the static or dynamic addresses on the local + interface is used. Defaults to <literal>auto</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>EncapsulationType=</varname></term> + <listitem> + <para>Specifies the encapsulation type of the tunnel. Takes one of <literal>udp</literal> or + <literal>ip</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDPSourcePort=</varname></term> + <listitem> + <para>Specifies the UDP source port to be used for the tunnel. When UDP encapsulation is selected + it's mandatory. Ignored when IP encapsulation is selected.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDPDestinationPort=</varname></term> + <listitem> + <para>Specifies destination port. When UDP encapsulation is selected it's mandatory. Ignored when IP + encapsulation is selected.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDPChecksum=</varname></term> + <listitem> + <para>Takes a boolean. When true, specifies that UDP checksum is calculated for transmitted packets + over IPv4.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDP6ZeroChecksumTx=</varname></term> + <listitem> + <para>Takes a boolean. When true, skip UDP checksum calculation for transmitted packets over IPv6.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDP6ZeroChecksumRx=</varname></term> + <listitem> + <para>Takes a boolean. When true, allows incoming UDP packets over IPv6 with zero checksum field.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[L2TPSession] Section Options</title> + + <para>The [L2TPSession] section only applies for + netdevs of kind <literal>l2tp</literal>, and accepts the + following keys:</para> + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>Specifies the name of the session. This setting is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SessionId=</varname></term> + <listitem> + <para>Specifies the session identifier. Takes an number in the range 1–4294967295. The value used + must match the <literal>SessionId=</literal> value being used at the peer. This setting is + compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PeerSessionId=</varname></term> + <listitem> + <para>Specifies the peer session identifier. Takes an number in the range 1–4294967295. + The value used must match the <literal>PeerSessionId=</literal> value being used at the peer. + This setting is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Layer2SpecificHeader=</varname></term> + <listitem> + <para>Specifies layer2specific header type of the session. One of <literal>none</literal> or <literal>default</literal>. Defaults to <literal>default</literal>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACsec] Section Options</title> + + <para>The [MACsec] 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 [MACsecReceiveChannel] 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 setting is compulsory, and is not set by + default.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACsecTransmitAssociation] Section Options</title> + + <para>The [MACsecTransmitAssociation] 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 setting 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. If the path + refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is made to + it and the key read from it.</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 [MACsecTransmitAssociation] 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 [MACsecReceiveAssociation] 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 as in [MACsecReceiveChannel] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>Accepts the same key as in [MACsecReceiveChannel] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PacketNumber=</varname></term> + <listitem> + <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeyId=</varname></term> + <listitem> + <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Key=</varname></term> + <listitem> + <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KeyFile=</varname></term> + <listitem> + <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Activate=</varname></term> + <listitem> + <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Tunnel] Section Options</title> + + <para>The [Tunnel] section only applies for + netdevs of kind + <literal>ipip</literal>, + <literal>sit</literal>, + <literal>gre</literal>, + <literal>gretap</literal>, + <literal>ip6gre</literal>, + <literal>ip6gretap</literal>, + <literal>vti</literal>, + <literal>vti6</literal>, + <literal>ip6tnl</literal>, and + <literal>erspan</literal> and accepts + the following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Local=</varname></term> + <listitem> + <para>A static local address for tunneled packets. It must be an address on another interface of + this host, or the special value <literal>any</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Remote=</varname></term> + <listitem> + <para>The remote endpoint of the tunnel. Takes an IP address or the special value + <literal>any</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TOS=</varname></term> + <listitem> + <para>The Type Of Service byte value for a tunnel interface. + For details about the TOS, see the + <ulink url="http://tools.ietf.org/html/rfc1349"> Type of + Service in the Internet Protocol Suite </ulink> document. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TTL=</varname></term> + <listitem> + <para>A fixed Time To Live N on tunneled packets. N is a + number in the range 1–255. 0 is a special value meaning that + packets inherit the TTL value. The default value for IPv4 + tunnels is 0 (inherit). The default value for IPv6 tunnels is + 64.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DiscoverPathMTU=</varname></term> + <listitem> + <para>Takes a boolean. When true, enables Path MTU Discovery on + the tunnel.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6FlowLabel=</varname></term> + <listitem> + <para>Configures the 20-bit flow label (see <ulink url="https://tools.ietf.org/html/rfc6437"> + RFC 6437</ulink>) field in the IPv6 header (see <ulink url="https://tools.ietf.org/html/rfc2460"> + RFC 2460</ulink>), which is used by a node to label packets of a flow. + It is only used for IPv6 tunnels. + A flow label of zero is used to indicate packets that have + not been labeled. + It can be configured to a value in the range 0–0xFFFFF, or be + set to <literal>inherit</literal>, in which case the original flowlabel is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>CopyDSCP=</varname></term> + <listitem> + <para>Takes a boolean. When true, the Differentiated Service Code + Point (DSCP) field will be copied to the inner header from + outer header during the decapsulation of an IPv6 tunnel + packet. DSCP is a field in an IP packet that enables different + levels of service to be assigned to network traffic. + Defaults to <literal>no</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>EncapsulationLimit=</varname></term> + <listitem> + <para>The Tunnel Encapsulation Limit option specifies how many additional + levels of encapsulation are permitted to be prepended to the packet. + For example, a Tunnel Encapsulation Limit option containing a limit + value of zero means that a packet carrying that option may not enter + another tunnel before exiting the current tunnel. + (see <ulink url="https://tools.ietf.org/html/rfc2473#section-4.1.1"> RFC 2473</ulink>). + The valid range is 0–255 and <literal>none</literal>. Defaults to 4. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Key=</varname></term> + <listitem> + <para>The <varname>Key=</varname> parameter specifies the same key to use in + both directions (<varname>InputKey=</varname> and <varname>OutputKey=</varname>). + The <varname>Key=</varname> is either a number or an IPv4 address-like dotted quad. + It is used as mark-configured SAD/SPD entry as part of the lookup key (both in data + and control path) in IP XFRM (framework used to implement IPsec protocol). + See <ulink url="http://man7.org/linux/man-pages/man8/ip-xfrm.8.html"> + ip-xfrm — transform configuration</ulink> for details. It is only used for VTI/VTI6, + GRE, GRETAP, and ERSPAN tunnels.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>InputKey=</varname></term> + <listitem> + <para>The <varname>InputKey=</varname> parameter specifies the key to use for input. + The format is same as <varname>Key=</varname>. It is only used for VTI/VTI6, GRE, GRETAP, + and ERSPAN tunnels.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>OutputKey=</varname></term> + <listitem> + <para>The <varname>OutputKey=</varname> parameter specifies the key to use for output. + The format is same as <varname>Key=</varname>. It is only used for VTI/VTI6, GRE, GRETAP, + and ERSPAN tunnels.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Mode=</varname></term> + <listitem> + <para>An <literal>ip6tnl</literal> tunnel can be in one of three + modes + <literal>ip6ip6</literal> for IPv6 over IPv6, + <literal>ipip6</literal> for IPv4 over IPv6 or + <literal>any</literal> for either. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Independent=</varname></term> + <listitem> + <para>Takes a boolean. When false (the default), the tunnel is always created over some network + device, and a .network file that requests this tunnel using <varname>Tunnel=</varname> is required + for the tunnel to be created. When true, the tunnel is created independently of any network as + "tunnel@NONE".</para> + </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. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FooOverUDP=</varname></term> + <listitem> + <para>Takes a boolean. Specifies whether <varname>FooOverUDP=</varname> tunnel is to be configured. + Defaults to false. This takes effects only for IPIP, SIT, GRE, and GRETAP tunnels. + For more detail information see + <ulink url="https://lwn.net/Articles/614348">Foo over UDP</ulink></para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FOUDestinationPort=</varname></term> + <listitem> + <para>This setting specifies the UDP destination port for encapsulation. + This field is mandatory when <varname>FooOverUDP=yes</varname>, and is not set by default.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FOUSourcePort=</varname></term> + <listitem> + <para>This setting specifies the UDP source port for encapsulation. Defaults to <constant>0</constant> + — that is, the source port for packets is left to the network stack to decide.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Encapsulation=</varname></term> + <listitem> + <para>Accepts the same key as in the [FooOverUDP] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6RapidDeploymentPrefix=</varname></term> + <listitem> + <para>Reconfigure the tunnel for <ulink url="https://tools.ietf.org/html/rfc5569">IPv6 Rapid + Deployment</ulink>, also known as 6rd. The value is an ISP-specific IPv6 prefix with a non-zero length. Only + applicable to SIT tunnels.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ISATAP=</varname></term> + <listitem> + <para>Takes a boolean. If set, configures the tunnel as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnel. + Only applicable to SIT tunnels. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SerializeTunneledPackets=</varname></term> + <listitem> + <para>Takes a boolean. If set to yes, then packets are serialized. Only applies for GRE, + GRETAP, and ERSPAN tunnels. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ERSPANIndex=</varname></term> + <listitem> + <para>Specifies the ERSPAN index field for the interface, an integer in the range 1-1048575 associated with + the ERSPAN traffic's source port and direction. This field is mandatory. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[FooOverUDP] Section Options</title> + + <para>The [FooOverUDP] section only applies for + netdevs of kind <literal>fou</literal> and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Encapsulation=</varname></term> + <listitem> + <para>Specifies the encapsulation mechanism used to store networking packets of various protocols + inside the UDP packets. Supports the following values: + + <literal>FooOverUDP</literal> provides the simplest no-frills model of UDP encapsulation, it simply + encapsulates packets directly in the UDP payload. <literal>GenericUDPEncapsulation</literal> is a + generic and extensible encapsulation, it allows encapsulation of packets for any IP protocol and + optional data as part of the encapsulation. For more detailed information see <ulink + url="https://lwn.net/Articles/615044">Generic UDP Encapsulation</ulink>. Defaults to + <literal>FooOverUDP</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Port=</varname></term> + <listitem> + <para>Specifies the port number where the encapsulated packets will arrive. Those packets will be + removed and manually fed back into the network stack with the encapsulation removed to be sent to + the real destination. This option is mandatory.</para> + </listitem> + </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 mandatory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Protocol=</varname></term> + <listitem> + <para>The <varname>Protocol=</varname> specifies the protocol number of the packets arriving + at the UDP port. When <varname>Encapsulation=FooOverUDP</varname>, this field is mandatory + and is not set by default. Takes an IP protocol name such as <literal>gre</literal> or + <literal>ipip</literal>, or an integer within the range 1-255. When + <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 mandatory.</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 [Peer] 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 setting 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 [VXCAN] 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 setting is compulsory.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Tun] Section Options</title> + + <para>The [Tun] section only applies for + netdevs of kind <literal>tun</literal>, and accepts the following + keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MultiQueue=</varname></term> + <listitem><para>Takes a boolean. Configures whether + to use multiple file descriptors (queues) to parallelize + packets sending and receiving. Defaults to + <literal>no</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PacketInfo=</varname></term> + <listitem><para>Takes a boolean. Configures whether + packets should be prepended with four extra bytes (two flag + bytes and two protocol bytes). If disabled, it indicates that + the packets will be pure IP packets. Defaults to + <literal>no</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>VNetHeader=</varname></term> + <listitem><para>Takes a boolean. Configures + 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 + <literal>no</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>User=</varname></term> + <listitem><para>User to grant access to the + <filename>/dev/net/tun</filename> device.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Group=</varname></term> + <listitem><para>Group to grant access to the + <filename>/dev/net/tun</filename> device.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Tap] Section Options</title> + + <para>The [Tap] section only applies for + netdevs of kind <literal>tap</literal>, and accepts the same keys + as the [Tun] section.</para> + </refsect1> + + <refsect1> + <title>[WireGuard] Section Options</title> + + <para>The [WireGuard] section accepts the following + keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <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> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PrivateKeyFile=</varname></term> + <listitem> + <para>Takes an absolute path to a file which contains the Base64 encoded private key for the + interface. When this option is specified, then <varname>PrivateKey=</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. If + the path refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is + made to it and the key read from it.</para> + </listitem> + </varlistentry> + <varlistentry> + <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> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FirewallMark=</varname></term> + <listitem> + <para>Sets a firewall mark on outgoing WireGuard packets from this interface. Takes a number between 1 and 4294967295.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[WireGuardPeer] Section Options</title> + + <para>The [WireGuardPeer] section accepts the following + keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <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> + </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-network</literal> + with a <literal>0640</literal> file mode.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PresharedKeyFile=</varname></term> + <listitem> + <para>Takes an absolute path to a file which contains the Base64 encoded preshared key for the + peer. When this option is specified, then <varname>PresharedKey=</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. If the + path refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is + made to it and the key read from it.</para> + </listitem> + </varlistentry> + <varlistentry> + <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.</para> + <para>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> + <para>Note that this only affects "routing inside the network interface itself", + as in, which wireguard peer packets with a specific destination address are sent to, + and what source addresses are accepted from which peer.</para> + <para>To cause packets to be sent via wireguard in first place, a route needs + to be added, as well - either in the <literal>[Routes]</literal> section on the + <literal>.network</literal> matching the wireguard interface, or outside of networkd. + </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> + </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> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Bond] Section Options</title> + + <para>The [Bond] section accepts the following + key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Mode=</varname></term> + <listitem> + <para>Specifies one of the bonding policies. The default is + <literal>balance-rr</literal> (round robin). Possible values are + <literal>balance-rr</literal>, + <literal>active-backup</literal>, + <literal>balance-xor</literal>, + <literal>broadcast</literal>, + <literal>802.3ad</literal>, + <literal>balance-tlb</literal>, and + <literal>balance-alb</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TransmitHashPolicy=</varname></term> + <listitem> + <para>Selects the transmit hash policy to use for slave + selection in balance-xor, 802.3ad, and tlb modes. Possible + values are + <literal>layer2</literal>, + <literal>layer3+4</literal>, + <literal>layer2+3</literal>, + <literal>encap2+3</literal>, and + <literal>encap3+4</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>LACPTransmitRate=</varname></term> + <listitem> + <para>Specifies the rate with which link partner transmits + Link Aggregation Control Protocol Data Unit packets in + 802.3ad mode. Possible values are <literal>slow</literal>, + which requests partner to transmit LACPDUs every 30 seconds, + and <literal>fast</literal>, which requests partner to + transmit LACPDUs every second. The default value is + <literal>slow</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MIIMonitorSec=</varname></term> + <listitem> + <para>Specifies the frequency that Media Independent + Interface link monitoring will occur. A value of zero + disables MII link monitoring. This value is rounded down to + the nearest millisecond. The default value is 0.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UpDelaySec=</varname></term> + <listitem> + <para>Specifies the delay before a link is enabled after a + link up status has been detected. This value is rounded down + to a multiple of MIIMonitorSec. The default value is + 0.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DownDelaySec=</varname></term> + <listitem> + <para>Specifies the delay before a link is disabled after a + link down status has been detected. This value is rounded + down to a multiple of MIIMonitorSec. The default value is + 0.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>LearnPacketIntervalSec=</varname></term> + <listitem> + <para>Specifies the number of seconds between instances where the bonding + driver sends learning packets to each slave peer switch. + The valid range is 1–0x7fffffff; the default value is 1. This option + has an effect only for the balance-tlb and balance-alb modes.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AdSelect=</varname></term> + <listitem> + <para>Specifies the 802.3ad aggregation selection logic to use. Possible values are + <literal>stable</literal>, + <literal>bandwidth</literal> and + <literal>count</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AdActorSystemPriority=</varname></term> + <listitem> + <para>Specifies the 802.3ad actor system priority. Takes a number in the range 1—65535.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AdUserPortKey=</varname></term> + <listitem> + <para>Specifies the 802.3ad user defined portion of the port key. Takes a number in the range + 0–1023.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AdActorSystem=</varname></term> + <listitem> + <para>Specifies the 802.3ad system MAC address. This cannot be a null or multicast address. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>FailOverMACPolicy=</varname></term> + <listitem> + <para>Specifies whether the active-backup mode should set all slaves to + the same MAC address at the time of enslavement or, when enabled, to perform special handling of the + bond's MAC address in accordance with the selected policy. The default policy is none. + Possible values are + <literal>none</literal>, + <literal>active</literal> and + <literal>follow</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ARPValidate=</varname></term> + <listitem> + <para>Specifies whether or not ARP probes and replies should be + validated in any mode that supports ARP monitoring, or whether + non-ARP traffic should be filtered (disregarded) for link + monitoring purposes. Possible values are + <literal>none</literal>, + <literal>active</literal>, + <literal>backup</literal> and + <literal>all</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ARPIntervalSec=</varname></term> + <listitem> + <para>Specifies the ARP link monitoring frequency. A value of 0 disables ARP monitoring. The + default value is 0, and the default unit seconds. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ARPIPTargets=</varname></term> + <listitem> + <para>Specifies the IP addresses to use as ARP monitoring peers when + ARPIntervalSec is greater than 0. These are the targets of the ARP request + sent to determine the health of the link to the targets. + Specify these values in IPv4 dotted decimal format. At least one IP + address must be given for ARP monitoring to function. The + maximum number of targets that can be specified is 16. The + default value is no IP addresses. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ARPAllTargets=</varname></term> + <listitem> + <para>Specifies the quantity of ARPIPTargets that must be reachable + in order for the ARP monitor to consider a slave as being up. + This option affects only active-backup mode for slaves with + ARPValidate enabled. Possible values are + <literal>any</literal> and + <literal>all</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrimaryReselectPolicy=</varname></term> + <listitem> + <para>Specifies the reselection policy for the primary slave. This + affects how the primary slave is chosen to become the active slave + when failure of the active slave or recovery of the primary slave + occurs. This option is designed to prevent flip-flopping between + the primary slave and other slaves. Possible values are + <literal>always</literal>, + <literal>better</literal> and + <literal>failure</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ResendIGMP=</varname></term> + <listitem> + <para>Specifies the number of IGMP membership reports to be issued after + a failover event. One membership report is issued immediately after + the failover, subsequent packets are sent in each 200ms interval. + The valid range is 0–255. Defaults to 1. A value of 0 + prevents the IGMP membership report from being issued in response + to the failover event. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <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. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <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. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AllSlavesActive=</varname></term> + <listitem> + <para>Takes a boolean. Specifies that duplicate frames (received on inactive ports) + should be dropped when false, or delivered when true. Normally, bonding will drop + duplicate frames (received on inactive ports), which is desirable for + most users. But there are some times it is nice to allow duplicate + frames to be delivered. The default value is false (drop duplicate frames + received on inactive ports). + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DynamicTransmitLoadBalancing=</varname></term> + <listitem> + <para>Takes a boolean. Specifies if dynamic shuffling of flows is enabled. Applies only + for balance-tlb mode. Defaults to unset. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MinLinks=</varname></term> + <listitem> + <para>Specifies the minimum number of links that must be active before + asserting carrier. The default value is 0. + </para> + </listitem> + </varlistentry> + </variablelist> + + <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 [Xfrm] 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 false (the default), the xfrm interface must have an underlying device + which can be used for hardware offloading.</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 [VRF] 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 setting is compulsory.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>/etc/systemd/network/25-bridge.netdev</title> + + <programlisting>[NetDev] +Name=bridge0 +Kind=bridge</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-vlan1.netdev</title> + + <programlisting>[Match] +Virtualization=no + +[NetDev] +Name=vlan1 +Kind=vlan + +[VLAN] +Id=1</programlisting> + </example> + <example> + <title>/etc/systemd/network/25-ipip.netdev</title> + <programlisting>[NetDev] +Name=ipip-tun +Kind=ipip +MTUBytes=1480 + +[Tunnel] +Local=192.168.223.238 +Remote=192.169.224.239 +TTL=64</programlisting> + </example> + <example> + <title>/etc/systemd/network/1-fou-tunnel.netdev</title> + <programlisting>[NetDev] +Name=fou-tun +Kind=fou + +[FooOverUDP] +Port=5555 +Protocol=4 + </programlisting> + </example> + <example> + <title>/etc/systemd/network/25-fou-ipip.netdev</title> + <programlisting>[NetDev] +Name=ipip-tun +Kind=ipip + +[Tunnel] +Independent=yes +Local=10.65.208.212 +Remote=10.65.208.211 +FooOverUDP=yes +FOUDestinationPort=5555 + </programlisting> + </example> + <example> + <title>/etc/systemd/network/25-tap.netdev</title> + <programlisting>[NetDev] +Name=tap-test +Kind=tap + +[Tap] +MultiQueue=yes +PacketInfo=yes</programlisting> </example> + + <example> + <title>/etc/systemd/network/25-sit.netdev</title> + <programlisting>[NetDev] +Name=sit-tun +Kind=sit +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +Remote=10.65.223.239</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-6rd.netdev</title> + <programlisting>[NetDev] +Name=6rd-tun +Kind=sit +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +IPv6RapidDeploymentPrefix=2602::/24</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-gre.netdev</title> + <programlisting>[NetDev] +Name=gre-tun +Kind=gre +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +Remote=10.65.223.239</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-ip6gre.netdev</title> + <programlisting>[NetDev] +Name=ip6gre-tun +Kind=ip6gre + +[Tunnel] +Key=123</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-vti.netdev</title> + + <programlisting>[NetDev] +Name=vti-tun +Kind=vti +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +Remote=10.65.223.239</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-veth.netdev</title> + <programlisting>[NetDev] +Name=veth-test +Kind=veth + +[Peer] +Name=veth-peer</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-bond.netdev</title> + <programlisting>[NetDev] +Name=bond1 +Kind=bond + +[Bond] +Mode=802.3ad +TransmitHashPolicy=layer3+4 +MIIMonitorSec=1s +LACPTransmitRate=fast +</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-dummy.netdev</title> + <programlisting>[NetDev] +Name=dummy-test +Kind=dummy +MACAddress=12:34:56:78:9a:bc</programlisting> + </example> + <example> + <title>/etc/systemd/network/25-vrf.netdev</title> + <para>Create a VRF interface with table 42.</para> + <programlisting>[NetDev] +Name=vrf-test +Kind=vrf + +[VRF] +Table=42</programlisting> + </example> + + <example> + <title>/etc/systemd/network/25-macvtap.netdev</title> + <para>Create a MacVTap device.</para> + <programlisting>[NetDev] +Name=macvtap-test +Kind=macvtap + </programlisting> + </example> + <example> + <title>/etc/systemd/network/25-wireguard.netdev</title> + <programlisting>[NetDev] +Name=wg0 +Kind=wireguard + +[WireGuard] +PrivateKey=EEGlnEPYJV//kbvvIqxKkQwOiS+UENyPncC4bF46ong= +ListenPort=51820 + +[WireGuardPeer] +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>[NetDev] +Name=xfrm0 +Kind=xfrm + +[Xfrm] +Independent=yes</programlisting> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.network.xml b/man/systemd.network.xml new file mode 100644 index 0000000..6314a82 --- /dev/null +++ b/man/systemd.network.xml @@ -0,0 +1,3847 @@ +<?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-or-later --> + +<refentry id="systemd.network" conditional='ENABLE_NETWORKD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd.network</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.network</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.network</refname> + <refpurpose>Network configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>network</replaceable>.network</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A plain ini-style text file that encodes network configuration for matching network interfaces, + used by + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + See <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + + <para>The main network file must have the extension <filename>.network</filename>; other + extensions are ignored. Networks are applied to links whenever the links appear.</para> + + <para>The <filename>.network</filename> files are read from the files located in the system network + directories <filename>/usr/lib/systemd/network</filename> and + <filename>/usr/local/lib/systemd/network</filename>, the volatile runtime network directory + <filename>/run/systemd/network</filename> and the local administration network directory + <filename>/etc/systemd/network</filename>. All configuration files are collectively sorted and processed + in lexical order, regardless of the directories in which they live. However, files with identical + filenames replace each other. Files in <filename>/etc/</filename> have the highest priority, files in + <filename>/run/</filename> take precedence over files with the same name under + <filename>/usr/</filename>. This can be used to override a system-supplied configuration file with a local + file if needed. As a special case, an empty file (file size 0) or symlink with the same name pointing to + <filename>/dev/null</filename> disables the configuration file entirely (it is "masked").</para> + + <para>Along with the network file <filename>foo.network</filename>, a "drop-in" directory + <filename>foo.network.d/</filename> may exist. All files with the suffix + <literal>.conf</literal> from this directory will be parsed after the file itself is + parsed. This is useful to alter or add configuration settings, without having to modify the main + configuration file. Each drop-in file must have appropriate section headers.</para> + + <para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal> + directories can be placed in <filename>/usr/lib/systemd/network</filename> or + <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 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 + disabled for that interface by writing "1" to + <filename>/proc/sys/net/ipv6/conf/<replaceable>ifname</replaceable>/disable_ipv6</filename>. + </para> + </refsect1> + + <refsect1> + <title>[Match] Section Options</title> + + <para>The network file contains a [Match] section, which determines if a given network file may be + applied to a given device; and a [Network] section specifying how the device should be configured. The + first (in lexical order) of the network files that matches a given device is applied, all later files + are ignored, even if they match as well.</para> + + <para>A network file is said to match a network interface if all matches specified by the [Match] + section are satisfied. When a network file does not contain valid settings in [Match] 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'> + <xi:include href="systemd.link.xml" xpointer="mac-address" /> + <xi:include href="systemd.link.xml" xpointer="permanent-mac-address" /> + <xi:include href="systemd.link.xml" xpointer="path" /> + <xi:include href="systemd.link.xml" xpointer="driver" /> + <xi:include href="systemd.link.xml" xpointer="type" /> + <xi:include href="systemd.link.xml" xpointer="property" /> + + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching the device name, as exposed + by the udev property <literal>INTERFACE</literal>, or device's alternative names. If the + list is prefixed with a "!", the test is inverted.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>WLANInterfaceType=</varname></term> + <listitem> + <para>A whitespace-separated list of wireless network type. Supported values are + <literal>ad-hoc</literal>, <literal>station</literal>, <literal>ap</literal>, + <literal>ap-vlan</literal>, <literal>wds</literal>, <literal>monitor</literal>, + <literal>mesh-point</literal>, <literal>p2p-client</literal>, <literal>p2p-go</literal>, + <literal>p2p-device</literal>, <literal>ocb</literal>, and <literal>nan</literal>. If the + list is prefixed with a "!", the test is inverted. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SSID=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching the SSID of the currently + connected wireless LAN. If the list is prefixed with a "!", the test is inverted. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BSSID=</varname></term> + <listitem> + <para>A whitespace-separated list of hardware address of the currently connected wireless + LAN. Use full colon-, hyphen- or dot-delimited hexadecimal. See the example in + <varname>MACAddress=</varname>. 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 is reset.</para> + </listitem> + </varlistentry> + + <xi:include href="systemd.link.xml" xpointer="host" /> + <xi:include href="systemd.link.xml" xpointer="virtualization" /> + <xi:include href="systemd.link.xml" xpointer="kernel-command-line" /> + <xi:include href="systemd.link.xml" xpointer="kernel-version" /> + <xi:include href="systemd.link.xml" xpointer="architecture" /> + </variablelist> + + </refsect1> + + <refsect1> + <title>[Link] Section Options</title> + + <para> The [Link] section accepts the following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The hardware address to set for the device.</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.</para> + <para>Note that if IPv6 is enabled on the interface, and the MTU is chosen + below 1280 (the minimum MTU for IPv6) it will automatically be increased to this value.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ARP=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the ARP (low-level Address Resolution Protocol) + for this interface is enabled. When unset, the kernel's default will be used.</para> + <para> For example, disabling ARP is useful when creating multiple MACVLAN or VLAN virtual + interfaces atop a single lower-level physical interface, which will then only serve as a + link/"bridge" device aggregating traffic to the same physical link and not participate in + the network otherwise.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Multicast=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the multicast flag on the device is enabled.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AllMulticast=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the driver retrieves all multicast packets from the network. + This happens when multicast routing is enabled.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Unmanaged=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, no attempts are + made to bring up or configure matching links, equivalent to + when there are no matching network files. Defaults to + <literal>no</literal>.</para> + <para>This is useful for preventing later matching network + files from interfering with certain interfaces that are fully + controlled by other applications.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Group=</varname></term> + <listitem> + <para>Link groups are similar to port ranges found in managed switches. + When network interfaces are added to a numbered group, operations on + all the interfaces from that group can be performed at once. An unsigned + integer in the range 0—4294967294. Defaults to unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RequiredForOnline=</varname></term> + <listitem> + <para>Takes a boolean or a minimum operational state and an optional maximum operational state. + Please see <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for possible operational states. When <literal>yes</literal>, the network is deemed required when + determining whether the system is online when running + <command>systemd-networkd-wait-online</command>. When <literal>no</literal>, the network is ignored + when checking for online state. When a minimum operational state and an optional maximum operational + state are set, <literal>yes</literal> is implied, and this controls the minimum and maximum + operational state required for the network interface to be considered online. + Defaults to <literal>yes</literal>.</para> + + <para>The network will be brought up normally in all cases, but in + the event that there is no address being assigned by DHCP or the + cable is not plugged in, the link will simply remain offline and be + skipped automatically by <command>systemd-networkd-wait-online</command> + if <literal>RequiredForOnline=no</literal>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[SR-IOV] Section Options</title> + <para>The [SR-IOV] section accepts the following keys. Specify several [SR-IOV] sections to configure + several SR-IOVs. SR-IOV provides the ability to partition a single physical PCI resource into virtual + PCI functions which can then be injected into a VM. In the case of network VFs, SR-IOV improves + north-south network performance (that is, traffic with endpoints outside the host machine) by allowing + traffic to bypass the host machine’s network stack.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>VirtualFunction=</varname></term> + <listitem> + <para>Specifies a Virtual Function (VF), lightweight PCIe function designed solely to move data + in and out. Takes an unsigned integer in the range 0..2147483646. This option is compulsory.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>VLANId=</varname></term> + <listitem> + <para>Specifies VLAN ID of the virtual function. Takes an unsigned integer in the range 1..4095.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>QualityOfService=</varname></term> + <listitem> + <para>Specifies quality of service of the virtual function. Takes an unsigned integer in the range 1..4294967294.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>VLANProtocol=</varname></term> + <listitem> + <para>Specifies VLAN protocol of the virtual function. Takes <literal>802.1Q</literal> or + <literal>802.1ad</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MACSpoofCheck=</varname></term> + <listitem> + <para>Takes a boolean. Controls the MAC spoof checking. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>QueryReceiveSideScaling=</varname></term> + <listitem> + <para>Takes a boolean. Toggle the ability of querying the receive side scaling (RSS) + configuration of the virtual function (VF). The VF RSS information like RSS hash key may be + considered sensitive on some devices where this information is shared between VF and the + physical function (PF). When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Trust=</varname></term> + <listitem> + <para>Takes a boolean. Allows to set trust mode of the virtual function (VF). When set, VF + users can set a specific feature which may impact security and/or performance. When unset, + the kernel's default will be used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>LinkState=</varname></term> + <listitem> + <para>Allows to set the link state of the virtual function (VF). Takes a boolean or a + special value <literal>auto</literal>. Setting to <literal>auto</literal> means a + reflection of the physical function (PF) link state, <literal>yes</literal> lets the VF to + communicate with other VFs on this host even if the PF link state is down, + <literal>no</literal> causes the hardware to drop any packets sent by the VF. When unset, + the kernel's default will be used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>Specifies the MAC address for the virtual function.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Network] Section Options</title> + + <para>The [Network] section accepts the following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Description=</varname></term> + <listitem> + <para>A description of the device. This is only used for + presentation purposes.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DHCP=</varname></term> + <listitem> + <para>Enables DHCPv4 and/or DHCPv6 client support. Accepts + <literal>yes</literal>, <literal>no</literal>, + <literal>ipv4</literal>, or <literal>ipv6</literal>. Defaults + to <literal>no</literal>.</para> + + <para>Note that DHCPv6 will by default be triggered by Router + Advertisement, if that is enabled, regardless of this parameter. + By enabling DHCPv6 support explicitly, the DHCPv6 client will + be started regardless of the presence of routers on the link, + or what flags the routers pass. See + <literal>IPv6AcceptRA=</literal>.</para> + + <para>Furthermore, note that by default the domain name + specified through DHCP is not used for name resolution. + See option <option>UseDomains=</option> below.</para> + + <para>See the [DHCPv4] or [DHCPv6] sections below for further configuration options for the DHCP + client support.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DHCPServer=</varname></term> + <listitem> + <para>Takes a boolean. If set to <literal>yes</literal>, DHCPv4 server will be started. Defaults + to <literal>no</literal>. Further settings for the DHCP server may be set in the [DHCPServer] + section described below.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LinkLocalAddressing=</varname></term> + <listitem> + <para>Enables link-local address autoconfiguration. Accepts <literal>yes</literal>, + <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> + <term><varname>IPv6LinkLocalAddressGenerationMode=</varname></term> + <listitem> + <para>Specifies how IPv6 link local address is generated. Takes one of <literal>eui64</literal>, + <literal>none</literal>, <literal>stable-privacy</literal> and <literal>random</literal>. + When unset, the kernel's default will be used. Note that if <varname>LinkLocalAdressing=</varname> + not configured as <literal>ipv6</literal> then <varname>IPv6LinkLocalAddressGenerationMode=</varname> + is ignored.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv4LLRoute=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, sets up the route needed for + non-IPv4LL hosts to communicate with IPv4LL-only hosts. Defaults + to false. + </para> + </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>Specifies an optional address generation mode for the Stateless Address + Autoconfiguration (SLAAC). Supported modes are <literal>prefixstable</literal> and + <literal>static</literal>.</para> + + <para>When the mode is set to <literal>static</literal>, an IPv6 address must be + specified after a colon (<literal>:</literal>), and the lower bits of the supplied + address are combined with the upper bits of a prefix received in a Router Advertisement + (RA) message to form a complete address. Note that if multiple prefixes are received in an + RA message, or in multiple RA messages, addresses will be formed from each of them using + the supplied address. This mode implements SLAAC but uses a static interface identifier + instead of an identifier generated by using the EUI-64 algorithm. Because the interface + identifier is static, if Duplicate Address Detection detects that the computed address is a + duplicate (in use by another node on the link), then this mode will fail to provide an + address for that prefix. If an IPv6 address without mode is specified, then + <literal>static</literal> mode is assumed.</para> + + <para>When the mode is set to <literal>prefixstable</literal> the + <ulink url="https://tools.ietf.org/html/rfc7217">RFC 7217</ulink> algorithm for generating + interface identifiers will be used. This mode can optionally take an IPv6 address separated + with a colon (<literal>:</literal>). If an IPv6 address is specified, then an interface + identifier is generated only when a prefix received in an RA message matches the supplied + address.</para> + + <para>If no address generation mode is specified (which is the default), or a received + prefix does not match any of the addresses provided in <literal>prefixstable</literal> + mode, then the EUI-64 algorithm will be used to form an interface identifier for that + prefix. This mode is also SLAAC, but with a potentially stable interface identifier which + does not directly map to the interface's hardware address.</para> + + <para>Note that the <literal>prefixstable</literal> algorithm uses both the interface + name and MAC address as input to the hash to compute the interface identifier, so if either + of those are changed the resulting interface identifier (and address) will change, even if + the prefix received in the RA message has not changed.</para> + + <para>This setting can be specified multiple times. If an empty string is assigned, then + the all previous assignments are cleared.</para> + + <para>Examples: + <programlisting>IPv6Token=::1a:2b:3c:4d +IPv6Token=static:::1a:2b:3c:4d +IPv6Token=prefixstable +IPv6Token=prefixstable:2002:da8:1::</programlisting></para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LLMNR=</varname></term> + <listitem> + <para>Takes a boolean or <literal>resolve</literal>. When true, + enables <ulink + url="https://tools.ietf.org/html/rfc4795">Link-Local + Multicast Name Resolution</ulink> on the link. When set to + <literal>resolve</literal>, only resolution is enabled, + but not host registration and announcement. Defaults to + true. This setting is read by + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastDNS=</varname></term> + <listitem> + <para>Takes a boolean or <literal>resolve</literal>. When true, + enables <ulink + url="https://tools.ietf.org/html/rfc6762">Multicast + DNS</ulink> support on the link. When set to + <literal>resolve</literal>, only resolution is enabled, + but not host or service registration and + announcement. Defaults to false. This setting is read by + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DNSOverTLS=</varname></term> + <listitem> + <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. + 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 + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DNSSEC=</varname></term> + <listitem> + <para>Takes a boolean or <literal>allow-downgrade</literal>. When true, enables + <ulink url="https://tools.ietf.org/html/rfc4033">DNSSEC</ulink> + DNS validation support on the link. When set to + <literal>allow-downgrade</literal>, compatibility with + non-DNSSEC capable networks is increased, by automatically + turning off DNSSEC in this case. This option defines a + per-interface setting for + <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s + global <varname>DNSSEC=</varname> option. Defaults to + false. This setting is read by + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DNSSECNegativeTrustAnchors=</varname></term> + <listitem><para>A space-separated list of DNSSEC negative + trust anchor domains. If specified and DNSSEC is enabled, + look-ups done via the interface's DNS server will be subject + to the list of negative trust anchors, and not require + authentication for the specified domains, or anything below + it. Use this to disable DNSSEC authentication for specific + private domains, that cannot be proven valid using the + Internet DNS hierarchy. Defaults to the empty list. This + setting is read by + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LLDP=</varname></term> + <listitem> + <para>Controls support for Ethernet LLDP packet reception. LLDP is a link-layer protocol commonly + implemented on professional routers and bridges which announces which physical port a system is connected + to, as well as other related data. Accepts a boolean or the special value + <literal>routers-only</literal>. When true, incoming LLDP packets are accepted and a database of all LLDP + neighbors maintained. If <literal>routers-only</literal> is set only LLDP data of various types of routers + is collected and LLDP data about other types of devices ignored (such as stations, telephones and + others). If false, LLDP reception is disabled. Defaults to <literal>routers-only</literal>. Use + <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to query the + collected neighbor data. LLDP is only available on Ethernet links. See <varname>EmitLLDP=</varname> below + for enabling LLDP packet emission from the local system. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>EmitLLDP=</varname></term> + <listitem> + <para>Controls support for Ethernet LLDP packet emission. Accepts a boolean parameter or the special values + <literal>nearest-bridge</literal>, <literal>non-tpmr-bridge</literal> and + <literal>customer-bridge</literal>. Defaults to false, which turns off LLDP packet emission. If not false, + a short LLDP packet with information about the local system is sent out in regular intervals on the + link. The LLDP packet will contain information about the local hostname, the local machine ID (as stored + in <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>) and the + local interface name, as well as the pretty hostname of the system (as set in + <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>). LLDP + emission is only available on Ethernet links. Note that this setting passes data suitable for + identification of host to the network and should thus not be enabled on untrusted networks, where such + identification data should not be made available. Use this option to permit other systems to identify on + which interfaces they are connected to this system. The three special values control propagation of the + LLDP packets. The <literal>nearest-bridge</literal> setting permits propagation only to the nearest + connected bridge, <literal>non-tpmr-bridge</literal> permits propagation across Two-Port MAC Relays, but + not any other bridges, and <literal>customer-bridge</literal> permits propagation until a customer bridge + is reached. For details about these concepts, see <ulink + url="https://standards.ieee.org/findstds/standard/802.1AB-2016.html">IEEE 802.1AB-2016</ulink>. Note that + configuring this setting to true is equivalent to <literal>nearest-bridge</literal>, the recommended and + most restricted level of propagation. See <varname>LLDP=</varname> above for an option to enable LLDP + reception.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BindCarrier=</varname></term> + <listitem> + <para>A link name or a list of link names. When set, controls the behavior of the current + link. When all links in the list are in an operational down state, the current link is brought + down. When at least one link has carrier, the current interface is brought up. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Address=</varname></term> + <listitem> + <para>A static IPv4 or IPv6 address and its prefix length, + separated by a <literal>/</literal> character. Specify + this key more than once to configure several addresses. + The format of the address must be as described in + <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This is a short-hand for an [Address] section only + containing an Address key (see below). This option may be + specified more than once. + </para> + + <para>If the specified address is <literal>0.0.0.0</literal> (for IPv4) or <literal>::</literal> + (for IPv6), a new address range of the requested size is automatically allocated from a + system-wide pool of unused ranges. Note that the prefix length must be equal or larger than 8 for + IPv4, and 64 for IPv6. The allocated range is checked against all current network interfaces and + all known network configuration files to avoid address range conflicts. The default system-wide + pool consists of 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 for IPv4, and fd00::/8 for IPv6. + This functionality is useful to manage a large number of dynamically created network interfaces + with the same network configuration and automatic address range assignment.</para> + + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Gateway=</varname></term> + <listitem> + <para>The gateway address, which must be in the format + described in + <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This is a short-hand for a [Route] section only containing + a Gateway key. This option may be specified more than + once.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DNS=</varname></term> + <listitem> + <para>A DNS server address, which must be in the format + described in + <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This option may be specified more than once. Each address can optionally take a port number + separated with <literal>:</literal>, a network interface name or index separated with + <literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>. + When IPv6 address is specified with a port number, then the address must be in the square + brackets. That is, the acceptable full formats are + <literal>111.222.333.444:9953%ifname#example.com</literal> for IPv4 and + <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. This setting can be + specified multiple times. If an empty string is assigned, then the all previous assignments + are cleared. This setting is read by + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Domains=</varname></term> + <listitem> + <para>A whitespace-separated list of domains which should be resolved using the DNS servers on + this link. Each item in the list should be a domain name, optionally prefixed with a tilde + (<literal>~</literal>). The domains with the prefix are called "routing-only domains". The + domains without the prefix are called "search domains" and are first used as search suffixes for + extending single-label hostnames (hostnames containing no dots) to become fully qualified + domain names (FQDNs). If a single-label hostname is resolved on this interface, each of the + specified search domains are appended to it in turn, converting it into a fully qualified domain + name, until one of them may be successfully resolved.</para> + + <para>Both "search" and "routing-only" domains are used for routing of DNS queries: look-ups for hostnames + ending in those domains (hence also single label names, if any "search domains" are listed), are routed to + the DNS servers configured for this interface. The domain routing logic is particularly useful on + multi-homed hosts with DNS servers serving particular private DNS zones on each interface.</para> + + <para>The "routing-only" domain <literal>~.</literal> (the tilde indicating definition of a routing domain, + the dot referring to the DNS root domain which is the implied suffix of all valid DNS names) has special + effect. It causes all DNS traffic which does not match another configured domain routing entry to be routed + to DNS servers specified for this interface. This setting is useful to prefer a certain set of DNS servers + if a link on which they are connected is available.</para> + + <para>This setting is read by + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + "Search domains" correspond to the <varname>domain</varname> and <varname>search</varname> entries in + <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Domain name routing has no equivalent in the traditional glibc API, which has no concept of domain + name servers limited to a specific link.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DNSDefaultRoute=</varname></term> + <listitem> + <para>Takes a boolean argument. If true, this link's configured DNS servers are used for resolving domain + names that do not match any link's configured <varname>Domains=</varname> setting. If false, this link's + configured DNS servers are never used for such domains, and are exclusively used for resolving names that + match at least one of the domains configured on this link. If not specified defaults to an automatic mode: + queries not matching any link's configured domains will be routed to this link if it has no routing-only + domains configured.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>NTP=</varname></term> + <listitem> + <para>An NTP server address (either an IP address, or a hostname). This option may be specified more than once. This setting is read by + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPForward=</varname></term> + <listitem><para>Configures IP packet forwarding for the + system. If enabled, incoming packets on any network + interface will be forwarded to any other interfaces + according to the routing table. Takes a boolean, + or the values <literal>ipv4</literal> or + <literal>ipv6</literal>, which only enable IP packet + forwarding for the specified address family. This controls + the <filename>net.ipv4.ip_forward</filename> and + <filename>net.ipv6.conf.all.forwarding</filename> sysctl + options of the network interface (see <ulink + url="https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt">ip-sysctl.txt</ulink> + for details about sysctl options). Defaults to + <literal>no</literal>.</para> + + <para>Note: this setting controls a global kernel option, + and does so one way only: if a network that has this setting + enabled is set up the global setting is turned on. However, + it is never turned off again, even after all networks with + this setting enabled are shut down again.</para> + + <para>To allow IP packet forwarding only between specific + network interfaces use a firewall.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPMasquerade=</varname></term> + <listitem><para>Configures IP masquerading for the network + interface. If enabled, packets forwarded from the network + interface will be appear as coming from the local host. + Takes a boolean argument. Implies + <varname>IPForward=ipv4</varname>. Defaults to + <literal>no</literal>.</para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6PrivacyExtensions=</varname></term> + <listitem><para>Configures use of stateless temporary + addresses that change over time (see <ulink + url="https://tools.ietf.org/html/rfc4941">RFC 4941</ulink>, + Privacy Extensions for Stateless Address Autoconfiguration + in IPv6). Takes a boolean or the special values + <literal>prefer-public</literal> and + <literal>kernel</literal>. When true, enables the privacy + extensions and prefers temporary addresses over public + addresses. When <literal>prefer-public</literal>, enables the + privacy extensions, but prefers public addresses over + temporary addresses. When false, the privacy extensions + remain disabled. When <literal>kernel</literal>, the kernel's + default setting will be left in place. Defaults to + <literal>no</literal>.</para></listitem> + </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. 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. The default is to disable RA reception for bridge devices or when IP + forwarding is enabled, and to enable it otherwise. Cannot be enabled on bond devices and when link + local addressing is disabled.</para> + + <para>Further settings for the IPv6 RA support may be configured in the [IPv6AcceptRA] section, see + below.</para> + + <para>Also see <ulink + url="https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt">ip-sysctl.txt</ulink> in the kernel + 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 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> + <term><varname>IPv6DuplicateAddressDetection=</varname></term> + <listitem><para>Configures the amount of IPv6 Duplicate + Address Detection (DAD) probes to send. When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6HopLimit=</varname></term> + <listitem><para>Configures IPv6 Hop Limit. For each router that + forwards the packet, the hop limit is decremented by 1. When the + hop limit field reaches zero, the packet is discarded. + When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv4AcceptLocal=</varname></term> + <listitem><para>Takes a boolean. Accept packets with local source addresses. In combination + with suitable routing, this can be used to direct packets between two local interfaces over + the wire and have them accepted properly. When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv4ProxyARP=</varname></term> + <listitem><para>Takes a boolean. Configures proxy ARP for IPv4. Proxy ARP is the technique in which one host, + usually a router, answers ARP requests intended for another machine. By "faking" its identity, + the router accepts responsibility for routing packets to the "real" destination. See <ulink + url="https://tools.ietf.org/html/rfc1027">RFC 1027</ulink>. + When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6ProxyNDP=</varname></term> + <listitem><para>Takes a boolean. Configures proxy NDP for IPv6. Proxy NDP (Neighbor Discovery + Protocol) is a technique for IPv6 to allow routing of addresses to a different + destination when peers expect them to be present on a certain physical link. + In this case a router answers Neighbour Advertisement messages intended for + another machine by offering its own MAC address as destination. + Unlike proxy ARP for IPv4, it is not enabled globally, but will only send Neighbour + Advertisement messages for addresses in the IPv6 neighbor proxy table, + which can also be shown by <command>ip -6 neighbour show proxy</command>. + systemd-networkd will control the per-interface `proxy_ndp` switch for each configured + interface depending on this option. + When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6ProxyNDPAddress=</varname></term> + <listitem><para>An IPv6 address, for which Neighbour Advertisement messages will be + proxied. This option may be specified more than once. systemd-networkd will add the + <option>IPv6ProxyNDPAddress=</option> entries to the kernel's IPv6 neighbor proxy table. + This option implies <option>IPv6ProxyNDP=yes</option> but has no effect if + <option>IPv6ProxyNDP</option> has been set to false. When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6SendRA=</varname></term> + <listitem><para>Whether to enable or disable Router Advertisement sending on a link. Takes a + boolean value. When enabled, prefixes configured in [IPv6Prefix] sections and routes + configured in [IPv6RoutePrefix] sections are distributed as defined in the [IPv6SendRA] + section. If <varname>DHCPv6PrefixDelegation=</varname> is enabled, then the delegated + prefixes are also distributed. See <varname>DHCPv6PrefixDelegation=</varname> setting and the + [IPv6SendRA], [IPv6Prefix], [IPv6RoutePrefix], and [DHCPv6PrefixDelegation] sections for more + configuration options.</para></listitem> + </varlistentry> + <varlistentry> + <term><varname>DHCPv6PrefixDelegation=</varname></term> + <listitem><para>Takes a boolean value. When enabled, requests prefixes using a DHCPv6 client + configured on another link. By default, an address within each delegated prefix will be + assigned, and the prefixes will be announced through IPv6 Router Advertisement when + <varname>IPv6SendRA=</varname> is enabled. Such default settings can be configured in + [DHCPv6PrefixDelegation] section. Defaults to disabled.</para></listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6MTUBytes=</varname></term> + <listitem><para>Configures IPv6 maximum transmission unit (MTU). + An integer greater than or equal to 1280 bytes. When unset, the kernel's default will be used. + </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>Bridge=</varname></term> + <listitem> + <para>The name of the bridge to add the link to. See + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Bond=</varname></term> + <listitem> + <para>The name of the bond to add the link to. See + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>VRF=</varname></term> + <listitem> + <para>The name of the VRF to add the link to. See + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>VLAN=</varname></term> + <listitem> + <para>The name of a VLAN 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>IPVLAN=</varname></term> + <listitem> + <para>The name of a IPVLAN 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>MACVLAN=</varname></term> + <listitem> + <para>The name of a MACVLAN 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>VXLAN=</varname></term> + <listitem> + <para>The name of a VXLAN 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>Tunnel=</varname></term> + <listitem> + <para>The name of a Tunnel 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>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> + <para>Takes a boolean. Specifies the new active slave. The <literal>ActiveSlave=</literal> + option is only valid for following modes: + <literal>active-backup</literal>, + <literal>balance-alb</literal> and + <literal>balance-tlb</literal>. Defaults to false. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PrimarySlave=</varname></term> + <listitem> + <para>Takes a boolean. Specifies which slave is the primary device. The specified + device will always be the active slave while it is available. Only when the + primary is off-line will alternate devices be used. This is useful when + one slave is preferred over another, e.g. when one slave has higher throughput + than another. The <literal>PrimarySlave=</literal> option is only valid for + following modes: + <literal>active-backup</literal>, + <literal>balance-alb</literal> and + <literal>balance-tlb</literal>. Defaults to false. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ConfigureWithoutCarrier=</varname></term> + <listitem> + <para>Takes a boolean. Allows networkd to configure a specific link even if it has no carrier. + Defaults to false. If <option>IgnoreCarrierLoss=</option> is not explicitly set, it will + default to this value. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IgnoreCarrierLoss=</varname></term> + <listitem> + <para>Takes a boolean. Allows networkd to retain both the static and dynamic configuration + of the interface even if its carrier is lost. When unset, the value specified with + <option>ConfigureWithoutCarrier=</option> is used. + </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>no</literal>. + </para> + </listitem> + </varlistentry> + + </variablelist> + + </refsect1> + + <refsect1> + <title>[Address] Section Options</title> + + <para>An [Address] section accepts the following keys. Specify several [Address] + sections to configure several addresses.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Address=</varname></term> + <listitem> + <para>As in the [Network] section. This key is mandatory. Each [Address] section can contain one + <varname>Address=</varname> setting.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Peer=</varname></term> + <listitem> + <para>The peer address in a point-to-point connection. + Accepts the same format as the <varname>Address=</varname> + key.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Broadcast=</varname></term> + <listitem> + <para>The broadcast address, which must be in the format + described in + <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + This key only applies to IPv4 addresses. If it is not + given, it is derived from the <varname>Address=</varname> + key.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Label=</varname></term> + <listitem> + <para>An address label.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PreferredLifetime=</varname></term> + <listitem> + <para>Allows the default "preferred lifetime" of the address to be overridden. + Only three settings are accepted: <literal>forever</literal> or <literal>infinity</literal> + which is the default and means that the address never expires, and <literal>0</literal> which means + that the address is considered immediately "expired" and will not be used, + unless explicitly requested. A setting of PreferredLifetime=0 is useful for + addresses which are added to be used only by a specific application, + which is then configured to use them explicitly.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Scope=</varname></term> + <listitem> + <para>The scope of the address, which can be + <literal>global</literal> (valid everywhere on the network, even through a gateway), + <literal>link</literal> (only valid on this device, will not traverse a gateway) or + <literal>host</literal> (only valid within the device itself, e.g. 127.0.0.1) + or an unsigned integer in the range 0—255. + Defaults to <literal>global</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>HomeAddress=</varname></term> + <listitem> + <para>Takes a boolean. Designates this address the "home address" as defined in + <ulink url="https://tools.ietf.org/html/rfc6275">RFC 6275</ulink>. + Supported only on IPv6. Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DuplicateAddressDetection=</varname></term> + <listitem> + <para>Takes one of <literal>ipv4</literal>, <literal>ipv6</literal>, + <literal>both</literal>, <literal>none</literal>. When <literal>ipv4</literal>, + performs IPv4 Duplicate Address Detection. See + <ulink url="https://tools.ietf.org/html/rfc5227">RFC 5224</ulink>. + When <literal>ipv6</literal>, performs IPv6 Duplicate Address Detection. See + <ulink url="https://tools.ietf.org/html/rfc4862">RFC 4862</ulink>. + Defaults to <literal>ipv6</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ManageTemporaryAddress=</varname></term> + <listitem> + <para>Takes a boolean. If true the kernel manage temporary addresses created + from this one as template on behalf of Privacy Extensions + <ulink url="https://tools.ietf.org/html/rfc3041">RFC 3041</ulink>. For this to become + active, the use_tempaddr sysctl setting has to be set to a value greater than zero. + The given address needs to have a prefix length of 64. This flag allows using privacy + extensions in a manually configured network, just like if stateless auto-configuration + was active. Defaults to false. </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AddPrefixRoute=</varname></term> + <listitem> + <para>Takes a boolean. When true, the prefix route for the address is automatically added. + Defaults to true.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AutoJoin=</varname></term> + <listitem> + <para>Takes a boolean. Joining multicast group on ethernet level via + <command>ip maddr</command> command would not work if we have an Ethernet switch that does + IGMP snooping since the switch would not replicate multicast packets on ports that did not + have IGMP reports for the multicast addresses. Linux vxlan interfaces created via + <command>ip link add vxlan</command> or networkd's netdev kind vxlan have the group option + that enables then to do the required join. By extending ip address command with option + <literal>autojoin</literal> we can get similar functionality for openvswitch (OVS) vxlan + interfaces as well as other tunneling mechanisms that need to receive multicast traffic. + Defaults to <literal>no</literal>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Neighbor] Section Options</title> + <para>A [Neighbor] section accepts the following keys. The neighbor section adds a permanent, static + entry to the neighbor table (IPv6) or ARP table (IPv4) for the given hardware address on the links + matched for the network. Specify several [Neighbor] sections to configure several static neighbors. + </para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Address=</varname></term> + <listitem> + <para>The IP address of the neighbor.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LinkLayerAddress=</varname></term> + <listitem> + <para>The link layer address (MAC address or IP address) of the neighbor.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6AddressLabel] Section Options</title> + + <para>An [IPv6AddressLabel] section accepts the following keys. Specify several [IPv6AddressLabel] + sections to configure several address labels. IPv6 address labels are used for address selection. See + <ulink url="https://tools.ietf.org/html/rfc3484">RFC 3484</ulink>. Precedence is managed by userspace, + and only the label itself is stored in the kernel.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Label=</varname></term> + <listitem> + <para>The label for the prefix, an unsigned integer in the range 0–4294967294. + 0xffffffff is reserved. This setting is mandatory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Prefix=</varname></term> + <listitem> + <para>IPv6 prefix is an address with a prefix length, separated by a slash <literal>/</literal> character. + This key is mandatory. </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[RoutingPolicyRule] Section Options</title> + + <para>An [RoutingPolicyRule] section accepts the following keys. Specify several [RoutingPolicyRule] + sections to configure several rules.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>TypeOfService=</varname></term> + <listitem> + <para>Takes a number between 0 and 255 that specifies the type of service to match.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>From=</varname></term> + <listitem> + <para>Specifies the source address prefix to match. Possibly followed by a slash and the prefix length.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>To=</varname></term> + <listitem> + <para>Specifies the destination address prefix to match. Possibly followed by a slash and the prefix length.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FirewallMark=</varname></term> + <listitem> + <para>Specifies the iptables firewall mark value to match (a number between 1 and + 4294967295). Optionally, the firewall mask (also a number between 1 and 4294967295) can be + suffixed with a slash (<literal>/</literal>), e.g., <literal>7/255</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Table=</varname></term> + <listitem> + <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> + <term><varname>Priority=</varname></term> + <listitem> + <para>Specifies the priority of this rule. <varname>Priority=</varname> is an unsigned + integer. Higher number means lower priority, and rules get processed in order of increasing number.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IncomingInterface=</varname></term> + <listitem> + <para>Specifies incoming device to match. If the interface is loopback, the rule only matches packets originating from this host.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>OutgoingInterface=</varname></term> + <listitem> + <para>Specifies the outgoing device to match. The outgoing interface is only available for packets originating from local sockets that are bound to a device.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SourcePort=</varname></term> + <listitem> + <para>Specifies the source IP port or IP port range match in forwarding information base (FIB) rules. + A port range is specified by the lower and upper port separated by a dash. Defaults to unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DestinationPort=</varname></term> + <listitem> + <para>Specifies the destination IP port or IP port range match in forwarding information base (FIB) rules. + A port range is specified by the lower and upper port separated by a dash. Defaults to unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPProtocol=</varname></term> + <listitem> + <para>Specifies the IP protocol to match in forwarding information base (FIB) rules. Takes IP protocol name such as <literal>tcp</literal>, + <literal>udp</literal> or <literal>sctp</literal>, or IP protocol number such as <literal>6</literal> for <literal>tcp</literal> or + <literal>17</literal> for <literal>udp</literal>. + Defaults to unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>InvertRule=</varname></term> + <listitem> + <para>A boolean. Specifies whether the rule is 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> + <varlistentry> + <term><varname>User=</varname></term> + <listitem> + <para>Takes a username, a user ID, or a range of user IDs separated by a dash. Defaults to + unset.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SuppressPrefixLength=</varname></term> + <listitem> + <para>Takes a number <replaceable>N</replaceable> in the range 0-128 and rejects routing + decisions that have a prefix length of <replaceable>N</replaceable> or less. Defaults to + unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[NextHop] Section Options</title> + <para>The [NextHop] section is used to manipulate entries in the kernel's "nexthop" tables. The + [NextHop] section accepts the following keys. Specify several [NextHop] sections to configure several + hops.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Gateway=</varname></term> + <listitem> + <para>As in the [Network] section. This is mandatory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>The id of the nexthop (an unsigned integer). If unspecified or '0' then automatically chosen by kernel.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Route] Section Options</title> + <para>The [Route] section accepts the following keys. Specify several [Route] sections to configure + several routes.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Gateway=</varname></term> + <listitem> + <para>Takes the gateway address or the special values <literal>_dhcp4</literal> and + <literal>_ipv6ra</literal>. If <literal>_dhcp4</literal> or <literal>_ipv6ra</literal> is + set, then the gateway address provided by DHCPv4 or IPv6 RA is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GatewayOnLink=</varname></term> + <listitem> + <para>Takes a boolean. If set to true, the kernel does not have + to check if the gateway is reachable directly by the current machine (i.e., the kernel does + not need to check if the gateway is attached to the local network), so that we can insert the + route in the kernel table without it being complained about. Defaults to <literal>no</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Destination=</varname></term> + <listitem> + <para>The destination prefix of the route. Possibly + followed by a slash and the prefix length. If omitted, a + full-length host route is assumed.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Source=</varname></term> + <listitem> + <para>The source prefix of the route. Possibly followed by + a slash and the prefix length. If omitted, a full-length + host route is assumed.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Metric=</varname></term> + <listitem> + <para>The metric of the route (an unsigned integer).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPv6Preference=</varname></term> + <listitem> + <para>Specifies the route preference as defined in <ulink + url="https://tools.ietf.org/html/rfc4191">RFC 4191</ulink> for Router Discovery messages. Which + can be one of <literal>low</literal> the route has a lowest priority, <literal>medium</literal> + the route has a default priority or <literal>high</literal> the route has a highest priority. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Scope=</varname></term> + <listitem> + <para>The scope of the IPv4 route, which can be <literal>global</literal>, <literal>site</literal>, + <literal>link</literal>, <literal>host</literal>, or + <literal>nowhere</literal>:</para> + <itemizedlist> + <listitem><para><literal>global</literal> means the route can reach + hosts more than one hop away.</para></listitem> + + <listitem><para><literal>site</literal> means an interior route in + the local autonomous system.</para></listitem> + + <listitem><para><literal>link</literal> means the route can only + reach hosts on the local network (one hop away).</para></listitem> + + <listitem><para><literal>host</literal> means the route will not + leave the local machine (used for internal addresses like + 127.0.0.1).</para></listitem> + + <listitem><para><literal>nowhere</literal> means the destination + doesn't exist.</para></listitem> + </itemizedlist> + <para>For IPv4 route, defaults to <literal>host</literal> if <varname>Type=</varname> is + <literal>local</literal> or <literal>nat</literal>, + and <literal>link</literal> if <varname>Type=</varname> is + <literal>broadcast</literal>, <literal>multicast</literal>, or <literal>anycast</literal>. + In other cases, defaults to <literal>global</literal>. The value is + not used for IPv6.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PreferredSource=</varname></term> + <listitem> + <para>The preferred source address of the route. The address + must be in the format described in + <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Table=</varname></term> + <listitem> + <para>The table identifier for the route. Takes <literal>default</literal>, + <literal>main</literal>, <literal>local</literal> or a number between 1 and 4294967295. + The table can be retrieved using <command>ip route show table <replaceable>num</replaceable></command>. + If unset and <varname>Type=</varname> is <literal>local</literal>, <literal>broadcast</literal>, + <literal>anycast</literal>, or <literal>nat</literal>, then <literal>local</literal> is used. + In other cases, defaults to <literal>main</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <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>, <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. 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 + to the defined route are discarded and the ICMP message "Communication Administratively Prohibited" is + generated. If <literal>throw</literal>, route lookup in the current routing table will fail and the route + selection process will return to Routing Policy Database (RPDB). Defaults to <literal>unicast</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>InitialCongestionWindow=</varname></term> + <listitem> + <para>The TCP initial congestion window is used during the start of a TCP connection. + During the start of a TCP session, when a client requests a resource, the server's initial + congestion window determines how many packets will be sent during the initial burst of data + without waiting for acknowledgement. Takes a number between 1 and 1023. Note that 100 is + considered an extremely large value for this option. When unset, the kernel's default + (typically 10) will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>InitialAdvertisedReceiveWindow=</varname></term> + <listitem> + <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 number between 1 and 1023. Note that 100 is considered an extremely + large value for this option. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>QuickAck=</varname></term> + <listitem> + <para>Takes a boolean. When true enables TCP quick ack mode for the route. When unset, the kernel's default will be used. + </para> + </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 + route. The usual suffixes K, M, G, are supported and are + understood to the base of 1024.</para> + <para>Note that if IPv6 is enabled on the interface, and the MTU is chosen + below 1280 (the minimum MTU for IPv6) it will automatically be increased to this value.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>IPServiceType=</varname></term> + <listitem> + <para>Takes string; <literal>CS6</literal> or <literal>CS4</literal>. Used to set IP + service type to CS6 (network control) or CS4 (Realtime). Defaults to CS6.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MultiPathRoute=<replaceable>address</replaceable>[@<replaceable>name</replaceable>] [<replaceable>weight</replaceable>]</varname></term> + <listitem> + <para>Configures multipath route. Multipath routing is the technique of using multiple + alternative paths through a network. Takes gateway address. Optionally, takes a network + interface name or index separated with <literal>@</literal>, and a weight in 1..256 for + this multipath route separated with whitespace. This setting can be specified multiple + times. If an empty string is assigned, then the all previous assignments are cleared.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCPv4] Section Options</title> + <para>The [DHCPv4] section configures the DHCPv4 client, if it is enabled with the + <varname>DHCP=</varname> setting described above:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>UseDNS=</varname></term> + <listitem> + <para>When true (the default), the DNS servers received + from the DHCP server will be used and take precedence over + any statically configured ones.</para> + + <para>This corresponds to the <option>nameserver</option> + option in <citerefentry + project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </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 from the DHCP server will be used by + <filename>systemd-timesyncd.service</filename> and take precedence over any statically configured + ones.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseSIP=</varname></term> + <listitem> + <para>When true (the default), the SIP servers received from the DHCP server will be collected + and made available to client programs.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UseMTU=</varname></term> + <listitem> + <para>When true, the interface maximum transmission unit + from the DHCP server will be used on the current link. + If <varname>MTUBytes=</varname> is set, then this setting is ignored. + Defaults to false.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Anonymize=</varname></term> + <listitem> + <para>Takes a boolean. When true, the options sent to the DHCP server will + follow the <ulink url="https://tools.ietf.org/html/rfc7844">RFC 7844</ulink> + (Anonymity Profiles for DHCP Clients) to minimize disclosure of identifying information. + Defaults to false.</para> + + <para>This option should only be set to true when + <varname>MACAddressPolicy=</varname> is set to <literal>random</literal> + (see <citerefentry + project='man-pages'><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para> + + <para>Note that this configuration will overwrite others. + In concrete, the following variables will be ignored: + <varname>SendHostname=</varname>, <varname>ClientIdentifier=</varname>, + <varname>UseRoutes=</varname>, <varname>UseMTU=</varname>, + <varname>VendorClassIdentifier=</varname>, <varname>UseTimezone=</varname>.</para> + + <para>With this option enabled DHCP requests will mimic those generated by Microsoft Windows, in + order to reduce the ability to fingerprint and recognize installations. This means DHCP request + sizes will grow and lease data will be more comprehensive than normally, though most of the + requested data is not actually used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SendHostname=</varname></term> + <listitem> + <para>When true (the default), the machine's hostname will be sent to the DHCP server. + Note that the machine's hostname must consist only of 7-bit ASCII lower-case characters and + no spaces or dots, and be formatted as a valid DNS domain name. Otherwise, the hostname is not + sent even if this is set to true.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MUDURL=</varname></term> + <listitem> + <para>When configured, the specified Manufacturer Usage Description (MUD) URL will be sent to the + DHCPv4 server. Takes a URL of length up to 255 characters. A superficial verification that the + string is a valid URL will be performed. DHCPv4 clients are intended to have at most one MUD URL + associated with them. See <ulink url="https://tools.ietf.org/html/rfc8520">RFC 8520</ulink>. + </para> + + <para>MUD is an embedded software standard defined by the IETF that allows IoT device makers to + advertise device specifications, including the intended communication patterns for their device + when it connects to the network. The network can then use this to author a context-specific + access policy, so the device functions only within those parameters.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UseHostname=</varname></term> + <listitem> + <para>When true (the default), the hostname received from + the DHCP server will be set as the transient hostname of the system. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Hostname=</varname></term> + <listitem> + <para>Use this value for the hostname which is sent to the DHCP server, instead of machine's hostname. + Note that the specified hostname must consist only of 7-bit ASCII lower-case characters and + no spaces or dots, and be formatted as a valid DNS domain name.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseDomains=</varname></term> + <listitem> + <para>Takes a boolean, or the special value <literal>route</literal>. When true, the domain name + received from the DHCP server will be used as DNS search domain over this link, similar to the effect of + the <option>Domains=</option> setting. If set to <literal>route</literal>, the domain name received from + the DHCP server will be used for routing DNS queries only, but not for searching, similar to the effect of + the <option>Domains=</option> setting when the argument is prefixed with <literal>~</literal>. Defaults to + false.</para> + + <para>It is recommended to enable this option only on trusted networks, as setting this affects resolution + of all hostnames, in particular of single-label names. It is generally safer to use the supplied domain + only as routing domain, rather than as search domain, in order to not have it affect local resolution of + single-label names.</para> + + <para>When set to true, this setting corresponds to the <option>domain</option> option in <citerefentry + project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseRoutes=</varname></term> + <listitem> + <para>When true (the default), the static routes will be requested from the DHCP server and added to the + routing table with a metric of 1024, and a scope of "global", "link" or "host", depending on the route's + destination and gateway. If the destination is on the local host, e.g., 127.x.x.x, or the same as the + link's own address, the scope will be set to "host". Otherwise if the gateway is null (a direct route), a + "link" scope will be used. For anything else, scope defaults to "global".</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseGateway=</varname></term> + <listitem> + <para>When true, the gateway will be requested from the DHCP server and added to the routing table with a + metric of 1024, and a scope of "link". When unset, the value specified with <option>UseRoutes=</option> + is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseTimezone=</varname></term> + + <listitem><para>When true, the timezone received from the + DHCP server will be set as timezone of the local + system. Defaults to <literal>no</literal>.</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>. + If set to <literal>mac</literal>, the MAC address of the link is used. + If set to <literal>duid</literal>, an RFC4361-compliant Client ID, which is the combination of IAID and DUID (see below), is used. + If set to <literal>duid-only</literal>, only DUID is used, this may not be RFC compliant, but some setups may require to use this. + Defaults to <literal>duid</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>VendorClassIdentifier=</varname></term> + <listitem> + <para>The vendor class identifier used to identify vendor + type and configuration.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UserClass=</varname></term> + <listitem> + <para>A DHCPv4 client can use UserClass option to identify the type or category of user or applications + it represents. The information contained in this option is a string that represents the user class of which + the client is a member. Each class sets an identifying string of information to be used by the DHCP + service to classify clients. Takes a whitespace-separated list of strings.</para> + </listitem> + </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 + <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of possible values.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DUIDRawData=</varname></term> + <listitem> + <para>Override the global <varname>DUIDRawData</varname> setting for this network. See + <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of possible values.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IAID=</varname></term> + <listitem> + <para>The DHCP Identity Association Identifier (IAID) for the interface, a 32-bit unsigned integer.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RequestBroadcast=</varname></term> + <listitem> + <para>Request the server to use broadcast messages before + the IP address has been configured. This is necessary for + devices that cannot receive RAW packets, or that cannot + receive packets at all before an IP address has been + configured. On the other hand, this must not be enabled on + networks where broadcasts are filtered out.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouteMetric=</varname></term> + <listitem> + <para>Set the routing metric for routes specified by the DHCP server. Defaults to 1024.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouteTable=<replaceable>num</replaceable></varname></term> + <listitem> + <para>The table identifier for DHCP routes (a number between 1 and 4294967295, or 0 to unset). + The table can be retrieved using <command>ip route show table <replaceable>num</replaceable></command>. + </para> + <para>When used in combination with <varname>VRF=</varname>, the + VRF's routing table is used when this parameter is not specified. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouteMTUBytes=</varname></term> + <listitem> + <para>Specifies the MTU for the DHCP routes. Please see the [Route] section for further details.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ListenPort=</varname></term> + <listitem> + <para>Allow setting custom port for the DHCP client to listen on.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>FallbackLeaseLifetimeSec=</varname></term> + <listitem> + <para>Allows to set DHCPv4 lease lifetime when DHCPv4 server does not send the lease lifetime. + Takes one of <literal>forever</literal> or <literal>infinity</literal> means that the address + never expires. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendRelease=</varname></term> + <listitem> + <para>When true, the DHCPv4 client sends a DHCP release packet when it stops. + Defaults to true.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendDecline=</varname></term> + <listitem> + <para>A boolean. When <literal>true</literal>, the DHCPv4 client receives the IP address from the + DHCP server. After a new IP is received, the DHCPv4 client performs IPv4 Duplicate Address + Detection. If duplicate use is detected, the DHCPv4 client rejects the IP by sending a + DHCPDECLINE packet and tries to obtain an IP address again. See <ulink + url="https://tools.ietf.org/html/rfc5227">RFC 5224</ulink>. Defaults to + <literal>unset</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DenyList=</varname></term> + <listitem> + <para>A whitespace-separated list of IPv4 addresses. DHCP offers from servers in the list are rejected. Note that + if <varname>AllowList=</varname> is configured then <varname>DenyList=</varname> is ignored.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AllowList=</varname></term> + <listitem> + <para>A whitespace-separated list of IPv4 addresses. DHCP offers from servers in the list are accepted.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RequestOptions=</varname></term> + <listitem> + <para>When configured, allows to set arbitrary request options in the DHCPv4 request options list and will be + sent to the DHCPV4 server. A whitespace-separated list of integers in the range 1..254. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendOption=</varname></term> + <listitem> + <para>Send an arbitrary raw option in the DHCPv4 request. Takes a DHCP option number, data type + and data separated with a colon + (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>). + The option number must be an integer in the range 1..254. The type takes one of <literal>uint8</literal>, + <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>, or + <literal>string</literal>. Special characters in the data string may be escaped using + <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style + escapes</ulink>. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendVendorOption=</varname></term> + <listitem> + <para>Send an arbitrary vendor option in the DHCPv4 request. Takes a DHCP option number, data type + and data separated with a colon + (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>). + The option number must be an integer in the range 1..254. The type takes one of <literal>uint8</literal>, + <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>, or + <literal>string</literal>. Special characters in the data string may be escaped using + <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style + escapes</ulink>. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCPv6] Section Options</title> + <para>The [DHCPv6] 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 [DHCPv4] section.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouteMetric=</varname></term> + <listitem> + <para>Set the routing metric for routes specified by the DHCP server. Defaults to 1024.</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 + a rapid two-message exchange (solicit and reply). When the rapid commit option is enabled by both + the DHCPv6 client and the DHCPv6 server, the two-message exchange is used, rather than the default + four-message exchange (solicit, advertise, request, and reply). The two-message exchange provides + faster client configuration and is beneficial in environments in which networks are under a heavy load. + See <ulink url="https://tools.ietf.org/html/rfc3315#section-17.2.1">RFC 3315</ulink> for details. + Defaults to true.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MUDURL=</varname></term> + <listitem> + <para>When configured, the specified Manufacturer Usage Description (MUD) URL will be sent to + the DHCPV6 server. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the + [DHCPv4] section described above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RequestOptions=</varname></term> + <listitem> + <para>When configured, allows to set arbitrary request options in the DHCPv6 request options list + that will be sent to the DHCPV6 server. A whitespace-separated list of integers in the range + 1..254. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendVendorOption=</varname></term> + <listitem> + <para>Send an arbitrary vendor option in the DHCPv6 request. Takes an enterprise identifier, DHCP + option number, data type, and data separated with a colon (<literal><replaceable>enterprise + identifier</replaceable>:<replaceable>option</replaceable>:<replaceable>type</replaceable>: + <replaceable>value</replaceable></literal>). Enterprise identifier is an unsigned integer in the + range 1–4294967294. The option number must be an integer in the range 1–254. Data type takes one + of <literal>uint8</literal>, <literal>uint16</literal>, <literal>uint32</literal>, + <literal>ipv4address</literal>, <literal>ipv6address</literal>, or + <literal>string</literal>. Special characters in the data string may be escaped using <ulink + url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style + escapes</ulink>. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ForceDHCPv6PDOtherInformation=</varname></term> + <listitem> + <para>Takes a boolean that enforces DHCPv6 stateful mode when the 'Other information' bit is set in + Router Advertisement messages. By default setting only the 'O' bit in Router Advertisements + makes DHCPv6 request network information in a stateless manner using a two-message Information + Request and Information Reply message exchange. + <ulink url="https://tools.ietf.org/html/rfc7084">RFC 7084</ulink>, requirement WPD-4, updates + this behavior for a Customer Edge router so that stateful DHCPv6 Prefix Delegation is also + requested when only the 'O' bit is set in Router Advertisements. This option enables such a CE + behavior as it is impossible to automatically distinguish the intention of the 'O' bit otherwise. + By default this option is set to 'false', enable it if no prefixes are delegated when the device + should be acting as a CE router.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrefixDelegationHint=</varname></term> + <listitem> + <para>Takes an IPv6 address with prefix length in the same format as the + <varname>Address=</varname> in the [Network] section. The DHCPv6 client will include a prefix + hint in the DHCPv6 solicitation sent to the server. The prefix length must be in the range + 1–128. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>WithoutRA=</varname></term> + <listitem> + <para>Allows DHCPv6 client to start without router advertisements's managed or other address + configuration flag. Takes one of <literal>solicit</literal> or + <literal>information-request</literal>. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendOption=</varname></term> + <listitem> + <para>As in the [DHCPv4] section, however because DHCPv6 uses 16-bit fields to store + option numbers, the option number is an integer in the range 1..65536.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UserClass=</varname></term> + <listitem> + <para>A DHCPv6 client can use User Class option to identify the type or category of user or applications + it represents. The information contained in this option is a string that represents the user class of which + the client is a member. Each class sets an identifying string of information to be used by the DHCP + service to classify clients. Special characters in the data string may be escaped using + <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style + escapes</ulink>. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Takes a whitespace-separated list of strings. Note that + currently <constant>NUL</constant> bytes are not allowed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>VendorClass=</varname></term> + <listitem> + <para>A DHCPv6 client can use VendorClass option to identify the vendor that + manufactured the hardware on which the client is running. The information + contained in the data area of this option is contained in one or more opaque + fields that identify details of the hardware configuration. Takes a + whitespace-separated list of strings.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCPv6PrefixDelegation] Section Options</title> + <para>The [DHCPv6PrefixDelegation] section configures delegated prefixes assigned by DHCPv6 server. + The settings in this section are used only when <varname>DHCPv6PrefixDelegation=</varname> setting + is enabled.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>SubnetId=</varname></term> + <listitem> + <para>Configure a specific subnet ID on the interface from a (previously) received prefix + delegation. You can either set "auto" (the default) or a specific subnet ID (as defined in + <ulink url="https://tools.ietf.org/html/rfc4291#section-2.5.4">RFC 4291</ulink>, section + 2.5.4), in which case the allowed value is hexadecimal, from 0 to 0x7fffffffffffffff + inclusive.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Announce=</varname></term> + <listitem> + <para>Takes a boolean. When enabled, and <varname>IPv6SendRA=</varname> in [Network] section + is enabled, the delegated prefixes are distributed through the IPv6 Router Advertisement. + Defaults to yes.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Assign=</varname></term> + <listitem> + <para>Takes a boolean. Specifies whether to add an address from the delegated prefixes which + are received from the WAN interface by the DHCPv6 Prefix Delegation. When true (on LAN + interfce), the EUI-64 algorithm will be used by default to form an interface identifier from + the delegated prefixes. See also <varname>Token=</varname> setting below. Defaults to yes. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Token=</varname></term> + <listitem> + <para>Specifies an optional address generation mode for assigning an address in each + delegated prefix. Takes an IPv6 address. When set, the lower bits of the supplied address is + combined with the upper bits of each delegatad prefix received from the WAN interface by the + DHCPv6 Prefix Delegation to form a complete address. When <varname>Assign=</varname> is + disabled, this setting is ignored. When unset, the EUI-64 algorithm will be used to form + addresses. Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6AcceptRA] Section Options</title> + <para>The [IPv6AcceptRA] section configures the IPv6 Router Advertisement (RA) client, if it is enabled + with the <varname>IPv6AcceptRA=</varname> setting described above:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>UseDNS=</varname></term> + <listitem> + <para>When true (the default), the DNS servers received in the Router Advertisement will be used and take + precedence over any statically configured ones.</para> + + <para>This corresponds to the <option>nameserver</option> option in <citerefentry + project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UseDomains=</varname></term> + <listitem> + <para>Takes a boolean, or the special value <literal>route</literal>. When true, the domain name + received via IPv6 Router Advertisement (RA) will be used as DNS search domain over this link, similar to + the effect of the <option>Domains=</option> setting. If set to <literal>route</literal>, the domain name + received via IPv6 RA will be used for routing DNS queries only, but not for searching, similar to the + effect of the <option>Domains=</option> setting when the argument is prefixed with + <literal>~</literal>. Defaults to false.</para> + + <para>It is recommended to enable this option only on trusted networks, as setting this affects resolution + of all hostnames, in particular of single-label names. It is generally safer to use the supplied domain + only as routing domain, rather than as search domain, in order to not have it affect local resolution of + single-label names.</para> + + <para>When set to true, this setting corresponds to the <option>domain</option> option in <citerefentry + project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouteTable=<replaceable>num</replaceable></varname></term> + <listitem> + <para>The table identifier for the routes received in the Router Advertisement + (a number between 1 and 4294967295, or 0 to unset). + The table can be retrieved using <command>ip route show table <replaceable>num</replaceable></command>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UseAutonomousPrefix=</varname></term> + <listitem> + <para>When true (the default), the autonomous prefix received in the Router Advertisement will be used and take + precedence over any statically configured ones.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>UseOnLinkPrefix=</varname></term> + <listitem> + <para>When true (the default), the onlink prefix received in the Router Advertisement will be + used and takes precedence over any statically configured ones.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DenyList=</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> + + <varlistentry> + <term><varname>DHCPv6Client=</varname></term> + <listitem> + <para>Takes a boolean, or the special value <literal>always</literal>. When true or + <literal>always</literal>, the DHCPv6 client will be started when the RA has the managed or + other information flag. If set to <literal>always</literal>, the DHCPv6 client will also be + started in managed mode when neither managed nor other information flag is set in the RA. + Defaults to true.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCPServer] Section Options</title> + <para>The [DHCPServer] section contains settings for the DHCP server, if enabled via the + <varname>DHCPServer=</varname> option described above:</para> + + <variablelist class='network-directives'> + + <varlistentry> + <term><varname>PoolOffset=</varname></term> + <term><varname>PoolSize=</varname></term> + + <listitem><para>Configures the pool of addresses to hand out. The pool + is a contiguous sequence of IP addresses in the subnet configured for + the server address, which does not include the subnet nor the broadcast + address. <varname>PoolOffset=</varname> takes the offset of the pool + from the start of subnet, or zero to use the default value. + <varname>PoolSize=</varname> takes the number of IP addresses in the + pool or zero to use the default value. By default, the pool starts at + the first address after the subnet address and takes up the rest of + the subnet, excluding the broadcast address. If the pool includes + the server address (the default), this is reserved and not handed + out to clients.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultLeaseTimeSec=</varname></term> + <term><varname>MaxLeaseTimeSec=</varname></term> + + <listitem><para>Control the default and maximum DHCP lease + time to pass to clients. These settings take time values in seconds or + another common time unit, depending on the suffix. The default + lease time is used for clients that did not ask for a specific + lease time. If a client asks for a lease time longer than the + maximum lease time, it is automatically shortened to the + specified time. The default lease time defaults to 1h, the + maximum lease time to 12h. Shorter lease times are beneficial + if the configuration data in DHCP leases changes frequently + and clients shall learn the new settings with shorter + latencies. Longer lease times reduce the generated DHCP + network traffic.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EmitDNS=</varname></term> + <term><varname>DNS=</varname></term> + + <listitem><para><varname>EmitDNS=</varname> takes a boolean. Configures whether the DHCP leases + handed out to clients shall contain DNS server information. Defaults to <literal>yes</literal>. The + DNS servers to pass to clients may be configured with the <varname>DNS=</varname> option, which takes + a list of IPv4 addresses. If the <varname>EmitDNS=</varname> option is enabled but no servers + configured, the servers are automatically propagated from an "uplink" interface that has appropriate + servers set. The "uplink" interface is determined by the default route of the system with the highest + priority. Note that this information is acquired at the time the lease is handed out, and does not + take uplink interfaces into account that acquire DNS server information at a later point. If no + suitable uplinkg interface is found the DNS server data from <filename>/etc/resolv.conf</filename> is + used. Also, note that the leases are not refreshed if the uplink network configuration changes. To + ensure clients regularly acquire the most current uplink DNS server information, it is thus advisable + to shorten the DHCP lease time via <varname>MaxLeaseTimeSec=</varname> described + above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EmitNTP=</varname></term> + <term><varname>NTP=</varname></term> + <term><varname>EmitSIP=</varname></term> + <term><varname>SIP=</varname></term> + <term><varname>EmitPOP3=</varname></term> + <term><varname>POP3=</varname></term> + <term><varname>EmitSMTP=</varname></term> + <term><varname>SMTP=</varname></term> + <term><varname>EmitLPR=</varname></term> + <term><varname>LPR=</varname></term> + + <listitem><para>Similar to the <varname>EmitDNS=</varname> and <varname>DNS=</varname> settings + described above, these settings configure whether and what server information for the indicate + protocol shall be emitted as part of the DHCP lease. The same syntax, propagation semantics and + defaults apply as for <varname>EmitDNS=</varname> and <varname>DNS=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EmitRouter=</varname></term> + + <listitem><para>Similar to the <varname>EmitDNS=</varname> + setting described above, this setting configures whether the + DHCP lease should contain the router option. The same syntax, + propagation semantics and defaults apply as for + <varname>EmitDNS=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EmitTimezone=</varname></term> + <term><varname>Timezone=</varname></term> + + <listitem><para>Takes a boolean. Configures whether the DHCP leases handed out + to clients shall contain timezone information. Defaults to <literal>yes</literal>. The + <varname>Timezone=</varname> setting takes a timezone string + (such as <literal>Europe/Berlin</literal> or + <literal>UTC</literal>) to pass to clients. If no explicit + timezone is set, the system timezone of the local host is + propagated, as determined by the + <filename>/etc/localtime</filename> symlink.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendOption=</varname></term> + <listitem> + <para>Send a raw option with value via DHCPv4 server. Takes a DHCP option number, data type + and data (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>). + The option number is an integer in the range 1..254. The type takes one of <literal>uint8</literal>, + <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>, <literal>ipv6address</literal>, or + <literal>string</literal>. Special characters in the data string may be escaped using + <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style + escapes</ulink>. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SendVendorOption=</varname></term> + <listitem> + <para>Send a vendor option with value via DHCPv4 server. Takes a DHCP option number, data type + and data (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>). + The option number is an integer in the range 1..254. The type takes one of <literal>uint8</literal>, + <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>, or + <literal>string</literal>. Special characters in the data string may be escaped using + <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style + escapes</ulink>. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6SendRA] Section Options</title> + <para>The [IPv6SendRA] section contains settings for sending IPv6 Router Advertisements and whether + to act as a router, if enabled via the <varname>IPv6SendRA=</varname> option described above. IPv6 + network prefixes or routes are defined with one or more [IPv6Prefix] or [IPv6RoutePrefix] sections. + </para> + + <variablelist class='network-directives'> + + <varlistentry> + <term><varname>Managed=</varname></term> + <term><varname>OtherInformation=</varname></term> + + <listitem><para>Takes a boolean. Controls whether a DHCPv6 server is used to acquire IPv6 + addresses on the network link when <varname>Managed=</varname> + is set to <literal>true</literal> or if only additional network + information can be obtained via DHCPv6 for the network link when + <varname>OtherInformation=</varname> is set to + <literal>true</literal>. Both settings default to + <literal>false</literal>, which means that a DHCPv6 server is not being + used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouterLifetimeSec=</varname></term> + + <listitem><para>Takes a timespan. Configures the IPv6 router lifetime in seconds. When set to + 0, the host is not acting as a router. Defaults to 30 minutes.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RouterPreference=</varname></term> + + <listitem><para>Configures IPv6 router preference if + <varname>RouterLifetimeSec=</varname> is non-zero. Valid values are + <literal>high</literal>, <literal>medium</literal> and + <literal>low</literal>, with <literal>normal</literal> and + <literal>default</literal> added as synonyms for + <literal>medium</literal> just to make configuration easier. See + <ulink url="https://tools.ietf.org/html/rfc4191">RFC 4191</ulink> + for details. Defaults to <literal>medium</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EmitDNS=</varname></term> + <term><varname>DNS=</varname></term> + + <listitem><para><varname>DNS=</varname> specifies a list of recursive DNS server IPv6 addresses that + are distributed via Router Advertisement messages when <varname>EmitDNS=</varname> is + true. <varname>DNS=</varname> also takes special value <literal>_link_local</literal>; in that case + the IPv6 link local address is distributed. If <varname>DNS=</varname> is empty, DNS servers are read + from the [Network] section. If the [Network] section does not contain any DNS servers either, DNS + servers from the uplink with the highest priority default route are used. When + <varname>EmitDNS=</varname> is false, no DNS server information is sent in Router Advertisement + messages. <varname>EmitDNS=</varname> defaults to true.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>EmitDomains=</varname></term> + <term><varname>Domains=</varname></term> + + <listitem><para>A list of DNS search domains distributed via Router Advertisement messages when + <varname>EmitDomains=</varname> is true. If <varname>Domains=</varname> is empty, DNS search domains + are read from the [Network] section. If the [Network] section does not contain any DNS search domains + either, DNS search domains from the uplink with the highest priority default route are used. When + <varname>EmitDomains=</varname> is false, no DNS search domain information is sent in Router + Advertisement messages. <varname>EmitDomains=</varname> defaults to true.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DNSLifetimeSec=</varname></term> + + <listitem><para>Lifetime in seconds for the DNS server addresses listed + in <varname>DNS=</varname> and search domains listed in + <varname>Domains=</varname>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6Prefix] Section Options</title> + <para>One or more [IPv6Prefix] sections contain the IPv6 prefixes that are announced via Router + Advertisements. See <ulink url="https://tools.ietf.org/html/rfc4861">RFC 4861</ulink> for further + details.</para> + + <variablelist class='network-directives'> + + <varlistentry> + <term><varname>AddressAutoconfiguration=</varname></term> + <term><varname>OnLink=</varname></term> + + <listitem><para>Takes a boolean to specify whether IPv6 addresses can be + autoconfigured with this prefix and whether the prefix can be used for + onlink determination. Both settings default to <literal>true</literal> + in order to ease configuration. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Prefix=</varname></term> + + <listitem><para>The IPv6 prefix that is to be distributed to hosts. Similarly to configuring static + IPv6 addresses, the setting is configured as an IPv6 prefix and its prefix length, separated by a + <literal>/</literal> character. Use multiple [IPv6Prefix] sections to configure multiple IPv6 + prefixes since prefix lifetimes, address autoconfiguration and onlink status may differ from one + prefix to another.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PreferredLifetimeSec=</varname></term> + <term><varname>ValidLifetimeSec=</varname></term> + + <listitem><para>Preferred and valid lifetimes for the prefix measured in + seconds. <varname>PreferredLifetimeSec=</varname> defaults to 604800 + seconds (one week) and <varname>ValidLifetimeSec=</varname> defaults + to 2592000 seconds (30 days).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Assign=</varname></term> + <listitem><para>Takes a boolean. When true, adds an address from the prefix. Default to false. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6RoutePrefix] Section Options</title> + <para>One or more [IPv6RoutePrefix] sections contain the IPv6 + prefix routes that are announced via Router Advertisements. See + <ulink url="https://tools.ietf.org/html/rfc4191">RFC 4191</ulink> + for further details.</para> + + <variablelist class='network-directives'> + + <varlistentry> + <term><varname>Route=</varname></term> + + <listitem><para>The IPv6 route that is to be distributed to hosts. Similarly to configuring static + IPv6 routes, the setting is configured as an IPv6 prefix routes and its prefix route length, + separated by a <literal>/</literal> character. Use multiple [IPv6PrefixRoutes] sections to configure + multiple IPv6 prefix routes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LifetimeSec=</varname></term> + + <listitem><para>Lifetime for the route prefix measured in + seconds. <varname>LifetimeSec=</varname> defaults to 604800 seconds (one week). + </para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[Bridge] Section Options</title> + <para>The [Bridge] section accepts the following keys:</para> + <variablelist class='network-directives'> + <varlistentry> + <term><varname>UnicastFlood=</varname></term> + <listitem> + <para>Takes a boolean. Controls whether the bridge should flood + traffic for which an FDB entry is missing and the destination + is unknown through this port. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastFlood=</varname></term> + <listitem> + <para>Takes a boolean. Controls whether the bridge should flood + traffic for which an MDB entry is missing and the destination + is unknown through this port. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastToUnicast=</varname></term> + <listitem> + <para>Takes a boolean. Multicast to unicast works on top of the multicast snooping feature of + the bridge. Which means unicast copies are only delivered to hosts which are interested in it. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>NeighborSuppression=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether ARP and ND neighbor suppression is enabled for + this port. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Learning=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether MAC address learning is enabled for + this port. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>HairPin=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether traffic may be sent back out of the port on which it + was received. When this flag is false, then the bridge will not forward traffic back out of the + receiving port. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UseBPDU=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether STP Bridge Protocol Data Units will be + processed by the bridge port. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FastLeave=</varname></term> + <listitem> + <para>Takes a boolean. This flag allows the bridge to immediately stop multicast + traffic on a port that receives an IGMP Leave message. It is only used with + IGMP snooping if enabled on the bridge. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AllowPortToBeRoot=</varname></term> + <listitem> + <para>Takes a boolean. Configures whether a given port is allowed to + become a root port. Only used when STP is enabled on the bridge. + When unset, the kernel's default will be used.</para> + </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. + Each port in a bridge may have a different speed and the cost + is used to decide which link to use. Faster interfaces + should have lower costs. It is an integer value between 1 and + 65535.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Priority=</varname></term> + <listitem> + <para>Sets the "priority" of sending packets on this interface. + Each port in a bridge may have a different priority which is used + to decide which link to use. Lower value means higher priority. + It is an integer value between 0 to 63. Networkd does not set any + default, meaning the kernel default value of 32 is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> + <title>[BridgeFDB] Section Options</title> + <para>The [BridgeFDB] section manages the forwarding database table of a port and accepts the following + keys. Specify several [BridgeFDB] sections to configure several static MAC table entries.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>As in the [Network] section. This key is mandatory.</para> + </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 + omitted, no VLAN ID information is appended to the new static MAC + 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> + <refsect1> + <title>[BridgeMDB] Section Options</title> + <para>The [BridgeMDB] section manages the multicast membership entries forwarding database table of a port and accepts the following + keys. Specify several [BridgeMDB] sections to configure several permanent multicast membership entries.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MulticastGroupAddress=</varname></term> + <listitem> + <para>Specifies the IPv4 or IPv6 multicast group address to add. This setting is mandatory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>VLANId=</varname></term> + <listitem> + <para>The VLAN ID for the new entry. Valid ranges are 0 (no VLAN) to 4094. Optional, defaults to 0.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[LLDP] Section Options</title> + <para>The [LLDP] section manages the Link Layer Discovery Protocol (LLDP) and accepts the following + keys:</para> + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MUDURL=</varname></term> + <listitem> + <para>When configured, the specified Manufacturer Usage Descriptions (MUD) URL will be sent in + LLDP packets. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the + [DHCPv4] section described above.</para> + + <para>The MUD URLs received via LLDP packets are saved and can be read using the + <function>sd_lldp_neighbor_get_mud_url()</function> function.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[CAN] Section Options</title> + <para>The [CAN] section manages the Controller Area Network (CAN bus) and accepts the + following keys:</para> + <variablelist class='network-directives'> + <varlistentry> + <term><varname>BitRate=</varname></term> + <listitem> + <para>The bitrate of CAN device in bits per second. The usual SI prefixes (K, M) with the base of 1000 can + be used here. Takes a number in the range 1..4294967295.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SamplePoint=</varname></term> + <listitem> + <para>Optional sample point in percent with one decimal (e.g. <literal>75%</literal>, + <literal>87.5%</literal>) or permille (e.g. <literal>875‰</literal>).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DataBitRate=</varname></term> + <term><varname>DataSamplePoint=</varname></term> + <listitem> + <para>The bitrate and sample point for the data phase, if CAN-FD is used. These settings are + analogous to the <varname>BitRate=</varname> and <varname>SamplePoint=</varname> keys.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FDMode=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, CAN-FD mode is enabled for the interface. + Note, that a bitrate and optional sample point should also be set for the CAN-FD data phase using + the <varname>DataBitRate=</varname> and <varname>DataSamplePoint=</varname> keys.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>FDNonISO=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, non-ISO CAN-FD mode is enabled for the + interface. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>RestartSec=</varname></term> + <listitem> + <para>Automatic restart delay time. If set to a non-zero value, a restart of the CAN controller will be + triggered automatically in case of a bus-off condition after the specified delay time. Subsecond delays can + be specified using decimals (e.g. <literal>0.1s</literal>) or a <literal>ms</literal> or + <literal>us</literal> postfix. Using <literal>infinity</literal> or <literal>0</literal> will turn the + automatic restart off. By default automatic restart is disabled.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Termination=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, the termination resistor will be selected for + the bias network. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TripleSampling=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, three samples (instead of one) are used to determine + the value of a received bit by majority rule. When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ListenOnly=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, listen-only mode is enabled. When the + interface is in listen-only mode, the interface neither transmit CAN frames nor send ACK + bit. Listen-only mode is important to debug CAN networks without interfering with the + communication or acknowledge the CAN frame. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[QDisc] Section Options</title> + <para>The [QDisc] section manages the traffic control queueing discipline (qdisc).</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Parent=</varname></term> + <listitem> + <para>Specifies the parent Queueing Discipline (qdisc). Takes one of <literal>clsact</literal> + or <literal>ingress</literal>. This is mandatory.</para> + </listitem> + </varlistentry> + + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + </variablelist> + </refsect1> + + <refsect1> + <title>[NetworkEmulator] Section Options</title> + <para>The [NetworkEmulator] section manages the queueing discipline (qdisc) of the network emulator. It + can be used to configure the kernel packet scheduler and simulate packet delay and loss for UDP or TCP + applications, or limit the bandwidth usage of a particular service to simulate internet connections. + </para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>DelaySec=</varname></term> + <listitem> + <para>Specifies the fixed amount of delay to be added to all packets going out of the + interface. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DelayJitterSec=</varname></term> + <listitem> + <para>Specifies the chosen delay to be added to the packets outgoing to the network + interface. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the maximum number of packets the qdisc may hold queued at a time. + An unsigned integer in the range 0–4294967294. Defaults to 1000.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>LossRate=</varname></term> + <listitem> + <para>Specifies an independent loss probability to be added to the packets outgoing from the + network interface. Takes a percentage value, suffixed with "%". Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DuplicateRate=</varname></term> + <listitem> + <para>Specifies that the chosen percent of packets is duplicated before queuing them. + Takes a percentage value, suffixed with "%". Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[TokenBucketFilter] Section Options</title> + <para>The [TokenBucketFilter] section manages the queueing discipline (qdisc) of token bucket filter + (tbf).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>LatencySec=</varname></term> + <listitem> + <para>Specifies the latency parameter, which specifies the maximum amount of time a + packet can sit in the Token Bucket Filter (TBF). Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>LimitBytes=</varname></term> + <listitem> + <para>Takes the number of bytes that can be queued waiting for tokens to become available. + When the size is suffixed with K, M, or G, it is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BurstBytes=</varname></term> + <listitem> + <para>Specifies the size of the bucket. This is the maximum amount of bytes that tokens + can be available for instantaneous transfer. When the size is suffixed with K, M, or G, it is + parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to + unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Rate=</varname></term> + <listitem> + <para>Specifies the device specific bandwidth. When suffixed with K, M, or G, the specified + bandwidth is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of 1000. + Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MPUBytes=</varname></term> + <listitem> + <para>The Minimum Packet Unit (MPU) determines the minimal token usage (specified in bytes) + for a packet. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to zero.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PeakRate=</varname></term> + <listitem> + <para>Takes the maximum depletion rate of the bucket. When suffixed with K, M, or G, the + specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of + 1000. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MTUBytes=</varname></term> + <listitem> + <para>Specifies the size of the peakrate bucket. When suffixed with K, M, or G, the specified + size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. + Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[PIE] Section Options</title> + <para>The [PIE] section manages the queueing discipline (qdisc) of Proportional Integral + controller-Enhanced (PIE).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached, incoming packets are + dropped. An unsigned integer in the range 1–4294967294. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[FlowQueuePIE] Section Options</title> + <para>The <literal>[FlowQueuePIE]</literal> section manages the queueing discipline + (qdisc) of Flow Queue Proportional Integral controller-Enhanced (fq_pie).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached, incoming packets are + dropped. An unsigned integer ranges 1 to 4294967294. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[StochasticFairBlue] Section Options</title> + <para>The [StochasticFairBlue] section manages the queueing discipline (qdisc) of stochastic fair blue + (sfb).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 0–4294967294. Defaults to unset and + kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[StochasticFairnessQueueing] Section Options</title> + <para>The [StochasticFairnessQueueing] section manages the queueing discipline (qdisc) of stochastic + fairness queueing (sfq).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PerturbPeriodSec=</varname></term> + <listitem> + <para>Specifies the interval in seconds for queue algorithm perturbation. Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[BFIFO] Section Options</title> + <para>The [BFIFO] section manages the queueing discipline (qdisc) of Byte limited Packet First In First + Out (bfifo).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>LimitBytes=</varname></term> + <listitem> + <para>Specifies the hard limit in bytes on the FIFO buffer size. The size limit prevents overflow + in case the kernel is unable to dequeue packets as quickly as it receives them. When this limit is + reached, incoming packets are dropped. When suffixed with K, M, or G, the specified size is parsed + as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and + kernel default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[PFIFO] Section Options</title> + <para>The [PFIFO] section manages the queueing discipline (qdisc) of Packet First In First Out + (pfifo).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the FIFO size in number of packets. The size limit (a buffer + size) to prevent it from overflowing in case it is unable to dequeue packets as quickly as it + receives them. When this limit is reached, incoming packets are dropped. An unsigned integer in the + range 0–4294967294. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[PFIFOHeadDrop] Section Options</title> + <para>The [PFIFOHeadDrop] section manages the queueing discipline (qdisc) of Packet First In First Out + Head Drop (pfifo_head_drop).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>As in [PFIFO] section.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[PFIFOFast] Section Options</title> + <para>The [PFIFOFast] section manages the queueing discipline (qdisc) of Packet First In First Out Fast + (pfifo_fast).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + </variablelist> + </refsect1> + + <refsect1> + <title>[CAKE] Section Options</title> + <para>The [CAKE] section manages the queueing discipline (qdisc) of Common Applications Kept Enhanced + (CAKE).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>OverheadBytes=</varname></term> + <listitem> + <para>Specifies that bytes to be addeded to the size of each packet. Bytes may be negative. Takes + an integer in the range from -64 to 256. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Bandwidth=</varname></term> + <listitem> + <para>Specifies the shaper bandwidth. When suffixed with K, M, or G, the specified size is + parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of 1000. Defaults to + unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[ControlledDelay] Section Options</title> + <para>The [ControlledDelay] section manages the queueing discipline (qdisc) of + controlled delay (CoDel).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 0–4294967294. Defaults to unset and + kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TargetSec=</varname></term> + <listitem> + <para>Takes a timespan. Specifies the acceptable minimum standing/persistent queue delay. + Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IntervalSec=</varname></term> + <listitem> + <para>Takes a timespan. This is used to ensure that the measured minimum delay does not + become too stale. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ECN=</varname></term> + <listitem> + <para>Takes a boolean. This can be used to mark packets instead of dropping them. Defaults to + unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CEThresholdSec=</varname></term> + <listitem> + <para>Takes a timespan. This sets a threshold above which all packets are marked with ECN + Congestion Experienced (CE). Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[DeficitRoundRobinScheduler] Section Options</title> + <para>The [DeficitRoundRobinScheduler] section manages the queueing discipline (qdisc) of Deficit Round + Robin Scheduler (DRR).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + </variablelist> + </refsect1> + + <refsect1> + <title>[DeficitRoundRobinSchedulerClass] Section Options</title> + <para>The [DeficitRoundRobinSchedulerClass] section manages the traffic control class of Deficit Round + Robin Scheduler (DRR).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="tclass-parent" /> + <xi:include href="tc.xml" xpointer="tclass-classid" /> + + <varlistentry> + <term><varname>QuantumBytes=</varname></term> + <listitem> + <para>Specifies the amount of bytes a flow is allowed to dequeue before the scheduler moves + to the next class. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to the MTU of the + interface.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[EnhancedTransmissionSelection] Section Options</title> + <para>The [EnhancedTransmissionSelection] section manages the queueing discipline (qdisc) of Enhanced + Transmission Selection (ETS).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>Bands=</varname></term> + <listitem> + <para>Specifies the number of bands. An unsigned integer in the range 1–16. This value has to be at + least large enough to cover the strict bands specified through the <varname>StrictBands=</varname> + and bandwidth-sharing bands specified in <varname>QuantumBytes=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>StrictBands=</varname></term> + <listitem> + <para>Specifies the number of bands that should be created in strict mode. An unsigned integer in + the range 1–16.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>QuantumBytes=</varname></term> + <listitem> + <para>Specifies the white-space separated list of quantum used in band-sharing bands. When + suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. This setting can be specified multiple times. If an empty + string is assigned, then the all previous assignments are cleared.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PriorityMap=</varname></term> + <listitem> + <para>The priority map maps the priority of a packet to a band. The argument is a whitespace + separated list of numbers. The first number indicates which band the packets with priority 0 should + be put to, the second is for priority 1, and so on. There can be up to 16 numbers in the list. If + there are fewer, the default band that traffic with one of the unmentioned priorities goes to is + the last one. Each band number must be in the range 0..255. This setting can be specified multiple + times. If an empty string is assigned, then the all previous assignments are cleared.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[GenericRandomEarlyDetection] Section Options</title> + <para>The [GenericRandomEarlyDetection] section manages the queueing discipline (qdisc) of Generic Random + Early Detection (GRED).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>VirtualQueues=</varname></term> + <listitem> + <para>Specifies the number of virtual queues. Takes a integer in the range 1-16. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultVirtualQueue=</varname></term> + <listitem> + <para>Specifies the number of default virtual queue. This must be less than <varname>VirtualQueue=</varname>. + Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>GenericRIO=</varname></term> + <listitem> + <para>Takes a boolean. It turns on the RIO-like buffering scheme. Defaults to + unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[FairQueueingControlledDelay] Section Options</title> + <para>The [FairQueueingControlledDelay] section manages the queueing discipline (qdisc) of fair queuing + controlled delay (FQ-CoDel).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the real queue size. When this limit is reached, incoming packets are + dropped. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryLimitBytes=</varname></term> + <listitem> + <para>Specifies the limit on the total number of bytes that can be queued in this FQ-CoDel instance. + When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Flows=</varname></term> + <listitem> + <para>Specifies the number of flows into which the incoming packets are classified. + Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TargetSec=</varname></term> + <listitem> + <para>Takes a timespan. Specifies the acceptable minimum standing/persistent queue delay. + Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IntervalSec=</varname></term> + <listitem> + <para>Takes a timespan. This is used to ensure that the measured minimum delay does not + become too stale. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>QuantumBytes=</varname></term> + <listitem> + <para>Specifies the number of bytes used as the "deficit" in the fair queuing algorithm timespan. + When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ECN=</varname></term> + <listitem> + <para>Takes a boolean. This can be used to mark packets instead of dropping them. Defaults to + unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CEThresholdSec=</varname></term> + <listitem> + <para>Takes a timespan. This sets a threshold above which all packets are marked with ECN + Congestion Experienced (CE). Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[FairQueueing] Section Options</title> + <para>The [FairQueueing] section manages the queueing discipline (qdisc) of fair queue traffic policing + (FQ).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the real queue size. When this limit is reached, incoming packets are + dropped. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>FlowLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the maximum number of packets queued per flow. Defaults to + unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>QuantumBytes=</varname></term> + <listitem> + <para>Specifies the credit per dequeue RR round, i.e. the amount of bytes a flow is allowed + to dequeue at once. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and kernel's + default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>InitialQuantumBytes=</varname></term> + <listitem> + <para>Specifies the initial sending rate credit, i.e. the amount of bytes a new flow is + allowed to dequeue initially. When suffixed with K, M, or G, the specified size is parsed as + Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and + kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaximumRate=</varname></term> + <listitem> + <para>Specifies the maximum sending rate of a flow. When suffixed with K, M, or G, the + specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of + 1000. Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Buckets=</varname></term> + <listitem> + <para>Specifies the size of the hash table used for flow lookups. Defaults to unset and + kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>OrphanMask=</varname></term> + <listitem> + <para>Takes an unsigned integer. For packets not owned by a socket, fq is able to mask a part + of hash and reduce number of buckets associated with the traffic. Defaults to unset and + kernel's default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Pacing=</varname></term> + <listitem> + <para>Takes a boolean, and enables or disables flow pacing. Defaults to unset and kernel's + default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CEThresholdSec=</varname></term> + <listitem> + <para>Takes a timespan. This sets a threshold above which all packets are marked with ECN + Congestion Experienced (CE). Defaults to unset and kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[TrivialLinkEqualizer] Section Options</title> + <para>The [TrivialLinkEqualizer] section manages the queueing discipline (qdisc) of trivial link + equalizer (teql).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>Specifies the interface ID <literal>N</literal> of teql. Defaults to <literal>0</literal>. + Note that when teql is used, currently, the module <constant>sch_teql</constant> with + <constant>max_equalizers=N+1</constant> option must be loaded before + <command>systemd-networkd</command> is started.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[HierarchyTokenBucket] Section Options</title> + <para>The [HierarchyTokenBucket] section manages the queueing discipline (qdisc) of hierarchy token + bucket (htb).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>DefaultClass=</varname></term> + <listitem> + <para>Takes the minor id in hexadecimal of the default class. Unclassified traffic gets sent + to the class. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RateToQuantum=</varname></term> + <listitem> + <para>Takes an unsigned integer. The DRR quantums are calculated by dividing the value + configured in <varname>Rate=</varname> by <varname>RateToQuantum=</varname>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[HierarchyTokenBucketClass] Section Options</title> + <para>The [HierarchyTokenBucketClass] section manages the traffic control class of hierarchy token bucket + (htb).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="tclass-parent" /> + <xi:include href="tc.xml" xpointer="tclass-classid" /> + + <varlistentry> + <term><varname>Priority=</varname></term> + <listitem> + <para>Specifies the priority of the class. In the round-robin process, classes with the lowest + priority field are tried for packets first.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>QuantumBytes=</varname></term> + <listitem> + <para>Specifies how many bytes to serve from leaf at once. When suffixed with K, M, or G, the + specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of + 1024.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MTUBytes=</varname></term> + <listitem> + <para>Specifies the maximum packet size we create. When suffixed with K, M, or G, the specified + size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>OverheadBytes=</varname></term> + <listitem> + <para>Takes an unsigned integer which specifies per-packet size overhead used in rate + computations. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Rate=</varname></term> + <listitem> + <para>Specifies the maximum rate this class and all its children are guaranteed. When suffixed + with K, M, or G, the specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, + to the base of 1000. This setting is mandatory.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CeilRate=</varname></term> + <listitem> + <para>Specifies the maximum rate at which a class can send, if its parent has bandwidth to spare. + When suffixed with K, M, or G, the specified size is parsed as Kilobits, Megabits, or Gigabits, + respectively, to the base of 1000. When unset, the value specified with <varname>Rate=</varname> + is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BufferBytes=</varname></term> + <listitem> + <para>Specifies the maximum bytes burst which can be accumulated during idle period. When suffixed + with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, + to the base of 1024.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CeilBufferBytes=</varname></term> + <listitem> + <para>Specifies the maximum bytes burst for ceil which can be accumulated during idle period. + When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[HeavyHitterFilter] Section Options</title> + <para>The [HeavyHitterFilter] section manages the queueing discipline (qdisc) of Heavy Hitter Filter + (hhf).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + + <varlistentry> + <term><varname>PacketLimit=</varname></term> + <listitem> + <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 0–4294967294. Defaults to unset and + kernel's default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[QuickFairQueueing] Section Options</title> + <para>The [QuickFairQueueing] section manages the queueing discipline (qdisc) of Quick Fair Queueing + (QFQ).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="qdisc-parent" /> + <xi:include href="tc.xml" xpointer="qdisc-handle" /> + </variablelist> + </refsect1> + + <refsect1> + <title>[QuickFairQueueingClass] Section Options</title> + <para>The [QuickFairQueueingClass] section manages the traffic control class of Quick Fair Queueing + (qfq).</para> + + <variablelist class='network-directives'> + <xi:include href="tc.xml" xpointer="tclass-parent" /> + <xi:include href="tc.xml" xpointer="tclass-classid" /> + + <varlistentry> + <term><varname>Weight=</varname></term> + <listitem> + <para>Specifies the weight of the class. Takes an integer in the range 1..1023. Defaults to + unset in which case the kernel default is used.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxPacketBytes=</varname></term> + <listitem> + <para>Specifies the maximum packet size in bytes for the class. When suffixed with K, M, or G, the specified + size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. When unset, + the kernel default is used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[BridgeVLAN] Section Options</title> + <para>The [BridgeVLAN] section manages the VLAN ID configuration of a bridge port and accepts the + following keys. Specify several [BridgeVLAN] sections to configure several VLAN entries. The + <varname>VLANFiltering=</varname> option has to be enabled, see the [Bridge] section in + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>VLAN=</varname></term> + <listitem> + <para>The VLAN ID allowed on the port. This can be either a single ID or a range M-N. VLAN IDs are valid + from 1 to 4094.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>EgressUntagged=</varname></term> + <listitem> + <para>The VLAN ID specified here will be used to untag frames on egress. Configuring + <varname>EgressUntagged=</varname> implicates the use of <varname>VLAN=</varname> above and will enable the + VLAN ID for ingress as well. This can be either a single ID or a range M-N.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PVID=</varname></term> + <listitem> + <para>The Port VLAN ID specified here is assigned to all untagged frames at ingress. + <varname>PVID=</varname> can be used only once. Configuring <varname>PVID=</varname> implicates the use of + <varname>VLAN=</varname> above and will enable the VLAN ID for ingress as well.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>Static network configuration</title> + + <programlisting># /etc/systemd/network/50-static.network +[Match] +Name=enp2s0 + +[Network] +Address=192.168.0.15/24 +Gateway=192.168.0.1</programlisting> + + <para>This brings interface <literal>enp2s0</literal> up with a static address. The + specified gateway will be used for a default route.</para> + </example> + + <example> + <title>DHCP on ethernet links</title> + + <programlisting># /etc/systemd/network/80-dhcp.network +[Match] +Name=en* + +[Network] +DHCP=yes</programlisting> + + <para>This will enable DHCPv4 and DHCPv6 on all interfaces with names starting with + <literal>en</literal> (i.e. ethernet interfaces).</para> + </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] +IPv6SendRA=yes +DHCPv6PrefixDelegation=yes</programlisting> + + <para>This will enable DHCPv6-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. + The delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network. + </para> + </example> + + <example> + <title>A bridge with two enslaved links</title> + + <programlisting># /etc/systemd/network/25-bridge-static.network +[Match] +Name=bridge0 + +[Network] +Address=192.168.0.15/24 +Gateway=192.168.0.1 +DNS=192.168.0.1</programlisting> + + <programlisting># /etc/systemd/network/25-bridge-slave-interface-1.network +[Match] +Name=enp2s0 + +[Network] +Bridge=bridge0</programlisting> + + <programlisting># /etc/systemd/network/25-bridge-slave-interface-2.network +[Match] +Name=wlp3s0 + +[Network] +Bridge=bridge0</programlisting> + + <para>This creates a bridge and attaches devices <literal>enp2s0</literal> and + <literal>wlp3s0</literal> to it. The bridge will have the specified static address + and network assigned, and a default route via the specified gateway will be + added. The specified DNS server will be added to the global list of DNS resolvers. + </para> + </example> + + <example> + <title></title> + + <programlisting> +# /etc/systemd/network/20-bridge-slave-interface-vlan.network +[Match] +Name=enp2s0 + +[Network] +Bridge=bridge0 + +[BridgeVLAN] +VLAN=1-32 +PVID=42 +EgressUntagged=42 + +[BridgeVLAN] +VLAN=100-200 + +[BridgeVLAN] +EgressUntagged=300-400</programlisting> + + <para>This overrides the configuration specified in the previous example for the + interface <literal>enp2s0</literal>, and enables VLAN on that bridge port. VLAN IDs + 1-32, 42, 100-400 will be allowed. Packets tagged with VLAN IDs 42, 300-400 will be + untagged when they leave on this interface. Untagged packets which arrive on this + interface will be assigned VLAN ID 42.</para> + </example> + + <example> + <title>Various tunnels</title> + + <programlisting>/etc/systemd/network/25-tunnels.network +[Match] +Name=ens1 + +[Network] +Tunnel=ipip-tun +Tunnel=sit-tun +Tunnel=gre-tun +Tunnel=vti-tun + </programlisting> + + <programlisting>/etc/systemd/network/25-tunnel-ipip.netdev +[NetDev] +Name=ipip-tun +Kind=ipip + </programlisting> + + <programlisting>/etc/systemd/network/25-tunnel-sit.netdev +[NetDev] +Name=sit-tun +Kind=sit + </programlisting> + + <programlisting>/etc/systemd/network/25-tunnel-gre.netdev +[NetDev] +Name=gre-tun +Kind=gre + </programlisting> + + <programlisting>/etc/systemd/network/25-tunnel-vti.netdev +[NetDev] +Name=vti-tun +Kind=vti + </programlisting> + + <para>This will bring interface <literal>ens1</literal> up and create an IPIP tunnel, + a SIT tunnel, a GRE tunnel, and a VTI tunnel using it.</para> + </example> + + <example> + <title>A bond device</title> + + <programlisting># /etc/systemd/network/30-bond1.network +[Match] +Name=bond1 + +[Network] +DHCP=ipv6 +</programlisting> + + <programlisting># /etc/systemd/network/30-bond1.netdev +[NetDev] +Name=bond1 +Kind=bond +</programlisting> + + <programlisting># /etc/systemd/network/30-bond1-dev1.network +[Match] +MACAddress=52:54:00:e9:64:41 + +[Network] +Bond=bond1 +</programlisting> + + <programlisting># /etc/systemd/network/30-bond1-dev2.network +[Match] +MACAddress=52:54:00:e9:64:42 + +[Network] +Bond=bond1 +</programlisting> + + <para>This will create a bond device <literal>bond1</literal> and enslave the two + devices with MAC addresses 52:54:00:e9:64:41 and 52:54:00:e9:64:42 to it. IPv6 DHCP + will be used to acquire an address.</para> + </example> + + <example> + <title>Virtual Routing and Forwarding (VRF)</title> + <para>Add the <literal>bond1</literal> interface to the VRF master interface + <literal>vrf1</literal>. This will redirect routes generated on this interface to be + within the routing table defined during VRF creation. For kernels before 4.8 traffic + won't be redirected towards the VRFs routing table unless specific ip-rules are added. + </para> + <programlisting># /etc/systemd/network/25-vrf.network +[Match] +Name=bond1 + +[Network] +VRF=vrf1 +</programlisting> + </example> + + <example> + <title>MacVTap</title> + <para>This brings up a network interface <literal>macvtap-test</literal> + and attaches it to <literal>enp0s25</literal>.</para> + <programlisting># /usr/lib/systemd/network/25-macvtap.network +[Match] +Name=enp0s25 + +[Network] +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> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.nspawn.xml b/man/systemd.nspawn.xml new file mode 100644 index 0000000..0125b71 --- /dev/null +++ b/man/systemd.nspawn.xml @@ -0,0 +1,551 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.nspawn"> + + <refentryinfo> + <title>systemd.nspawn</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.nspawn</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.nspawn</refname> + <refpurpose>Container settings</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para> + <para><filename>/run/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para> + <para><filename>/var/lib/machines/<replaceable>machine</replaceable>.nspawn</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>An nspawn container settings file (suffix <filename>.nspawn</filename>) contains runtime + configuration for a local container, and is used used by + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + Files of this type are named after the containers they define settings for. They are optional, and only + required for containers whose execution environment shall differ from the defaults. Files of this type + mostly contain settings that may also be set on the <command>systemd-nspawn</command> command line, and + make it easier to persistently attach specific settings to specific containers. The syntax of these files + is inspired by <filename>.desktop</filename> files, similarly to other configuration files supported by + the systemd project. See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> for an + overview.</para> + </refsect1> + + <refsect1> + <title><filename>.nspawn</filename> File Discovery</title> + + <para>Files are searched for by appending the <filename>.nspawn</filename> suffix to the machine name of + the container, as specified with the <option>--machine=</option> switch of + <command>systemd-nspawn</command>, or derived from the directory or image file name. This file is first + searched for in <filename>/etc/systemd/nspawn/</filename> and + <filename>/run/systemd/nspawn/</filename>. If found there, the settings are read and all of them take + full effect (but may still be overridden by corresponding command line arguments). Otherwise, the file + will then be searched for next to the image file or in the immediate parent of the root directory of the + container. If the file is found there, only a subset of the settings will take effect however. All + settings that possibly elevate privileges or grant additional access to resources of the host (such as + files or directories) are ignored. To which options this applies is documented below.</para> + + <para>Persistent settings files created and maintained by the + administrator (and thus trusted) should be placed in + <filename>/etc/systemd/nspawn/</filename>, while automatically + downloaded (and thus potentially untrusted) settings files are + placed in <filename>/var/lib/machines/</filename> instead (next to + the container images), where their security impact is limited. In + order to add privileged settings to <filename>.nspawn</filename> + files acquired from the image vendor, it is recommended to copy the + settings files into <filename>/etc/systemd/nspawn/</filename> and + edit them there, so that the privileged options become + available. The precise algorithm for how the files are searched and + interpreted may be configured with + <command>systemd-nspawn</command>'s <option>--settings=</option> + switch, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for details.</para> + </refsect1> + + <refsect1> + <title>[Exec] Section Options</title> + + <para>Settings files may include an [Exec] + section, which carries various execution parameters:</para> + + <variablelist class='nspawn-directives'> + + <varlistentry> + <term><varname>Boot=</varname></term> + + <listitem><para>Takes a boolean argument, which defaults to off. If enabled, <command>systemd-nspawn</command> + will automatically search for an <filename>init</filename> executable and invoke it. In this case, the + 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 specified by default in the + <filename>systemd-nspawn@.service</filename> template unit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Ephemeral=</varname></term> + + <listitem><para>Takes a boolean argument, which defaults to off, If enabled, the container is run with + a temporary snapshot of its file system that is removed immediately when the container terminates. + This is equivalent to the <option>--ephemeral</option> command line switch. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details + about the specific options supported.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ProcessTwo=</varname></term> + + <listitem><para>Takes a boolean argument, which defaults to off. If enabled, the specified program is run as + PID 2. A stub init process is run as PID 1. This setting corresponds to the <option>--as-pid2</option> switch + on the <command>systemd-nspawn</command> command line. This option may not be combined with + <varname>Boot=yes</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Parameters=</varname></term> + + <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> + <term><varname>Environment=</varname></term> + + <listitem><para>Takes an environment variable assignment + consisting of key and value, separated by + <literal>=</literal>. Sets an environment variable for the + main process invoked in the container. This setting may be + used multiple times to set multiple environment variables. It + corresponds to the <option>--setenv=</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>User=</varname></term> + + <listitem><para>Takes a UNIX user name. Specifies the user + name to invoke the main process of the container as. This user + must be known in the container's user database. This + corresponds to the <option>--user=</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WorkingDirectory=</varname></term> + + <listitem><para>Selects the working directory for the process invoked in the container. Expects an absolute + path in the container's file system namespace. This corresponds to the <option>--chdir=</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PivotRoot=</varname></term> + + <listitem><para>Selects a directory to pivot to <filename>/</filename> inside the container when starting up. + Takes a single path, or a pair of two paths separated by a colon. Both paths must be absolute, and are resolved + in the container's file system namespace. This corresponds to the <option>--pivot-root=</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Capability=</varname></term> + <term><varname>DropCapability=</varname></term> + + <listitem><para>Takes a space-separated list of Linux process + capabilities (see + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details). The <varname>Capability=</varname> setting + specifies additional capabilities to pass on top of the + default set of capabilities. The + <varname>DropCapability=</varname> setting specifies + capabilities to drop from the default set. These settings + correspond to the <option>--capability=</option> and + <option>--drop-capability=</option> command line + switches. Note that <varname>Capability=</varname> is a + privileged setting, and only takes effect in + <filename>.nspawn</filename> files in + <filename>/etc/systemd/nspawn/</filename> and + <filename>/run/system/nspawn/</filename> (see above). On the + other hand, <varname>DropCapability=</varname> takes effect in + all cases. If the special value <literal>all</literal> is passed, all + capabilities are retained (or dropped).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NoNewPrivileges=</varname></term> + + <listitem><para>Takes a boolean argument that controls the <constant>PR_SET_NO_NEW_PRIVS</constant> flag for + the container payload. This is equivalent to the + <option>--no-new-privileges=</option> command line switch. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>KillSignal=</varname></term> + + <listitem><para>Specify the process signal to send to the + container's PID 1 when nspawn itself receives SIGTERM, in + order to trigger an orderly shutdown of the container. + Defaults to SIGRTMIN+3 if <option>Boot=</option> is used + (on systemd-compatible init systems SIGRTMIN+3 triggers an + orderly shutdown). For a list of valid signals, see + <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Personality=</varname></term> + + <listitem><para>Configures the kernel personality for the + container. This is equivalent to the + <option>--personality=</option> switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MachineID=</varname></term> + + <listitem><para>Configures the 128-bit machine ID (UUID) to pass to + the container. This is equivalent to the + <option>--uuid=</option> command line switch. This option is + privileged (see above). </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateUsers=</varname></term> + + <listitem><para>Configures support for usernamespacing. This is equivalent to the + <option>--private-users=</option> command line switch, and takes the same options. This option is privileged + (see above). This option is the default if the <filename>systemd-nspawn@.service</filename> template unit file + is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NotifyReady=</varname></term> + + <listitem><para>Configures support for notifications from the container's init process. This is equivalent to + the <option>--notify-ready=</option> command line switch, and takes the same parameters. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details + about the specific options supported.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SystemCallFilter=</varname></term> + + <listitem><para>Configures the system call filter applied to containers. This is equivalent to the + <option>--system-call-filter=</option> command line switch, and takes the same list parameter. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LimitCPU=</varname></term> + <term><varname>LimitFSIZE=</varname></term> + <term><varname>LimitDATA=</varname></term> + <term><varname>LimitSTACK=</varname></term> + <term><varname>LimitCORE=</varname></term> + <term><varname>LimitRSS=</varname></term> + <term><varname>LimitNOFILE=</varname></term> + <term><varname>LimitAS=</varname></term> + <term><varname>LimitNPROC=</varname></term> + <term><varname>LimitMEMLOCK=</varname></term> + <term><varname>LimitLOCKS=</varname></term> + <term><varname>LimitSIGPENDING=</varname></term> + <term><varname>LimitMSGQUEUE=</varname></term> + <term><varname>LimitNICE=</varname></term> + <term><varname>LimitRTPRIO=</varname></term> + <term><varname>LimitRTTIME=</varname></term> + + <listitem><para>Configures various types of resource limits applied to containers. This is equivalent to the + <option>--rlimit=</option> command line switch, and takes the same arguments. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OOMScoreAdjust=</varname></term> + + <listitem><para>Configures the OOM score adjustment value. This is equivalent to the + <option>--oom-score-adjust=</option> command line switch, and takes the same argument. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUAffinity=</varname></term> + + <listitem><para>Configures the CPU affinity. This is equivalent to the <option>--cpu-affinity=</option> command + line switch, and takes the same argument. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Hostname=</varname></term> + + <listitem><para>Configures the kernel hostname set for the container. This is equivalent to the + <option>--hostname=</option> command line switch, and takes the same argument. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ResolvConf=</varname></term> + + <listitem><para>Configures how <filename>/etc/resolv.conf</filename> in the container shall be handled. This is + equivalent to the <option>--resolv-conf=</option> command line switch, and takes the same argument. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Timezone=</varname></term> + + <listitem><para>Configures how <filename>/etc/localtime</filename> in the container shall be handled. This is + equivalent to the <option>--timezone=</option> command line switch, and takes the same argument. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>LinkJournal=</varname></term> + + <listitem><para>Configures how to link host and container journal setups. This is equivalent to the + <option>--link-journal=</option> command line switch, and takes the same parameter. See + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[Files] Section Options</title> + + <para>Settings files may include a [Files] + section, which carries various parameters configuring the file + system of the container:</para> + + <variablelist class='nspawn-directives'> + + <varlistentry> + <term><varname>ReadOnly=</varname></term> + + <listitem><para>Takes a boolean argument, which defaults to off. If + specified, the container will be run with a read-only file + system. This setting corresponds to the + <option>--read-only</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Volatile=</varname></term> + + <listitem><para>Takes a boolean argument, or the special value + <literal>state</literal>. This configures whether to run the + container with volatile state and/or configuration. This + option is equivalent to <option>--volatile=</option>, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for details about the specific options + supported.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Bind=</varname></term> + <term><varname>BindReadOnly=</varname></term> + + <listitem><para>Adds a bind mount from the host into the + container. Takes a single path, a pair of two paths separated + by a colon, or a triplet of two paths plus an option string + separated by colons. This option may be used multiple times to + configure multiple bind mounts. This option is equivalent to + the command line switches <option>--bind=</option> and + <option>--bind-ro=</option>, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for details about the specific options supported. This setting + is privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TemporaryFileSystem=</varname></term> + + <listitem><para>Adds a <literal>tmpfs</literal> mount to the + container. Takes a path or a pair of path and option string, + separated by a colon. This option may be used multiple times to + configure multiple <literal>tmpfs</literal> mounts. This + option is equivalent to the command line switch + <option>--tmpfs=</option>, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for details about the specific options supported. This setting + is privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Inaccessible=</varname></term> + + <listitem><para>Masks the specified file or directory 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 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 + about the specific options supported. This setting is privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Overlay=</varname></term> + <term><varname>OverlayReadOnly=</varname></term> + + <listitem><para>Adds an overlay mount point. Takes a colon-separated list of paths. This option may be used + multiple times to configure multiple overlay mounts. This option is equivalent to the command line switches + <option>--overlay=</option> and <option>--overlay-ro=</option>, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details + about the specific options supported. This setting is privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PrivateUsersChown=</varname></term> + + <listitem><para>Configures whether the ownership of the files and directories in the container tree shall be + adjusted to the UID/GID range used, if necessary and user namespacing is enabled. This is equivalent to the + <option>--private-users-chown</option> command line switch. This option is privileged (see + above). </para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>[Network] Section Options</title> + + <para>Settings files may include a [Network] + section, which carries various parameters configuring the network + connectivity of the container:</para> + + <variablelist class='nspawn-directives'> + + <varlistentry> + <term><varname>Private=</varname></term> + + <listitem><para>Takes a boolean argument, which defaults to off. If + enabled, the container will run in its own network namespace + and not share network interfaces and configuration with the + host. This setting corresponds to the + <option>--private-network</option> command line + switch.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VirtualEthernet=</varname></term> + + <listitem><para>Takes a boolean argument. Configures whether to create a virtual Ethernet connection + (<literal>veth</literal>) between host and the container. This setting implies + <varname>Private=yes</varname>. This setting corresponds to the <option>--network-veth</option> command line + switch. This option is privileged (see above). This option is the default if the + <filename>systemd-nspawn@.service</filename> template unit file is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>VirtualEthernetExtra=</varname></term> + + <listitem><para>Takes a colon-separated pair of interface names. Configures an additional virtual + Ethernet connection (<literal>veth</literal>) between host and the container. The first specified + name is the interface name on the host, the second the interface name in the container. The latter + may be omitted in which case it is set to the same name as the host side interface. This setting + implies <varname>Private=yes</varname>. This setting corresponds to the + <option>--network-veth-extra=</option> command line switch, and maybe be used multiple times. It is + independent of <varname>VirtualEthernet=</varname>. Note that this option is unrelated to the + <varname>Bridge=</varname> setting below, and thus any connections created this way are not + automatically added to any bridge device on the host side. This option is privileged (see + above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Interface=</varname></term> + + <listitem><para>Takes a space-separated list of interfaces to + add to the container. This option corresponds to the + <option>--network-interface=</option> command line switch and + implies <varname>Private=yes</varname>. This option is + privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MACVLAN=</varname></term> + <term><varname>IPVLAN=</varname></term> + + <listitem><para>Takes a space-separated list of interfaces to + add MACLVAN or IPVLAN interfaces to, which are then added to + the container. These options correspond to the + <option>--network-macvlan=</option> and + <option>--network-ipvlan=</option> command line switches and + imply <varname>Private=yes</varname>. These options are + privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Bridge=</varname></term> + + <listitem><para>Takes an interface name. This setting implies + <varname>VirtualEthernet=yes</varname> and + <varname>Private=yes</varname> and has the effect that the + host side of the created virtual Ethernet link is connected to + the specified bridge interface. This option corresponds to the + <option>--network-bridge=</option> command line switch. This + option is privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Zone=</varname></term> + + <listitem><para>Takes a network zone name. This setting implies <varname>VirtualEthernet=yes</varname> and + <varname>Private=yes</varname> and has the effect that the host side of the created virtual Ethernet link is + connected to an automatically managed bridge interface named after the passed argument, prefixed with + <literal>vz-</literal>. This option corresponds to the <option>--network-zone=</option> command line + switch. This option is privileged (see above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Port=</varname></term> + + <listitem><para>Exposes a TCP or UDP port of the container on + the host. This option corresponds to the + <option>--port=</option> command line switch, see + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for the precise syntax of the argument this option takes. This + option is privileged (see above).</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.offline-updates.xml b/man/systemd.offline-updates.xml new file mode 100644 index 0000000..6706451 --- /dev/null +++ b/man/systemd.offline-updates.xml @@ -0,0 +1,163 @@ +<?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-or-later --> + +<refentry id="systemd.offline-updates"> + <refentryinfo> + <title>systemd.offline-updates</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.offline-updates</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.offline-updates</refname> + <refpurpose>Implementation of offline updates in systemd</refpurpose> + </refnamediv> + + <refsect1> + <title>Implementing Offline System Updates</title> + + <para>This man page describes how to implement "offline" system updates with systemd. By "offline" + OS updates we mean package installations and updates that are run with the system booted into a + special system update mode, in order to avoid problems related to conflicts of libraries and + services that are currently running with those on disk. This document is inspired by this + <ulink url="https://wiki.gnome.org/Design/OS/SoftwareUpdates">GNOME design whiteboard</ulink>. + </para> + + <para>The logic:</para> + + <orderedlist> + <listitem> + <para>The package manager prepares system updates by downloading all (.rpm or .deb or + whatever) packages to update off-line in a special directory + <filename index="false">/var/lib/system-update</filename> (or + another directory of the package/upgrade manager's choice).</para> + </listitem> + + <listitem> + <para>When the user OK'ed the update, the symlink <filename>/system-update</filename> is + created that points to <filename index="false">/var/lib/system-update</filename> (or + wherever the directory with the upgrade files is located) and the system is rebooted. This + symlink is in the root directory, since we need to check for it very early at boot, at a + time where <filename>/var/</filename> is not available yet.</para> + </listitem> + + <listitem> + <para>Very early in the new boot + <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + checks whether <filename>/system-update</filename> exists. If so, it (temporarily and for + this boot only) redirects (i.e. symlinks) <filename>default.target</filename> to + <filename>system-update.target</filename>, a special target that pulls in the base system + (i.e. <filename>sysinit.target</filename>, so that all file systems are mounted but little + else) and the system update units.</para> + </listitem> + + <listitem> + <para>The system now continues to boot into <filename>default.target</filename>, and + thus into <filename>system-update.target</filename>. This target pulls in all system + update units. Only one service should perform an update (see the next point), and all + the other ones should exit cleanly with a "success" return code and without doing + anything. Update services should be ordered after <filename>sysinit.target</filename> + so that the update starts after all file systems have been mounted.</para> + </listitem> + + <listitem> + <para>As the first step, an update service should check if the + <filename>/system-update</filename> symlink points to the location used by that update + service. In case it does not exist or points to a different location, the service must exit + without error. It is possible for multiple update services to be installed, and for multiple + update services to be launched in parallel, and only the one that corresponds to the tool + that <emphasis>created</emphasis> the symlink before reboot should perform any actions. It + is unsafe to run multiple updates in parallel.</para> + </listitem> + + <listitem> + <para>The update service should now do its job. If applicable and possible, it should + create a file system snapshot, then install all packages. After completion (regardless + whether the update succeeded or failed) the machine must be rebooted, for example by + calling <command>systemctl reboot</command>. In addition, on failure the script should + revert to the old file system snapshot (without the symlink).</para> + </listitem> + + <listitem> + <para>The update scripts should exit only after the update is finished. It is expected + that the service which performs the update will cause the machine to reboot after it + is done. If the <filename>system-update.target</filename> is successfully reached, i.e. + all update services have run, and the <filename>/system-update</filename> symlink still + exists, it will be removed and the machine rebooted as a safety measure.</para> + </listitem> + + <listitem> + <para>After a reboot, now that the <filename>/system-update</filename> symlink is gone, + the generator won't redirect <filename>default.target</filename> anymore and the system + now boots into the default target again.</para> + </listitem> + </orderedlist> + </refsect1> + + <refsect1> + <title>Recommendations</title> + + <orderedlist> + <listitem> + <para>To make things a bit more robust we recommend hooking the update script into + <filename>system-update.target</filename> via a <filename index="false">.wants/</filename> + symlink in the distribution package, rather than depending on <command>systemctl + enable</command> in the postinst scriptlets of your package. More specifically, for your + update script create a .service file, without [Install] section, and then add a symlink like + <filename index="false">/usr/lib/systemd/system/system-update.target.wants/foobar.service</filename> + → <filename index="false">../foobar.service</filename> to your package.</para> + </listitem> + + <listitem> + <para>Make sure to remove the <filename>/system-update</filename> symlink as early as + possible in the update script to avoid reboot loops in case the update fails.</para> + </listitem> + + <listitem> + <para>Use <varname>FailureAction=reboot</varname> in the service file for your update script + to ensure that a reboot is automatically triggered if the update fails. + <varname>FailureAction=</varname> makes sure that the specified unit is activated if your + script exits uncleanly (by non-zero error code, or signal/coredump). If your script succeeds + you should trigger the reboot in your own code, for example by invoking logind's + <command>Reboot()</command> call or calling <command>systemctl reboot</command>. See + <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details about the logind D-Bus API.</para> + </listitem> + + <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>Before=system-update.target</varname> + and explicitly pull in any other services it requires.</para> + </listitem> + + <listitem> + <para>It may be desirable to always run an auxiliary unit when booting + into offline-updates mode, which itself does not install updates. To + do this create a .service file with + <varname>Wants=system-update-pre.target</varname> and + <varname>Before=system-update-pre.target</varname> and add a symlink + to that file under + <filename index="false">/usr/lib/systemd/system-update.target.wants</filename> + .</para> + </listitem> + </orderedlist> + </refsect1> + + <refsect1> + <title>See also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>dnf.plugin.system-upgrade</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/systemd.path.xml b/man/systemd.path.xml new file mode 100644 index 0000000..bca1514 --- /dev/null +++ b/man/systemd.path.xml @@ -0,0 +1,201 @@ +<?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-or-later --> + +<refentry id="systemd.path"> + <refentryinfo> + <title>systemd.path</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.path</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.path</refname> + <refpurpose>Path unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>path</replaceable>.path</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.path</literal> encodes information about a path + monitored by systemd, for path-based activation.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The path specific configuration options are + configured in the [Path] section.</para> + + <para>For each path file, a matching unit file must exist, + describing the unit to activate when the path changes. By default, + a service by the same name as the path (except for the suffix) is + activated. Example: a path file <filename>foo.path</filename> + activates a matching service <filename>foo.service</filename>. The + unit to activate may be controlled by <varname>Unit=</varname> + (see below).</para> + + <para>Internally, path units use the + <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> + API to monitor file systems. Due to that, it suffers by the same + limitations as inotify, and for example cannot be used to monitor + files or directories changed by other machines on remote NFS file + systems.</para> + + <para>When a service unit triggered by a path unit terminates (regardless whether it exited successfully + or failed), monitored paths are checked immediately again, and the service accordingly restarted + instantly. As protection against busy looping in this trigger/start cycle, a start rate limit is enforced + on the service unit, see <varname>StartLimitIntervalSec=</varname> and + <varname>StartLimitBurst=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Unlike + other service failures, the error condition that the start rate limit is hit is propagated from the + service unit to the path unit and causes the path unit to fail as well, thus ending the loop.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>If a path unit is beneath another mount unit in the file + system hierarchy, both a requirement and an ordering dependency + between both units are created automatically.</para></listitem> + + <listitem><para>An implicit <varname>Before=</varname> dependency is added + between a path unit and the unit it is supposed to activate.</para></listitem> + </itemizedlist> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Path units will automatically have dependencies of type <varname>Before=</varname> on + <filename>paths.target</filename>, + dependencies of type <varname>After=</varname> and <varname>Requires=</varname> on + <filename>sysinit.target</filename>, and have dependencies of type <varname>Conflicts=</varname> and + <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that path units are terminated + cleanly prior to system shutdown. Only path units involved with early boot or late system shutdown should + disable <varname>DefaultDependencies=</varname> option.</para></listitem> + </itemizedlist> + + <para></para> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Path files must include a [Path] section, which carries + information about the path(s) it monitors. The options specific to + the [Path] section of path units are the following:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>PathExists=</varname></term> + <term><varname>PathExistsGlob=</varname></term> + <term><varname>PathChanged=</varname></term> + <term><varname>PathModified=</varname></term> + <term><varname>DirectoryNotEmpty=</varname></term> + + <listitem><para>Defines paths to monitor for certain changes: + <varname>PathExists=</varname> may be used to watch the mere + existence of a file or directory. If the file specified + exists, the configured unit is activated. + <varname>PathExistsGlob=</varname> works similar, but checks + for the existence of at least one file matching the globbing + pattern specified. <varname>PathChanged=</varname> may be used + to watch a file or directory and activate the configured unit + whenever it changes. It is not activated on every write to the + watched file but it is activated if the file which was open + for writing gets closed. <varname>PathModified=</varname> is + similar, but additionally it is activated also on simple + writes to the watched file. + <varname>DirectoryNotEmpty=</varname> may be used to watch a + directory and activate the configured unit whenever it + contains at least one file.</para> + + <para>The arguments of these directives must be absolute file + system paths.</para> + + <para>Multiple directives may be combined, of the same and of + different types, to watch multiple paths. If the empty string + is assigned to any of these options, the list of paths to + watch is reset, and any prior assignments of these options + will not have any effect.</para> + + <para>If a path already exists (in case of + <varname>PathExists=</varname> and + <varname>PathExistsGlob=</varname>) or a directory already is + not empty (in case of <varname>DirectoryNotEmpty=</varname>) + at the time the path unit is activated, then the configured + unit is immediately activated as well. Something similar does + not apply to <varname>PathChanged=</varname> and + <varname>PathModified=</varname>.</para> + + <para>If the path itself or any of the containing directories + are not accessible, <command>systemd</command> will watch for + permission changes and notice that conditions are satisfied + when permissions allow that. </para></listitem> + </varlistentry> + <varlistentry> + <term><varname>Unit=</varname></term> + + <listitem><para>The unit to activate when any of the + configured paths changes. The argument is a unit name, whose + suffix is not <literal>.path</literal>. If not specified, this + value defaults to a service that has the same name as the path + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + path unit are named identical, except for the + suffix.</para></listitem> + </varlistentry> + <varlistentry> + <term><varname>MakeDirectory=</varname></term> + + <listitem><para>Takes a boolean argument. If true, the + directories to watch are created before watching. This option + is ignored for <varname>PathExists=</varname> settings. + Defaults to <option>false</option>.</para></listitem> + </varlistentry> + <varlistentry> + <term><varname>DirectoryMode=</varname></term> + + <listitem><para>If <varname>MakeDirectory=</varname> is + enabled, use the mode specified here to create the directories + in question. Takes an access mode in octal notation. Defaults + to <option>0755</option>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml new file mode 100644 index 0000000..5697e50 --- /dev/null +++ b/man/systemd.preset.xml @@ -0,0 +1,187 @@ +<?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-or-later --> +<refentry id="systemd.preset"> + + <refentryinfo> + <title>systemd.preset</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.preset</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.preset</refname> + <refpurpose>Service enablement presets</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/system-preset/*.preset</filename></para> + <para><filename>/run/systemd/system-preset/*.preset</filename></para> + <para><filename>/usr/lib/systemd/system-preset/*.preset</filename></para> + <para><filename>/etc/systemd/user-preset/*.preset</filename></para> + <para><filename>/run/systemd/user-preset/*.preset</filename></para> + <para><filename>/usr/lib/systemd/user-preset/*.preset</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Preset files may be used to encode policy which units shall + be enabled by default and which ones shall be disabled. They are + read by <command>systemctl preset</command> (for more information + see + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>) + which uses this information to enable or disable a unit according + to preset policy. <command>systemctl preset</command> is used by + the post install scriptlets of RPM packages (or other OS package + formats), to enable/disable specific units by default on package + installation, enforcing distribution, spin or administrator preset + policy. This allows choosing a certain set of units to be + enabled/disabled even before installing the actual package.</para> + + <para>For more information on the preset logic please have a look + at the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/Preset">Presets</ulink> + document.</para> + + <para>It is not recommended to ship preset files within the + respective software packages implementing the units, but rather + centralize them in a distribution or spin default policy, which + can be amended by administrator policy.</para> + + <para>If no preset files exist, <command>systemctl + preset</command> will enable all units that are installed by + default. If this is not desired and all units shall rather be + disabled, it is necessary to ship a preset file with a single, + catchall "<filename>disable *</filename>" line. (See example 1, + below.)</para> + </refsect1> + + <refsect1> + <title>Preset File Format</title> + + <para>The preset files contain a list of directives consisting of + either the word <literal>enable</literal> or + <literal>disable</literal> followed by a space and a unit name + (possibly with shell style wildcards), separated by newlines. + Empty lines and lines whose first non-whitespace character is <literal>#</literal> or + <literal>;</literal> are ignored. Multiple instance names for unit + templates may be specified as a space separated list at the end of + the line instead of the customary position between <literal>@</literal> + and the unit suffix.</para> + + <para>Presets must refer to the "real" unit file, and not to any aliases. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a description of unit aliasing.</para> + + <para>Two different directives are understood: + <literal>enable</literal> may be used to enable units by default, + <literal>disable</literal> to disable units by default.</para> + + <para>If multiple lines apply to a unit name, the first matching + one takes precedence over all others.</para> + + <para>Each preset file shall be named in the style of + <filename><priority>-<policy-name>.preset</filename>. Files + in <filename>/etc/</filename> override files with the same name in + <filename>/usr/lib/</filename> and <filename>/run/</filename>. + Files in <filename>/run/</filename> override files with the same + name in <filename>/usr/lib/</filename>. Packages should install + their preset files in <filename>/usr/lib/</filename>. Files in + <filename>/etc/</filename> are reserved for the local + administrator, who may use this logic to override the preset files + installed by vendor packages. All preset files are sorted by their + filename in lexicographic order, regardless of which of the + directories they reside in. If multiple files specify the same + unit name, the entry in the file with the lexicographically + earliest name will be applied. It is recommended to prefix all + filenames with a two-digit number and a dash, to simplify the + ordering of the files.</para> + + <para>If the administrator wants to disable a preset file supplied + by the vendor, the recommended way is to place a symlink to + <filename>/dev/null</filename> in + <filename>/etc/systemd/system-preset/</filename> bearing the same + filename.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Default to off</title> + + <programlisting># /usr/lib/systemd/system-preset/99-default.preset + +disable *</programlisting> + </example> + + <para>This disables all units. Due to the filename prefix + <literal>99-</literal>, it will be read last and hence can easily + be overridden by spin or administrator preset policy.</para> + + <example> + <title>Enable multiple template instances</title> + + <programlisting># /usr/lib/systemd/system-preset/80-dirsrv.preset + +enable dirsrv@.service foo bar baz</programlisting> + </example> + + <para>This enables all three of <filename>dirsrv@foo.service</filename>, + <filename>dirsrv@bar.service</filename> and <filename>dirsrv@baz.service</filename>.</para> + + <example> + <title>A GNOME spin</title> + + <programlisting># /usr/lib/systemd/system-preset/50-gnome.preset + +enable gdm.service +enable colord.service +enable accounts-daemon.service +enable avahi-daemon.*</programlisting> + + </example> + + <para>This enables the three mentioned units, plus all + <filename>avahi-daemon</filename> regardless of which unit type. A + file like this could be useful for inclusion in a GNOME spin of a + distribution. It will ensure that the units necessary for GNOME + are properly enabled as they are installed. It leaves all other + units untouched, and subject to other (later) preset files, for + example like the one from the first example above.</para> + + <example> + <title>Administrator policy</title> + + <programlisting># /etc/systemd/system-preset/00-lennart.preset + +enable httpd.service +enable sshd.service +enable postfix.service +disable *</programlisting> + </example> + + <para>This enables three specific services and disables all + others. This is useful for administrators to specifically select + the units to enable, and disable all others. Due to the filename + prefix <literal>00-</literal> it will be read early and + override all other preset policy files.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml new file mode 100644 index 0000000..26dedda --- /dev/null +++ b/man/systemd.resource-control.xml @@ -0,0 +1,1081 @@ +<?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-or-later --> + +<refentry id="systemd.resource-control" xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>systemd.resource-control</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.resource-control</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.resource-control</refname> + <refpurpose>Resource control unit settings</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para> + <filename><replaceable>slice</replaceable>.slice</filename>, + <filename><replaceable>scope</replaceable>.scope</filename>, + <filename><replaceable>service</replaceable>.service</filename>, + <filename><replaceable>socket</replaceable>.socket</filename>, + <filename><replaceable>mount</replaceable>.mount</filename>, + <filename><replaceable>swap</replaceable>.swap</filename> + </para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Unit configuration files for services, slices, scopes, sockets, mount points, and swap devices share a subset + of configuration options for resource control of spawned processes. Internally, this relies on the Linux Control + Groups (cgroups) kernel concept for organizing processes in a hierarchical tree of named groups for the purpose of + resource management.</para> + + <para>This man page lists the configuration options shared by + those six unit types. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files, and + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + and + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information on the specific unit configuration files. The + resource control configuration options are configured in the + [Slice], [Scope], [Service], [Socket], [Mount], or [Swap] + sections, depending on the unit type.</para> + + <para>In addition, options which control resources available to programs + <emphasis>executed</emphasis> by systemd are listed in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Those options complement options listed here.</para> + + <para>See the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New + Control Group Interfaces</ulink> for an introduction on how to make + use of resource control APIs from programs.</para> + </refsect1> + + <refsect1> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>Units with the <varname>Slice=</varname> setting set automatically acquire + <varname>Requires=</varname> and <varname>After=</varname> dependencies on the specified + slice unit.</para></listitem> + </itemizedlist> + </refsect1> + + <!-- We don't have any default dependency here. --> + + <refsect1> + <title>Unified and Legacy Control Group Hierarchies</title> + + <para>The unified control group hierarchy is the new version of kernel control group interface, see + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">Control Groups v2</ulink>. + Depending on the resource type, there are differences in resource control capabilities. Also, because of + interface changes, some resource types have separate set of options on the unified hierarchy.</para> + + <para> + <variablelist> + + <varlistentry> + <term>CPU</term> + <listitem> + <para><varname>CPUWeight=</varname> and <varname>StartupCPUWeight=</varname> replace + <varname>CPUShares=</varname> and <varname>StartupCPUShares=</varname>, respectively.</para> + + <para>The <literal>cpuacct</literal> controller does not exist separately on the unified hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Memory</term> + <listitem> + <para><varname>MemoryMax=</varname> replaces <varname>MemoryLimit=</varname>. <varname>MemoryLow=</varname> + and <varname>MemoryHigh=</varname> are effective only on unified hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>IO</term> + <listitem> + <para><literal>IO</literal>-prefixed settings are a superset of and replace + <literal>BlockIO</literal>-prefixed ones. On unified hierarchy, IO resource control also applies + to buffered writes.</para> + </listitem> + </varlistentry> + + </variablelist> + </para> + + <para>To ease the transition, there is best-effort translation between the two versions of settings. For each + controller, if any of the settings for the unified hierarchy are present, all settings for the legacy hierarchy are + ignored. If the resulting settings are for the other type of hierarchy, the configurations are translated before + application.</para> + + <para>Legacy control group hierarchy (see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/">Control Groups version 1</ulink>), + also called cgroup-v1, doesn't allow safe delegation of controllers to unprivileged processes. If the + system uses the legacy control group hierarchy, resource control is disabled for the systemd user + instance, see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Units of the types listed above can have settings + for resource control configuration:</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>CPUAccounting=</varname></term> + + <listitem> + <para>Turn on CPU usage accounting for this unit. Takes a + boolean argument. Note that turning on CPU accounting for + one unit will also implicitly turn it on for all units + contained in the same slice and for all its parent slices + and the units contained therein. The system default for this + setting may be controlled with + <varname>DefaultCPUAccounting=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUWeight=<replaceable>weight</replaceable></varname></term> + <term><varname>StartupCPUWeight=<replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy + is used on the system. These options take an integer value and control the <literal>cpu.weight</literal> + control group attribute. The allowed range is 1 to 10000. Defaults to 100. For details about this control + group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">Control Groups v2</ulink> and <ulink + url="https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html">CFS Scheduler</ulink>. + The available CPU time is split up among all units within one slice relative to their CPU time weight.</para> + + <para>While <varname>StartupCPUWeight=</varname> only applies to the startup phase of the system, + <varname>CPUWeight=</varname> applies to normal runtime of the system, and if the former is not set also to + the startup phase. Using <varname>StartupCPUWeight=</varname> allows prioritizing specific services at + boot-up differently than during normal runtime.</para> + + <para>These settings replace <varname>CPUShares=</varname> and <varname>StartupCPUShares=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUQuota=</varname></term> + + <listitem> + <para>Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with + "%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU time + available on one CPU. Use values > 100% for allotting CPU time on more than one CPU. This controls the + <literal>cpu.max</literal> attribute on the unified control group hierarchy and + <literal>cpu.cfs_quota_us</literal> on legacy. For details about these control group attributes, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">Control Groups v2</ulink> and <ulink + url="https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt">sched-bwc.txt</ulink>.</para> + + <para>Example: <varname>CPUQuota=20%</varname> ensures that the executed processes will never get more than + 20% CPU time on one CPU.</para> + + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CPUQuotaPeriodSec=</varname></term> + + <listitem> + <para>Assign the duration over which the CPU time quota specified by <varname>CPUQuota=</varname> is measured. + Takes a time duration value in seconds, with an optional suffix such as "ms" for milliseconds (or "s" for seconds.) + The default setting is 100ms. The period is clamped to the range supported by the kernel, which is [1ms, 1000ms]. + Additionally, the period is adjusted up so that the quota interval is also at least 1ms. + Setting <varname>CPUQuotaPeriodSec=</varname> to an empty value resets it to the default.</para> + + <para>This controls the second field of <literal>cpu.max</literal> attribute on the unified control group hierarchy + and <literal>cpu.cfs_period_us</literal> on legacy. For details about these control group attributes, see + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">Control Groups v2</ulink> and + <ulink url="https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html">CFS Scheduler</ulink>.</para> + + <para>Example: <varname>CPUQuotaPeriodSec=10ms</varname> to request that the CPU quota is measured in periods of 10ms.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AllowedCPUs=</varname></term> + + <listitem> + <para>Restrict processes to be executed on specific CPUs. 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.</para> + + <para>Setting <varname>AllowedCPUs=</varname> doesn't guarantee that all of the CPUs will be used by the processes + as it may be limited by parent units. The effective configuration is reported as <varname>EffectiveCPUs=</varname>.</para> + + <para>This setting is supported only with the unified control group hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AllowedMemoryNodes=</varname></term> + + <listitem> + <para>Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices + or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper + NUMA nodes indices separated by a dash.</para> + + <para>Setting <varname>AllowedMemoryNodes=</varname> doesn't guarantee that all of the memory NUMA nodes will + be used by the processes as it may be limited by parent units. The effective configuration is reported as + <varname>EffectiveMemoryNodes=</varname>.</para> + + <para>This setting is supported only with the unified control group hierarchy.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryAccounting=</varname></term> + + <listitem> + <para>Turn on process and kernel memory accounting for this + unit. Takes a boolean argument. Note that turning on memory + accounting for one unit will also implicitly turn it on for + all units contained in the same slice and for all its parent + slices and the units contained therein. The system default + for this setting may be controlled with + <varname>DefaultMemoryAccounting=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryMin=<replaceable>bytes</replaceable></varname>, <varname>MemoryLow=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the memory usage protection of the executed processes in this unit. + When reclaiming memory, the unit is treated as if it was using less memory resulting in memory + to be preferentially reclaimed from unprotected units. + Using <varname>MemoryLow=</varname> results in a weaker protection where memory may still + be reclaimed to avoid invoking the OOM killer in case there is no other reclaimable memory.</para> + <para> + For a protection to be effective, it is generally required to set a corresponding + allocation on all ancestors, which is then distributed between children + (with the exception of the root slice). + Any <varname>MemoryMin=</varname> or <varname>MemoryLow=</varname> allocation that is not + explicitly distributed to specific children is used to create a shared protection for all children. + As this is a shared protection, the children will freely compete for the memory.</para> + + <para>Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a + percentage value may be specified, which is taken relative to the installed physical memory on the + system. If assigned the special value <literal>infinity</literal>, all available memory is protected, which may be + useful in order to always inherit all of the protection afforded by ancestors. + This controls the <literal>memory.min</literal> or <literal>memory.low</literal> control group attribute. + For details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para> + + <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> or + <literal>memory.low</literal> value by specifying <varname>DefaultMemoryMin=</varname> or + <varname>DefaultMemoryLow=</varname>, which has the same semantics as + <varname>MemoryMin=</varname> and <varname>MemoryLow=</varname>. + This setting does not affect <literal>memory.min</literal> or <literal>memory.low</literal> + in the unit itself. + Using it to set a default child allocation is only useful on kernels older than 5.7, + which do not support the <literal>memory_recursiveprot</literal> cgroup2 mount option.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryHigh=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the throttling limit on memory usage of the executed processes in this unit. Memory usage may go + above the limit if unavoidable, but the processes are heavily slowed down and memory is taken away + aggressively in such cases. This is the main mechanism to control memory usage of a unit.</para> + + <para>Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a + percentage value may be specified, which is taken relative to the installed physical memory on the + system. If assigned the + special value <literal>infinity</literal>, no memory throttling is applied. This controls the + <literal>memory.high</literal> control group attribute. For details about this control group attribute, see + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used and disables + <varname>MemoryLimit=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryMax=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the absolute limit on memory usage of the executed processes in this unit. If memory usage + cannot be contained under the limit, out-of-memory killer is invoked inside the unit. It is recommended to + use <varname>MemoryHigh=</varname> as the main control mechanism and use <varname>MemoryMax=</varname> as the + last line of defense.</para> + + <para>Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a + percentage value may be specified, which is taken relative to the installed physical memory on the system. If + assigned the special value <literal>infinity</literal>, no memory limit is applied. This controls the + <literal>memory.max</literal> control group attribute. For details about this control group attribute, see + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para> + + <para>This setting replaces <varname>MemoryLimit=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemorySwapMax=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the absolute limit on swap usage of the executed processes in this unit.</para> + + <para>Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the + special value <literal>infinity</literal>, no swap limit is applied. This controls the + <literal>memory.swap.max</literal> control group attribute. For details about this control group attribute, + see <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used and disables + <varname>MemoryLimit=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TasksAccounting=</varname></term> + + <listitem> + <para>Turn on task accounting for this unit. Takes a + boolean argument. If enabled, the system manager will keep + track of the number of tasks in the unit. The number of + tasks accounted this way includes both kernel threads and + userspace processes, with each thread counting + individually. Note that turning on tasks accounting for one + unit will also implicitly turn it on for all units contained + in the same slice and for all its parent slices and the + units contained therein. The system default for this setting + may be controlled with + <varname>DefaultTasksAccounting=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TasksMax=<replaceable>N</replaceable></varname></term> + + <listitem> + <para>Specify the maximum number of tasks that may be created in the unit. This ensures that the number of + tasks accounted for the unit (see above) stays below a specific limit. This either takes an absolute number + of tasks or a percentage value that is taken relative to the configured maximum number of tasks on the + system. If assigned the special value <literal>infinity</literal>, no tasks limit is applied. This controls + the <literal>pids.max</literal> control group attribute. For details about this control group attribute, see + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/pids.html">Process Number Controller</ulink>. + </para> + + <para>The system default for this setting may be controlled with + <varname>DefaultTasksMax=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOAccounting=</varname></term> + + <listitem> + <para>Turn on Block I/O accounting for this unit, if the unified control group hierarchy is used on the + system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly + turn it on for all units contained in the same slice and all for its parent slices and the units contained + therein. The system default for this setting may be controlled with <varname>DefaultIOAccounting=</varname> + in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>This setting replaces <varname>BlockIOAccounting=</varname> and disables settings prefixed with + <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOWeight=<replaceable>weight</replaceable></varname></term> + <term><varname>StartupIOWeight=<replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Set the default overall block I/O weight for the executed processes, if the unified control group + hierarchy is used on the system. Takes a single weight value (between 1 and 10000) to set the default block + I/O weight. This controls the <literal>io.weight</literal> control group attribute, which defaults to + 100. For details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>. + The available I/O bandwidth is split up among all units within one slice relative to their block + I/O weight.</para> + + <para>While <varname>StartupIOWeight=</varname> only applies + to the startup phase of the system, + <varname>IOWeight=</varname> applies to the later runtime of + the system, and if the former is not set also to the startup + phase. This allows prioritizing specific services at boot-up + differently than during runtime.</para> + + <para>These settings replace <varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname> + and disable settings prefixed with <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O weight for the executed processes, if the unified control group + hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify + the device specific weight value, between 1 and 10000. (Example: <literal>/dev/sda 1000</literal>). The file + path may be specified as path to a block device node or as any other file, in which case the backing block + device of the file system of the file is determined. This controls the <literal>io.weight</literal> control + group attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices. + For details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>.</para> + + <para>This setting replaces <varname>BlockIODeviceWeight=</varname> and disables settings prefixed with + <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para> + + <para>The specified device node should reference a block device that has an I/O scheduler + associated, i.e. should not refer to partition or loopback block devices, but to the originating, + physical device. When a path to a regular file or directory is specified it is attempted to + discover the correct originating device backing the file system of the specified path. This works + correctly only for simpler cases, where the file system is directly placed on a partition or + physical block device, or where simple 1:1 encryption using dm-crypt/LUKS is used. This discovery + does not cover complex storage and in particular RAID and volume management storage devices.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOReadBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + <term><varname>IOWriteBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified + control group hierarchy is used on the system. This limit is not work-conserving and the executed processes + are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of a file + path and a bandwidth value (in bytes per second) to specify the device specific bandwidth. The file path may + be a path to a block device node, or as any other file in which case the backing block device of the file + system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the <literal>io.max</literal> control + group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details + about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>. + </para> + + <para>These settings replace <varname>BlockIOReadBandwidth=</varname> and + <varname>BlockIOWriteBandwidth=</varname> and disable settings prefixed with <varname>BlockIO</varname> or + <varname>StartupBlockIO</varname>.</para> + + <para>Similar restrictions on block device discovery as for <varname>IODeviceWeight=</varname> apply, see above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOReadIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term> + <term><varname>IOWriteIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the + unified control group hierarchy is used on the system. This limit is not work-conserving and the executed + processes are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of + a file path and an IOPS value to specify the device specific IOPS. The file path may be a path to a block + device node, or as any other file in which case the backing block device of the file system of the file is + used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS, + GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the <literal>io.max</literal> control + group attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about + this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>. + </para> + + <para>These settings are supported only if the unified control group hierarchy is used and disable settings + prefixed with <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para> + + <para>Similar restrictions on block device discovery as for <varname>IODeviceWeight=</varname> apply, see above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IODeviceLatencyTargetSec=<replaceable>device</replaceable> <replaceable>target</replaceable></varname></term> + + <listitem> + <para>Set the per-device average target I/O latency for the executed processes, if the unified control group + hierarchy is used on the system. Takes a file path and a timespan separated by a space to specify + the device specific latency target. (Example: "/dev/sda 25ms"). The file path may be specified + as path to a block device node or as any other file, in which case the backing block device of the file + system of the file is determined. This controls the <literal>io.latency</literal> control group + attribute. Use this option multiple times to set latency target for multiple devices. For details about this + control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>.</para> + + <para>Implies <literal>IOAccounting=yes</literal>.</para> + + <para>These settings are supported only if the unified control group hierarchy is used.</para> + + <para>Similar restrictions on block device discovery as for <varname>IODeviceWeight=</varname> apply, see above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IPAccounting=</varname></term> + + <listitem> + <para>Takes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for packets sent + or received by the unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of + the unit are accounted for.</para> + + <para>When this option is used in socket units, it applies to all IPv4 and IPv6 sockets + associated with it (including both listening and connection sockets where this applies). Note that for + socket-activated services, this configuration setting and the accounting data of the service unit and the + socket unit are kept separate, and displayed separately. No propagation of the setting and the collected + statistics is done, in either direction. Moreover, any traffic sent or received on any of the socket unit's + sockets is accounted to the socket unit — and never to the service unit it might have activated, even if the + socket is used by it.</para> + + <para>The system default for this setting may be controlled with <varname>DefaultIPAccounting=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IPAddressAllow=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term> + <term><varname>IPAddressDeny=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term> + + <listitem> + <para>Turn on network traffic filtering for IP packets sent and received over + <constant>AF_INET</constant> and <constant>AF_INET6</constant> sockets. Both directives take a + space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix + length in bits after a <literal>/</literal> character. If the suffix is omitted, the address is + considered a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for + IPv6).</para> + + <para>The access lists 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 lists are implicitly + combined with any lists configured for any of the parent slice units this unit might be a member + of. By default both access lists are empty. Both ingress and egress traffic is filtered by these + settings. In case of ingress traffic the source IP address is checked against these access lists, + in case of egress traffic the destination IP address is checked. The following rules are applied in + turn:</para> + + <itemizedlist> + <listitem><para>Access is granted when the checked IP address matches an entry in the + <varname>IPAddressAllow=</varname> list.</para></listitem> + + <listitem><para>Otherwise, access is denied when the checked IP address matches an entry in the + <varname>IPAddressDeny=</varname> list.</para></listitem> + + <listitem><para>Otherwise, access is granted.</para></listitem> + </itemizedlist> + + <para>In order to implement an allow-listing IP firewall, it is recommended to use a + <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit + (such as the root slice <filename>-.slice</filename> or the slice containing all system services + <filename>system.slice</filename> – see + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname> + lines permitting network access to relevant services, and only them.</para> + + <para>Note that for socket-activated services, the IP access list configured on the socket unit + applies to all sockets associated with it directly, but not to any sockets created by the + ultimately activated services for it. Conversely, the IP access list configured for the service is + not applied to any sockets passed into the service via socket activation. Thus, it is usually a + good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless, + it may make sense to maintain one list more open and the other one more restricted, depending on + the usecase.</para> + + <para>If these settings are used multiple times in the same unit the specified lists are combined. If an + empty string is assigned to these settings the specific access list is reset and all previous settings undone.</para> + + <para>In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic + names may be used. The following names are defined:</para> + + <table> + <title>Special address/network names</title> + + <tgroup cols='3'> + <colspec colname='name'/> + <colspec colname='definition'/> + <colspec colname='meaning'/> + + <thead> + <row> + <entry>Symbolic Name</entry> + <entry>Definition</entry> + <entry>Meaning</entry> + </row> + </thead> + + <tbody> + <row> + <entry><constant>any</constant></entry> + <entry>0.0.0.0/0 ::/0</entry> + <entry>Any host</entry> + </row> + + <row> + <entry><constant>localhost</constant></entry> + <entry>127.0.0.0/8 ::1/128</entry> + <entry>All addresses on the local loopback</entry> + </row> + + <row> + <entry><constant>link-local</constant></entry> + <entry>169.254.0.0/16 fe80::/64</entry> + <entry>All link-local IP addresses</entry> + </row> + + <row> + <entry><constant>multicast</constant></entry> + <entry>224.0.0.0/4 ff00::/8</entry> + <entry>All IP multicasting addresses</entry> + </row> + </tbody> + </tgroup> + </table> + + <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 have no effect in + that case. If compatibility with such systems is desired it is hence recommended to not exclusively rely on + them for IP security.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term> + <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAM_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. 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/html/latest/admin-guide/cgroup-v1/devices.html">Device Whitelist Controller</ulink>. + In the unified cgroup hierarchy 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 allow-list 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 allow lists 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 allow list. In order to work around this limitation, consider extending service units + with a pair of <command>After=modprobe@xyz.service</command> and + <command>Wants=modprobe@xyz.service</command> lines that load the necessary kernel module + implementing the device group if missing. + Example: <programlisting>… +[Unit] +Wants=modprobe@loop.service +After=modprobe@loop.service + +[Service] +DeviceAllow=block-loop +DeviceAllow=/dev/loop-control +…</programlisting></para> + + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DevicePolicy=auto|closed|strict</varname></term> + + <listitem> + <para> + Control the policy for allowing device access: + </para> + <variablelist> + <varlistentry> + <term><option>strict</option></term> + <listitem> + <para>means to only allow types of access that are + explicitly specified.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>closed</option></term> + <listitem> + <para>in addition, allows access to standard pseudo + devices including + <filename>/dev/null</filename>, + <filename>/dev/zero</filename>, + <filename>/dev/full</filename>, + <filename>/dev/random</filename>, and + <filename>/dev/urandom</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>auto</option></term> + <listitem> + <para> + in addition, allows access to all devices if no + explicit <varname>DeviceAllow=</varname> is present. + This is the default. + </para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Slice=</varname></term> + + <listitem> + <para>The name of the slice unit to place the unit + in. Defaults to <filename>system.slice</filename> for all + non-instantiated units of all unit types (except for slice + units themselves see below). Instance units are by default + placed in a subslice of <filename>system.slice</filename> + that is named after the template name.</para> + + <para>This option may be used to arrange systemd units in a + hierarchy of slices each of which might have resource + settings applied.</para> + + <para>For units of type slice, the only accepted value for + this setting is the parent slice. Since the name of a slice + unit implies the parent slice, it is hence redundant to ever + set this parameter directly for slice units.</para> + + <para>Special care should be taken when relying on the default slice assignment in templated service units + that have <varname>DefaultDependencies=no</varname> set, see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, section + "Default Dependencies" for details.</para> + + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Delegate=</varname></term> + + <listitem> + <para>Turns on delegation of further resource control partitioning to processes of the unit. Units where this + is enabled may create and manage their own private subhierarchy of control groups below the control group of + the unit itself. For unprivileged services (i.e. those using the <varname>User=</varname> setting) the unit's + control group will be made accessible to the relevant user. When enabled the service manager will refrain + from manipulating control groups or moving processes below the unit's control group, so that a clear concept + of ownership is established: the control group tree above the unit's control group (i.e. towards the root + control group) is owned and managed by the service manager of the host, while the control group tree below + the unit's control group is owned and managed by the unit itself. Takes either a boolean argument or a list + of control group controller names. If true, delegation is turned on, and all supported controllers are + enabled for the unit, making them available to the unit's processes for management. If false, delegation is + turned off entirely (and no additional controllers are enabled). If set to a list of controllers, delegation + is turned on, and the specified controllers are enabled for the unit. Note that additional controllers than + the ones specified might be made available as well, depending on configuration of the containing slice unit + or other units contained in it. Note that assigning the empty string will enable delegation, but reset the + list of controllers, all assignments prior to this will have no effect. Defaults to false.</para> + + <para>Note that controller delegation to less privileged code is only safe on the unified control group + hierarchy. Accordingly, access to the specified controllers will not be granted to unprivileged services on + the legacy hierarchy, even when requested.</para> + + <xi:include href="supported-controllers.xml" xpointer="controllers-text" /> + + <para>Not all of these controllers are available on all kernels however, and some are + specific to the unified hierarchy while others are specific to the legacy hierarchy. Also note that the + kernel might support further controllers, which aren't covered here yet as delegation is either not supported + at all for them or not defined cleanly.</para> + + <para>For further details on the delegation model consult <ulink + url="https://systemd.io/CGROUP_DELEGATION">Control Group APIs and Delegation</ulink>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DisableControllers=</varname></term> + + <listitem> + <para>Disables controllers from being enabled for a unit's children. If a controller listed is already in use + in its subtree, the controller will be removed from the subtree. This can be used to avoid child units being + able to implicitly or explicitly enable a controller. Defaults to not disabling any controllers.</para> + + <para>It may not be possible to successfully disable a controller if the unit or any child of the unit in + question delegates controllers to its children, as any delegated subtree of the cgroup hierarchy is unmanaged + by systemd.</para> + + <para>Multiple controllers may be specified, separated by spaces. You may also pass + <varname>DisableControllers=</varname> multiple times, in which case each new instance adds another controller + to disable. Passing <varname>DisableControllers=</varname> by itself with no controller name present resets + the disabled controller list.</para> + + <xi:include href="supported-controllers.xml" xpointer="controllers-text" /> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ManagedOOMSwap=auto|kill</varname></term> + <term><varname>ManagedOOMMemoryPressure=auto|kill</varname></term> + + <listitem> + <para>Specifies how + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + will act on this unit's cgroups. Defaults to <option>auto</option>.</para> + + <para>When set to <option>kill</option>, <command>systemd-oomd</command> will actively monitor this unit's + cgroup metrics to decide whether it needs to act. If the cgroup passes the limits set by + <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> or its + overrides, <command>systemd-oomd</command> will send a <constant>SIGKILL</constant> to all of the processes + under the chosen candidate cgroup. Note that only descendant cgroups can be eligible candidates for killing; + the unit that set its property to <option>kill</option> is not a candidate (unless one of its ancestors set + their property to <option>kill</option>). You can find more details on candidates and kill behavior at + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Setting + either of these properties to <option>kill</option> will also automatically acquire + <varname>After=</varname> and <varname>Wants=</varname> dependencies on + <filename>systemd-oomd.service</filename> unless <varname>DefaultDependencies=no</varname>. + </para> + + <para>When set to <option>auto</option>, <command>systemd-oomd</command> will not actively use this cgroup's + data for monitoring and detection. However, if an ancestor cgroup has one of these properties set to + <option>kill</option>, a unit with <option>auto</option> can still be an eligible candidate for + <command>systemd-oomd</command> to act on.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ManagedOOMMemoryPressureLimitPercent=</varname></term> + + <listitem> + <para>Overrides the default memory pressure limit set by + <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for this unit + (cgroup). Takes a percentage value between 0% and 100%, inclusive. This property is ignored unless + <varname>ManagedOOMMemoryPressure=</varname><option>kill</option>. Defaults to 0%, which means use the + default set by <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Deprecated Options</title> + + <para>The following options are deprecated. Use the indicated superseding options instead:</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>CPUShares=<replaceable>weight</replaceable></varname></term> + <term><varname>StartupCPUShares=<replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Assign the specified CPU time share weight to the processes executed. These options take an integer + value and control the <literal>cpu.shares</literal> control group attribute. The allowed range is 2 to + 262144. Defaults to 1024. For details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html">CFS Scheduler</ulink>. + The available CPU time is split up among all units within one slice relative to their CPU time share + weight.</para> + + <para>While <varname>StartupCPUShares=</varname> only applies to the startup phase of the system, + <varname>CPUShares=</varname> applies to normal runtime of the system, and if the former is not set also to + the startup phase. Using <varname>StartupCPUShares=</varname> allows prioritizing specific services at + boot-up differently than during normal runtime.</para> + + <para>Implies <literal>CPUAccounting=yes</literal>.</para> + + <para>These settings are deprecated. Use <varname>CPUWeight=</varname> and + <varname>StartupCPUWeight=</varname> instead.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryLimit=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the limit on maximum memory usage of the executed processes. The limit specifies how much + process and kernel memory can be used by tasks in this unit. Takes a memory size in bytes. If the value is + suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or + Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is + taken relative to the installed physical memory on the system. If assigned the special value + <literal>infinity</literal>, no memory limit is applied. This controls the + <literal>memory.limit_in_bytes</literal> control group attribute. For details about this control group + attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html">Memory Resource Controller</ulink>.</para> + + <para>Implies <literal>MemoryAccounting=yes</literal>.</para> + + <para>This setting is deprecated. Use <varname>MemoryMax=</varname> instead.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BlockIOAccounting=</varname></term> + + <listitem> + <para>Turn on Block I/O accounting for this unit, if the legacy control group hierarchy is used on the + system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly + turn it on for all units contained in the same slice and all for its parent slices and the units contained + therein. The system default for this setting may be controlled with + <varname>DefaultBlockIOAccounting=</varname> in + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>This setting is deprecated. Use <varname>IOAccounting=</varname> instead.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BlockIOWeight=<replaceable>weight</replaceable></varname></term> + <term><varname>StartupBlockIOWeight=<replaceable>weight</replaceable></varname></term> + + <listitem><para>Set the default overall block I/O weight for the executed processes, if the legacy control + group hierarchy is used on the system. Takes a single weight value (between 10 and 1000) to set the default + block I/O weight. This controls the <literal>blkio.weight</literal> control group attribute, which defaults to + 500. For details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html">Block IO Controller</ulink>. + The available I/O bandwidth is split up among all units within one slice relative to their block I/O + weight.</para> + + <para>While <varname>StartupBlockIOWeight=</varname> only + applies to the startup phase of the system, + <varname>BlockIOWeight=</varname> applies to the later runtime + of the system, and if the former is not set also to the + startup phase. This allows prioritizing specific services at + boot-up differently than during runtime.</para> + + <para>Implies + <literal>BlockIOAccounting=yes</literal>.</para> + + <para>These settings are deprecated. Use <varname>IOWeight=</varname> and <varname>StartupIOWeight=</varname> + instead.</para> + + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BlockIODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O weight for the executed processes, if the legacy control group + hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify + the device specific weight value, between 10 and 1000. (Example: "/dev/sda 500"). The file path may be + specified as path to a block device node or as any other file, in which case the backing block device of the + file system of the file is determined. This controls the <literal>blkio.weight_device</literal> control group + attribute, which defaults to 1000. Use this option multiple times to set weights for multiple devices. For + details about this control group attribute, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html">Block IO Controller</ulink>.</para> + + <para>Implies + <literal>BlockIOAccounting=yes</literal>.</para> + + <para>This setting is deprecated. Use <varname>IODeviceWeight=</varname> instead.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BlockIOReadBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + <term><varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O bandwidth limit for the executed processes, if the legacy control + group hierarchy is used on the system. Takes a space-separated pair of a file path and a bandwidth value (in + bytes per second) to specify the device specific bandwidth. The file path may be a path to a block device + node, or as any other file in which case the backing block device of the file system of the file is used. If + the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is parsed as Kilobytes, Megabytes, + Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the + <literal>blkio.throttle.read_bps_device</literal> and <literal>blkio.throttle.write_bps_device</literal> + control group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For + details about these control group attributes, see <ulink + url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html">Block IO Controller</ulink>. + </para> + + <para>Implies + <literal>BlockIOAccounting=yes</literal>.</para> + + <para>These settings are deprecated. Use <varname>IOReadBandwidthMax=</varname> and + <varname>IOWriteBandwidthMax=</varname> instead.</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + The documentation for control groups and specific controllers in the Linux kernel: + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">Control Groups v2</ulink>. + </para> + </refsect1> +</refentry> diff --git a/man/systemd.scope.xml b/man/systemd.scope.xml new file mode 100644 index 0000000..7d7b32d --- /dev/null +++ b/man/systemd.scope.xml @@ -0,0 +1,126 @@ +<?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-or-later --> + +<refentry id="systemd.scope"> + <refentryinfo> + <title>systemd.scope</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.scope</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.scope</refname> + <refpurpose>Scope unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>scope</replaceable>.scope</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>Scope units are not configured via unit configuration files, + but are only created programmatically using the bus interfaces of + systemd. They are named similar to filenames. A unit whose name + ends in <literal>.scope</literal> refers to a scope unit. Scopes + units manage a set of system processes. Unlike service units, scope + units manage externally created processes, and do not fork off + processes on its own.</para> + + <para>The main purpose of scope units is grouping worker processes + of a system service for organization and for managing resources.</para> + + <para><command>systemd-run <option>--scope</option></command> may + be used to easily launch a command in a new scope unit from the + command line.</para> + + <para>See the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New + Control Group Interfaces</ulink> for an introduction on how to make + use of scope units from programs.</para> + + <para>Note that, unlike service units, scope units have no "main" process: all processes in the scope are + equivalent. The lifecycle of the scope unit is thus not bound to the lifetime of one specific process, + but to the existence of at least one process in the scope. This also means that the exit statuses of + these processes are not relevant for the scope unit failure state. Scope units may still enter a failure + state, for example due to resource exhaustion or stop timeouts being reached, but not due to programs + inside of them terminating uncleanly. Since processes managed as scope units generally remain children of + the original process that forked them off, it is also the job of that process to collect their exit + statuses and act on them as needed.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>Implicit dependencies may be added as result of + resource control parameters as documented in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless + <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Scope units will automatically have dependencies of + type <varname>Conflicts=</varname> and + <varname>Before=</varname> on + <filename>shutdown.target</filename>. These ensure + that scope units are removed prior to system + shutdown. Only scope units involved with early boot or + late system shutdown should disable + <varname>DefaultDependencies=</varname> option.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Scope files may include a [Scope] + section, which carries information about the scope and the + units it contains. A number of options that may be used in + this section are shared with other unit types. These options are + documented in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The options specific to the [Scope] section + of scope units are the following:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>RuntimeMaxSec=</varname></term> + + <listitem><para>Configures a maximum time for the scope to run. If this is used and the scope has been + active for longer than the specified time it is terminated and put into a failure state. Pass + <literal>infinity</literal> (the default) to configure no runtime limit.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.service.xml b/man/systemd.service.xml new file mode 100644 index 0000000..5da6d13 --- /dev/null +++ b/man/systemd.service.xml @@ -0,0 +1,1579 @@ +<?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-or-later --> + +<refentry id="systemd.service"> + <refentryinfo> + <title>systemd.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.service</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.service</refname> + <refpurpose>Service unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>service</replaceable>.service</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.service</literal> encodes information about a process + controlled and supervised by systemd.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic + [Unit] and [Install] + sections. The service specific configuration options are + configured in the [Service] section.</para> + + <para>Additional options are listed in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the execution environment the commands are executed + in, and in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the way the processes of the service are terminated, + and in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which configure resource control settings for the processes of the + service.</para> + + <para>If a service is requested under a certain name but no unit + configuration file is found, systemd looks for a SysV init script + by the same name (with the <filename>.service</filename> suffix + removed) and dynamically creates a service unit from that script. + This is useful for compatibility with SysV. Note that this + compatibility is quite comprehensive but not 100%. For details + about the incompatibilities, see the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities + with SysV</ulink> document.</para> + + <para>The <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> + command allows creating <filename>.service</filename> and <filename>.scope</filename> units dynamically + and transiently from the command line.</para> + </refsect1> + + <refsect1> + <title>Service Templates</title> + + <para>It is possible for <command>systemd</command> services to take a single argument via the + <literal><replaceable>service</replaceable>@<replaceable>argument</replaceable>.service</literal> + syntax. Such services are called "instantiated" services, while the unit definition without the + <replaceable>argument</replaceable> parameter is called a "template". An example could be a + <filename>dhcpcd@.service</filename> service template which takes a network interface as a + parameter to form an instantiated service. Within the service file, this parameter or "instance + name" can be accessed with %-specifiers. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>Services with <varname>Type=dbus</varname> set automatically + acquire dependencies of type <varname>Requires=</varname> and + <varname>After=</varname> on + <filename>dbus.socket</filename>.</para></listitem> + + <listitem><para>Socket activated services are automatically ordered after + their activating <filename>.socket</filename> units via an + automatic <varname>After=</varname> dependency. + Services also pull in all <filename>.socket</filename> units + listed in <varname>Sockets=</varname> via automatic + <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem> + </itemizedlist> + + <para>Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Service units will have dependencies of type <varname>Requires=</varname> and + <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on + <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and + <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in + basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early + boot or late system shutdown should disable this option.</para></listitem> + + <listitem><para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by + default a per-template slice unit (see + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the + template unit, containing all instances of the specific template. This slice is normally stopped at shutdown, + together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the + template unit, and either define your own per-template slice unit file that also sets + <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice) + in the template unit. Also see + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Service files must include a [Service] + section, which carries information about the service and the + process it supervises. A number of options that may be used in + this section are shared with other unit types. These options are + documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The options specific to the [Service] section + of service units are the following:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>Type=</varname></term> + + <listitem> + <para>Configures the process start-up type for this service unit. One of <option>simple</option>, + <option>exec</option>, <option>forking</option>, <option>oneshot</option>, <option>dbus</option>, + <option>notify</option> or <option>idle</option>:</para> + + <itemizedlist> + <listitem><para>If set to <option>simple</option> (the default if <varname>ExecStart=</varname> is + specified but neither <varname>Type=</varname> nor <varname>BusName=</varname> are), the service manager + will consider the unit started immediately after the main service process has been forked off. It is + expected that the process configured with <varname>ExecStart=</varname> is the main process of the + service. In this mode, if the process offers functionality to other processes on the system, its + communication channels should be installed before the service is started up (e.g. sockets set up by + systemd, via socket activation), as the service manager will immediately proceed starting follow-up units, + right after creating the main service process, and before executing the service's binary. Note that this + means <command>systemctl start</command> command lines for <option>simple</option> services will report + success even if the service's binary cannot be invoked successfully (for example because the selected + <varname>User=</varname> doesn't exist, or the service binary is missing).</para></listitem> + + <listitem><para>The <option>exec</option> type is similar to <option>simple</option>, but the service + manager will consider the unit started immediately after the main service binary has been executed. The service + manager will delay starting of follow-up units until that point. (Or in other words: + <option>simple</option> proceeds with further jobs right after <function>fork()</function> returns, while + <option>exec</option> will not proceed before both <function>fork()</function> and + <function>execve()</function> in the service process succeeded.) Note that this means <command>systemctl + start</command> command lines for <option>exec</option> services will report failure when the service's + binary cannot be invoked successfully (for example because the selected <varname>User=</varname> doesn't + exist, or the service binary is missing).</para></listitem> + + <listitem><para>If set to <option>forking</option>, it is expected that the process configured with + <varname>ExecStart=</varname> will call <function>fork()</function> as part of its start-up. The parent + process is expected to exit when start-up is complete and all communication channels are set up. The child + continues to run as the main service process, and the service manager will consider the unit started when + the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is + recommended to also use the <varname>PIDFile=</varname> option, so that systemd can reliably identify the + 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 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 continuously. 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 + <varname>BusName=</varname>. systemd will proceed with starting follow-up units after the D-Bus + bus name has been acquired. Service units with this option configured implicitly gain + dependencies on the <filename>dbus.socket</filename> unit. This type is the default if + <varname>BusName=</varname> is specified. A service unit of this type is considered to be in the + activating state until the specified bus name is acquired. It is considered activated while the + bus name is taken. Once the bus name is released the service is considered being no longer + functional which has the effect that the service manager attempts to terminate any remaining + processes belonging to the service. Services that drop their bus name as part of their shutdown + logic thus should be prepared to receive a <constant>SIGTERM</constant> (or whichever signal is + configured in <varname>KillSignal=</varname>) as result.</para></listitem> + + <listitem><para>Behavior of <option>notify</option> is similar to <option>exec</option>; however, it is + expected that the service sends a notification message via + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> or an + equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after + this notification message has been sent. If this option is used, <varname>NotifyAccess=</varname> (see + below) should be set to open access to the notification socket provided by systemd. If + <varname>NotifyAccess=</varname> is missing or set to <option>none</option>, it will be forcibly set to + <option>main</option>.</para></listitem> + + <listitem><para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however, + actual execution of the service program is delayed until all active jobs are dispatched. This may be used + to avoid interleaving of output of shell services with the status output on the console. Note that this + type is useful only to improve console output, it is not useful as a general unit ordering tool, and the + effect of this service type is subject to a 5s timeout, after which the service program is invoked + anyway.</para></listitem> + </itemizedlist> + + <para>It is generally recommended to use <varname>Type=</varname><option>simple</option> for long-running + services whenever possible, as it is the simplest and fastest option. However, as this service type won't + propagate service start-up failures and doesn't allow ordering of other units against completion of + initialization of the service (which for example is useful if clients need to connect to the service through + some form of IPC, and the IPC channel is only established by the service itself — in contrast to doing this + ahead of time through socket or bus activation or similar), it might not be sufficient for many cases. If so, + <option>notify</option> or <option>dbus</option> (the latter only in case the service provides a D-Bus + interface) are the preferred options as they allow service program code to precisely schedule when to + consider the service started up successfully and when to proceed with follow-up units. The + <option>notify</option> service type requires explicit support in the service codebase (as + <function>sd_notify()</function> or an equivalent API needs to be invoked by the service at the appropriate + time) — if it's not supported, then <option>forking</option> is an alternative: it supports the traditional + UNIX service start-up protocol. Finally, <option>exec</option> might be an option for cases where it is + enough to ensure the service binary is invoked, and where the service binary itself executes no or little + initialization on its own (and its initialization is unlikely to fail). Note that using any type other than + <option>simple</option> possibly delays the boot process, as the service manager needs to wait for service + initialization to complete. It is hence recommended not to needlessly use any types other than + <option>simple</option>. (Also note it is generally not recommended to use <option>idle</option> or + <option>oneshot</option> for long-running services.)</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemainAfterExit=</varname></term> + + <listitem><para>Takes a boolean value that specifies whether + the service shall be considered active even when all its + processes exited. Defaults to <option>no</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>GuessMainPID=</varname></term> + + <listitem><para>Takes a boolean value that specifies whether + systemd should try to guess the main PID of a service if it + cannot be determined reliably. This option is ignored unless + <option>Type=forking</option> is set and + <option>PIDFile=</option> is unset because for the other types + or with an explicitly configured PID file, the main PID is + always known. The guessing algorithm might come to incorrect + conclusions if a daemon consists of more than one process. If + the main PID cannot be determined, failure detection and + automatic restarting of a service will not work reliably. + Defaults to <option>yes</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PIDFile=</varname></term> + + <listitem><para>Takes a path referring to the PID file of the service. Usage of this option is recommended for + services where <varname>Type=</varname> is set to <option>forking</option>. The path specified typically points + to a file below <filename>/run/</filename>. If a relative path is specified it is hence prefixed with + <filename>/run/</filename>. The service manager will read the PID of the main process of the service from this + file after start-up of the service. The service manager will not write to the file configured here, although it + will remove the file after the service has shut down if it still exists. The PID file does not need to be owned + by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: + the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the + PID file must refer to a process already belonging to the service.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>BusName=</varname></term> + + <listitem><para>Takes a D-Bus destination name that this service shall use. This option is mandatory + for services where <varname>Type=</varname> is set to <option>dbus</option>. It is recommended to + always set this property if known to make it easy to map the service name to the D-Bus destination. + In particular, <command>systemctl service-log-level/service-log-target</command> verbs make use of + this.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExecStart=</varname></term> + <listitem><para>Commands with their arguments that are + executed when this service is started. The value is split into + zero or more command lines according to the rules described + below (see section "Command Lines" below). + </para> + + <para>Unless <varname>Type=</varname> is <option>oneshot</option>, exactly one command must be given. When + <varname>Type=oneshot</varname> is used, zero or more commands may be specified. Commands may be specified by + providing multiple command lines in the same directive, or alternatively, this directive may be specified more + than once with the same effect. If the empty string is assigned to this option, the list of commands to start + is reset, prior assignments of this option will have no effect. If no <varname>ExecStart=</varname> is + specified, then the service must have <varname>RemainAfterExit=yes</varname> and at least one + <varname>ExecStop=</varname> line set. (Services lacking both <varname>ExecStart=</varname> and + <varname>ExecStop=</varname> are not valid.)</para> + + <para>For each of the specified commands, the first argument must be either an absolute path to an executable + or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special + characters:</para> + + <table> + <title>Special executable prefixes</title> + + <tgroup cols='2'> + <colspec colname='prefix'/> + <colspec colname='meaning'/> + + <thead> + <row> + <entry>Prefix</entry> + <entry>Effect</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>@</literal></entry> + <entry>If the executable path is prefixed with <literal>@</literal>, the second specified token will be passed as <literal>argv[0]</literal> to the executed process (instead of the actual filename), followed by the further arguments specified.</entry> + </row> + + <row> + <entry><literal>-</literal></entry> + <entry>If the executable path is prefixed with <literal>-</literal>, an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.</entry> + </row> + + <row> + <entry><literal>:</literal></entry> + <entry>If the executable path is prefixed with <literal>:</literal>, environment variable substitution (as described by the "Command Lines" section below) is not applied.</entry> + </row> + + <row> + <entry><literal>+</literal></entry> + <entry>If the executable path is prefixed with <literal>+</literal> then the process is executed with full privileges. In this mode privilege restrictions configured with <varname>User=</varname>, <varname>Group=</varname>, <varname>CapabilityBoundingSet=</varname> or the various file system namespacing options (such as <varname>PrivateDevices=</varname>, <varname>PrivateTmp=</varname>) are not applied to the invoked command line (but still affect any other <varname>ExecStart=</varname>, <varname>ExecStop=</varname>, … lines).</entry> + </row> + + <row> + <entry><literal>!</literal></entry> + + <entry>Similar to the <literal>+</literal> character discussed above this permits invoking command lines with elevated privileges. However, unlike <literal>+</literal> the <literal>!</literal> character exclusively alters the effect of <varname>User=</varname>, <varname>Group=</varname> and <varname>SupplementaryGroups=</varname>, i.e. only the stanzas that affect user and group credentials. Note that this setting may be combined with <varname>DynamicUser=</varname>, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.</entry> + </row> + + <row> + <entry><literal>!!</literal></entry> + + <entry>This prefix is very similar to <literal>!</literal>, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for <varname>AmbientCapabilities=</varname>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when <literal>!!</literal> is used, and a system lacking ambient capability support is detected any configured <varname>SystemCallFilter=</varname> and <varname>CapabilityBoundingSet=</varname> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected <varname>AmbientCapabilities=</varname> will be skipped and not be applied. On systems supporting ambient capabilities, <literal>!!</literal> has no effect and is redundant.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para><literal>@</literal>, <literal>-</literal>, <literal>:</literal>, and one of + <literal>+</literal>/<literal>!</literal>/<literal>!!</literal> may be used together and they can appear in any + order. However, only one of <literal>+</literal>, <literal>!</literal>, <literal>!!</literal> may be used at a + time. Note that these prefixes are also supported for the other command line settings, + i.e. <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecReload=</varname>, + <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>.</para> + + <para>If more than one command is specified, the commands are + invoked sequentially in the order they appear in the unit + file. If one of the commands fails (and is not prefixed with + <literal>-</literal>), other lines are not executed, and the + unit is considered failed.</para> + + <para>Unless <varname>Type=forking</varname> is set, the + process started via this command line will be considered the + main process of the daemon.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExecStartPre=</varname></term> + <term><varname>ExecStartPost=</varname></term> + <listitem><para>Additional commands that are executed before + or after the command in <varname>ExecStart=</varname>, + respectively. 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>If any of those commands (not prefixed with + <literal>-</literal>) fail, the rest are not executed and the + unit is considered failed.</para> + + <para><varname>ExecStart=</varname> commands are only run after + all <varname>ExecStartPre=</varname> commands that were not prefixed + with a <literal>-</literal> exit successfully.</para> + + <para><varname>ExecStartPost=</varname> commands are only run after the commands specified in + <varname>ExecStart=</varname> have been invoked successfully, as determined by <varname>Type=</varname> + (i.e. the process has been started for <varname>Type=simple</varname> or <varname>Type=idle</varname>, the last + <varname>ExecStart=</varname> process exited successfully for <varname>Type=oneshot</varname>, the initial + process exited successfully for <varname>Type=forking</varname>, <literal>READY=1</literal> is sent for + <varname>Type=notify</varname>, or the <varname>BusName=</varname> has been taken for + <varname>Type=dbus</varname>).</para> + + <para>Note that <varname>ExecStartPre=</varname> may not be + used to start long-running processes. All processes forked + off by processes invoked via <varname>ExecStartPre=</varname> will + be killed before the next service process is run.</para> + + <para>Note that if any of the commands specified in <varname>ExecStartPre=</varname>, + <varname>ExecStart=</varname>, or <varname>ExecStartPost=</varname> fail (and are not prefixed with + <literal>-</literal>, see above) or time out before the service is fully up, execution continues with commands + specified in <varname>ExecStopPost=</varname>, the commands in <varname>ExecStop=</varname> are skipped.</para> + + <para>Note that the execution of <varname>ExecStartPost=</varname> is taken into account for the purpose of + <varname>Before=</varname>/<varname>After=</varname> ordering constraints.</para> + </listitem> + </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 + lines, following the same scheme as described for + <varname>ExecStart=</varname> above. Use of this setting is + optional. Specifier and environment variable substitution is + supported here following the same scheme as for + <varname>ExecStart=</varname>.</para> + + <para>One additional, special environment variable is set: if + known, <varname>$MAINPID</varname> is set to the main process + of the daemon, and may be used for command lines like the + following:</para> + + <programlisting>ExecReload=kill -HUP $MAINPID</programlisting> + + <para>Note however that reloading a daemon by sending a signal + (as with the example line above) is usually not a good choice, + because this is an asynchronous operation and hence not + suitable to order reloads of multiple services against each + other. It is strongly recommended to set + <varname>ExecReload=</varname> to a command that not only + triggers a configuration reload of the daemon, but also + synchronously waits for it to complete. For example, + <citerefentry project='mankier'><refentrytitle>dbus-broker</refentrytitle><manvolnum>1</manvolnum></citerefentry> + uses the following:</para> + + <programlisting>ExecReload=busctl call org.freedesktop.DBus \ + /org/freedesktop/DBus org.freedesktop.DBus \ + ReloadConfig +</programlisting> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExecStop=</varname></term> + <listitem><para>Commands to execute to stop the service started via + <varname>ExecStart=</varname>. This argument takes multiple command lines, following the same scheme + as described for <varname>ExecStart=</varname> above. Use of this setting is optional. After the + commands configured in this option are run, it is implied that the service is stopped, and any + processes remaining for it are terminated according to the <varname>KillMode=</varname> setting (see + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + If this option is not specified, the process is terminated by sending the signal specified in + <varname>KillSignal=</varname> or <varname>RestartKillSignal=</varname> when service stop is + requested. Specifier and environment variable substitution is supported (including + <varname>$MAINPID</varname>, see above).</para> + + <para>Note that it is usually not sufficient to specify a command for this setting that only asks the + service to terminate (for example, by sending some form of termination signal to it), but does not + wait for it to do so. Since the remaining processes of the services are killed according to + <varname>KillMode=</varname> and <varname>KillSignal=</varname> or + <varname>RestartKillSignal=</varname> as described above immediately after the command exited, this + may not result in a clean stop. The specified command should hence be a synchronous operation, not an + asynchronous one.</para> + + <para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service + started successfully first. They are not invoked if the service was never started at all, or in case its + start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>, + <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with + <literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a + service failed to start up correctly and is shut down again. Also note that the stop operation is always + performed if the service started successfully, even if the processes in the service terminated on their + own or were killed. The stop commands must be prepared to deal with that case. <varname>$MAINPID</varname> + will be unset if systemd knows that the main process exited by the time the stop commands are called.</para> + + <para>Service restart requests are implemented as stop operations followed by start operations. This + means that <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> are executed during a + service restart operation.</para> + + <para>It is recommended to use this setting for commands that communicate with the service requesting + clean termination. For post-mortem clean-up steps use <varname>ExecStopPost=</varname> instead. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExecStopPost=</varname></term> + <listitem><para>Additional commands that are executed after the service is stopped. This includes cases where + the commands configured in <varname>ExecStop=</varname> were used, where the service does not have any + <varname>ExecStop=</varname> defined, or where the service exited unexpectedly. This argument takes multiple + command lines, following the same scheme as described for <varname>ExecStart=</varname>. Use of these settings + is optional. Specifier and environment variable substitution is supported. Note that – unlike + <varname>ExecStop=</varname> – commands specified with this setting are invoked when a service failed to start + up correctly and is shut down again.</para> + + <para>It is recommended to use this setting for clean-up operations that shall be executed even when the + service failed to start up correctly. Commands configured with this setting need to be able to operate even if + the service failed starting up half-way and left incompletely initialized data around. As the service's + processes have been terminated already when the commands specified with this setting are executed they should + not attempt to communicate with them.</para> + + <para>Note that all commands that are configured with this setting are invoked with the result code of the + service, as well as the main process' exit code and status, set in the <varname>$SERVICE_RESULT</varname>, + <varname>$EXIT_CODE</varname> and <varname>$EXIT_STATUS</varname> environment variables, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details.</para> + + <para>Note that the execution of <varname>ExecStopPost=</varname> is taken into account for the purpose of + <varname>Before=</varname>/<varname>After=</varname> ordering constraints.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestartSec=</varname></term> + <listitem><para>Configures the time to sleep before restarting + a service (as configured with <varname>Restart=</varname>). + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Defaults to 100ms.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimeoutStartSec=</varname></term> + <listitem><para>Configures the time to wait for start-up. If a daemon service does not signal start-up + completion within the configured time, the service will be considered failed and will be shut down again. The + precise action depends on the <varname>TimeoutStartFailureMode=</varname> option. Takes a unit-less value in + seconds, or a time span value such as "5min 20s". Pass <literal>infinity</literal> to disable the timeout logic. + Defaults to <varname>DefaultTimeoutStartSec=</varname> from the manager configuration file, except when + <varname>Type=oneshot</varname> is used, in which case the timeout is disabled by default (see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + </para> + + <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause + the start time to be extended beyond <varname>TimeoutStartSec=</varname>. The first receipt of this message + must occur before <varname>TimeoutStartSec=</varname> is exceeded, and once the start time has extended beyond + <varname>TimeoutStartSec=</varname>, the service manager will allow the service to continue to start, provided + the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified until the service + startup status is finished by <literal>READY=1</literal>. (see + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimeoutStopSec=</varname></term> + <listitem><para>This option serves two purposes. First, it configures the time to wait for each + <varname>ExecStop=</varname> command. If any of them times out, subsequent <varname>ExecStop=</varname> commands + are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <varname>ExecStop=</varname> + commands are specified, the service gets the <constant>SIGTERM</constant> immediately. This default behavior + can be changed by the <varname>TimeoutStopFailureMode=</varname> option. Second, it configures the time + to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated + by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass <literal>infinity</literal> to disable the + timeout logic. Defaults to + <varname>DefaultTimeoutStopSec=</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> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause + the stop time to be extended beyond <varname>TimeoutStopSec=</varname>. The first receipt of this message + must occur before <varname>TimeoutStopSec=</varname> is exceeded, and once the stop time has extended beyond + <varname>TimeoutStopSec=</varname>, the service manager will allow the service to continue to stop, 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>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 extended 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 + <varname>TimeoutStopSec=</varname> to the specified value. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimeoutStartFailureMode=</varname></term> + <term><varname>TimeoutStopFailureMode=</varname></term> + + <listitem><para>These options configure the action that is taken in case a daemon service does not signal + start-up within its configured <varname>TimeoutStartSec=</varname>, respectively if it does not stop within + <varname>TimeoutStopSec=</varname>. Takes one of <option>terminate</option>, <option>abort</option> and + <option>kill</option>. Both options default to <option>terminate</option>.</para> + + <para>If <option>terminate</option> is set the service will be gracefully terminated by sending the signal + specified in <varname>KillSignal=</varname> (defaults to <constant>SIGTERM</constant>, see + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If the + service does not terminate the <varname>FinalKillSignal=</varname> is sent after + <varname>TimeoutStopSec=</varname>. If <option>abort</option> is set, <varname>WatchdogSignal=</varname> is sent + instead and <varname>TimeoutAbortSec=</varname> applies before sending <varname>FinalKillSignal=</varname>. + This setting may be used to analyze services that fail to start-up or shut-down intermittently. + By using <option>kill</option> the service is immediately terminated by sending + <varname>FinalKillSignal=</varname> without any further timeout. This setting can be used to expedite the + shutdown of failing services. + </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 + active for longer than the specified time it is terminated and put into a failure state. Note that this setting + does not have any effect on <varname>Type=oneshot</varname> services, as they terminate immediately after + activation completed. Pass <literal>infinity</literal> (the default) to configure no runtime + limit.</para> + + <para>If a service of <varname>Type=notify</varname> sends <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause + the runtime to be extended beyond <varname>RuntimeMaxSec=</varname>. The first receipt of this message + must occur before <varname>RuntimeMaxSec=</varname> is exceeded, and once the runtime has extended beyond + <varname>RuntimeMaxSec=</varname>, the service manager will allow the service to continue to run, provided + the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified until the service + shutdown is achieved by <literal>STOPPING=1</literal> (or termination). (see + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WatchdogSec=</varname></term> + <listitem><para>Configures the watchdog timeout for a service. + The watchdog is activated when the start-up is completed. The + service must call + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> + regularly with <literal>WATCHDOG=1</literal> (i.e. the + "keep-alive ping"). If the time between two such calls is + larger than the configured time, then the service is placed in + a failed state and it will be terminated with + <constant>SIGABRT</constant> (or the signal specified by + <varname>WatchdogSignal=</varname>). By setting + <varname>Restart=</varname> to <option>on-failure</option>, + <option>on-watchdog</option>, <option>on-abnormal</option> or + <option>always</option>, the service will be automatically + restarted. The time configured here will be passed to the + executed service process in the + <varname>WATCHDOG_USEC=</varname> environment variable. This + allows daemons to automatically enable the keep-alive pinging + logic if watchdog support is enabled for the service. If this + option is used, <varname>NotifyAccess=</varname> (see below) + should be set to open access to the notification socket + provided by systemd. If <varname>NotifyAccess=</varname> is + not set, it will be implicitly set to <option>main</option>. + Defaults to 0, which disables this feature. The service can + check whether the service manager expects watchdog keep-alive + notifications. See + <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for details. + <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + may be used to enable automatic watchdog notification support. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Restart=</varname></term> + <listitem><para>Configures whether the service shall be + restarted when the service process exits, is killed, or a + timeout is reached. The service process may be the main + service process, but it may also be one of the processes + specified with <varname>ExecStartPre=</varname>, + <varname>ExecStartPost=</varname>, + <varname>ExecStop=</varname>, + <varname>ExecStopPost=</varname>, or + <varname>ExecReload=</varname>. When the death of the process + is a result of systemd operation (e.g. service stop or + restart), the service will not be restarted. Timeouts include + missing the watchdog "keep-alive ping" deadline and a service + start, reload, and stop operation timeouts.</para> + + <para>Takes one of + <option>no</option>, + <option>on-success</option>, + <option>on-failure</option>, + <option>on-abnormal</option>, + <option>on-watchdog</option>, + <option>on-abort</option>, or + <option>always</option>. + If set to <option>no</option> (the default), the service will + not be restarted. If set to <option>on-success</option>, it + will be restarted only when the service process exits cleanly. + In this context, a clean exit means an exit code of 0, or one + of the signals + <constant>SIGHUP</constant>, + <constant>SIGINT</constant>, + <constant>SIGTERM</constant> or + <constant>SIGPIPE</constant>, and + additionally, exit statuses and signals specified in + <varname>SuccessExitStatus=</varname>. If set to + <option>on-failure</option>, the service will be restarted + when the process exits with a non-zero exit code, is + terminated by a signal (including on core dump, but excluding + the aforementioned four signals), when an operation (such as + service reload) times out, and when the configured watchdog + timeout is triggered. If set to <option>on-abnormal</option>, + the service will be restarted when the process is terminated + by a signal (including on core dump, excluding the + aforementioned four signals), when an operation times out, or + when the watchdog timeout is triggered. If set to + <option>on-abort</option>, the service will be restarted only + if the service process exits due to an uncaught signal not + specified as a clean exit status. If set to + <option>on-watchdog</option>, the service will be restarted + only if the watchdog timeout for the service expires. If set + to <option>always</option>, the service will be restarted + regardless of whether it exited cleanly or not, got terminated + abnormally by a signal, or hit a timeout.</para> + + <table> + <title>Exit causes and the effect of the <varname>Restart=</varname> settings on them</title> + + <tgroup cols='2'> + <colspec colname='path' /> + <colspec colname='expl' /> + <thead> + <row> + <entry>Restart settings/Exit causes</entry> + <entry><option>no</option></entry> + <entry><option>always</option></entry> + <entry><option>on-success</option></entry> + <entry><option>on-failure</option></entry> + <entry><option>on-abnormal</option></entry> + <entry><option>on-abort</option></entry> + <entry><option>on-watchdog</option></entry> + </row> + </thead> + <tbody> + <row> + <entry>Clean exit code or signal</entry> + <entry/> + <entry>X</entry> + <entry>X</entry> + <entry/> + <entry/> + <entry/> + <entry/> + </row> + <row> + <entry>Unclean exit code</entry> + <entry/> + <entry>X</entry> + <entry/> + <entry>X</entry> + <entry/> + <entry/> + <entry/> + </row> + <row> + <entry>Unclean signal</entry> + <entry/> + <entry>X</entry> + <entry/> + <entry>X</entry> + <entry>X</entry> + <entry>X</entry> + <entry/> + </row> + <row> + <entry>Timeout</entry> + <entry/> + <entry>X</entry> + <entry/> + <entry>X</entry> + <entry>X</entry> + <entry/> + <entry/> + </row> + <row> + <entry>Watchdog</entry> + <entry/> + <entry>X</entry> + <entry/> + <entry>X</entry> + <entry>X</entry> + <entry/> + <entry>X</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>As exceptions to the setting above, the service will not + be restarted if the exit code or signal is specified in + <varname>RestartPreventExitStatus=</varname> (see below) or + the service is stopped with <command>systemctl stop</command> + or an equivalent operation. Also, the services will always be + restarted if the exit code or signal is specified in + <varname>RestartForceExitStatus=</varname> (see below).</para> + + <para>Note that service restart is subject to unit start rate + limiting configured with <varname>StartLimitIntervalSec=</varname> + and <varname>StartLimitBurst=</varname>, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. A restarted service enters the failed state only + after the start limits are reached.</para> + + <para>Setting this to <option>on-failure</option> is the + recommended choice for long-running services, in order to + increase reliability by attempting automatic recovery from + errors. For services that shall be able to terminate on their + own choice (and avoid immediate restarting), + <option>on-abnormal</option> is an alternative choice.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SuccessExitStatus=</varname></term> + + <listitem><para>Takes a list of exit status definitions that, when returned by the main service + process, will be considered successful termination, in addition to the normal successful exit status + 0 and the signals <constant>SIGHUP</constant>, <constant>SIGINT</constant>, + <constant>SIGTERM</constant>, and <constant>SIGPIPE</constant>. Exit status definitions can be + numeric termination statuses, termination status 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 status 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>Note that this setting does not change the mapping between numeric exit statuses and their + names, i.e. regardless how this setting is used 0 will still be mapped to <literal>SUCCESS</literal> + (and thus typically shown as <literal>0/SUCCESS</literal> in tool outputs) and 1 to + <literal>FAILURE</literal> (and thus typically shown as <literal>1/FAILURE</literal>), and so on. It + only controls what happens as effect of these exit statuses, and how it propagates to the state of + the service as a whole.</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> + + <example> + <title>A service with the <varname>SuccessExitStatus=</varname> setting</title> + + <programlisting>SuccessExitStatus=TEMPFAIL 250 SIGKILL</programlisting> + + <para>Exit status 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-status</command> may be used to list exit statuses and + translate between numerical status values and names.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestartPreventExitStatus=</varname></term> + + <listitem><para>Takes a list of exit status definitions that, when returned by the main service + process, will prevent automatic service restarts, regardless of the restart setting configured with + <varname>Restart=</varname>. Exit status definitions can either be numeric exit codes or termination + signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit + status is excluded from the configured restart logic. For example: + + <programlisting>RestartPreventExitStatus=1 6 SIGABRT</programlisting> + + ensures that exit codes 1 and 6 and the termination signal <constant>SIGABRT</constant> will not + result in automatic service restarting. This option may appear more than once, in which case the list + of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is + reset and all prior assignments of this option will have no effect.</para> + + <para>Note that this setting has no effect on processes configured via + <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecStop=</varname>, + <varname>ExecStopPost=</varname> or <varname>ExecReload=</varname>, but only on the main service + process, i.e. either the one invoked by <varname>ExecStart=</varname> or (depending on + <varname>Type=</varname>, <varname>PIDFile=</varname>, …) the otherwise configured main + process.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RestartForceExitStatus=</varname></term> + <listitem><para>Takes a list of exit status definitions that, + when returned by the main service process, will force automatic + service restarts, regardless of the restart setting configured + with <varname>Restart=</varname>. The argument format is + similar to + <varname>RestartPreventExitStatus=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootDirectoryStartOnly=</varname></term> + <listitem><para>Takes a boolean argument. If true, the root + directory, as configured with the + <varname>RootDirectory=</varname> option (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information), is only applied to the process started + with <varname>ExecStart=</varname>, and not to the various + other <varname>ExecStartPre=</varname>, + <varname>ExecStartPost=</varname>, + <varname>ExecReload=</varname>, <varname>ExecStop=</varname>, + and <varname>ExecStopPost=</varname> commands. If false, the + setting is applied to all configured commands the same way. + Defaults to false.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NonBlocking=</varname></term> + <listitem><para>Set the <constant>O_NONBLOCK</constant> flag for all file descriptors passed via socket-based + activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr), excluding those passed + in via the file descriptor storage logic (see <varname>FileDescriptorStoreMax=</varname> for details), will + have the <constant>O_NONBLOCK</constant> flag set and hence are in non-blocking mode. This option is only + useful in conjunction with a socket unit, as described in + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> and has no + effect on file descriptors which were previously saved in the file-descriptor store for example. Defaults to + false.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NotifyAccess=</varname></term> + <listitem><para>Controls access to the service status notification socket, as accessible via the + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> call. Takes one + of <option>none</option> (the default), <option>main</option>, <option>exec</option> or + <option>all</option>. If <option>none</option>, no daemon status updates are accepted from the service + processes, all status update messages are ignored. If <option>main</option>, only service updates sent from the + main process of the service are accepted. If <option>exec</option>, only service updates sent from any of the + main or control processes originating from one of the <varname>Exec*=</varname> commands are accepted. If + <option>all</option>, all services updates from all members of the service's control group are accepted. This + option should be set to open access to the notification socket when using <varname>Type=notify</varname> or + <varname>WatchdogSec=</varname> (see above). If those options are used but <varname>NotifyAccess=</varname> is + not configured, it will be implicitly set to <option>main</option>.</para> + + <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if + either the sending process is still around at the time PID 1 processes the message, or if the sending process + is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally + forked off the process, i.e. on all processes that match <option>main</option> or + <option>exec</option>. Conversely, if an auxiliary process of the unit sends an + <function>sd_notify()</function> message and immediately exits, the service manager might not be able to + properly attribute the message to the unit, and thus will ignore it, even if + <varname>NotifyAccess=</varname><option>all</option> is set for it.</para> + + <para>Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications + to units correctly, <function>sd_notify_barrier()</function> may be used. This call acts as a synchronization point + and ensures all notifications sent before this call have been picked up by the service manager when it returns + successfully. Use of <function>sd_notify_barrier()</function> is needed for clients which are not invoked by the + service manager, otherwise this synchronization mechanism is unnecessary for attribution of notifications to the + unit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Sockets=</varname></term> + <listitem><para>Specifies the name of the socket units this + service shall inherit socket file descriptors from when the + service is started. Normally, it should not be necessary to use + this setting, as all socket file descriptors whose unit shares + the same name as the service (subject to the different unit + name suffix of course) are passed to the spawned + process.</para> + + <para>Note that the same socket file descriptors may be passed + to multiple processes simultaneously. Also note that a + different service may be activated on incoming socket traffic + than the one which is ultimately configured to inherit the + socket file descriptors. Or, in other words: the + <varname>Service=</varname> setting of + <filename>.socket</filename> units does not have to match the + 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. 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> + <term><varname>FileDescriptorStoreMax=</varname></term> + <listitem><para>Configure how many file descriptors may be stored in the service manager for the + service using + <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s + <literal>FDSTORE=1</literal> messages. This is useful for implementing services that can restart + after an explicit request or a crash without losing state. Any open sockets and other file + descriptors which should not be closed during the restart may be stored this way. Application state + can either be serialized to a file in <filename>/run/</filename>, or better, stored in a + <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> + memory file descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service + manager. All file descriptors passed to the service manager from a specific service are passed back + to the service's main process on the next service restart (see + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details about the precise protocol used and the order in which the file descriptors are passed). Any + file descriptors passed to the service manager are automatically closed when + <constant>POLLHUP</constant> or <constant>POLLERR</constant> is seen on them, or when the service is + fully stopped and no job is queued or being executed for it. If this option is used, + <varname>NotifyAccess=</varname> (see above) should be set to open access to the notification socket + provided by systemd. If <varname>NotifyAccess=</varname> is not set, it will be implicitly set to + <option>main</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>USBFunctionDescriptors=</varname></term> + <listitem><para>Configure the location of a file containing + <ulink + url="https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB + FunctionFS</ulink> descriptors, for implementation of USB + gadget functions. This is used only in conjunction with a + socket unit with <varname>ListenUSBFunction=</varname> + configured. The contents of this file are written to the + <filename>ep0</filename> file after it is + opened.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>USBFunctionStrings=</varname></term> + <listitem><para>Configure the location of a file containing + USB FunctionFS strings. Behavior is similar to + <varname>USBFunctionDescriptors=</varname> + 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>systemd-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 + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more settings.</para> + + </refsect1> + + <refsect1> + <title>Command lines</title> + + <para>This section describes command line parsing and + variable and specifier substitutions for + <varname>ExecStart=</varname>, + <varname>ExecStartPre=</varname>, + <varname>ExecStartPost=</varname>, + <varname>ExecReload=</varname>, + <varname>ExecStop=</varname>, and + <varname>ExecStopPost=</varname> options.</para> + + <para>Multiple command lines may be concatenated in a single + directive by separating them with semicolons (these semicolons + must be passed as separate words). Lone semicolons may be escaped + as <literal>\;</literal>.</para> + + <para>Each command line is split on whitespace, with the first item being the command to + execute, and the subsequent items being the arguments. Double quotes ("…") and single quotes + ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning or + after whitespace that is not quoted, and the closing quote must be followed by whitespace or the + end of line), in which case everything until the next matching quote becomes part of the same + argument. Quotes themselves are removed. C-style escapes are also supported. The table below + contains the list of known escape patterns. Only escape patterns which match the syntax in the + table are allowed; other patterns may be added in the future and unknown patterns will result in + a warning. In particular, any backslashes should be doubled. Finally, a trailing backslash + (<literal>\</literal>) may be used to merge lines.</para> + + <para>This syntax is inspired by shell syntax, but only the meta-characters and expansions + described in the following paragraphs are understood, and the expansion of variables is + different. Specifically, redirection using + <literal><</literal>, + <literal><<</literal>, + <literal>></literal>, and + <literal>>></literal>, pipes using + <literal>|</literal>, running programs in the background using + <literal>&</literal>, and <emphasis>other elements of shell + syntax are not supported</emphasis>.</para> + + <para>The command to execute may contain spaces, but control characters are not allowed.</para> + + <para>The command line accepts <literal>%</literal> specifiers as described in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + + <para>Basic environment variable substitution is supported. Use + <literal>${FOO}</literal> as part of a word, or as a word of its + own, on the command line, in which case it will be erased and replaced + by the exact value of the environment variable (if any) including all + whitespace it contains, always resulting in exactly a single argument. + Use <literal>$FOO</literal> as a separate word on the command line, in + which case it will be replaced by the value of the environment + variable split at whitespace, resulting in zero or more arguments. + For this type of expansion, quotes are respected when splitting + into words, and afterwards removed.</para> + + <para>If the command is not a full (absolute) path, it will be resolved to a full path using a + fixed search path determined at compilation time. Searched directories include + <filename>/usr/local/bin/</filename>, <filename>/usr/bin/</filename>, <filename>/bin/</filename> + on systems using split <filename>/usr/bin/</filename> and <filename>/bin/</filename> + directories, and their <filename>sbin/</filename> counterparts on systems using split + <filename>bin/</filename> and <filename>sbin/</filename>. It is thus safe to use just the + executable name in case of executables located in any of the "standard" directories, and an + absolute path must be used in other cases. Using an absolute path is recommended to avoid + ambiguity. Hint: this search path may be queried using + <command>systemd-path search-binaries-default</command>.</para> + + <para>Example:</para> + + <programlisting>Environment="ONE=one" 'TWO=two two' +ExecStart=echo $ONE $TWO ${TWO}</programlisting> + + <para>This will execute <command>/bin/echo</command> with four + arguments: <literal>one</literal>, <literal>two</literal>, + <literal>two</literal>, and <literal>two two</literal>.</para> + + <para>Example:</para> + <programlisting>Environment=ONE='one' "TWO='two two' too" THREE= +ExecStart=/bin/echo ${ONE} ${TWO} ${THREE} +ExecStart=/bin/echo $ONE $TWO $THREE</programlisting> + <para>This results in <filename>/bin/echo</filename> being + called twice, the first time with arguments + <literal>'one'</literal>, + <literal>'two two' too</literal>, <literal></literal>, + and the second time with arguments + <literal>one</literal>, <literal>two two</literal>, + <literal>too</literal>. + </para> + + <para>To pass a literal dollar sign, use <literal>$$</literal>. + Variables whose value is not known at expansion time are treated + as empty strings. Note that the first argument (i.e. the program + to execute) may not be a variable.</para> + + <para>Variables to be used in this fashion may be defined through + <varname>Environment=</varname> and + <varname>EnvironmentFile=</varname>. In addition, variables listed + in the section "Environment variables in spawned processes" in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which are considered "static configuration", may be used (this + includes e.g. <varname>$USER</varname>, but not + <varname>$TERM</varname>).</para> + + <para>Note that shell command lines are not directly supported. If + shell command lines are to be used, they need to be passed + explicitly to a shell implementation of some kind. Example:</para> + <programlisting>ExecStart=sh -c 'dmesg | tac'</programlisting> + + <para>Example:</para> + + <programlisting>ExecStart=echo one ; echo "two two"</programlisting> + + <para>This will execute <command>echo</command> two times, + each time with one argument: <literal>one</literal> and + <literal>two two</literal>, respectively. Because two commands are + specified, <varname>Type=oneshot</varname> must be used.</para> + + <para>Example:</para> + + <programlisting>ExecStart=echo / >/dev/null & \; \ +ls</programlisting> + + <para>This will execute <command>echo</command> + with five arguments: <literal>/</literal>, + <literal>>/dev/null</literal>, + <literal>&</literal>, <literal>;</literal>, and + <literal>ls</literal>.</para> + + <table> + <title>C escapes supported in command lines and environment variables</title> + <tgroup cols='2'> + <colspec colname='escape' /> + <colspec colname='meaning' /> + <thead> + <row> + <entry>Literal</entry> + <entry>Actual value</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>\a</literal></entry> + <entry>bell</entry> + </row> + <row> + <entry><literal>\b</literal></entry> + <entry>backspace</entry> + </row> + <row> + <entry><literal>\f</literal></entry> + <entry>form feed</entry> + </row> + <row> + <entry><literal>\n</literal></entry> + <entry>newline</entry> + </row> + <row> + <entry><literal>\r</literal></entry> + <entry>carriage return</entry> + </row> + <row> + <entry><literal>\t</literal></entry> + <entry>tab</entry> + </row> + <row> + <entry><literal>\v</literal></entry> + <entry>vertical tab</entry> + </row> + <row> + <entry><literal>\\</literal></entry> + <entry>backslash</entry> + </row> + <row> + <entry><literal>\"</literal></entry> + <entry>double quotation mark</entry> + </row> + <row> + <entry><literal>\'</literal></entry> + <entry>single quotation mark</entry> + </row> + <row> + <entry><literal>\s</literal></entry> + <entry>space</entry> + </row> + <row> + <entry><literal>\x<replaceable>xx</replaceable></literal></entry> + <entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry> + </row> + <row> + <entry><literal>\<replaceable>nnn</replaceable></literal></entry> + <entry>character number <replaceable>nnn</replaceable> in octal encoding</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Simple service</title> + + <para>The following unit file creates a service that will + execute <filename index="false">/usr/sbin/foo-daemon</filename>. Since no + <varname>Type=</varname> is specified, the default + <varname>Type=</varname><option>simple</option> will be assumed. + systemd will assume the unit to be started immediately after the + program has begun executing.</para> + + <programlisting>[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Note that systemd assumes here that the process started by + systemd will continue running until the service terminates. If + the program daemonizes itself (i.e. forks), please use + <varname>Type=</varname><option>forking</option> instead.</para> + + <para>Since no <varname>ExecStop=</varname> was specified, + systemd will send SIGTERM to all processes started from this + service, and after a timeout also SIGKILL. This behavior can be + modified, see + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>Note that this unit type does not include any type of + notification when a service has completed initialization. For + this, you should use other unit types, such as + <varname>Type=</varname><option>notify</option> if the service + understands systemd's notification protocol, + <varname>Type=</varname><option>forking</option> if the service + can background itself or + <varname>Type=</varname><option>dbus</option> if the unit + acquires a DBus name once initialization is complete. See + below.</para> + </example> + + <example> + <title>Oneshot service</title> + + <para>Sometimes, units should just execute an action without + keeping active processes, such as a filesystem check or a + cleanup action on boot. For this, + <varname>Type=</varname><option>oneshot</option> exists. Units + of this type will wait until the process specified terminates + and then fall back to being inactive. The following unit will + perform a cleanup action:</para> + + <programlisting>[Unit] +Description=Cleanup old Foo data + +[Service] +Type=oneshot +ExecStart=/usr/sbin/foo-cleanup + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Note that systemd will consider the unit to be in the + state "starting" until the program has terminated, so ordered + dependencies will wait for the program to finish before starting + themselves. The unit will revert to the "inactive" state after + the execution is done, never reaching the "active" state. That + means another request to start the unit will perform the action + again.</para> + + <para><varname>Type=</varname><option>oneshot</option> are the + only service units that may have more than one + <varname>ExecStart=</varname> specified. For units with multiple + commands (<varname index="false">Type=oneshot</varname>), all commands will be run again.</para> + <para> For <varname index="false">Type=oneshot</varname>, <varname>Restart=</varname><option>always</option> + and <varname>Restart=</varname><option>on-success</option> are <emphasis>not</emphasis> allowed.</para> + </example> + + <example> + <title>Stoppable oneshot service</title> + + <para>Similarly to the oneshot services, there are sometimes + units that need to execute a program to set up something and + then execute another to shut it down, but no process remains + active while they are considered "started". Network + configuration can sometimes fall into this category. Another use + case is if a oneshot service shall not be executed each time + when they are pulled in as a dependency, but only the first + time.</para> + + <para>For this, systemd knows the setting + <varname>RemainAfterExit=</varname><option>yes</option>, which + causes systemd to consider the unit to be active if the start + action exited successfully. This directive can be used with all + types, but is most useful with + <varname>Type=</varname><option>oneshot</option> and + <varname>Type=</varname><option>simple</option>. With + <varname>Type=</varname><option>oneshot</option>, systemd waits + until the start action has completed before it considers the + unit to be active, so dependencies start only after the start + action has succeeded. With + <varname>Type=</varname><option>simple</option>, dependencies + will start immediately after the start action has been + dispatched. The following unit provides an example for a simple + static firewall.</para> + + <programlisting>[Unit] +Description=Simple firewall + +[Service] +Type=oneshot +RemainAfterExit=yes +ExecStart=/usr/local/sbin/simple-firewall-start +ExecStop=/usr/local/sbin/simple-firewall-stop + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Since the unit is considered to be running after the start + action has exited, invoking <command>systemctl start</command> + on that unit again will cause no action to be taken.</para> + </example> + + <example> + <title>Traditional forking services</title> + + <para>Many traditional daemons/services background (i.e. fork, + daemonize) themselves when starting. Set + <varname>Type=</varname><option>forking</option> in the + service's unit file to support this mode of operation. systemd + will consider the service to be in the process of initialization + while the original program is still running. Once it exits + successfully and at least a process remains (and + <varname>RemainAfterExit=</varname><option>no</option>), the + service is considered started.</para> + + <para>Often, a traditional daemon only consists of one process. + Therefore, if only one process is left after the original + process terminates, systemd will consider that process the main + process of the service. In that case, the + <varname>$MAINPID</varname> variable will be available in + <varname>ExecReload=</varname>, <varname>ExecStop=</varname>, + etc.</para> + + <para>In case more than one process remains, systemd will be + unable to determine the main process, so it will not assume + there is one. In that case, <varname>$MAINPID</varname> will not + expand to anything. However, if the process decides to write a + traditional PID file, systemd will be able to read the main PID + from there. Please set <varname>PIDFile=</varname> accordingly. + Note that the daemon should write that file before finishing + with its initialization. Otherwise, systemd might try to read the + file before it exists.</para> + + <para>The following example shows a simple daemon that forks and + just starts one process in the background:</para> + + <programlisting>[Unit] +Description=Some simple daemon + +[Service] +Type=forking +ExecStart=/usr/sbin/my-simple-daemon -d + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Please see + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details on how you can influence the way systemd terminates + the service.</para> + </example> + + <example> + <title>DBus services</title> + + <para>For services that acquire a name on the DBus system bus, + use <varname>Type=</varname><option>dbus</option> and set + <varname>BusName=</varname> accordingly. The service should not + fork (daemonize). systemd will consider the service to be + initialized once the name has been acquired on the system bus. + The following example shows a typical DBus service:</para> + + <programlisting>[Unit] +Description=Simple DBus service + +[Service] +Type=dbus +BusName=org.example.simple-dbus-service +ExecStart=/usr/sbin/simple-dbus-service + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>For <emphasis>bus-activatable</emphasis> services, do not + include a [Install] section in the systemd + service file, but use the <varname>SystemdService=</varname> + option in the corresponding DBus service file, for example + (<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para> + + <programlisting>[D-BUS Service] +Name=org.example.simple-dbus-service +Exec=/usr/sbin/simple-dbus-service +User=root +SystemdService=simple-dbus-service.service</programlisting> + + <para>Please see + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details on how you can influence the way systemd terminates + the service.</para> + </example> + + <example> + <title>Services that notify systemd about their initialization</title> + + <para><varname>Type=</varname><option>simple</option> services + are really easy to write, but have the major disadvantage of + systemd not being able to tell when initialization of the given + service is complete. For this reason, systemd supports a simple + notification protocol that allows daemons to make systemd aware + that they are done initializing. Use + <varname>Type=</varname><option>notify</option> for this. A + typical service file for such a daemon would look like + this:</para> + + <programlisting>[Unit] +Description=Simple notifying service + +[Service] +Type=notify +ExecStart=/usr/sbin/simple-notifying-service + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Note that the daemon has to support systemd's notification + protocol, else systemd will think the service has not started yet + and kill it after a timeout. For an example of how to update + daemons to support this protocol transparently, take a look at + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + systemd will consider the unit to be in the 'starting' state + until a readiness notification has arrived.</para> + + <para>Please see + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details on how you can influence the way systemd terminates + the service.</para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml new file mode 100644 index 0000000..0d3616f --- /dev/null +++ b/man/systemd.slice.xml @@ -0,0 +1,114 @@ +<?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-or-later --> + +<refentry id="systemd.slice"> + <refentryinfo> + <title>systemd.slice</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.slice</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.slice</refname> + <refpurpose>Slice unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>slice</replaceable>.slice</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in <literal>.slice</literal> encodes information about a slice + unit. A slice unit is a concept for hierarchically managing resources of a group of processes. This management is + performed by creating a node in the Linux Control Group (cgroup) tree. Units that manage processes (primarily scope + and service units) may be assigned to a specific slice. For each slice, certain resource limits may be set that + apply to all processes of all units contained in that slice. Slices are organized hierarchically in a tree. The + name of the slice encodes the location in the tree. The name consists of a dash-separated series of names, which + describes the path to the slice from the root slice. The root slice is named <filename>-.slice</filename>. Example: + <filename>foo-bar.slice</filename> is a slice that is located within <filename>foo.slice</filename>, which in turn + is located in the root slice <filename>-.slice</filename>. + </para> + + <para>Note that slice units cannot be templated, nor is possible to add multiple names to a slice unit by creating + additional symlinks to its unit file.</para> + + <para>By default, service and scope units are placed in + <filename>system.slice</filename>, virtual machines and containers + registered with + <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry> + are found in <filename>machine.slice</filename>, and user sessions + handled by + <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry> + in <filename>user.slice</filename>. See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information.</para> + + <para>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 + slice specific configuration options are configured in + the [Slice] section. Currently, only generic resource control settings + as described in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> are allowed. + </para> + + <para>See the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/">New + Control Group Interfaces</ulink> for an introduction on how to make + use of slice units from programs.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>Slice units automatically gain dependencies of type + <varname>After=</varname> and <varname>Requires=</varname> on + their immediate parent slice unit.</para></listitem> + </itemizedlist> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Slice units will automatically have dependencies of type <varname>Conflicts=</varname> and + <varname>Before=</varname> on + <filename>shutdown.target</filename>. These ensure that slice units are removed prior to system shutdown. + Only slice units involved with late system shutdown should disable + <varname>DefaultDependencies=</varname> option.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml new file mode 100644 index 0000000..520a906 --- /dev/null +++ b/man/systemd.socket.xml @@ -0,0 +1,872 @@ +<?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-or-later --> + +<refentry id="systemd.socket"> + <refentryinfo> + <title>systemd.socket</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.socket</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.socket</refname> + <refpurpose>Socket unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>socket</replaceable>.socket</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.socket</literal> encodes information about an IPC or + network socket or a file system FIFO controlled and supervised by + systemd, for socket-based activation.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The socket specific configuration options are + configured in the [Socket] section.</para> + + <para>Additional options are listed in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the execution environment the + <option>ExecStartPre=</option>, <option>ExecStartPost=</option>, + <option>ExecStopPre=</option> and <option>ExecStopPost=</option> + commands are executed in, and in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the way the processes are terminated, and in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which configure resource control settings for the processes of the + socket.</para> + + <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 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 + <option>Accept=</option> option described below, this .service + unit must either be named like the .socket unit, but with the + suffix replaced, unless overridden with <option>Service=</option>; + or it must be a template unit named the same way. Example: a + 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 + <filename>foo@.service</filename> must exist from which services + are instantiated for each incoming connection.</para> + + <para>No implicit <varname>WantedBy=</varname> or + <varname>RequiredBy=</varname> dependency from the socket to the + service is added. This means that the service may be started + without the socket, in which case it must be able to open sockets + by itself. To prevent this, an explicit + <varname>Requires=</varname> dependency may be added.</para> + + <para>Socket units may be used to implement on-demand starting of + services, as well as parallelized starting of services. See the + blog stories linked at the end for an introduction.</para> + + <para>Note that the daemon software configured for socket activation with socket units needs to be able + to accept sockets from systemd, either via systemd's native socket passing interface (see + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> for + details about the precise protocol used and the order in which the file descriptors are passed) or via + traditional <citerefentry + project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>-style + socket passing (i.e. sockets passed in via standard input and output, using + <varname>StandardInput=socket</varname> in the service file).</para> + + <para>All network sockets allocated through <filename>.socket</filename> units are allocated in the host's network + namespace (see <citerefentry + project='man-pages'><refentrytitle>network_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>). This + does not mean however that the service activated by a configured socket unit has to be part of the host's network + namespace as well. It is supported and even good practice to run services in their own network namespace (for + example through <varname>PrivateNetwork=</varname>, see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>), receiving only + the sockets configured through socket-activation from the host's namespace. In such a set-up communication within + the host's network namespace is only permitted through the activation sockets passed in while all sockets allocated + from the service code itself will be associated with the service's own namespace, and thus possibly subject to a a + much more restrictive configuration.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>Socket units automatically gain a <varname>Before=</varname> + dependency on the service units they activate.</para></listitem> + + <listitem><para>Socket units referring to file system paths (such as <constant>AF_UNIX</constant> + sockets or FIFOs) implicitly gain <varname>Requires=</varname> and <varname>After=</varname> + dependencies on all mount units necessary to access those paths.</para></listitem> + + <listitem><para>Socket units using the <varname>BindToDevice=</varname> + setting automatically gain a <varname>BindsTo=</varname> and + <varname>After=</varname> dependency on the device unit + encapsulating the specified network interface.</para></listitem> + </itemizedlist> + + <para>Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless + <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Socket units automatically gain a + <varname>Before=</varname> dependency on + <filename>sockets.target</filename>.</para></listitem> + + <listitem><para>Socket units automatically gain a pair of + <varname>After=</varname> and <varname>Requires=</varname> + dependency on <filename>sysinit.target</filename>, and a pair of + <varname>Before=</varname> and <varname>Conflicts=</varname> + dependencies on <filename>shutdown.target</filename>. These + dependencies ensure that the socket unit is started before normal + services at boot, and is stopped on shutdown. Only sockets + involved with early boot or late system shutdown should disable + <varname>DefaultDependencies=</varname> option.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Socket files must include a [Socket] section, which carries + information about the socket or FIFO it supervises. A number of + options that may be used in this section are shared with other + unit types. These options are documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The options specific to the [Socket] section of socket units are + the following:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>ListenStream=</varname></term> + <term><varname>ListenDatagram=</varname></term> + <term><varname>ListenSequentialPacket=</varname></term> + <listitem><para>Specifies an address to listen on for a stream + (<constant>SOCK_STREAM</constant>), datagram + (<constant>SOCK_DGRAM</constant>), or sequential packet + (<constant>SOCK_SEQPACKET</constant>) socket, respectively. + The address can be written in various formats:</para> + + <para>If the address starts with a slash + (<literal>/</literal>), it is read as file system socket in + the <constant>AF_UNIX</constant> socket family.</para> + + <para>If the address starts with an at symbol + (<literal>@</literal>), it is read as abstract namespace + socket in the <constant>AF_UNIX</constant> family. The + <literal>@</literal> is replaced with a + <constant>NUL</constant> character before binding. For + details, see + <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>If the address string is a single number, it is read as + port number to listen on via IPv6. Depending on the value of + <varname>BindIPv6Only=</varname> (see below) this might result + in the service being available via both IPv6 and IPv4 + (default) or just via IPv6. + </para> + + <para>If the address string is a string in the format + <literal><replaceable>v.w.x.y</replaceable>:<replaceable>z</replaceable></literal>, it is interpreted + as IPv4 address <replaceable>v.w.x.y</replaceable> and port <replaceable>z</replaceable>.</para> + + <para>If the address string is a string in the format + <literal>[<replaceable>x</replaceable>]:<replaceable>y</replaceable></literal>, it is interpreted as + IPv6 address <replaceable>x</replaceable> and port <replaceable>y</replaceable>. An optional + interface scope (interface name or number) may be specified after a <literal>%</literal> symbol: + <literal>[<replaceable>x</replaceable>]:<replaceable>y</replaceable>%<replaceable>dev</replaceable></literal>. + Interface scopes are only useful with link-local addresses, because the kernel ignores them in other + cases. Note that if an address is specified as IPv6, it might still make the service available via + IPv4 too, depending on the <varname>BindIPv6Only=</varname> setting (see below).</para> + + <para>If the address string is a string in the format + <literal>vsock:<replaceable>x</replaceable>:<replaceable>y</replaceable></literal>, it is read as CID + <replaceable>x</replaceable> on a port <replaceable>y</replaceable> address in the + <constant>AF_VSOCK</constant> family. The CID is a unique 32-bit integer identifier in + <constant>AF_VSOCK</constant> analogous to an IP address. Specifying the CID is optional, and may be + set to the empty string.</para> + + <para>Note that <constant>SOCK_SEQPACKET</constant> (i.e. + <varname>ListenSequentialPacket=</varname>) is only available + for <constant>AF_UNIX</constant> sockets. + <constant>SOCK_STREAM</constant> (i.e. + <varname>ListenStream=</varname>) when used for IP sockets + refers to TCP sockets, <constant>SOCK_DGRAM</constant> (i.e. + <varname>ListenDatagram=</varname>) to UDP.</para> + + <para>These options may be specified more than once, in which + case incoming traffic on any of the sockets will trigger + service activation, and all listed sockets will be passed to + the service, regardless of whether there is incoming traffic + on them or not. If the empty string is assigned to any of + these options, the list of addresses to listen on is reset, + all prior uses of any of these options will have no + effect.</para> + + <para>It is also possible to have more than one socket unit + for the same service when using <varname>Service=</varname>, + and the service will receive all the sockets configured in all + the socket units. Sockets configured in one unit are passed in + the order of configuration, but no ordering between socket + units is specified.</para> + + <para>If an IP address is used here, it is often desirable to + listen on it before the interface it is configured on is up + and running, and even regardless of whether it will be up and + running at any point. To deal with this, it is recommended to + set the <varname>FreeBind=</varname> option described + below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ListenFIFO=</varname></term> + <listitem><para>Specifies a file system FIFO (see <citerefentry + project='man-pages'><refentrytitle>fifo</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details) to listen on. This expects an absolute file system path as argument. Behavior otherwise is + very similar to the <varname>ListenDatagram=</varname> directive above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ListenSpecial=</varname></term> + <listitem><para>Specifies a special file in the file system to + listen on. This expects an absolute file system path as + argument. Behavior otherwise is very similar to the + <varname>ListenFIFO=</varname> directive above. Use this to + open character device nodes as well as special files in + <filename>/proc/</filename> and + <filename>/sys/</filename>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ListenNetlink=</varname></term> + <listitem><para>Specifies a Netlink family to create a socket + for to listen on. This expects a short string referring to the + <constant>AF_NETLINK</constant> family name (such as + <varname>audit</varname> or <varname>kobject-uevent</varname>) + as argument, optionally suffixed by a whitespace followed by a + multicast group integer. Behavior otherwise is very similar to + the <varname>ListenDatagram=</varname> directive + above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ListenMessageQueue=</varname></term> + <listitem><para>Specifies a POSIX message queue name to listen on (see <citerefentry + project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details). This expects a valid message queue name (i.e. beginning with + <literal>/</literal>). Behavior otherwise is very similar to the <varname>ListenFIFO=</varname> + directive above. On Linux message queue descriptors are actually file descriptors and can be + inherited between processes.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ListenUSBFunction=</varname></term> + <listitem><para>Specifies a <ulink + url="https://www.kernel.org/doc/Documentation/usb/functionfs.txt">USB + FunctionFS</ulink> endpoints location to listen on, for + implementation of USB gadget functions. This expects an + absolute file system path of a FunctionFS mount point as the argument. + Behavior otherwise is very similar to the <varname>ListenFIFO=</varname> + directive above. Use this to open the FunctionFS endpoint + <filename>ep0</filename>. When using this option, the + activated service has to have the + <varname>USBFunctionDescriptors=</varname> and + <varname>USBFunctionStrings=</varname> options set. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SocketProtocol=</varname></term> + <listitem><para>Takes one of <option>udplite</option> + or <option>sctp</option>. The socket will use the UDP-Lite + (<constant>IPPROTO_UDPLITE</constant>) or SCTP + (<constant>IPPROTO_SCTP</constant>) protocol, respectively.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BindIPv6Only=</varname></term> + <listitem><para>Takes one of <option>default</option>, + <option>both</option> or <option>ipv6-only</option>. Controls + the IPV6_V6ONLY socket option (see + <citerefentry project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details). If <option>both</option>, IPv6 sockets bound + will be accessible via both IPv4 and IPv6. If + <option>ipv6-only</option>, they will be accessible via IPv6 + only. If <option>default</option> (which is the default, + surprise!), the system wide default setting is used, as + controlled by + <filename>/proc/sys/net/ipv6/bindv6only</filename>, which in + turn defaults to the equivalent of + <option>both</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Backlog=</varname></term> + <listitem><para>Takes an unsigned integer argument. Specifies + the number of connections to queue that have not been accepted + yet. This setting matters only for stream and sequential + packet sockets. See + <citerefentry><refentrytitle>listen</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. Defaults to SOMAXCONN (128).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>BindToDevice=</varname></term> + <listitem><para>Specifies a network interface name to bind this socket to. If set, traffic will only + be accepted from the specified network interfaces. This controls the + <constant>SO_BINDTODEVICE</constant> socket option (see <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details). If this option is used, an implicit dependency from this socket unit on the network + interface device unit is created + (see <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + Note that setting this parameter might result in additional dependencies to be added to the unit (see + above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SocketUser=</varname></term> + <term><varname>SocketGroup=</varname></term> + + <listitem><para>Takes a UNIX user/group name. When specified, all <constant>AF_UNIX</constant> + sockets and FIFO nodes in the file system are owned by the specified user and group. If unset (the + default), the nodes are owned by the root user/group (if run in system context) or the invoking + user/group (if run in user context). If only a user is specified but no group, then the group is + derived from the user's default group.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SocketMode=</varname></term> + <listitem><para>If listening on a file system socket or FIFO, + this option specifies the file system access mode used when + creating the file node. Takes an access mode in octal + notation. Defaults to 0666.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DirectoryMode=</varname></term> + <listitem><para>If listening on a file system socket or FIFO, + the parent directories are automatically created if needed. + This option specifies the file system access mode used when + creating these directories. Takes an access mode in octal + notation. Defaults to 0755.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Accept=</varname></term> + <listitem><para>Takes a boolean argument. If yes, a service + instance is spawned for each incoming connection and only the + connection socket is passed to it. If no, all listening + sockets themselves are passed to the started service unit, and + only one service unit is spawned for all connections (also see + above). This value is ignored for datagram sockets and FIFOs + where a single service unit unconditionally handles all + incoming traffic. Defaults to <option>no</option>. For + performance reasons, it is recommended to write new daemons + only in a way that is suitable for + <option>Accept=no</option>. A daemon listening on an + <constant>AF_UNIX</constant> socket may, but does not need to, + call + <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> + on the received socket before exiting. However, it must not + unlink the socket from a file system. It should not invoke + <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry> + on sockets it got with <varname>Accept=no</varname>, but it + may do so for sockets it got with + <varname>Accept=yes</varname> set. Setting + <varname>Accept=yes</varname> is mostly useful to allow + daemons designed for usage with + <citerefentry project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + to work unmodified with systemd socket + activation.</para> + + <para>For IPv4 and IPv6 connections, the <varname>REMOTE_ADDR</varname> environment variable will + contain the remote IP address, and <varname>REMOTE_PORT</varname> will contain the remote port. This + is the same as the format used by CGI. For <constant>SOCK_RAW</constant>, the port is the IP + protocol.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Writable=</varname></term> + <listitem><para>Takes a boolean argument. May only be used in + conjunction with <varname>ListenSpecial=</varname>. If true, + the specified special file is opened in read-write mode, if + false, in read-only mode. Defaults to false.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FlushPending=</varname></term> + <listitem><para>Takes a boolean argument. May only be used when + <option>Accept=no</option>. If yes, the socket's buffers are cleared after the + triggered service exited. This causes any pending data to be + flushed and any pending incoming connections to be rejected. If no, the + socket's buffers won't be cleared, permitting the service to handle any + pending connections after restart, which is the usually expected behaviour. + Defaults to <option>no</option>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxConnections=</varname></term> + <listitem><para>The maximum number of connections to + simultaneously run services instances for, when + <option>Accept=yes</option> is set. If more concurrent + connections are coming in, they will be refused until at least + one existing connection is terminated. This setting has no + effect on sockets configured with + <option>Accept=no</option> or datagram sockets. Defaults to + 64.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MaxConnectionsPerSource=</varname></term> + <listitem><para>The maximum number of connections for a service per source IP address. + This is very similar to the <varname>MaxConnections=</varname> directive + above. Disabled by default.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>KeepAlive=</varname></term> + <listitem><para>Takes a boolean argument. If true, the TCP/IP stack will send a keep alive message + after 2h (depending on the configuration of + <filename>/proc/sys/net/ipv4/tcp_keepalive_time</filename>) for all TCP streams accepted on this + socket. This controls the <constant>SO_KEEPALIVE</constant> socket option (see <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> and + the <ulink url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP Keepalive + HOWTO</ulink> for details.) Defaults to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>KeepAliveTimeSec=</varname></term> + <listitem><para>Takes time (in seconds) as argument. The connection needs to remain + idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE + socket option (see + <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> + and the <ulink + url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP + Keepalive HOWTO</ulink> for details.) + Defaults value is 7200 seconds (2 hours).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>KeepAliveIntervalSec=</varname></term> + <listitem><para>Takes time (in seconds) as argument between individual keepalive probes, if the + socket option <constant>SO_KEEPALIVE</constant> has been set on this socket. This controls the + <constant>TCP_KEEPINTVL</constant> socket option (see <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> and + the <ulink url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP Keepalive + HOWTO</ulink> for details.) Defaults value is 75 seconds.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>KeepAliveProbes=</varname></term> + <listitem><para>Takes an integer as argument. It is the number of + unacknowledged probes to send before considering the + connection dead and notifying the application layer. This + controls the TCP_KEEPCNT socket option (see + <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> + and the <ulink + url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP + Keepalive HOWTO</ulink> for details.) Defaults value is + 9.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>NoDelay=</varname></term> + <listitem><para>Takes a boolean argument. TCP Nagle's + algorithm works by combining a number of small outgoing + messages, and sending them all at once. This controls the + TCP_NODELAY socket option (see + <citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>). + Defaults to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Priority=</varname></term> + <listitem><para>Takes an integer argument controlling the priority for all traffic sent from this + socket. This controls the <constant>SO_PRIORITY</constant> socket option (see <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DeferAcceptSec=</varname></term> + + <listitem><para>Takes time (in seconds) as argument. If set, + the listening process will be awakened only when data arrives + on the socket, and not immediately when connection is + established. When this option is set, the + <constant>TCP_DEFER_ACCEPT</constant> socket option will be + used (see + <citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>), + and the kernel will ignore initial ACK packets without any + data. The argument specifies the approximate amount of time + the kernel should wait for incoming data before falling back + to the normal behavior of honoring empty ACK packets. This + option is beneficial for protocols where the client sends the + data first (e.g. HTTP, in contrast to SMTP), because the + server process will not be woken up unnecessarily before it + can take any action. + </para> + + <para>If the client also uses the + <constant>TCP_DEFER_ACCEPT</constant> option, the latency of + the initial connection may be reduced, because the kernel will + send data in the final packet establishing the connection (the + third packet in the "three-way handshake").</para> + + <para>Disabled by default.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReceiveBuffer=</varname></term> + <term><varname>SendBuffer=</varname></term> + <listitem><para>Takes an integer argument controlling the receive or send buffer sizes of this + socket, respectively. This controls the <constant>SO_RCVBUF</constant> and + <constant>SO_SNDBUF</constant> socket options (see <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.). The usual suffixes K, M, G are supported and are understood to the base of + 1024.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>IPTOS=</varname></term> + <listitem><para>Takes an integer argument controlling the IP Type-Of-Service field for packets + generated from this socket. This controls the <constant>IP_TOS</constant> socket option (see + <citerefentry + project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.). Either a numeric string or one of <option>low-delay</option>, <option>throughput</option>, + <option>reliability</option> or <option>low-cost</option> may be specified.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>IPTTL=</varname></term> + <listitem><para>Takes an integer argument controlling the IPv4 Time-To-Live/IPv6 Hop-Count field for + packets generated from this socket. This sets the + <constant>IP_TTL</constant>/<constant>IPV6_UNICAST_HOPS</constant> socket options (see <citerefentry + project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry> and + <citerefentry + project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.)</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Mark=</varname></term> + <listitem><para>Takes an integer value. Controls the firewall mark of packets generated by this + socket. This can be used in the firewall logic to filter packets from this socket. This sets the + <constant>SO_MARK</constant> socket option. See <citerefentry + project='die-net'><refentrytitle>iptables</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ReusePort=</varname></term> + <listitem><para>Takes a boolean value. If true, allows multiple + <citerefentry><refentrytitle>bind</refentrytitle><manvolnum>2</manvolnum></citerefentry>s to this TCP + or UDP port. This controls the <constant>SO_REUSEPORT</constant> socket option. See <citerefentry + project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SmackLabel=</varname></term> + <term><varname>SmackLabelIPIn=</varname></term> + <term><varname>SmackLabelIPOut=</varname></term> + <listitem><para>Takes a string value. Controls the extended + attributes <literal>security.SMACK64</literal>, + <literal>security.SMACK64IPIN</literal> and + <literal>security.SMACK64IPOUT</literal>, respectively, i.e. + the security label of the FIFO, or the security label for the + incoming or outgoing connections of the socket, respectively. + See <ulink + url="https://www.kernel.org/doc/Documentation/security/Smack.txt">Smack.txt</ulink> + for details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SELinuxContextFromNet=</varname></term> + <listitem><para>Takes a boolean argument. When true, systemd + will attempt to figure out the SELinux label used for the + instantiated service from the information handed by the peer + over the network. Note that only the security level is used + from the information provided by the peer. Other parts of the + resulting SELinux context originate from either the target + binary that is effectively triggered by socket unit or from + the value of the <varname>SELinuxContext=</varname> option. + This configuration option only affects sockets with + <varname>Accept=</varname> mode set to + <literal>yes</literal>. Also note that this option is useful + only when MLS/MCS SELinux policy is deployed. Defaults to + <literal>false</literal>. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PipeSize=</varname></term> + <listitem><para>Takes a size in bytes. Controls the pipe + buffer size of FIFOs configured in this socket unit. See + <citerefentry><refentrytitle>fcntl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. The usual suffixes K, M, G are supported and are + understood to the base of 1024.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>MessageQueueMaxMessages=</varname>, + <varname>MessageQueueMessageSize=</varname></term> + <listitem><para>These two settings take integer values and + control the mq_maxmsg field or the mq_msgsize field, + respectively, when creating the message queue. Note that + either none or both of these variables need to be set. See + <citerefentry project='die-net'><refentrytitle>mq_setattr</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FreeBind=</varname></term> + <listitem><para>Takes a boolean value. Controls whether the socket can be bound to non-local IP + addresses. This is useful to configure sockets listening on specific IP addresses before those IP + addresses are successfully configured on a network interface. This sets the + <constant>IP_FREEBIND</constant>/<constant>IPV6_FREEBIND</constant> socket option. For robustness + reasons it is recommended to use this option whenever you bind a socket to a specific IP + address. Defaults to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Transparent=</varname></term> + <listitem><para>Takes a boolean value. Controls the + <constant>IP_TRANSPARENT</constant>/<constant>IPV6_TRANSPARENT</constant> socket option. Defaults to + <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Broadcast=</varname></term> + <listitem><para>Takes a boolean value. This controls the <constant>SO_BROADCAST</constant> socket + option, which allows broadcast datagrams to be sent from this socket. Defaults to + <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PassCredentials=</varname></term> + <listitem><para>Takes a boolean value. This controls the <constant>SO_PASSCRED</constant> socket + option, which allows <constant>AF_UNIX</constant> sockets to receive the credentials of the sending + process in an ancillary message. Defaults to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PassSecurity=</varname></term> + <listitem><para>Takes a boolean value. This controls the <constant>SO_PASSSEC</constant> socket + option, which allows <constant>AF_UNIX</constant> sockets to receive the security context of the + sending process in an ancillary message. Defaults to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PassPacketInfo=</varname></term> + <listitem><para>Takes a boolean value. This controls the <constant>IP_PKTINFO</constant>, + <constant>IPV6_RECVPKTINFO</constant>, <constant>NETLINK_PKTINFO</constant> or + <constant>PACKET_AUXDATA</constant> socket options, which enable reception of additional per-packet + metadata as ancillary message, on <constant>AF_INET</constant>, <constant>AF_INET6</constant>, + <constant>AF_UNIX</constant> and <constant>AF_PACKET</constant> sockets. Defaults to + <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Timestamping=</varname></term> + <listitem><para>Takes one of <literal>off</literal>, <literal>us</literal> (alias: + <literal>usec</literal>, <literal>µs</literal>) or <literal>ns</literal> (alias: + <literal>nsec</literal>). This controls the <constant>SO_TIMESTAMP</constant> or + <constant>SO_TIMESTAMPNS</constant> socket options, and enables whether ingress network traffic shall + carry timestamping metadata. Defaults to <option>off</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TCPCongestion=</varname></term> + <listitem><para>Takes a string value. Controls the TCP congestion algorithm used by this + socket. Should be one of <literal>westwood</literal>, <literal>veno</literal>, + <literal>cubic</literal>, <literal>lp</literal> or any other available algorithm supported by the IP + stack. This setting applies only to stream sockets.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExecStartPre=</varname></term> + <term><varname>ExecStartPost=</varname></term> + <listitem><para>Takes one or more command lines, which are + executed before or after the listening sockets/FIFOs are + created and bound, respectively. The first token of the + command line must be an absolute filename, then followed by + arguments for the process. Multiple command lines may be + specified following the same scheme as used for + <varname>ExecStartPre=</varname> of service unit + files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>ExecStopPre=</varname></term> + <term><varname>ExecStopPost=</varname></term> + <listitem><para>Additional commands that are executed before + or after the listening sockets/FIFOs are closed and removed, + respectively. Multiple command lines may be specified + following the same scheme as used for + <varname>ExecStartPre=</varname> of service unit + files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimeoutSec=</varname></term> + <listitem><para>Configures the time to wait for the commands + specified in <varname>ExecStartPre=</varname>, + <varname>ExecStartPost=</varname>, + <varname>ExecStopPre=</varname> and + <varname>ExecStopPost=</varname> to finish. If a command does + not exit within the configured time, the socket will be + considered failed and be shut down again. All commands still + running will be terminated forcibly via + <constant>SIGTERM</constant>, and after another delay of this + time with <constant>SIGKILL</constant>. (See + <option>KillMode=</option> in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass <literal>0</literal> to disable the + timeout logic. Defaults to + <varname>DefaultTimeoutStartSec=</varname> from the manager + configuration file (see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Service=</varname></term> + <listitem><para>Specifies the service unit name to activate on + incoming traffic. This setting is only allowed for sockets + with <varname>Accept=no</varname>. It defaults to the service + that bears the same name as the socket (with the suffix + replaced). In most cases, it should not be necessary to use + this option. Note that setting this parameter might result in + additional dependencies to be added to the unit (see + above).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemoveOnStop=</varname></term> + <listitem><para>Takes a boolean argument. If enabled, any file nodes created by this socket unit are + removed when it is stopped. This applies to <constant>AF_UNIX</constant> sockets in the file system, + POSIX message queues, FIFOs, as well as any symlinks to them configured with + <varname>Symlinks=</varname>. Normally, it should not be necessary to use this option, and is not + recommended as services might continue to run after the socket unit has been terminated and it should + still be possible to communicate with them via their file system node. Defaults to + off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Symlinks=</varname></term> + <listitem><para>Takes a list of file system paths. The specified paths will be created as symlinks to the + <constant>AF_UNIX</constant> socket path or FIFO path of this socket unit. If this setting is used, only one + <constant>AF_UNIX</constant> socket in the file system or one FIFO may be configured for the socket unit. Use + this option to manage one or more symlinked alias names for a socket, binding their lifecycle together. Note + that if creation of a symlink fails this is not considered fatal for the socket unit, and the socket unit may + still start. If an empty string is assigned, the list of paths is reset. Defaults to an empty + list.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FileDescriptorName=</varname></term> + <listitem><para>Assigns a name to all file descriptors this + socket unit encapsulates. This is useful to help activated + services identify specific file descriptors, if multiple fds + are passed. Services may use the + <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry> + call to acquire the names configured for the received file + descriptors. Names may contain any ASCII character, but must + exclude control characters and <literal>:</literal>, and must + be at most 255 characters in length. If this setting is not + used, the file descriptor name defaults to the name of the + socket unit, including its <filename>.socket</filename> + suffix.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TriggerLimitIntervalSec=</varname></term> + <term><varname>TriggerLimitBurst=</varname></term> + + <listitem><para>Configures a limit on how often this socket unit my be activated within a specific time + interval. The <varname>TriggerLimitIntervalSec=</varname> may be used to configure the length of the time + interval in the usual time units <literal>us</literal>, <literal>ms</literal>, <literal>s</literal>, + <literal>min</literal>, <literal>h</literal>, … and defaults to 2s (See + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on + the various time units understood). The <varname>TriggerLimitBurst=</varname> setting takes a positive integer + value and specifies the number of permitted activations per time interval, and defaults to 200 for + <varname>Accept=yes</varname> sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20 + activations per 2s). Set either to 0 to disable any form of trigger rate limiting. If the limit is hit, the + socket unit is placed into a failure mode, and will not be connectible anymore until restarted. Note that this + limit is enforced before the service activation is enqueued.</para></listitem> + </varlistentry> + + </variablelist> + + <para>Check + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more settings.</para> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry> + </para> + <para> + For more extensive descriptions see the "systemd for Developers" series: + <ulink url="http://0pointer.de/blog/projects/socket-activation.html">Socket Activation</ulink>, + <ulink url="http://0pointer.de/blog/projects/socket-activation2.html">Socket Activation, part II</ulink>, + <ulink url="http://0pointer.de/blog/projects/inetd.html">Converting inetd Services</ulink>, + <ulink url="http://0pointer.de/blog/projects/socket-activated-containers.html">Socket Activated Internet Services and OS Containers</ulink>. + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.special.xml b/man/systemd.special.xml new file mode 100644 index 0000000..a70e9ee --- /dev/null +++ b/man/systemd.special.xml @@ -0,0 +1,1253 @@ +<?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-or-later --> + +<refentry id="systemd.special"> + + <refentryinfo> + <title>systemd.special</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.special</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.special</refname> + <refpurpose>Special systemd units</refpurpose> + </refnamediv> + + <refsynopsisdiv><para> + <!-- sort alphabetically, targets first --><filename>basic.target</filename>, + <filename>bluetooth.target</filename>, + <filename>cryptsetup-pre.target</filename>, + <filename>cryptsetup.target</filename>, + <filename>ctrl-alt-del.target</filename>, + <filename>blockdev@.target</filename>, + <filename>boot-complete.target</filename>, + <filename>default.target</filename>, + <filename>emergency.target</filename>, + <filename>exit.target</filename>, + <filename>final.target</filename>, + <filename>first-boot-complete.target</filename>, + <filename>getty.target</filename>, + <filename>getty-pre.target</filename>, + <filename>graphical.target</filename>, + <filename>halt.target</filename>, + <filename>hibernate.target</filename>, + <filename>hybrid-sleep.target</filename>, + <filename>suspend-then-hibernate.target</filename>, + <filename>initrd.target</filename>, + <filename>initrd-fs.target</filename>, + <filename>initrd-root-device.target</filename>, + <filename>initrd-root-fs.target</filename>, + <filename>kbrequest.target</filename>, + <filename>kexec.target</filename>, + <filename>local-fs-pre.target</filename>, + <filename>local-fs.target</filename>, + <filename>machines.target</filename> + <filename>multi-user.target</filename>, + <filename>network-online.target</filename>, + <filename>network-pre.target</filename>, + <filename>network.target</filename>, + <filename>nss-lookup.target</filename>, + <filename>nss-user-lookup.target</filename>, + <filename>paths.target</filename>, + <filename>poweroff.target</filename>, + <filename>printer.target</filename>, + <filename>reboot.target</filename>, + <filename>remote-cryptsetup.target</filename>, + <filename>remote-fs-pre.target</filename>, + <filename>remote-fs.target</filename>, + <filename>rescue.target</filename>, + <filename>rpcbind.target</filename>, + <filename>runlevel2.target</filename>, + <filename>runlevel3.target</filename>, + <filename>runlevel4.target</filename>, + <filename>runlevel5.target</filename>, + <filename>shutdown.target</filename>, + <filename>sigpwr.target</filename>, + <filename>sleep.target</filename>, + <filename>slices.target</filename>, + <filename>smartcard.target</filename>, + <filename>sockets.target</filename>, + <filename>sound.target</filename>, + <filename>suspend.target</filename>, + <filename>swap.target</filename>, + <filename>sysinit.target</filename>, + <filename>system-update.target</filename>, + <filename>system-update-pre.target</filename>, + <filename>time-set.target</filename>, + <filename>time-sync.target</filename>, + <filename>timers.target</filename>, + <filename>umount.target</filename>, + <filename>usb-gadget.target</filename>, + <!-- slices --><filename>-.slice</filename>, + <filename>system.slice</filename>, + <filename>user.slice</filename>, + <filename>machine.slice</filename>, + <!-- the rest --><filename>-.mount</filename>, + <filename>dbus.service</filename>, + <filename>dbus.socket</filename>, + <filename>display-manager.service</filename>, + <filename>init.scope</filename>, + <filename>syslog.socket</filename>, + <filename>system-update-cleanup.service</filename> + </para></refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A few units are treated specially by systemd. Many of them have + special internal semantics and cannot be renamed, while others simply + have a standard meaning and should be present on all systems.</para> + </refsect1> + + <refsect1> + <title>Units managed by the system service manager</title> + + <refsect2> + <title>Special System Units</title> + + <variablelist> + <varlistentry> + <term><filename>-.mount</filename></term> + <listitem> + <para>The root mount point, i.e. the mount unit for the <filename>/</filename> + path. This unit is unconditionally active, during the entire time the system is up, as + this mount point is where the basic userspace is running from.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>basic.target</filename></term> + <listitem> + <para>A special target unit covering basic boot-up.</para> + + <para>systemd automatically adds dependency of the type + <varname>After=</varname> for this target unit to all + services (except for those with + <varname>DefaultDependencies=no</varname>).</para> + + <para>Usually, this should pull-in all local mount points plus + <filename>/var/</filename>, <filename>/tmp/</filename> and + <filename>/var/tmp/</filename>, swap devices, sockets, timers, + path units and other basic initialization necessary for general + purpose daemons. The mentioned mount points are special cased + to allow them to be remote. + </para> + + <para>This target usually does not pull in any non-target units + directly, but rather does so indirectly via other early boot targets. + It is instead meant as a synchronization point for late boot + services. Refer to + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details on the targets involved. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>boot-complete.target</filename></term> + <listitem> + <para>This target is intended as generic synchronization point for services that shall determine or act on + whether the boot process completed successfully. Order units that are required to succeed for a boot process + to be considered successful before this unit, and add a <varname>Requires=</varname> dependency from the + target unit to them. Order units that shall only run when the boot process is considered successful after the + target unit and pull in the target from it, also with <varname>Requires=</varname>. Note that by default this + target unit is not part of the initial boot transaction, but is supposed to be pulled in only if required by + units that want to run only on successful boots.</para> + + <para>See + <citerefentry><refentrytitle>systemd-boot-check-no-failures.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for a service that implements a generic system health check and orders itself before + <filename>boot-complete.target</filename>.</para> + + <para>See + <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for a service that propagates boot success information to the boot loader, and orders itself after + <filename>boot-complete.target</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>ctrl-alt-del.target</filename></term> + <listitem> + <para>systemd starts this target whenever Control+Alt+Del is + pressed on the console. Usually, this should be aliased + (symlinked) to <filename>reboot.target</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>cryptsetup.target</filename></term> + <listitem> + <para>A target that pulls in setup services for all + encrypted block devices.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>dbus.service</filename></term> + <listitem> + <para>A special unit for the D-Bus bus daemon. As soon as + this service is fully started up systemd will connect to it + and register its service.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>dbus.socket</filename></term> + <listitem> + <para>A special unit for the D-Bus system bus socket. All + units with <varname>Type=dbus</varname> automatically gain a + dependency on this unit.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>default.target</filename></term> + <listitem> + <para>The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to + <filename>multi-user.target</filename> or <filename>graphical.target</filename>. See + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + more discussion.</para> + + <para>The default unit systemd starts at bootup can be overridden with the + <varname>systemd.unit=</varname> kernel command line option, or more conveniently, with the short + names like <varname>single</varname>, <varname>rescue</varname>, <varname>1</varname>, + <varname>3</varname>, <varname>5</varname>, …; see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>display-manager.service</filename></term> + <listitem> + <para>The display manager service. Usually, this should be + aliased (symlinked) to <filename>gdm.service</filename> or a + similar display manager service.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>emergency.target</filename></term> + <listitem> + <para>A special target unit that starts an emergency shell on the main console. This + target does not pull in other services or mounts. It is the most minimal version of + starting the system in order to acquire an interactive shell; the only processes running + are usually just the system manager (PID 1) and the shell process. This unit may be used + by specifying <varname>emergency</varname> on the kernel command line; it is + also used when a file system check on a required file system fails and boot-up cannot + continue. Compare with <filename>rescue.target</filename>, which serves a similar + purpose, but also starts the most basic services and mounts all file systems.</para> + + <para>In many ways booting into <filename>emergency.target</filename> is similar to the + effect of booting with <literal>init=/bin/sh</literal> on the kernel command line, + except that emergency mode provides you with the full system and service manager, and + allows starting individual units in order to continue the boot process in steps.</para> + + <para>Note that depending on how <filename>emergency.target</filename> is reached, the root file + system might be mounted read-only or read-write (no remounting is done specially for this + target). For example, the system may boot with root mounted read-only when <varname>ro</varname> + is used on the kernel command line and remain this way for <filename>emergency.target</filename>, + or the system may transition to <filename>emergency.target</filename> after the system has been + partially booted and disks have already been remounted read-write.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>exit.target</filename></term> + <listitem> + <para>A special service unit for shutting down the system or + user service manager. It is equivalent to + <filename>poweroff.target</filename> on non-container + systems, and also works in containers.</para> + + <para>systemd will start this unit when it receives the + <constant>SIGTERM</constant> or <constant>SIGINT</constant> + signal when running as user service daemon.</para> + + <para>Normally, this (indirectly) pulls in + <filename>shutdown.target</filename>, which in turn should be + conflicted by all units that want to be scheduled for + shutdown when the service manager starts to exit.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>final.target</filename></term> + <listitem> + <para>A special target unit that is used during the shutdown + logic and may be used to pull in late services after all + normal services are already terminated and all mounts + unmounted. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>getty.target</filename></term> + <listitem> + <para>A special target unit that pulls in statically + configured local TTY <filename>getty</filename> instances. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>graphical.target</filename></term> + <listitem> + <para>A special target unit for setting up a graphical login + screen. This pulls in + <filename>multi-user.target</filename>.</para> + + <para>Units that are needed for graphical logins shall add + <varname>Wants=</varname> dependencies for their unit to + this unit (or <filename>multi-user.target</filename>) during + installation. This is best configured via + <varname>WantedBy=graphical.target</varname> in the unit's + [Install] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>hibernate.target</filename></term> + <listitem> + <para>A special target unit for hibernating the system. This + pulls in <filename>sleep.target</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>hybrid-sleep.target</filename></term> + <listitem> + <para>A special target unit for hibernating and suspending + the system at the same time. This pulls in + <filename>sleep.target</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>suspend-then-hibernate.target</filename></term> + <listitem> + <para>A special target unit for suspending the system for a period + of time, waking it and putting it into hibernate. This pulls in + <filename>sleep.target</filename>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>halt.target</filename></term> + <listitem> + <para>A special target unit for shutting down and halting + the system. Note that this target is distinct from + <filename>poweroff.target</filename> in that it generally + really just halts the system rather than powering it + down.</para> + + <para>Applications wanting to halt the system should not start this unit + directly, but should instead execute <command>systemctl halt</command> + (possibly with the <option>--no-block</option> option) or call + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>org.freedesktop.systemd1.Manager.Halt</command> D-Bus method + directly.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>init.scope</filename></term> + <listitem> + <para>This scope unit is where the system and service manager (PID 1) itself resides. It + is active as long as the system is running.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>initrd.target</filename></term> + <listitem> + <para>This is the default target in the initramfs, similar to <filename>default.target</filename> + in the main system. It is used to mount the real root and transition to it. See + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + more discussion.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>initrd-fs.target</filename></term> + <listitem> + <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry> + automatically adds dependencies of type + <varname>Before=</varname> to + <filename>sysroot-usr.mount</filename> and all mount points + found in <filename>/etc/fstab</filename> that have + <option>x-initrd.mount</option> and not have + <option>noauto</option> mount options set.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>initrd-root-device.target</filename></term> + <listitem> + <para>A special initrd target unit that is reached when the root filesystem device is available, but before + it has been mounted. + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry> + automatically setup the appropriate dependencies to make this happen. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>initrd-root-fs.target</filename></term> + <listitem> + <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry> + automatically adds dependencies of type + <varname>Before=</varname> to the + <filename>sysroot.mount</filename> unit, which is generated + from the kernel command line. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>kbrequest.target</filename></term> + <listitem> + <para>systemd starts this target whenever Alt+ArrowUp is + pressed on the console. Note that any user with physical access + to the machine will be able to do this, without authentication, + so this should be used carefully.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>kexec.target</filename></term> + <listitem> + <para>A special target unit for shutting down and rebooting + the system via kexec.</para> + + <para>Applications wanting to reboot the system should not start this unit + directly, but should instead execute <command>systemctl kexec</command> + (possibly with the <option>--no-block</option> option) or call + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>org.freedesktop.systemd1.Manager.KExec</command> D-Bus method + directly.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>local-fs.target</filename></term> + <listitem> + <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry> + automatically adds dependencies of type + <varname>Before=</varname> to all mount units that refer to + local mount points for this target unit. In addition, it + adds dependencies of type <varname>Wants=</varname> to this + target unit for those mounts listed in + <filename>/etc/fstab</filename> that have the + <option>auto</option> mount option set.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>machines.target</filename></term> + <listitem> + <para>A standard target unit for starting all the containers + and other virtual machines. See <filename>systemd-nspawn@.service</filename> + for an example.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>multi-user.target</filename></term> + <listitem> + <para>A special target unit for setting up a multi-user + system (non-graphical). This is pulled in by + <filename>graphical.target</filename>.</para> + + <para>Units that are needed for a multi-user system shall + add <varname>Wants=</varname> dependencies for their unit to + this unit during installation. This is best configured via + <varname>WantedBy=multi-user.target</varname> in the unit's + [Install] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>network-online.target</filename></term> + <listitem> + <para>Units that strictly require a configured network + connection should pull in + <filename>network-online.target</filename> (via a + <varname>Wants=</varname> type dependency) and order + themselves after it. This target unit is intended to pull in + a service that delays further execution until the network is + sufficiently set up. What precisely this requires is left to + the implementation of the network managing service.</para> + + <para>Note the distinction between this unit and + <filename>network.target</filename>. This unit is an active + unit (i.e. pulled in by the consumer rather than the + provider of this functionality) and pulls in a service which + possibly adds substantial delays to further execution. In + contrast, <filename>network.target</filename> is a passive + unit (i.e. pulled in by the provider of the functionality, + rather than the consumer) that usually does not delay + execution much. Usually, <filename>network.target</filename> + is part of the boot of most systems, while + <filename>network-online.target</filename> is not, except + when at least one unit requires it. Also see <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running + Services After the Network is up</ulink> for more + information.</para> + + <para>All mount units for remote network file systems + automatically pull in this unit, and order themselves after + it. Note that networking daemons that simply provide + functionality to other hosts generally do not need to pull + this in.</para> + + <para>systemd automatically adds dependencies of type <varname>Wants=</varname> and + <varname>After=</varname> for this target unit to all SysV init script service units + with an LSB header referring to the <literal>$network</literal> facility.</para> + + <para>Note that this unit is only useful during the original system start-up + logic. After the system has completed booting up, it will not track the online state of + the system anymore. Due to this it cannot be used as a network connection monitor + concept, it is purely a one-time system start-up concept.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>paths.target</filename></term> + <listitem> + <para>A special target unit that sets up all path units (see + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details) that shall be active after boot.</para> + + <para>It is recommended that path units installed by + applications get pulled in via <varname>Wants=</varname> + dependencies from this unit. This is best configured via a + <varname>WantedBy=paths.target</varname> in the path unit's + [Install] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>poweroff.target</filename></term> + <listitem> + <para>A special target unit for shutting down and powering + off the system.</para> + + <para>Applications wanting to power off the system should not start this unit + directly, but should instead execute <command>systemctl poweroff</command> + (possibly with the <option>--no-block</option> option) or call + <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <command>org.freedesktop.login1.Manager.PowerOff</command> D-Bus method + directly.</para> + + <para><filename>runlevel0.target</filename> is an alias for + this target unit, for compatibility with SysV.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>reboot.target</filename></term> + <listitem> + <para>A special target unit for shutting down and rebooting + the system.</para> + + <para>Applications wanting to reboot the system should not start this unit + directly, but should instead execute <command>systemctl reboot</command> + (possibly with the <option>--no-block</option> option) or call + <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s + <command>org.freedesktop.login1.Manager.Reboot</command> D-Bus method + directly.</para> + + <para><filename>runlevel6.target</filename> is an alias for + this target unit, for compatibility with SysV.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>remote-cryptsetup.target</filename></term> + <listitem> + <para>Similar to <filename>cryptsetup.target</filename>, but for encrypted + devices which are accessed over the network. It is used for + <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>8</manvolnum></citerefentry> + entries marked with <option>_netdev</option>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>remote-fs.target</filename></term> + <listitem> + <para>Similar to <filename>local-fs.target</filename>, but + for remote mount points.</para> + + <para>systemd automatically adds dependencies of type + <varname>After=</varname> for this target unit to all SysV + init script service units with an LSB header referring to + the <literal>$remote_fs</literal> facility.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>rescue.target</filename></term> + <listitem> + <para>A special target unit that pulls in the base system (including system mounts) and + spawns a rescue shell. Isolate to this target in order to administer the system in + single-user mode with all file systems mounted but with no services running, except for + the most basic. Compare with <filename>emergency.target</filename>, which is much more + reduced and does not provide the file systems or most basic services. Compare with + <filename>multi-user.target</filename>, this target could be seen as + <filename>single-user.target</filename>.</para> + + <para><filename>runlevel1.target</filename> is an alias for this target unit, for + compatibility with SysV.</para> + + <para>Use the <literal>systemd.unit=rescue.target</literal> kernel command line option + to boot into this mode. A short alias for this kernel command line option is + <literal>1</literal>, for compatibility with SysV.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>runlevel2.target</filename></term> + <term><filename>runlevel3.target</filename></term> + <term><filename>runlevel4.target</filename></term> + <term><filename>runlevel5.target</filename></term> + <listitem> + <para>These are targets that are called whenever the SysV + compatibility code asks for runlevel 2, 3, 4, 5, + respectively. It is a good idea to make this an alias for + (i.e. symlink to) <filename>graphical.target</filename> + (for runlevel 5) or <filename>multi-user.target</filename> + (the others).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>shutdown.target</filename></term> + <listitem> + <para>A special target unit that terminates the services on + system shutdown.</para> + + <para>Services that shall be terminated on system shutdown + shall add <varname>Conflicts=</varname> and + <varname>Before=</varname> dependencies to this unit for + their service unit, which is implicitly done when + <varname>DefaultDependencies=yes</varname> is set (the + default).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>sigpwr.target</filename></term> + <listitem> + <para>A special target that is started when systemd receives + the SIGPWR process signal, which is normally sent by the + kernel or UPS daemons when power fails.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>sleep.target</filename></term> + <listitem> + <para>A special target unit that is pulled in by + <filename>suspend.target</filename>, + <filename>hibernate.target</filename> and + <filename>hybrid-sleep.target</filename> and may be used to + hook units into the sleep state logic.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>slices.target</filename></term> + <listitem> + <para>A special target unit that sets up all slice units (see + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details) that shall always be active after boot. By default the generic + <filename>system.slice</filename> slice unit as well as the root slice unit + <filename>-.slice</filename> are pulled in and ordered before this unit (see + below).</para> + + <para>Adding slice units to <filename>slices.target</filename> is generally not + necessary. Instead, when some unit that uses <varname>Slice=</varname> is started, the + specified slice will be started automatically. Adding + <varname>WantedBy=slices.target</varname> lines to the [Install] + section should only be done for units that need to be always active. In that case care + needs to be taken to avoid creating a loop through the automatic dependencies on + "parent" slices.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>sockets.target</filename></term> + <listitem> + <para>A special target unit that sets up all socket + units (see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details) that shall be active after boot.</para> + + <para>Services that can be socket-activated shall add + <varname>Wants=</varname> dependencies to this unit for + their socket unit during installation. This is best + configured via a <varname>WantedBy=sockets.target</varname> + in the socket unit's [Install] + section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>suspend.target</filename></term> + <listitem> + <para>A special target unit for suspending the system. This + pulls in <filename>sleep.target</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>swap.target</filename></term> + <listitem> + <para>Similar to <filename>local-fs.target</filename>, but + for swap partitions and swap files.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>sysinit.target</filename></term> + <listitem> + <para>systemd automatically adds dependencies of the types + <varname>Requires=</varname> and <varname>After=</varname> + for this target unit to all services (except for those with + <varname>DefaultDependencies=no</varname>).</para> + + <para>This target pulls in the services required for system + initialization. System services pulled in by this target should + declare <varname>DefaultDependencies=no</varname> and specify + all their dependencies manually, including access to anything + more than a read only root filesystem. For details on the + dependencies of this target, refer to + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>syslog.socket</filename></term> + <listitem> + <para>The socket unit syslog implementations should listen + on. All userspace log messages will be made available on + this socket. For more information about syslog integration, + please consult the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/syslog">Syslog + Interface</ulink> document.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>system-update.target</filename></term> + <term><filename>system-update-pre.target</filename></term> + <term><filename>system-update-cleanup.service</filename></term> + <listitem> + <para>A special target unit that is used for offline system updates. + <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + will redirect the boot process to this target if <filename>/system-update</filename> + exists. For more information see + <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + + <para>Updates should happen before the <filename>system-update.target</filename> is + reached, and the services which implement them should cause the machine to reboot. The + main units executing the update should order themselves after + <filename>system-update-pre.target</filename> but not pull it in. Services which want to + run during system updates only, but before the actual system update is executed should + order themselves before this unit and pull it in. As a safety measure, if this does not + happen, and <filename>/system-update</filename> still exists after + <filename>system-update.target</filename> is reached, + <filename>system-update-cleanup.service</filename> will remove this symlink and reboot + the machine.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>timers.target</filename></term> + <listitem> + <para>A special target unit that sets up all timer units + (see + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details) that shall be active after boot.</para> + + <para>It is recommended that timer units installed by + applications get pulled in via <varname>Wants=</varname> + dependencies from this unit. This is best configured via + <varname>WantedBy=timers.target</varname> in the timer + unit's [Install] section.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>umount.target</filename></term> + <listitem> + <para>A special target unit that unmounts all mount and + automount points on system shutdown.</para> + + <para>Mounts that shall be unmounted on system shutdown + shall add Conflicts dependencies to this unit for their + mount unit, which is implicitly done when + <varname>DefaultDependencies=yes</varname> is set (the + default).</para> + </listitem> + </varlistentry> + + </variablelist> + </refsect2> + + <refsect2> + <title>Special System Units for Devices</title> + + <para>Some target units are automatically pulled in as devices of + certain kinds show up in the system. These may be used to + automatically activate various services based on the specific type + of the available hardware.</para> + + <variablelist> + <varlistentry> + <term><filename>bluetooth.target</filename></term> + <listitem> + <para>This target is started automatically as soon as a + Bluetooth controller is plugged in or becomes available at + boot.</para> + + <para>This may be used to pull in Bluetooth management + daemons dynamically when Bluetooth hardware is found.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>printer.target</filename></term> + <listitem> + <para>This target is started automatically as soon as a + printer is plugged in or becomes available at boot.</para> + + <para>This may be used to pull in printer management daemons + dynamically when printer hardware is found.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>smartcard.target</filename></term> + <listitem> + <para>This target is started automatically as soon as a + smartcard controller is plugged in or becomes available at + boot.</para> + + <para>This may be used to pull in smartcard management + daemons dynamically when smartcard hardware is found.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>sound.target</filename></term> + <listitem> + <para>This target is started automatically as soon as a + sound card is plugged in or becomes available at + boot.</para> + + <para>This may be used to pull in audio management daemons + dynamically when audio hardware is found.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>usb-gadget.target</filename></term> + <listitem> + <para>This target is started automatically as soon as a + USB Device Controller becomes available at boot.</para> + + <para>This may be used to pull in usb gadget + dynamically when UDC hardware is found.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Special Passive System Units </title> + + <para>A number of special system targets are defined that can be + used to properly order boot-up of optional services. These targets + are generally not part of the initial boot transaction, unless + they are explicitly pulled in by one of the implementing services. + Note specifically that these <emphasis>passive</emphasis> target + units are generally not pulled in by the consumer of a service, + but by the provider of the service. This means: a consuming + service should order itself after these targets (as appropriate), + but not pull it in. A providing service should order itself before + these targets (as appropriate) and pull it in (via a + <varname>Wants=</varname> type dependency).</para> + + <para>Note that these passive units cannot be started manually, + i.e. <literal>systemctl start time-sync.target</literal> will fail + with an error. They can only be pulled in by dependency. This is + enforced since they exist for ordering purposes only and thus are + not useful as only unit within a transaction.</para> + + <variablelist> + <varlistentry> + <term><filename>blockdev@.target</filename></term> + <listitem><para>This template unit is used to order mount units and other consumers of block + devices after services that synthesize these block devices. In particular, this is intended to be + used with storage services (such as + <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>) + that allocate and manage a virtual block device. Storage services are ordered before an instance of + <filename>blockdev@.target</filename>, and the consumer units after it. The ordering is + particularly relevant during shutdown, as it ensures that the mount is deactivated first and the + service backing the mount later. The <filename>blockdev@.target</filename> instance should be + pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be + part of any transaction unless a storage daemon is used. The instance name for instances of this + template unit must be a properly escaped block device node path, e.g. + <filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device + <filename index="false">/dev/mapper/foobar</filename>.</para></listitem> + </varlistentry> + <varlistentry> + <term><filename>cryptsetup-pre.target</filename></term> + <listitem> + <para>This passive target unit may be pulled in by services + that want to run before any encrypted block device is set + up. All encrypted block devices are set up after this target + has been reached. Since the shutdown order is implicitly the + reverse start-up order between units, this target is + particularly useful to ensure that a service is shut down + only after all encrypted block devices are fully + stopped.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>first-boot-complete.target</filename></term> + <listitem> + <para>This passive target is intended as a synchronization point for units that need to run once + during the first boot. Only after all units ordered before this target have finished, will the + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> + be committed to disk, marking the first boot as completed. If the boot is aborted at any time + before that, the next boot will re-run any units with <varname>ConditionFirstBoot=yes</varname>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>getty-pre.target</filename></term> + <listitem> + <para>A special passive target unit. Users of this target + are expected to pull it in the boot transaction via + a dependency (e.g. <varname>Wants=</varname>). Order your + unit before this unit if you want to make use of the console + just before <filename>getty</filename> is started. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>local-fs-pre.target</filename></term> + <listitem> + <para>This target unit is + automatically ordered before + all local mount points marked + with <option>auto</option> + (see above). It can be used to + execute certain units before + all local mounts.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>network.target</filename></term> + <listitem> + <para>This unit is supposed to indicate when network + functionality is available, but it is only very weakly + defined what that is supposed to mean, with one exception: + at shutdown, a unit that is ordered after + <filename>network.target</filename> will be stopped before + the network — to whatever level it might be set up then — + is shut down. It is hence useful when writing service files + that require network access on shutdown, which should order + themselves after this target, but not pull it in. Also see + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running + Services After the Network is up</ulink> for more + information. Also see + <filename>network-online.target</filename> described + above.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>network-pre.target</filename></term> + <listitem> + <para>This passive target unit may be pulled in by services + that want to run before any network is set up, for example + for the purpose of setting up a firewall. All network + management software orders itself after this target, but + does not pull it in.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>nss-lookup.target</filename></term> + <listitem> + <para>A target that should be used as synchronization point for all host/network name + service lookups. Note that this is independent of UNIX user/group name lookups for which + <filename>nss-user-lookup.target</filename> should be used. All services for which the + availability of full host/network name resolution is essential should be ordered after + this target, but not pull it in. systemd automatically adds dependencies of type + <varname>After=</varname> for this target unit to all SysV init script service units + with an LSB header referring to the <literal>$named</literal> facility.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>nss-user-lookup.target</filename></term> + <listitem> + <para>A target that should be used as synchronization point for all regular UNIX + user/group name service lookups. Note that this is independent of host/network name + lookups for which <filename>nss-lookup.target</filename> should be used. All services + for which the availability of the full user/group database is essential should be + ordered after this target, but not pull it in. All services which provide parts of the + user/group database should be ordered before this target, and pull it in. Note that this + unit is only relevant for regular users and groups — system users and groups are + required to be resolvable during earliest boot already, and hence do not need any + special ordering against this target.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>remote-fs-pre.target</filename></term> + <listitem> + <para>This target unit is automatically ordered before all + mount point units (see above) and cryptsetup devices + marked with the <option>_netdev</option>. It can be used to run + certain units before remote encrypted devices and mounts are established. + Note that this unit is generally not part of the initial + transaction, unless the unit that wants to be ordered before + all remote mounts pulls it in via a + <varname>Wants=</varname> type dependency. If the unit wants + to be pulled in by the first remote mount showing up, it + should use <filename>network-online.target</filename> (see + above).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>rpcbind.target</filename></term> + <listitem> + <para>The portmapper/rpcbind pulls in this target and orders + itself before it, to indicate its availability. systemd + automatically adds dependencies of type + <varname>After=</varname> for this target unit to all SysV + init script service units with an LSB header referring to + the <literal>$portmap</literal> facility.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>time-set.target</filename></term> + <listitem> + <para>Services responsible for setting the system clock from + a local source (such as a maintained timestamp file or + imprecise real-time clock) should pull in this target and + order themselves before it. Services where approximate time + is desired should be ordered after this unit, but not pull + it in. This target does not provide the accuracy guarantees + of <filename>time-sync.target</filename>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><filename>time-sync.target</filename></term> + <listitem> + <para>Services responsible for synchronizing the system + clock from a remote source (such as NTP client + implementations) should pull in this target and order + themselves before it. All services where correct time is + essential should be ordered after this unit, but not pull it + in. systemd automatically adds dependencies of type + <varname>After=</varname> for this target unit to all SysV + init script service units with an LSB header referring to + the <literal>$time</literal> facility. </para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Special Slice Units</title> + + <para>There are four <literal>.slice</literal> units which form the basis of the hierarchy for + assignment of resources for services, users, and virtual machines or containers. See + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about slice units.</para> + + <variablelist> + <varlistentry> + <term><filename>-.slice</filename></term> + <listitem> + <para>The root slice is the root of the slice hierarchy. It usually does not contain + units directly, but may be used to set defaults for the whole tree.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>system.slice</filename></term> + <listitem> + <para>By default, all system services started by + <command>systemd</command> are found in this slice.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>user.slice</filename></term> + <listitem> + <para>By default, all user processes and services started on + behalf of the user, including the per-user systemd instance + are found in this slice. This is pulled in by + <filename>systemd-logind.service</filename>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>machine.slice</filename></term> + <listitem> + <para>By default, all virtual machines and containers + registered with <command>systemd-machined</command> are + found in this slice. This is pulled in by + <filename>systemd-machined.service</filename>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Units managed by the user service manager</title> + + <refsect2> + <title>Special User Units</title> + + <para>When systemd runs as a user instance, the following special + units are available:</para> + + <variablelist> + <varlistentry> + <term><filename>default.target</filename></term> + <listitem> + <para>This is the main target of the user session, started by default. Various services that + compose the normal user session should be pulled into this target. In this regard, + <filename>default.target</filename> is similar to <filename>multi-user.target</filename> in the + system instance, but it is a real unit, not an alias.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>In addition, the following units are available which have definitions similar to their + system counterparts: + <filename>exit.target</filename>, + <filename>shutdown.target</filename>, + <filename>sockets.target</filename>, + <filename>timers.target</filename>, + <filename>paths.target</filename>, + <filename>bluetooth.target</filename>, + <filename>printer.target</filename>, + <filename>smartcard.target</filename>, + <filename>sound.target</filename>.</para> + </refsect2> + + <refsect2> + <title>Special Passive User Units</title> + + <variablelist> + <varlistentry> + <term><filename>graphical-session.target</filename></term> + <listitem> + <para>This target is active whenever any graphical session is running. It is used to + stop user services which only apply to a graphical (X, Wayland, etc.) session when the + session is terminated. Such services should have + <literal>PartOf=graphical-session.target</literal> in their [Unit] + section. A target for a particular session (e. g. + <filename>gnome-session.target</filename>) starts and stops + <literal>graphical-session.target</literal> with + <literal>BindsTo=graphical-session.target</literal>.</para> + + <para>Which services are started by a session target is determined by the + <literal>Wants=</literal> and <literal>Requires=</literal> dependencies. For services + that can be enabled independently, symlinks in <literal>.wants/</literal> and + <literal>.requires/</literal> should be used, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Those symlinks should either be shipped in packages, or should be added dynamically + after installation, for example using <literal>systemctl add-wants</literal>, see + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + + <example> + <title>Nautilus as part of a GNOME session</title> + + <para><literal>gnome-session.target</literal> pulls in Nautilus as top-level service:</para> + + <programlisting>[Unit] + Description=User systemd services for GNOME graphical session + Wants=nautilus.service + BindsTo=graphical-session.target</programlisting> + + <para><literal>nautilus.service</literal> gets stopped when the session stops:</para> + + <programlisting>[Unit] + Description=Render the desktop icons with Nautilus + PartOf=graphical-session.target + + [Service] + …</programlisting> + </example> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>graphical-session-pre.target</filename></term> + <listitem> + <para>This target contains services which set up the environment or global configuration + of a graphical session, such as SSH/GPG agents (which need to export an environment + variable into all desktop processes) or migration of obsolete d-conf keys after an OS + upgrade (which needs to happen before starting any process that might use them). This + target must be started before starting a graphical session like + <filename>gnome-session.target</filename>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>xdg-desktop-autostart.target</filename></term> + <listitem> + <para>The XDG specification defines a way to autostart applications using XDG desktop files. + systemd ships + <citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for the XDG desktop files in autostart directories. + Desktop Environments can opt-in to use this service by adding a <varname>Wants=</varname> + dependency on <literal>xdg-desktop-autostart.target</literal>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Special User Slice Units</title> + + <para>There are four <literal>.slice</literal> units which form the basis of the user hierarchy for + assignment of resources for user applications and services. See + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about slice units and the documentation about + <ulink url="https://systemd.io/DESKTOP_ENVIRONMENTS">Desktop Environments</ulink> + for further information.</para> + + <variablelist> + <varlistentry> + <term><filename>-.slice</filename></term> + <listitem> + <para>The root slice is the root of the user's slice hierarchy. + It usually does not contain units directly, but may be used to set defaults for the whole tree.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>app.slice</filename></term> + <listitem> + <para>By default, all user services and applications managed by + <command>systemd</command> are found in this slice. + All interactively launched applications like web browsers and text editors + as well as non-critical services should be placed into this slice.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>session.slice</filename></term> + <listitem> + <para>All essential services and applications required for the + session should use this slice. + These are services that either cannot be restarted easily + or where latency issues may affect the interactivity of the system and applications. + This includes the display server, screen readers and other services such as DBus or XDG portals. + Such services should be configured to be part of this slice by + adding <varname>Slice=session.slice</varname> to their unit files.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><filename>background.slice</filename></term> + <listitem> + <para>All services running low-priority background tasks should use this slice. + This permits resources to be preferentially assigned to the other slices. + Examples include non-interactive tasks like file indexing or backup operations + where latency is not important.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml new file mode 100644 index 0000000..2a867f9 --- /dev/null +++ b/man/systemd.swap.xml @@ -0,0 +1,263 @@ +<?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-or-later --> + +<refentry id="systemd.swap" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd.swap</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.swap</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.swap</refname> + <refpurpose>Swap unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>swap</replaceable>.swap</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.swap</literal> encodes information about a swap device + or file for memory paging controlled and supervised by + systemd.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The swap specific configuration options are + configured in the [Swap] section.</para> + + <para>Additional options are listed in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the execution environment the <citerefentry + project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> + program is executed in, in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which define the way these processes are + terminated, and in + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + which configure resource control settings for these processes of the + unit.</para> + + <para>Swap units must be named after the devices or files they control. Example: the swap device <filename + index="false">/dev/sda5</filename> must be configured in a unit file <filename>dev-sda5.swap</filename>. For + details about the escaping logic used to convert a file system path to a unit name, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note that swap + units cannot be templated, nor is possible to add multiple names to a swap unit by creating additional symlinks to + it.</para> + + <para>Note that swap support on Linux is privileged, swap units are hence only available in the system + service manager (and root's user service manager), but not in unprivileged user's service manager.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>All swap units automatically get the + <varname>BindsTo=</varname> and <varname>After=</varname> + dependencies on the device units or the mount units of the files + they are activated from.</para></listitem> + </itemizedlist> + + <para>Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Swap units automatically acquire a <varname>Conflicts=</varname> and a + <varname>Before=</varname> dependency on <filename>umount.target</filename> so that they are deactivated at + shutdown as well as a <varname>Before=swap.target</varname> dependency.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title><filename>fstab</filename></title> + + <para>Swap units may either be configured via unit files, or via + <filename>/etc/fstab</filename> (see + <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details). Swaps listed in <filename>/etc/fstab</filename> will + be converted into native units dynamically at boot and when the + configuration of the system manager is reloaded. See + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for details about the conversion.</para> + + <para>If a swap device or file is configured in both + <filename>/etc/fstab</filename> and a unit file, the configuration + in the latter takes precedence.</para> + + <para>When reading <filename>/etc/fstab</filename>, a few special + options are understood by systemd which influence how dependencies + are created for swap units.</para> + + <variablelist class='fstab-options'> + <varlistentry> + <term><option>noauto</option></term> + <term><option>auto</option></term> + + <listitem><para>With <option>noauto</option>, the swap unit + will not be added as a dependency for + <filename>swap.target</filename>. This means that it will not + be activated automatically during boot, unless it is pulled in + by some other unit. The <option>auto</option> option has the + opposite meaning and is the default.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>nofail</option></term> + + <listitem><para>With <option>nofail</option>, the swap unit + will be only wanted, not required by + <filename>swap.target</filename>. This means that the boot + will continue even if this swap device is not activated + successfully.</para> + </listitem> + </varlistentry> + + <xi:include href="systemd.mount.xml" xpointer="device-timeout" /> + + <varlistentry> + <term><option>x-systemd.makefs</option></term> + + <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 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> + + <para>See + <citerefentry><refentrytitle>systemd-mkswap@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and the discussion of + <citerefentry project='man-pages'><refentrytitle>wipefs</refentrytitle><manvolnum>8</manvolnum></citerefentry> + in <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Swap unit files must include a [Swap] section, which carries + information about the swap device it supervises. A number of + options that may be used in this section are shared with other + unit types. These options are documented in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + The options specific to the [Swap] section of swap units are the + following:</para> + + <variablelist class='unit-directives'> + + <varlistentry> + <term><varname>What=</varname></term> + <listitem><para>Takes an absolute path of a device node or file to use for paging. See <citerefentry + project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + details. If this refers to a device node, a dependency on the respective device unit is automatically + created. (See + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information.) If this refers to a file, a dependency on the respective mount unit is + automatically created. (See + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + more information.) This option is mandatory. Note that the usual specifier expansion is applied to + this setting, literal percent characters should hence be written as + <literal class='specifiers'>%%</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Priority=</varname></term> + + <listitem><para>Swap priority to use when activating the swap + device or file. This takes an integer. This setting is + optional and ignored when the priority is set by <option>pri=</option> in the + <varname>Options=</varname> key.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Options=</varname></term> + + <listitem><para>May contain an option string for the swap device. This may be used for controlling discard + options among other functionality, if the swap backing device supports the discard or trim operation. (See + <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> + for more information.) Note that the usual specifier expansion is applied to this setting, literal percent + characters should hence be written as <literal>%%</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>TimeoutSec=</varname></term> + <listitem><para>Configures the time to wait for the swapon + command to finish. If a command does not exit within the + configured time, the swap will be considered failed and be + shut down again. All commands still running will be terminated + forcibly via <constant>SIGTERM</constant>, and after another + delay of this time with <constant>SIGKILL</constant>. (See + <option>KillMode=</option> in + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass <literal>0</literal> to disable the + timeout logic. Defaults to + <varname>DefaultTimeoutStartSec=</varname> from the manager + configuration file (see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + </para></listitem> + </varlistentry> + </variablelist> + + <para>Check + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more settings.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.syntax.xml b/man/systemd.syntax.xml new file mode 100644 index 0000000..7960adb --- /dev/null +++ b/man/systemd.syntax.xml @@ -0,0 +1,139 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.syntax"> + + <refentryinfo> + <title>systemd.syntax</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.syntax</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.syntax</refname> + <refpurpose>General syntax of systemd configuration files</refpurpose> + </refnamediv> + + <refsect1> + <title>Introduction</title> + + <para>This page describes the basic principles of configuration files used by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and related programs for: + <itemizedlist> + <listitem><para>systemd unit files, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para></listitem> + + <listitem><para>link files, see + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para></listitem> + + <listitem><para>netdev and network files, see + <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para></listitem> + + <listitem><para>daemon config files, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + </para></listitem> + </itemizedlist> + </para> + + <para>The syntax is inspired by + <ulink url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG Desktop Entry Specification</ulink> + <filename>.desktop</filename> files, which are in turn inspired by Microsoft Windows + <filename>.ini</filename> files. + </para> + + <para>Each file is a plain text file divided into sections, with configuration entries in the + style <replaceable>key</replaceable>=<replaceable>value</replaceable>. + Whitespace immediately before or after the <literal>=</literal> is ignored. Empty lines and lines starting with <literal>#</literal> or <literal>;</literal> are + ignored, which may be used for commenting.</para> + + <para>Lines ending in a backslash are concatenated with the following line while reading and the + backslash is replaced by a space character. This may be used to wrap long lines. The limit on + line length is very large (currently 1 MB), but it is recommended to avoid such long lines and + use multiple directives, variable substitution, or other mechanism as appropriate for the given + file type. When a comment line or lines follow a line ending with a backslash, the comment block + is ignored, so the continued line is concatenated with whatever follows the comment block.</para> + + <example><programlisting>[Section A] +KeyOne=value 1 +KeyTwo=value 2 + +# a comment + +[Section B] +Setting="something" "some thing" "…" +KeyTwo=value 2 \ + value 2 continued + +[Section C] +KeyThree=value 3\ +# this line is ignored +; this line is ignored too + value 3 continued +</programlisting></example> + + <para>Boolean arguments used in configuration files can be written in + various formats. For positive settings the strings + <option>1</option>, <option>yes</option>, <option>true</option> + and <option>on</option> are equivalent. For negative settings, the + strings <option>0</option>, <option>no</option>, + <option>false</option> and <option>off</option> are + equivalent.</para> + + <para>Time span values encoded in configuration files can be written in various formats. A stand-alone + number specifies a time in seconds. If suffixed with a time unit, the unit is honored. A + concatenation of multiple values with units is supported, in which case the values are added + up. Example: <literal>50</literal> refers to 50 seconds; <literal>2min 200ms</literal> refers to + 2 minutes and 200 milliseconds, i.e. 120200 ms. The following time units are understood: + <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, <literal>d</literal>, + <literal>w</literal>, <literal>ms</literal>, <literal>us</literal>. For details see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>Various settings are allowed to be specified more than once, in which case the + interpretation depends on the setting. Often, multiple settings form a list, and setting to an + empty value "resets", which means that previous assignments are ignored. When this is allowed, + it is mentioned in the description of the setting. Note that using multiple assignments to the + same value makes the file incompatible with parsers for the XDG <filename>.desktop</filename> + file format.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.target.xml b/man/systemd.target.xml new file mode 100644 index 0000000..bd618d8 --- /dev/null +++ b/man/systemd.target.xml @@ -0,0 +1,135 @@ +<?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-or-later --> + +<refentry id="systemd.target"> + <refentryinfo> + <title>systemd.target</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.target</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.target</refname> + <refpurpose>Target unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>target</replaceable>.target</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.target</literal> encodes information about a target unit + of systemd, which is used for grouping units and as well-known + synchronization points during start-up.</para> + + <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, + since no target-specific options may be configured.</para> + + <para>Target units do not offer any additional functionality on + top of the generic functionality provided by units. They exist + merely to group units via dependencies (useful as boot targets), + and to establish standardized names for synchronization points + used in dependencies between units. Among other things, target + units are a more flexible replacement for SysV runlevels in the + classic SysV init system. (And for compatibility reasons special + target units such as <filename>runlevel3.target</filename> exist + which are used by the SysV runlevel compatibility code in systemd. + See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details).</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>There are no implicit dependencies for target units.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless + <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Target units will automatically complement all + configured dependencies of type <varname>Wants=</varname> or + <varname>Requires=</varname> with dependencies of type + <varname>After=</varname> unless <varname>DefaultDependencies=no</varname> + is set in the specified units. Note that <varname>Wants=</varname> or + <varname>Requires=</varname> must be defined in the target unit itself — if + you for example define <varname>Wants=</varname>some.target in + some.service, the automatic ordering will not be added.</para></listitem> + + <listitem><para>Target units automatically gain <varname>Conflicts=</varname> + and <varname>Before=</varname> dependencies against + <filename>shutdown.target</filename>.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Example</title> + + <example> + <title>Simple standalone target</title> + + <programlisting># emergency-net.target + +[Unit] +Description=Emergency Mode with Networking +Requires=emergency.target systemd-networkd.service +After=emergency.target systemd-networkd.service +AllowIsolate=yes</programlisting> + + <para>When adding dependencies to other units, it's important to check if they set + <varname>DefaultDependencies=</varname>. Service units, unless they set + <varname>DefaultDependencies=no</varname>, automatically get a dependency on + <filename>sysinit.target</filename>. In this case, both + <filename>emergency.target</filename> and <filename>systemd-networkd.service</filename> + have <varname>DefaultDependencies=no</varname>, so they are suitable for use + in this target, and do not pull in <filename>sysinit.target</filename>.</para> + + <para>You can now switch into this emergency mode by running <varname>systemctl + isolate emergency-net.target</varname> or by passing the option + <varname>systemd.unit=emergency-net.target</varname> on the kernel command + line.</para> + + <para>Other units can have <varname>WantedBy=emergency-net.target</varname> in the + <varname>[Install]</varname> section. After they are enabled using + <command>systemctl enable</command>, they will be started before + <varname>emergency-net.target</varname> is started. It is also possible to add + arbitrary units as dependencies of <filename>emergency.target</filename> without + modifying them by using <command>systemctl add-wants</command>. + </para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.time.xml b/man/systemd.time.xml new file mode 100644 index 0000000..a759707 --- /dev/null +++ b/man/systemd.time.xml @@ -0,0 +1,312 @@ +<?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-or-later --> + +<refentry id="systemd.time"> + + <refentryinfo> + <title>systemd.time</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.time</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.time</refname> + <refpurpose>Time and date specifications</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>In systemd, timestamps, time spans, and calendar events are + displayed and may be specified in closely related syntaxes.</para> + </refsect1> + + <refsect1> + <title>Displaying Time Spans</title> + + <para>Time spans refer to time durations. On display, systemd will present time spans as a space-separated series + of time values each suffixed by a time unit. Example:</para> + + <programlisting>2h 30min</programlisting> + + <para>All specified time values are meant to be added up. The above hence refers to 150 minutes. Display is + locale-independent, only English names for the time units are used.</para> + </refsect1> + + <refsect1> + <title>Parsing Time Spans</title> + + <para>When parsing, systemd will accept the same time span syntax. + Separating spaces may be omitted. The following time units are + understood:</para> + + <itemizedlist> + <listitem><para>usec, us, µs</para></listitem> + <listitem><para>msec, ms</para></listitem> + <listitem><para>seconds, second, sec, s</para></listitem> + <listitem><para>minutes, minute, min, m</para></listitem> + <listitem><para>hours, hour, hr, h</para></listitem> + <listitem><para>days, day, d</para></listitem> + <listitem><para>weeks, week, w</para></listitem> + <listitem><para>months, month, M (defined as 30.44 days)</para></listitem> + <listitem><para>years, year, y (defined as 365.25 days)</para></listitem> + </itemizedlist> + + <para>If no time unit is specified, generally seconds are assumed, but some exceptions exist and are marked as + such. In a few cases <literal>ns</literal>, <literal>nsec</literal> is accepted too, where the granularity of the + time span permits this. Parsing is generally locale-independent, non-English names for the time units are not + accepted.</para> + + <para>Examples for valid time span specifications:</para> + + <programlisting>2 h +2hours +48hr +1y 12month +55s500ms +300ms20s 5day</programlisting> + + <para>One can use the <command>timespan</command> command of + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> + to normalise a textual time span for testing and validation purposes.</para> + + <para>Internally, systemd generally operates with microsecond time granularity, while the default time + unit in user-configurable time spans is usually seconds (see above). This disparity becomes visible when + comparing the same settings in the (high-level) unit file syntax with the matching (more low-level) D-Bus + properties (which are what + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>show</command> command displays). The former typically are suffixed with <literal>…Sec</literal> + to indicate the default unit of seconds, the latter are typically suffixed with <literal>…USec</literal> + to indicate the underlying low-level time unit, even if they both encapsulate the very same + settings.</para> + </refsect1> + + <refsect1> + <title>Displaying Timestamps</title> + + <para>Timestamps refer to specific, unique points in time. On + display, systemd will format these in the local timezone as + follows:</para> + + <programlisting>Fri 2012-11-23 23:02:15 CET</programlisting> + + <para>The weekday is printed in the abbreviated English language form. The formatting is locale-independent.</para> + + <para>In some cases timestamps are shown in the UTC timezone instead of the local timezone, which is indicated via + the <literal>UTC</literal> timezone specifier in the output.</para> + + <para>In some cases timestamps are shown with microsecond granularity. In this case the sub-second remainder is + separated by a full stop from the seconds component.</para> + </refsect1> + + <refsect1> + <title>Parsing Timestamps</title> + + <para>When parsing, systemd will accept a similar syntax, but expects no timezone specification, unless + it is given as the literal string <literal>UTC</literal> (for the UTC timezone), or is specified to be + the locally configured timezone, or the timezone name in the IANA timezone database format. The complete + list of timezones supported on your system can be obtained using the <literal>timedatectl + list-timezones</literal> (see + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Using + IANA format is recommended over local timezone names, as less prone to errors (e.g. with local timezone + it's possible to specify daylight saving time in winter, even though that is not correct). The weekday + specification is optional, but when the weekday is specified, it must either be in the abbreviated + (<literal>Wed</literal>) or non-abbreviated (<literal>Wednesday</literal>) English language form (case + does not matter), and is not subject to the locale choice of the user. Either the date, or the time part + may be omitted, in which case the current date or 00:00:00, respectively, is assumed. The seconds + component of the time may also be omitted, in which case ":00" is assumed. Year numbers may be specified + in full or may be abbreviated (omitting the century).</para> + + <para>A timestamp is considered invalid if a weekday is specified and the date does not match the specified day of + the week.</para> + + <para>When parsing, systemd will also accept a few special + placeholders instead of timestamps: <literal>now</literal> may be + used to refer to the current time (or of the invocation of the + command that is currently executed). <literal>today</literal>, + <literal>yesterday</literal>, and <literal>tomorrow</literal> refer to + 00:00:00 of the current day, the day before, or the next day, + respectively.</para> + + <para>When parsing, systemd will also accept relative time + specifications. A time span (see above) that is prefixed with + <literal>+</literal> is evaluated to the current time plus the + specified time span. Correspondingly, a time span that is prefixed + with <literal>-</literal> is evaluated to the current time minus + the specified time span. Instead of prefixing the time span with + <literal>+</literal> or <literal>-</literal>, it may also be + suffixed with a space and the word <literal>left</literal> or + <literal>ago</literal>.</para> + + <para>Finally, a timespan prefixed with <literal>@</literal> is + evaluated relative to the UNIX time epoch 1st Jan, 1970, + 00:00.</para> + + <para>Examples for valid timestamps and their normalized form (assuming the current time was 2012-11-23 + 18:15:22 and the timezone was UTC+8, for example <literal>TZ=:Asia/Shanghai</literal>):</para> + + <programlisting> Fri 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13 + 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13 + 2012-11-23 11:12:13 UTC → Fri 2012-11-23 19:12:13 + 2012-11-23 → Fri 2012-11-23 00:00:00 + 12-11-23 → Fri 2012-11-23 00:00:00 + 11:12:13 → Fri 2012-11-23 11:12:13 + 11:12 → Fri 2012-11-23 11:12:00 + now → Fri 2012-11-23 18:15:22 + today → Fri 2012-11-23 00:00:00 + today UTC → Fri 2012-11-23 16:00:00 + yesterday → Fri 2012-11-22 00:00:00 + tomorrow → Fri 2012-11-24 00:00:00 +tomorrow Pacific/Auckland → Thu 2012-11-23 19:00:00 + +3h30min → Fri 2012-11-23 21:45:22 + -5s → Fri 2012-11-23 18:15:17 + 11min ago → Fri 2012-11-23 18:04:22 + @1395716396 → Tue 2014-03-25 03:59:56</programlisting> + + <para>Note that timestamps displayed by remote systems with a non-matching timezone are usually not parsable + locally, as the timezone component is not understood (unless it happens to be <literal>UTC</literal>).</para> + + <para>Timestamps may also be specified with microsecond granularity. The sub-second remainder is expected separated + by a full stop from the seconds component. Example:</para> + + <programlisting>2014-03-25 03:59:56.654563</programlisting> + + <para>In some cases, systemd will display a relative timestamp (relative to the current time, or the time of + invocation of the command) instead of or in addition to an absolute timestamp as described above. A relative + timestamp is formatted as follows:</para> + + <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> + <title>Calendar Events</title> + + <para>Calendar events may be used to refer to one or more points + in time in a single expression. They form a superset of the + absolute timestamps explained above:</para> + + <programlisting>Thu,Fri 2012-*-1,5 11:12:13</programlisting> + + <para>The above refers to 11:12:13 of the first or fifth day of + any month of the year 2012, but only if that day is a Thursday or + Friday.</para> + + <para>The weekday specification is optional. If specified, it + should consist of one or more English language weekday names, + either in the abbreviated (Wed) or non-abbreviated (Wednesday) + form (case does not matter), separated by commas. Specifying two + weekdays separated by <literal>..</literal> refers to a range of + continuous weekdays. <literal>,</literal> and <literal>..</literal> + may be combined freely.</para> + + <para>In the date and time specifications, any component may be specified as <literal>*</literal> in + which case any value will match. Alternatively, each component can be specified as a list of values + separated by commas. Values may be suffixed with <literal>/</literal> and a repetition value, which + indicates that the value itself and the value plus all multiples of the repetition value are matched. + Two values separated by <literal>..</literal> may be used to indicate a range of values; ranges may also + be followed with <literal>/</literal> and a repetition value, in which case the expression matches all + times starting with the start value, and continuing with all multiples of the repetition value relative + to the start value, ending at the end value the latest.</para> + + <para>A date specification may use <literal>~</literal> to indicate the + last day(s) in a month. For example, <literal>*-02~03</literal> means + "the third last day in February," and <literal>Mon *-05~07/1</literal> + means "the last Monday in May."</para> + + <para>The seconds component may contain decimal fractions both in + the value and the repetition. All fractions are rounded to 6 + decimal places.</para> + + <para>Either time or date specification may be omitted, in which + case the current day and 00:00:00 is implied, respectively. If the + second component is not specified, <literal>:00</literal> is + assumed.</para> + + <para>Timezone can be specified as the literal string <literal>UTC</literal>, or + the local timezone, similar to the supported syntax of timestamps (see above), or the timezone + in the IANA timezone database format (also see above).</para> + + <para>The following special expressions may be used as shorthands for longer normalized forms:</para> + + <programlisting> minutely → *-*-* *:*:00 + hourly → *-*-* *:00:00 + daily → *-*-* 00:00:00 + monthly → *-*-01 00:00:00 + weekly → Mon *-*-* 00:00:00 + yearly → *-01-01 00:00:00 + quarterly → *-01,04,07,10-01 00:00:00 +semiannually → *-01,07-01 00:00:00 + </programlisting> + + <para>Examples for valid timestamps and their + normalized form:</para> + +<programlisting> Sat,Thu,Mon..Wed,Sat..Sun → Mon..Thu,Sat,Sun *-*-* 00:00:00 + Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00 + Wed *-1 → Wed *-*-01 00:00:00 + Wed..Wed,Wed *-1 → Wed *-*-01 00:00:00 + Wed, 17:48 → Wed *-*-* 17:48:00 +Wed..Sat,Tue 12-10-15 1:2:3 → Tue..Sat 2012-10-15 01:02:03 + *-*-7 0:0:0 → *-*-07 00:00:00 + 10-15 → *-10-15 00:00:00 + monday *-12-* 17:00 → Mon *-12-* 17:00:00 + Mon,Fri *-*-3,1,2 *:30:45 → Mon,Fri *-*-01,02,03 *:30:45 + 12,14,13,12:20,10,30 → *-*-* 12,13,14:10,20,30:00 + 12..14:10,20,30 → *-*-* 12..14:10,20,30:00 + mon,fri *-1/2-1,3 *:30:45 → Mon,Fri *-01/2-01,03 *:30:45 + 03-05 08:05:40 → *-03-05 08:05:40 + 08:05:40 → *-*-* 08:05:40 + 05:40 → *-*-* 05:40:00 + Sat,Sun 12-05 08:05:40 → Sat,Sun *-12-05 08:05:40 + Sat,Sun 08:05:40 → Sat,Sun *-*-* 08:05:40 + 2003-03-05 05:40 → 2003-03-05 05:40:00 + 05:40:23.4200004/3.1700005 → *-*-* 05:40:23.420000/3.170001 + 2003-02..04-05 → 2003-02..04-05 00:00:00 + 2003-03-05 05:40 UTC → 2003-03-05 05:40:00 UTC + 2003-03-05 → 2003-03-05 00:00:00 + 03-05 → *-03-05 00:00:00 + hourly → *-*-* *:00:00 + daily → *-*-* 00:00:00 + daily UTC → *-*-* 00:00:00 UTC + monthly → *-*-01 00:00:00 + weekly → Mon *-*-* 00:00:00 + weekly Pacific/Auckland → Mon *-*-* 00:00:00 Pacific/Auckland + yearly → *-01-01 00:00:00 + annually → *-01-01 00:00:00 + *:2/3 → *-*-* *:02/3:00</programlisting> + + <para>Calendar events are used by timer units, see + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + + <para>Use the <command>calendar</command> command of + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> to validate + and normalize calendar time specifications for testing purposes. The tool also calculates when a specified + calendar event would occur next.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml new file mode 100644 index 0000000..9fe7ff3 --- /dev/null +++ b/man/systemd.timer.xml @@ -0,0 +1,374 @@ +<?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-or-later --> + +<refentry id="systemd.timer"> + <refentryinfo> + <title>systemd.timer</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.timer</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.timer</refname> + <refpurpose>Timer unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>timer</replaceable>.timer</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit configuration file whose name ends in + <literal>.timer</literal> encodes information about a timer + controlled and supervised by systemd, for timer-based + activation.</para> + + <para>This man page lists the configuration options specific to + this unit type. See + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The timer specific configuration options are + configured in the [Timer] section.</para> + + <para>For each timer file, a matching unit file must exist, + describing the unit to activate when the timer elapses. By + default, a service by the same name as the timer (except for the + suffix) is activated. Example: a timer file + <filename>foo.timer</filename> activates a matching service + <filename>foo.service</filename>. The unit to activate may be + controlled by <varname>Unit=</varname> (see below).</para> + + <para>Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, + but simply left running. There is no concept of spawning new service instances in this case. Due to this, services + with <varname>RemainAfterExit=</varname> set (which stay around continuously even after the service's main process + exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and + then stay around forever.</para> + </refsect1> + + <refsect1> + <title>Automatic Dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>The following dependencies are implicitly added:</para> + + <itemizedlist> + <listitem><para>Timer units automatically gain a <varname>Before=</varname> + dependency on the service they are supposed to activate.</para></listitem> + </itemizedlist> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para> + + <itemizedlist> + <listitem><para>Timer units will automatically have dependencies of type <varname>Requires=</varname> and + <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>Before=</varname> + on <filename>timers.target</filename>, as well as <varname>Conflicts=</varname> and <varname>Before=</varname> on + <filename>shutdown.target</filename> to ensure that they are stopped cleanly prior to system shutdown. Only timer + units involved with early boot or late system shutdown should disable the + <varname>DefaultDependencies=</varname> option.</para></listitem> + + <listitem><para>Timer units + with at least one <varname>OnCalendar=</varname> directive will have an additional <varname>After=</varname> + dependency on <filename>time-sync.target</filename> to avoid being started before the system clock has been + correctly set.</para></listitem> + </itemizedlist> + </refsect2> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>Timer files must include a [Timer] section, which carries + information about the timer it defines. The options specific to + the [Timer] section of timer units are the following:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>OnActiveSec=</varname></term> + <term><varname>OnBootSec=</varname></term> + <term><varname>OnStartupSec=</varname></term> + <term><varname>OnUnitActiveSec=</varname></term> + <term><varname>OnUnitInactiveSec=</varname></term> + + <listitem><para>Defines monotonic timers relative to different + starting points:</para> + + <table> + <title>Settings and their starting points</title> + + <tgroup cols='2'> + <thead> + <row> + <entry>Setting</entry> + <entry>Meaning</entry> + </row> + </thead> + <tbody> + <row> + <entry><varname>OnActiveSec=</varname></entry> + <entry>Defines a timer relative to the moment the timer unit itself is activated.</entry> + </row> + <row> + <entry><varname>OnBootSec=</varname></entry> + <entry>Defines a timer relative to when the machine was booted up. In containers, for the system manager instance, this is mapped to <varname>OnStartupSec=</varname>, making both equivalent.</entry> + </row> + <row> + <entry><varname>OnStartupSec=</varname></entry> + <entry>Defines a timer relative to when the service manager was first started. For system timer units this is very similar to <varname>OnBootSec=</varname> as the system service manager is generally started very early at boot. It's primarily useful when configured in units running in the per-user service manager, as the user service manager is generally started on first login only, not already during boot.</entry> + </row> + <row> + <entry><varname>OnUnitActiveSec=</varname></entry> + <entry>Defines a timer relative to when the unit the timer unit is activating was last activated.</entry> + </row> + <row> + <entry><varname>OnUnitInactiveSec=</varname></entry> + <entry>Defines a timer relative to when the unit the timer unit is activating was last deactivated.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Multiple directives may be combined of the same and of different types, in which case the timer + unit will trigger whenever any of the specified timer expressions elapse. For example, by combining + <varname>OnBootSec=</varname> and <varname>OnUnitActiveSec=</varname>, it is possible to define a + timer that elapses in regular intervals and activates a specific service each time. Moreover, both + monotonic time expressions and <varname>OnCalendar=</varname> calendar expressions may be combined in + the same timer unit.</para> + + <para>The arguments to the directives are time spans + configured in seconds. Example: "OnBootSec=50" means 50s after + boot-up. The argument may also include time units. Example: + "OnBootSec=5h 30min" means 5 hours and 30 minutes after + boot-up. For details about the syntax of time spans, see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>If a timer configured with <varname>OnBootSec=</varname> + or <varname>OnStartupSec=</varname> is already in the past + when the timer unit is activated, it will immediately elapse + and the configured unit is started. This is not the case for + timers defined in the other directives.</para> + + <para>These are monotonic timers, independent of wall-clock time and timezones. If the computer is + temporarily suspended, the monotonic clock generally pauses, too. Note that if + <varname>WakeSystem=</varname> is used, a different monotonic clock is selected that continues to + advance while the system is suspended and thus can be used as the trigger to resume the + system.</para> + + <para>If the empty string is assigned to any of these options, the list of timers is reset (both + monotonic timers and <varname>OnCalendar=</varname> timers, see below), and all prior assignments + will have no effect.</para> + + <para>Note that timers do not necessarily expire at the + precise time configured with these settings, as they are + subject to the <varname>AccuracySec=</varname> setting + below.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><varname>OnCalendar=</varname></term> + + <listitem><para>Defines realtime (i.e. wallclock) timers with + calendar event expressions. See + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for more information on the syntax of calendar event + expressions. Otherwise, the semantics are similar to + <varname>OnActiveSec=</varname> and related settings.</para> + + <para>Note that timers do not necessarily expire at the + precise time configured with this setting, as it is subject to + the <varname>AccuracySec=</varname> setting + below.</para> + + <para>May be specified more than once, in which case the timer unit will trigger whenever any of the + specified expressions elapse. Moreover calendar timers and monotonic timers (see above) may be + combined within the same timer unit.</para> + + <para>If the empty string is assigned to any of these options, the list of timers is reset (both + <varname>OnCalendar=</varname> timers and monotonic timers, see above), and all prior assignments + will have no effect.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>AccuracySec=</varname></term> + + <listitem><para>Specify the accuracy the timer shall elapse + with. Defaults to 1min. The timer is scheduled to elapse + within a time window starting with the time specified in + <varname>OnCalendar=</varname>, + <varname>OnActiveSec=</varname>, + <varname>OnBootSec=</varname>, + <varname>OnStartupSec=</varname>, + <varname>OnUnitActiveSec=</varname> or + <varname>OnUnitInactiveSec=</varname> and ending the time + configured with <varname>AccuracySec=</varname> later. Within + this time window, the expiry time will be placed at a + host-specific, randomized, but stable position that is + synchronized between all local timer units. This is done in + order to optimize power consumption to suppress unnecessary + CPU wake-ups. To get best accuracy, set this option to + 1us. Note that the timer is still subject to the timer slack + configured via + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s + <varname>TimerSlackNSec=</varname> setting. See + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. To optimize power consumption, make sure to set + this value as high as possible and as low as + necessary.</para> + + <para>Note that this setting is primarily a power saving option that allows coalescing CPU + wake-ups. It should not be confused with <varname>RandomizedDelaySec=</varname> (see below) which + adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to + stretch elapsing of timer events over a longer period to reduce workload spikes. For further details + and explanations and how both settings play together, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RandomizedDelaySec=</varname></term> + + <listitem><para>Delay the timer by a randomly selected, evenly distributed amount of time between 0 + and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. + Each timer unit will determine this delay randomly before each iteration, and the delay will simply + be added on top of the next determined elapsing time, unless modified with + <varname>FixedRandomDelay=</varname>, see below.</para> + + <para>This setting is useful to stretch dispatching of similarly configured timer events over a + certain time interval, to prevent them from firing all at the same time, possibly resulting in + resource congestion.</para> + + <para>Note the relation to <varname>AccuracySec=</varname> above: the latter allows the service + manager to coalesce timer events within a specified time range in order to minimize wakeups, while + this setting does the opposite: it stretches timer events over an interval, to make it unlikely that + they fire simultaneously. If <varname>RandomizedDelaySec=</varname> and + <varname>AccuracySec=</varname> are used in conjunction, first the randomized delay is added, and + then the result is possibly further shifted to coalesce it with other timer events happening on the + system. As mentioned above <varname>AccuracySec=</varname> defaults to 1 minute and + <varname>RandomizedDelaySec=</varname> to 0, thus encouraging coalescing of timer events. In order to + optimally stretch timer events over a certain range of time, set + <varname>AccuracySec=1us</varname> and <varname>RandomizedDelaySec=</varname> to some higher value. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FixedRandomDelay=</varname></term> + + <listitem><para>Takes a boolean argument. When enabled, the randomized offset specified by + <varname>RandomizedDelaySec=</varname> is reused for all firings of the same timer. For a given timer + unit, the offset depends on the machine ID, user identifier and timer name, which means that it is + stable between restarts of the manager. This effectively creates a fixed offset for an individual + timer, reducing the jitter in firings of this timer, while still avoiding firing at the same time as + other similarly configured timers.</para> + + <para>This setting has no effect if <varname>RandomizedDelaySec=</varname> is set to 0. Defaults to + <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OnClockChange=</varname></term> + <term><varname>OnTimezoneChange=</varname></term> + + <listitem><para>These options take boolean arguments. When true, the service unit will be triggered + when the system clock (<constant>CLOCK_REALTIME</constant>) jumps relative to the monotonic clock + (<constant>CLOCK_MONOTONIC</constant>), or when the local system timezone is modified. These options + can be used alone or in combination with other timer expressions (see above) within the same timer + unit. These options default to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Unit=</varname></term> + + <listitem><para>The unit to activate when this timer elapses. + The argument is a unit name, whose suffix is not + <literal>.timer</literal>. If not specified, this value + defaults to a service that has the same name as the timer + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + timer unit are named identically, except for the + suffix.</para></listitem> + </varlistentry> + + <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. Such triggering + is nonetheless subject to the delay imposed by <varname>RandomizedDelaySec=</varname>. + 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 + <option>false</option>.</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 + <option>false</option>.</para> + + <para>Note that this functionality requires privileges and is thus generally only available in the + system service manager.</para> + + <para>Note that behaviour of monotonic clock timers (as configured with + <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>, + <varname>OnUnitActiveSec=</varname>, <varname>OnUnitInactiveSec=</varname>, see above) is altered + depending on this option. If false, a monotonic clock is used that is paused during system suspend + (<constant>CLOCK_MONOTONIC</constant>), if true a different monotonic clock is used that continues + advancing during system suspend (<constant>CLOCK_BOOTTIME</constant>), see + <citerefentry><refentrytitle>clock_getres</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemainAfterElapse=</varname></term> + + <listitem><para>Takes a boolean argument. If true, a timer will stay loaded, and its state remains + queryable even after it elapsed and the associated unit (as configured with <varname>Unit=</varname>, + see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded + once its associated unit deactivated again. Turning this off is particularly useful for transient + timer units. Note that this setting has an effect when repeatedly starting a timer unit: if + <varname>RemainAfterElapse=</varname> is on, starting the timer a second time has no effect. However, + if <varname>RemainAfterElapse=</varname> is off and the timer unit was already unloaded, it can be + started again, and thus the service can be triggered multiple times. Defaults to + <option>true</option>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml new file mode 100644 index 0000000..5364c4c --- /dev/null +++ b/man/systemd.unit.xml @@ -0,0 +1,2071 @@ +<?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 % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="systemd.unit" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd.unit</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd.unit</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd.unit</refname> + <refpurpose>Unit configuration</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename><replaceable>service</replaceable>.service</filename>, + <filename><replaceable>socket</replaceable>.socket</filename>, + <filename><replaceable>device</replaceable>.device</filename>, + <filename><replaceable>mount</replaceable>.mount</filename>, + <filename><replaceable>automount</replaceable>.automount</filename>, + <filename><replaceable>swap</replaceable>.swap</filename>, + <filename><replaceable>target</replaceable>.target</filename>, + <filename><replaceable>path</replaceable>.path</filename>, + <filename><replaceable>timer</replaceable>.timer</filename>, + <filename><replaceable>slice</replaceable>.slice</filename>, + <filename><replaceable>scope</replaceable>.scope</filename></para> + + <refsect2> + <title>System Unit Search Path</title> + + <para><literallayout><filename>/etc/systemd/system.control/*</filename> +<filename>/run/systemd/system.control/*</filename> +<filename>/run/systemd/transient/*</filename> +<filename>/run/systemd/generator.early/*</filename> +<filename>/etc/systemd/system/*</filename> +<filename>/etc/systemd/systemd.attached/*</filename> +<filename>/run/systemd/system/*</filename> +<filename>/run/systemd/systemd.attached/*</filename> +<filename>/run/systemd/generator/*</filename> +<filename index='false'>…</filename> +<filename>/usr/lib/systemd/system/*</filename> +<filename>/run/systemd/generator.late/*</filename></literallayout></para> + </refsect2> + + <refsect2> + <title>User Unit Search Path</title> + <para><literallayout><filename>~/.config/systemd/user.control/*</filename> +<filename>$XDG_RUNTIME_DIR/systemd/user.control/*</filename> +<filename>$XDG_RUNTIME_DIR/systemd/transient/*</filename> +<filename>$XDG_RUNTIME_DIR/systemd/generator.early/*</filename> +<filename>$XDG_CONFIG_HOME/systemd/user/*</filename> +<filename>$XDG_CONFIG_DIRS/systemd/user/*</filename> +<filename>/etc/systemd/user/*</filename> +<filename>$XDG_RUNTIME_DIR/systemd/user/*</filename> +<filename>/run/systemd/user/*</filename> +<filename>$XDG_RUNTIME_DIR/systemd/generator/*</filename> +<filename>$XDG_DATA_HOME/systemd/user/*</filename> +<filename>$XDG_DATA_DIRS/systemd/user/*</filename> +<filename index='false'>…</filename> +<filename>/usr/lib/systemd/user/*</filename> +<filename>$XDG_RUNTIME_DIR/systemd/generator.late/*</filename></literallayout></para> + </refsect2> + + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>A unit file is a plain text ini-style file that encodes information about a service, a + socket, a device, a mount point, an automount point, a swap file or partition, a start-up + target, a watched file system path, a timer controlled and supervised by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a + resource management slice or a group of externally created processes. See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + + <para>This man page lists the common configuration options of all + the unit types. These options need to be configured in the [Unit] + or [Install] sections of the unit files.</para> + + <para>In addition to the generic [Unit] and [Install] sections + described here, each unit may have a type-specific section, e.g. + [Service] for a service unit. See the respective man pages for + more information: + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <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>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 + write a warning log message but continue loading the unit. If an + option or section name is prefixed with <option>X-</option>, it is + ignored completely by systemd. Options within an ignored section + 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 + 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>. As another example, <filename>default.target</filename> — + the default system target started at boot — is commonly symlinked (aliased) to either + <filename>multi-user.target</filename> or <filename>graphical.target</filename> to select what is started + by default. Alias names may be used in commands like <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>Aliases obey the following restrictions: a unit of a certain type (<literal>.service</literal>, + <literal>.socket</literal>, …) can only be aliased by a name with the same type suffix. A plain unit (not + a template or an instance), may only be aliased by a plain name. A template instance may only be aliased + by another template instance, and the instance part must be identical. A template may be aliased by + another template (in which case the alias applies to all instances of the template). As a special case, a + template instance (e.g. <literal>alias@inst.service</literal>) may be a symlink to different template + (e.g. <literal>template@inst.service</literal>). In that case, just this specific instance is aliased, + while other instances of the template (e.g. <literal>alias@foo.service</literal>, + <literal>alias@bar.service</literal>) are not aliased. Those rule preserve the requirement that the + instance (if any) is always uniquely defined for a given unit and all its aliases.</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. 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 <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 + directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration + settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section + headers. For instantiated units, this logic will first look for the instance <literal>.d/</literal> subdirectory + (e.g. <literal>foo@bar.service.d/</literal>) and read its <literal>.conf</literal> files, followed by the template + <literal>.d/</literal> subdirectory (e.g. <literal>foo@.service.d/</literal>) and the <literal>.conf</literal> + files there. Moreover for units names containing dashes (<literal>-</literal>), the set of directories generated by + truncating the unit name after all dashes is searched too. Specifically, for a unit name + <filename>foo-bar-baz.service</filename> not only the regular drop-in directory + <filename>foo-bar-baz.service.d/</filename> is searched but also both <filename>foo-bar-.service.d/</filename> and + <filename>foo-.service.d/</filename>. This is useful for defining common drop-ins for a set of related units, whose + names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose + systematic naming structure is built around dashes as component separators. Note that equally named drop-in files + further down the prefix hierarchy override those further up, + i.e. <filename>foo-bar-.service.d/10-override.conf</filename> overrides + <filename>foo-.service.d/10-override.conf</filename>.</para> + + <para>In cases of unit aliases (described above), dropins for the aliased name and all aliases are + loaded. In the example of <filename>default.target</filename> aliasing + <filename>graphical.target</filename>, <filename>default.target.d/</filename>, + <filename>default.target.wants/</filename>, <filename>default.target.requires/</filename>, + <filename>graphical.target.d/</filename>, <filename>graphical.target.wants/</filename>, + <filename>graphical.target.requires/</filename> would all be read. For templates, dropins for the + template, any template aliases, the template instance, and all alias instances are read. When just a + specific template instance is aliased, then the dropins for the target template, the target template + instance, and the alias template instance are read.</para> + + <para>In addition to <filename>/etc/systemd/system</filename>, the drop-in <literal>.d/</literal> + directories for system services can be placed in <filename>/usr/lib/systemd/system</filename> or + <filename>/run/systemd/system</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 unit files wherever located. Multiple drop-in files with different names are applied in + lexicographic order, regardless of which of the directories they reside in.</para> + + <para>Units also support a top-level drop-in with <filename><replaceable>type</replaceable>.d/</filename>, + where <replaceable>type</replaceable> may be e.g. <literal>service</literal> or <literal>socket</literal>, + that allows altering or adding to the settings of all corresponding unit files on the system. + The formatting and precedence of applying drop-in configurations follow what is defined above. + Configurations in <filename><replaceable>type</replaceable>.d/</filename> have the lowest precedence + compared to settings in the name specific override directories. So the contents of + <filename>foo-.service.d/10-override.conf</filename> would override + <filename>service.d/10-override.conf</filename>.</para> + + <para>Note that while systemd offers a flexible dependency system + between units it is recommended to use this functionality only + sparingly and instead rely on techniques such as bus-based or + socket-based activation which make dependencies implicit, + resulting in a both simpler and more flexible system.</para> + + <para>As mentioned above, a unit may be instantiated from a template file. This allows creation + of multiple units from a single configuration file. If systemd looks for a unit configuration + file, it will first search for the literal unit name in the file system. If that yields no + success and the unit name contains an <literal>@</literal> character, systemd will look for a + unit template that shares the same name but with the instance string (i.e. the part between the + <literal>@</literal> character and the suffix) removed. Example: if a service + <filename>getty@tty3.service</filename> is requested and no file by that name is found, systemd + will look for <filename>getty@.service</filename> and instantiate a service from that + configuration file if it is found.</para> + + <para>To refer to the instance string from within the + configuration file you may use the special <literal>%i</literal> + specifier in many of the configuration options. See below for + details.</para> + + <para>If a unit file is empty (i.e. has the file size 0) or is + symlinked to <filename>/dev/null</filename>, its configuration + will not be loaded and it appears with a load state of + <literal>masked</literal>, and cannot be activated. Use this as an + effective way to fully disable a unit, making it impossible to + start it even manually.</para> + + <para>The unit file format is covered by the + <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface + Portability and Stability Promise</ulink>.</para> + + </refsect1> + + <refsect1> + <title>String Escaping for Inclusion in Unit Names</title> + + <para>Sometimes it is useful to convert arbitrary strings into unit names. To facilitate this, a method of string + escaping is used, in order to map strings containing arbitrary byte values (except <constant>NUL</constant>) into + valid unit names and their restricted character set. A common special case are unit names that reflect paths to + objects in the file system hierarchy. Example: a device unit <filename>dev-sda.device</filename> refers to a device + with the device node <filename index="false">/dev/sda</filename> in the file system.</para> + + <para>The escaping algorithm operates as follows: given a string, any <literal>/</literal> character is replaced by + <literal>-</literal>, and all other characters which are not ASCII alphanumerics or <literal>_</literal> are + replaced by C-style <literal>\x2d</literal> escapes. In addition, <literal>.</literal> is replaced with such a + C-style escape when it would appear as the first character in the escaped string.</para> + + <para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the + root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading, + trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example: + <filename index="false">/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para> + + <para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the + unescaping results are different for paths and non-path strings). The + <citerefentry><refentrytitle>systemd-escape</refentrytitle><manvolnum>1</manvolnum></citerefentry> command may be + used to apply and reverse escaping on arbitrary strings. Use <command>systemd-escape --path</command> to escape + path strings, and <command>systemd-escape</command> without <option>--path</option> otherwise.</para> + </refsect1> + + <refsect1> + <title>Automatic dependencies</title> + + <refsect2> + <title>Implicit Dependencies</title> + + <para>A number of unit dependencies are implicitly established, depending on unit type and + unit configuration. These implicit dependencies can make unit configuration file cleaner. For + the implicit dependencies in each unit type, please refer to section "Implicit Dependencies" + in respective man pages.</para> + + <para>For example, service units with <varname>Type=dbus</varname> automatically acquire + dependencies of type <varname>Requires=</varname> and <varname>After=</varname> on + <filename>dbus.socket</filename>. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + </refsect2> + + <refsect2> + <title>Default Dependencies</title> + + <para>Default dependencies are similar to implicit dependencies, but can be turned on and off + by setting <varname>DefaultDependencies=</varname> to <varname>yes</varname> (the default) and + <varname>no</varname>, while implicit dependencies are always in effect. See section "Default + Dependencies" in respective man pages for the effect of enabling + <varname>DefaultDependencies=</varname> in each unit types.</para> + + <para>For example, target units will complement all configured dependencies of type + <varname>Wants=</varname> or <varname>Requires=</varname> with dependencies of type + <varname>After=</varname> unless <varname>DefaultDependencies=no</varname> is set in the + specified units. See + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. Note that this behavior can be turned off by setting + <varname>DefaultDependencies=no</varname>.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Unit File Load Path</title> + + <para>Unit files are loaded from a set of paths determined during + compilation, described in the two tables below. Unit files found + in directories listed earlier override files with the same name in + directories lower in the list.</para> + + <para>When the variable <varname>$SYSTEMD_UNIT_PATH</varname> is set, + the contents of this variable overrides the unit load path. If + <varname>$SYSTEMD_UNIT_PATH</varname> ends with an empty component + (<literal>:</literal>), the usual unit load path will be appended + to the contents of the variable.</para> + + <table> + <title> + Load path when running in system mode (<option>--system</option>). + </title> + + <tgroup cols='2'> + <colspec colname='path' /> + <colspec colname='expl' /> + <thead> + <row> + <entry>Path</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>/etc/systemd/system.control</filename></entry> + <entry morerows="1">Persistent and transient configuration created using the dbus API</entry> + </row> + <row> + <entry><filename>/run/systemd/system.control</filename></entry> + </row> + <row> + <entry><filename>/run/systemd/transient</filename></entry> + <entry>Dynamic configuration for transient units</entry> + </row> + <row> + <entry><filename>/run/systemd/generator.early</filename></entry> + <entry>Generated units with high priority (see <replaceable>early-dir</replaceable> in <citerefentry + ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry><filename>/etc/systemd/system</filename></entry> + <entry>System units created by the administrator</entry> + </row> + <row> + <entry><filename>/run/systemd/system</filename></entry> + <entry>Runtime units</entry> + </row> + <row> + <entry><filename>/run/systemd/generator</filename></entry> + <entry>Generated units with medium priority (see <replaceable>normal-dir</replaceable> in <citerefentry + ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry><filename>/usr/local/lib/systemd/system</filename></entry> + <entry>System units installed by the administrator </entry> + </row> + <row> + <entry><filename>/usr/lib/systemd/system</filename></entry> + <entry>System units installed by the distribution package manager</entry> + </row> + <row> + <entry><filename>/run/systemd/generator.late</filename></entry> + <entry>Generated units with low priority (see <replaceable>late-dir</replaceable> in <citerefentry + ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + </tbody> + </tgroup> + </table> + + <table> + <title> + Load path when running in user mode (<option>--user</option>). + </title> + + <tgroup cols='2'> + <colspec colname='path' /> + <colspec colname='expl' /> + <thead> + <row> + <entry>Path</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry><filename>$XDG_CONFIG_HOME/systemd/user.control</filename> or <filename + >~/.config/systemd/user.control</filename></entry> + <entry morerows="1">Persistent and transient configuration created using the dbus API (<varname>$XDG_CONFIG_HOME</varname> is used if set, <filename>~/.config</filename> otherwise)</entry> + </row> + <row> + <entry><filename>$XDG_RUNTIME_DIR/systemd/user.control</filename></entry> + </row> + <row> + <entry><filename>/run/systemd/transient</filename></entry> + <entry>Dynamic configuration for transient units</entry> + </row> + <row> + <entry><filename>/run/systemd/generator.early</filename></entry> + <entry>Generated units with high priority (see <replaceable>early-dir</replaceable> in <citerefentry + ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename> or <filename>$HOME/.config/systemd/user</filename></entry> + <entry>User configuration (<varname>$XDG_CONFIG_HOME</varname> is used if set, <filename>~/.config</filename> otherwise)</entry> + </row> + <row> + <entry><filename>$XDG_CONFIG_DIRS/systemd/user</filename> or <filename>/etc/xdg/systemd/user</filename></entry> + <entry>Additional configuration directories as specified by the XDG base directory specification (<varname>$XDG_CONFIG_DIRS</varname> is used if set, <filename>/etc/xdg</filename> otherwise)</entry> + </row> + <row> + <entry><filename>/etc/systemd/user</filename></entry> + <entry>User units created by the administrator</entry> + </row> + <row> + <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry> + <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry> + </row> + <row> + <entry><filename>/run/systemd/user</filename></entry> + <entry>Runtime units</entry> + </row> + <row> + <entry><filename>$XDG_RUNTIME_DIR/systemd/generator</filename></entry> + <entry>Generated units with medium priority (see <replaceable>normal-dir</replaceable> in <citerefentry + ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + <row> + <entry><filename>$XDG_DATA_HOME/systemd/user</filename> or <filename>$HOME/.local/share/systemd/user</filename></entry> + <entry>Units of packages that have been installed in the home directory (<varname>$XDG_DATA_HOME</varname> is used if set, <filename>~/.local/share</filename> otherwise)</entry> + </row> + <row> + <entry><filename>$XDG_DATA_DIRS/systemd/user</filename> or <filename>/usr/local/share/systemd/user</filename> and <filename>/usr/share/systemd/user</filename></entry> + <entry>Additional data directories as specified by the XDG base directory specification (<varname>$XDG_DATA_DIRS</varname> is used if set, <filename>/usr/local/share</filename> and <filename>/usr/share</filename> otherwise)</entry> + </row> + <row> + <entry><filename>$dir/systemd/user</filename> for each <varname index="false">$dir</varname> in <varname>$XDG_DATA_DIRS</varname></entry> + <entry>Additional locations for installed user units, one for each entry in <varname>$XDG_DATA_DIRS</varname></entry> + </row> + <row> + <entry><filename>/usr/local/lib/systemd/user</filename></entry> + <entry>User units installed by the administrator</entry> + </row> + <row> + <entry><filename>/usr/lib/systemd/user</filename></entry> + <entry>User units installed by the distribution package manager</entry> + </row> + <row> + <entry><filename>$XDG_RUNTIME_DIR/systemd/generator.late</filename></entry> + <entry>Generated units with low priority (see <replaceable>late-dir</replaceable> in <citerefentry + ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The set of load paths for the user manager instance may be augmented or + changed using various environment variables. And environment variables may in + turn be set using environment generators, see + <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + In particular, <varname>$XDG_DATA_HOME</varname> and + <varname>$XDG_DATA_DIRS</varname> may be easily set using + <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Thus, directories listed here are just the defaults. To see the actual list that + would be used based on compilation options and current environment use + <programlisting>systemd-analyze --user unit-paths</programlisting> + </para> + + <para>Moreover, additional units might be loaded into systemd from + directories not on the unit load path by creating a symlink pointing to a + unit file in the directories. You can use <command>systemctl link</command> + for this operation. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for its usage and precaution. + </para> + </refsect1> + + <refsect1> + <title>Unit Garbage Collection</title> + + <para>The system and service manager loads a unit's configuration automatically when a unit is referenced for the + first time. It will automatically unload the unit configuration and state again when the unit is not needed anymore + ("garbage collection"). A unit may be referenced through a number of different mechanisms:</para> + + <orderedlist> + <listitem><para>Another loaded unit references it with a dependency such as <varname>After=</varname>, + <varname>Wants=</varname>, …</para></listitem> + + <listitem><para>The unit is currently starting, running, reloading or stopping.</para></listitem> + + <listitem><para>The unit is currently in the <constant>failed</constant> state. (But see below.)</para></listitem> + + <listitem><para>A job for the unit is pending.</para></listitem> + + <listitem><para>The unit is pinned by an active IPC client program.</para></listitem> + + <listitem><para>The unit is a special "perpetual" unit that is always active and loaded. Examples for perpetual + units are the root mount unit <filename>-.mount</filename> or the scope unit <filename>init.scope</filename> that + the service manager itself lives in.</para></listitem> + + <listitem><para>The unit has running processes associated with it.</para></listitem> + </orderedlist> + + <para>The garbage collection logic may be altered with the <varname>CollectMode=</varname> option, which allows + configuration whether automatic unloading of units that are in <constant>failed</constant> state is permissible, + see below.</para> + + <para>Note that when a unit's configuration and state is unloaded, all execution results, such as exit codes, exit + signals, resource consumption and other statistics are lost, except for what is stored in the log subsystem.</para> + + <para>Use <command>systemctl daemon-reload</command> or an equivalent command to reload unit configuration while + the unit is already loaded. In this case all configuration settings are flushed out and replaced with the new + configuration (which however might not be in effect immediately), however all runtime state is + saved/restored.</para> + </refsect1> + + <refsect1> + <title>[Unit] Section Options</title> + + <para>The unit file may include a [Unit] section, which carries + generic information about the unit that is not dependent on the + type of unit:</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>Description=</varname></term> + <listitem><para>A human readable name for the unit. This is used by + <command>systemd</command> (and other UIs) as the label for the unit, so this string should + identify the unit rather than describe it, despite the name. <literal>Apache2 Web + Server</literal> is a good example. Bad examples are <literal>high-performance light-weight + HTTP server</literal> (too generic) or <literal>Apache2</literal> (too specific and + meaningless for people who do not know Apache). <command>systemd</command> will use this + string as a noun in status messages (<literal>Starting + <replaceable>description</replaceable>...</literal>, <literal>Started + <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 continuous verb. Bad examples include + <literal>exiting the container</literal> or <literal>updating the database once per + day.</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Documentation=</varname></term> + <listitem><para>A space-separated list of URIs referencing + documentation for this unit or its configuration. Accepted are + only URIs of the types <literal>http://</literal>, + <literal>https://</literal>, <literal>file:</literal>, + <literal>info:</literal>, <literal>man:</literal>. For more + information about the syntax of these URIs, see <citerefentry + project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + The URIs should be listed in order of relevance, starting with + the most relevant. It is a good idea to first reference + documentation that explains what the unit's purpose is, + followed by how it is configured, followed by any other + related documentation. This option may be specified more than + once, in which case the specified list of URIs is merged. If + the empty string is assigned to this option, the list is reset + and all prior assignments will have no + effect.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Wants=</varname></term> + + <listitem><para>Configures requirement dependencies on other units. This option may be specified more + than once or multiple space-separated units may be specified in one option in which case dependencies + for all listed names will be created. Dependencies of this type may also be configured outside of the + unit configuration file by adding a symlink to a <filename>.wants/</filename> directory accompanying + the unit file. For details, see above.</para> + + <para>Units listed in this option will be started if the configuring unit is. However, if the listed + units fail to start or cannot be added to the transaction, this has no impact on the validity of the + transaction as a whole, and this unit will still be started. This is the recommended way to hook + the start-up of one unit to the start-up of another unit.</para> + + <para>Note that requirement dependencies do not influence the order in which services are started or + stopped. This has to be configured independently with the <varname>After=</varname> or + <varname>Before=</varname> options. If unit <filename>foo.service</filename> pulls in unit + <filename>bar.service</filename> as configured with <varname>Wants=</varname> and no ordering is + configured with <varname>After=</varname> or <varname>Before=</varname>, then both units will be + started simultaneously and without any delay between them if <filename>foo.service</filename> is + activated.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Requires=</varname></term> + + <listitem><para>Similar to <varname>Wants=</varname>, but declares a stronger + dependency. Dependencies of this type may also be configured by adding a symlink to a + <filename>.requires/</filename> directory accompanying the unit file.</para> + + <para>If this unit gets activated, the units listed will be activated as well. If one of + the other units fails to activate, and an ordering dependency <varname>After=</varname> on the + failing unit is set, this unit will not be started. Besides, with or without specifying + <varname>After=</varname>, this unit will be stopped if one of the other units is explicitly + stopped.</para> + + <para>Often, it is a better choice to use <varname>Wants=</varname> instead of + <varname>Requires=</varname> in order to achieve a system that is more robust when dealing with + failing services.</para> + + <para>Note that this dependency type does not imply that the other unit always has to be in active state when + this unit is running. Specifically: failing condition checks (such as <varname>ConditionPathExists=</varname>, + <varname>ConditionPathIsSymbolicLink=</varname>, … — see below) do not cause the start job of a unit with a + <varname>Requires=</varname> dependency on it to fail. Also, some unit types may deactivate on their own (for + example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not + propagated to units having a <varname>Requires=</varname> dependency. Use the <varname>BindsTo=</varname> + dependency type together with <varname>After=</varname> to ensure that a unit may never be in active state + without a specific other unit also in active state (see below).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Requisite=</varname></term> + + <listitem><para>Similar to <varname>Requires=</varname>. However, if the units listed here + are not started already, they will not be started and the starting of this unit will fail + immediately. <varname>Requisite=</varname> does not imply an ordering dependency, even if + both units are started in the same transaction. Hence this setting should usually be + combined with <varname>After=</varname>, to ensure this unit is not started before the other + unit.</para> + + <para>When <varname>Requisite=b.service</varname> is used on + <filename>a.service</filename>, this dependency will show as + <varname>RequisiteOf=a.service</varname> in property listing of + <filename>b.service</filename>. <varname>RequisiteOf=</varname> + dependency cannot be specified directly.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>BindsTo=</varname></term> + + <listitem><para>Configures requirement dependencies, very similar in style to + <varname>Requires=</varname>. However, this dependency type is stronger: in addition to the effect of + <varname>Requires=</varname> it declares that if the unit bound to is stopped, this unit will be stopped + too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too. + Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit + might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of + a mount unit might be unmounted without involvement of the system and service manager.</para> + + <para>When used in conjunction with <varname>After=</varname> on the same unit the behaviour of + <varname>BindsTo=</varname> is even stronger. In this case, the unit bound to strictly has to be in active + state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly + enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition + check (such as <varname>ConditionPathExists=</varname>, <varname>ConditionPathIsSymbolicLink=</varname>, … — + see below) will be stopped, should it be running. Hence, in many cases it is best to combine + <varname>BindsTo=</varname> with <varname>After=</varname>.</para> + + <para>When <varname>BindsTo=b.service</varname> is used on + <filename>a.service</filename>, this dependency will show as + <varname>BoundBy=a.service</varname> in property listing of + <filename>b.service</filename>. <varname>BoundBy=</varname> + dependency cannot be specified directly.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PartOf=</varname></term> + + <listitem><para>Configures dependencies similar to + <varname>Requires=</varname>, but limited to stopping and + restarting of units. When systemd stops or restarts the units + listed here, the action is propagated to this unit. Note that + this is a one-way dependency — changes to this unit do not + affect the listed units.</para> + + <para>When <varname>PartOf=b.service</varname> is used on + <filename>a.service</filename>, this dependency will show as + <varname>ConsistsOf=a.service</varname> in property listing of + <filename>b.service</filename>. <varname>ConsistsOf=</varname> + dependency cannot be specified directly.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>Conflicts=</varname></term> + + <listitem><para>A space-separated list of unit names. Configures negative requirement + dependencies. If a unit has a <varname>Conflicts=</varname> setting on another unit, starting the + former will stop the latter and vice versa.</para> + + <para>Note that this setting does not imply an ordering dependency, similarly to the + <varname>Wants=</varname> and <varname>Requires=</varname> dependencies described above. This means + that to ensure that the conflicting unit is stopped before the other unit is started, an + <varname>After=</varname> or <varname>Before=</varname> dependency must be declared. It doesn't + matter which of the two ordering dependencies is used, because stop jobs are always ordered before + start jobs, see the discussion in <varname>Before=</varname>/<varname>After=</varname> below.</para> + + <para>If unit A that conflicts with unit B is scheduled to + be started at the same time as B, the transaction will either + fail (in case both are required parts of the transaction) or be + modified to be fixed (in case one or both jobs are not a + required part of the transaction). In the latter case, the job + that is not required will be removed, or in case both are + not required, the unit that conflicts will be started and the + unit that is conflicted is stopped.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Before=</varname></term> + <term><varname>After=</varname></term> + + <listitem><para>These two settings expect a space-separated list of unit names. They may be specified + more than once, in which case dependencies for all listed names are created.</para> + + <para>Those two settings configure ordering dependencies between units. If unit + <filename>foo.service</filename> contains the setting <option>Before=bar.service</option> and both + units are being started, <filename>bar.service</filename>'s start-up is delayed until + <filename>foo.service</filename> has finished starting up. <varname>After=</varname> is the inverse + of <varname>Before=</varname>, i.e. while <varname>Before=</varname> ensures that the configured unit + is started before the listed unit begins starting up, <varname>After=</varname> ensures the opposite, + that the listed unit is fully started up before the configured unit is started.</para> + + <para>When two units with an ordering dependency between them are shut down, the inverse of the + start-up order is applied. I.e. if a unit is configured with <varname>After=</varname> on another + unit, the former is stopped before the latter if both are shut down. Given two units with any + ordering dependency between them, if one unit is shut down and the other is started up, the shutdown + is ordered before the start-up. It doesn't matter if the ordering dependency is + <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which + of the two is shut down, as long as one is shut down and the other is started up; the shutdown is + ordered before the start-up in all cases. If two units have no ordering dependencies between them, + they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit + type when precisely a unit has finished starting up. Most importantly, for service units start-up is + considered completed for the purpose of <varname>Before=</varname>/<varname>After=</varname> when all + its configured start-up commands have been invoked and they either failed or reported start-up + success. Note that this does includes <varname>ExecStartPost=</varname> (or + <varname>ExecStopPost=</varname> for the shutdown case).</para> + + <para>Note that those settings are independent of and orthogonal to the requirement dependencies as + configured by <varname>Requires=</varname>, <varname>Wants=</varname>, <varname>Requisite=</varname>, + or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both the + <varname>After=</varname> and <varname>Wants=</varname> options, in which case the unit listed will + be started before the unit that is configured with these options.</para> + + <para>Note that <varname>Before=</varname> dependencies on device units have no effect and are not + supported. Devices generally become available as a result of an external hotplug event, and systemd + creates the corresponding device unit without delay.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OnFailure=</varname></term> + + <listitem><para>A space-separated list of one or more units + that are activated when this unit enters the + <literal>failed</literal> state. A service unit using + <varname>Restart=</varname> enters the failed state only after + the start limits are reached.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PropagatesReloadTo=</varname></term> + <term><varname>ReloadPropagatedFrom=</varname></term> + + <listitem><para>A space-separated list of one or more units + where reload requests on this unit will be propagated to, or + reload requests on the other unit will be propagated to this + unit, respectively. Issuing a reload request on a unit will + automatically also enqueue a reload request on all units that + the reload request shall be propagated to via these two + settings.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>JoinsNamespaceOf=</varname></term> + + <listitem><para>For units that start processes (such as service units), lists one or more other units + whose network and/or temporary file namespace to join. This only applies to unit types which support + the <varname>PrivateNetwork=</varname>, <varname>NetworkNamespacePath=</varname> and + <varname>PrivateTmp=</varname> directives (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details). If a unit that has this setting set is started, its processes will see the same + <filename>/tmp/</filename>, <filename>/var/tmp/</filename> and network namespace as one listed unit + that is started. If multiple listed units are already started, it is not defined which namespace is + joined. Note that this setting only has an effect if + <varname>PrivateNetwork=</varname>/<varname>NetworkNamespacePath=</varname> and/or + <varname>PrivateTmp=</varname> is enabled for both the unit that joins the namespace and the unit + whose namespace is joined.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RequiresMountsFor=</varname></term> + + <listitem><para>Takes a space-separated list of absolute + paths. Automatically adds dependencies of type + <varname>Requires=</varname> and <varname>After=</varname> for + all mount units required to access the specified path.</para> + + <para>Mount points marked with <option>noauto</option> are not + mounted automatically through <filename>local-fs.target</filename>, + but are still honored for the purposes of this option, i.e. they + will be pulled in by this unit.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>OnFailureJobMode=</varname></term> + + <listitem><para>Takes a value of + <literal>fail</literal>, + <literal>replace</literal>, + <literal>replace-irreversibly</literal>, + <literal>isolate</literal>, + <literal>flush</literal>, + <literal>ignore-dependencies</literal> or + <literal>ignore-requirements</literal>. Defaults to + <literal>replace</literal>. Specifies how the units listed in + <varname>OnFailure=</varname> will be enqueued. See + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <option>--job-mode=</option> option for details on the + possible values. If this is set to <literal>isolate</literal>, + only a single unit may be listed in + <varname>OnFailure=</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>IgnoreOnIsolate=</varname></term> + + <listitem><para>Takes a boolean argument. If <option>true</option>, this unit will not be stopped + when isolating another unit. Defaults to <option>false</option> for service, target, socket, timer, + and path units, and <option>true</option> for slice, scope, device, swap, mount, and automount + units.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>StopWhenUnneeded=</varname></term> + + <listitem><para>Takes a boolean argument. If + <option>true</option>, this unit will be stopped when it is no + longer used. Note that, in order to minimize the work to be + executed, systemd will not stop units by default unless they + are conflicting with other units, or the user explicitly + requested their shut down. If this option is set, a unit will + be automatically cleaned up if no other active unit requires + it. Defaults to <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RefuseManualStart=</varname></term> + <term><varname>RefuseManualStop=</varname></term> + + <listitem><para>Takes a boolean argument. If + <option>true</option>, this unit can only be activated or + deactivated indirectly. In this case, explicit start-up or + termination requested by the user is denied, however if it is + started or stopped as a dependency of another unit, start-up + or termination will succeed. This is mostly a safety feature + to ensure that the user does not accidentally activate units + that are not intended to be activated explicitly, and not + accidentally deactivate units that are not intended to be + deactivated. These options default to + <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>AllowIsolate=</varname></term> + + <listitem><para>Takes a boolean argument. If + <option>true</option>, this unit may be used with the + <command>systemctl isolate</command> command. Otherwise, this + will be refused. It probably is a good idea to leave this + disabled except for target units that shall be used similar to + runlevels in SysV init systems, just as a precaution to avoid + unusable system states. This option defaults to + <option>false</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultDependencies=</varname></term> + + <listitem><para>Takes a boolean argument. If + <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 + service is started only after basic system initialization is + 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>no</option>. It is highly recommended to + leave this option enabled for the majority of common units. If + set to <option>no</option>, this option does not disable + all implicit dependencies, just non-essential + ones.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>CollectMode=</varname></term> + + <listitem><para>Tweaks the "garbage collection" algorithm for this unit. Takes one of <option>inactive</option> + or <option>inactive-or-failed</option>. If set to <option>inactive</option> the unit will be unloaded if it is + in the <constant>inactive</constant> state and is not referenced by clients, jobs or other units — however it + is not unloaded if it is in the <constant>failed</constant> state. In <option>failed</option> mode, failed + units are not unloaded until the user invoked <command>systemctl reset-failed</command> on them to reset the + <constant>failed</constant> state, or an equivalent command. This behaviour is altered if this option is set to + <option>inactive-or-failed</option>: in this case the unit is unloaded even if the unit is in a + <constant>failed</constant> state, and thus an explicitly resetting of the <constant>failed</constant> state is + not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed + resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging + subsystem. Defaults to <option>inactive</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>FailureAction=</varname></term> + <term><varname>SuccessAction=</varname></term> + + <listitem><para>Configure the action to take when the unit stops and enters a failed state or inactive state. + Takes one of <option>none</option>, <option>reboot</option>, <option>reboot-force</option>, + <option>reboot-immediate</option>, <option>poweroff</option>, <option>poweroff-force</option>, + <option>poweroff-immediate</option>, <option>exit</option>, and <option>exit-force</option>. In system mode, + all options are allowed. In user mode, only <option>none</option>, <option>exit</option>, and + <option>exit-force</option> are allowed. Both options default to <option>none</option>.</para> + + <para>If <option>none</option> is set, no action will be triggered. <option>reboot</option> causes a reboot + following the normal shutdown procedure (i.e. equivalent to <command>systemctl reboot</command>). + <option>reboot-force</option> causes a forced reboot which will terminate all processes forcibly but should + cause no dirty file systems on reboot (i.e. equivalent to <command>systemctl reboot -f</command>) and + <option>reboot-immediate</option> causes immediate execution of the + <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, which + might result in data loss (i.e. equivalent to <command>systemctl reboot -ff</command>). Similarly, + <option>poweroff</option>, <option>poweroff-force</option>, <option>poweroff-immediate</option> have the effect + 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 overridden + with <varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see + below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FailureActionExitStatus=</varname></term> + <term><varname>SuccessActionExitStatus=</varname></term> + + <listitem><para>Controls the exit status to propagate back to an invoking container manager (in case of a + system service) or service manager (in case of a user manager) when the + <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> are set to <option>exit</option> or + <option>exit-force</option> and the action is triggered. By default the exit status of the main process of the + triggering unit (if this applies) is propagated. Takes a value in the range 0…255 or the empty string to + request default behaviour.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>JobTimeoutSec=</varname></term> + <term><varname>JobRunningTimeoutSec=</varname></term> + + <listitem><para>When a job for this unit is queued, a timeout <varname>JobTimeoutSec=</varname> may be + configured. Similarly, <varname>JobRunningTimeoutSec=</varname> starts counting when the queued job is actually + started. If either time limit is reached, the job will be cancelled, the unit however will not change state or + even enter the <literal>failed</literal> mode. This value defaults to <literal>infinity</literal> (job timeouts + disabled), except for device units (<varname>JobRunningTimeoutSec=</varname> defaults to + <varname>DefaultTimeoutStartSec=</varname>). NB: this timeout is independent from any unit-specific timeout + (for example, the timeout set with <varname>TimeoutStartSec=</varname> in service units) as the job timeout has + no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific + timeouts are useful to abort unit state changes, and revert them. The job timeout set with this option however + is useful to abort only the job waiting for the unit state to change.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>JobTimeoutAction=</varname></term> + <term><varname>JobTimeoutRebootArgument=</varname></term> + + <listitem><para><varname>JobTimeoutAction=</varname> optionally configures an additional action to take when + the timeout is hit, see description of <varname>JobTimeoutSec=</varname> and + <varname>JobRunningTimeoutSec=</varname> above. It takes the same values as + <varname>StartLimitAction=</varname>. Defaults to <option>none</option>. + <varname>JobTimeoutRebootArgument=</varname> configures an optional reboot string to pass to the + <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>StartLimitIntervalSec=<replaceable>interval</replaceable></varname></term> + <term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term> + + <listitem><para>Configure unit start rate limiting. Units which are started more than + <replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval are not + permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the checking interval + (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, set it to 0 to + disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many starts per + interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager configuration + file). These configuration options are particularly useful in conjunction with the service setting + <varname>Restart=</varname> (see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>); however, + they apply to all kinds of starts (including manual), not just those triggered by the + <varname>Restart=</varname> logic. Note that units which are configured for <varname>Restart=</varname> and + which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted + manually at a later point, after the <replaceable>interval</replaceable> has passed. From this point on, the + restart logic is activated again. Note that <command>systemctl reset-failed</command> will cause the restart + rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit + and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition + checks are executed, and hence unit activations with failing conditions do not count towards this rate + limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose + activation may either never fail, or may succeed only a single time.</para> + + <para>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are + flushed out too. This means that configuring start rate limiting for a unit that is not referenced continuously + has no effect.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>StartLimitAction=</varname></term> + + <listitem><para>Configure an additional action to take if the rate limit configured with + <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> is hit. Takes the same + values as the <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> settings. If + <option>none</option> is set, hitting the rate limit will trigger no action except that + the start will not be permitted. Defaults to <option>none</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RebootArgument=</varname></term> + <listitem><para>Configure the optional argument for the + <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call if + <varname>StartLimitAction=</varname> or <varname>FailureAction=</varname> is a reboot action. This + works just like the optional argument to <command>systemctl reboot</command> command.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>SourcePath=</varname></term> + <listitem><para>A path to a configuration file this unit has + been generated from. This is primarily useful for + implementation of generator tools that convert configuration + from an external configuration file format into native unit + files. This functionality should not be used in normal + units.</para></listitem> + </varlistentry> + </variablelist> + + <refsect2> + <title>Conditions and Asserts</title> + + <para>Unit files may also include a number of <varname index="false">Condition…=</varname> and + <varname index="false">Assert…=</varname> settings. Before the unit is started, systemd will verify + that the specified conditions are true. If not, the starting of the unit will be (mostly silently) + skipped. Failing conditions will not result in the unit being moved into the <literal>failed</literal> + state. The conditions are checked at the time the queued start job is to be executed. The ordering + dependencies are still respected, so other units are still pulled in and ordered as if this unit was + successfully activated. Use condition expressions in order to skip units that do not apply to the local + system, for example because the kernel or runtime environment doesn't require their functionality. + </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 use a pipe symbol (<literal>|</literal>) after the equals + sign (<literal>Condition…=|…</literal>), which causes the 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. 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> + + <para>The <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options + provide a similar mechanism that causes the job to fail (instead of being skipped). The failed check is + logged. 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>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> + + <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> + + <para>Except for <varname>ConditionPathIsSymbolicLink=</varname>, all path checks follow symlinks.</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>ConditionArchitecture=</varname></term> + + <listitem><para>Check whether the system is running on a specific architecture. Takes one of + <literal>x86</literal>, + <literal>x86-64</literal>, + <literal>ppc</literal>, + <literal>ppc-le</literal>, + <literal>ppc64</literal>, + <literal>ppc64-le</literal>, + <literal>ia64</literal>, + <literal>parisc</literal>, + <literal>parisc64</literal>, + <literal>s390</literal>, + <literal>s390x</literal>, + <literal>sparc</literal>, + <literal>sparc64</literal>, + <literal>mips</literal>, + <literal>mips-le</literal>, + <literal>mips64</literal>, + <literal>mips64-le</literal>, + <literal>alpha</literal>, + <literal>arm</literal>, + <literal>arm-be</literal>, + <literal>arm64</literal>, + <literal>arm64-be</literal>, + <literal>sh</literal>, + <literal>sh64</literal>, + <literal>m68k</literal>, + <literal>tilegx</literal>, + <literal>cris</literal>, + <literal>arc</literal>, + <literal>arc-be</literal>, or + <literal>native</literal>.</para> + + <para>The architecture is determined from the information returned by + <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> + and is thus subject to + <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>. + Note that a <varname>Personality=</varname> setting in the same unit file has no effect on this + condition. A special architecture name <literal>native</literal> is mapped to the architecture the + system manager itself is compiled for. The test may be negated by prepending an exclamation + mark.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionVirtualization=</varname></term> + + <listitem><para>Check whether the system is executed in a virtualized environment and optionally + test whether it is a specific implementation. Takes either boolean value to check if being executed + in any virtualized environment, or one of + <literal>vm</literal> and + <literal>container</literal> to test against a generic type of virtualization solution, or one of + <literal>qemu</literal>, + <literal>kvm</literal>, + <literal>zvm</literal>, + <literal>vmware</literal>, + <literal>microsoft</literal>, + <literal>oracle</literal>, + <literal>powervm</literal>, + <literal>xen</literal>, + <literal>bochs</literal>, + <literal>uml</literal>, + <literal>bhyve</literal>, + <literal>qnx</literal>, + <literal>openvz</literal>, + <literal>lxc</literal>, + <literal>lxc-libvirt</literal>, + <literal>systemd-nspawn</literal>, + <literal>docker</literal>, + <literal>podman</literal>, + <literal>rkt</literal>, + <literal>wsl</literal>, + <literal>proot</literal>, + <literal>pouch</literal>, + <literal>acrn</literal> to test + against a specific implementation, or + <literal>private-users</literal> to check whether we are running in a user namespace. See + <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for a full list of known virtualization technologies and their identifiers. If multiple + virtualization technologies are nested, only the innermost is considered. The test may be negated + by prepending an exclamation mark.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionHost=</varname></term> + + <listitem><para><varname>ConditionHost=</varname> may be used to match against the hostname or + machine ID of the host. This either takes a hostname string (optionally with shell style globs) + which is tested against the locally set hostname as returned by + <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>, or + a machine ID formatted as string (see + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + The test may be negated by prepending an exclamation mark.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionKernelCommandLine=</varname></term> + + <listitem><para><varname>ConditionKernelCommandLine=</varname> may be used to check whether a + specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The + argument must either be a single word, or an assignment (i.e. two words, separated by + <literal>=</literal>). In the former case the kernel command line is searched for the word + appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is + looked for with right and left hand side matching. This operates on the kernel command line + communicated to userspace via <filename>/proc/cmdline</filename>, except when the service manager + is invoked as payload of a container manager, in which case the command line of <filename>PID + 1</filename> is used instead (i.e. <filename>/proc/1/cmdline</filename>).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionKernelVersion=</varname></term> + + <listitem><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 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 kernels into older versions provided by distributions. Hence, this check + is inherently unportable and should not be used for units which may be used on different + distributions.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionEnvironment=</varname></term> + + <listitem><para><varname>ConditionEnvironment=</varname> may be used to check whether a specific + environment variable is set (or if prefixed with the exclamation mark — unset) in the service + manager's environment block. + + The argument may be a single word, to check if the variable with this name is defined in the + environment block, or an assignment + (<literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>), to check if + the variable with this exact value is defined. Note that the environment block of the service + manager itself is checked, i.e. not any variables defined with <varname>Environment=</varname> or + <varname>EnvironmentFile=</varname>, as described above. This is particularly useful when the + service manager runs inside a containerized environment or as per-user service manager, in order to + check for variables passed in by the enclosing container manager or PAM.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionSecurity=</varname></term> + + <listitem><para><varname>ConditionSecurity=</varname> may be used to check whether the given + security technology is enabled on the system. Currently, the recognized values are + <literal>selinux</literal>, <literal>apparmor</literal>, <literal>tomoyo</literal>, + <literal>ima</literal>, <literal>smack</literal>, <literal>audit</literal> and + <literal>uefi-secureboot</literal>. The test may be negated by prepending an exclamation + mark.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionCapability=</varname></term> + + <listitem><para>Check whether the given capability exists in the capability bounding set of the + service manager (i.e. this does not check whether capability is actually available in the permitted + or effective sets, see + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details). Pass a capability name such as <literal>CAP_MKNOD</literal>, possibly prefixed with + an exclamation mark to negate the check.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionACPower=</varname></term> + + <listitem><para>Check whether the system has AC power, or is exclusively battery powered at the + time of activation of the unit. This takes a boolean argument. If set to <literal>true</literal>, + the condition will hold only if at least one AC connector of the system is connected to a power + source, or if no AC connectors are known. Conversely, if set to <literal>false</literal>, the + condition will hold only if there is at least one AC connector known and all AC connectors are + disconnected from a power source.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionNeedsUpdate=</varname></term> + + <listitem><para>Takes one of <filename>/var/</filename> or <filename>/etc/</filename> as argument, + possibly prefixed with a <literal>!</literal> (to invert the condition). This condition may be + used to conditionalize units on whether the specified directory requires an update because + <filename>/usr/</filename>'s modification time is newer than the stamp file + <filename>.updated</filename> in the specified directory. This is useful to implement offline + updates of the vendor operating system resources in <filename>/usr/</filename> that require updating + of <filename>/etc/</filename> or <filename>/var/</filename> on the next following boot. Units making + use of this condition should order themselves before + <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + to make sure they run before the stamp file's modification time gets reset indicating a completed + update.</para> + + <para>If the <varname>systemd.condition-needs-update=</varname> option is specified on the kernel + command line (taking a boolean), it will override the result of this condition check, taking + precedence over any file modification time checks. If it is used + <filename>systemd-update-done.service</filename> will not have immediate effect on any following + <varname>ConditionNeedsUpdate=</varname> checks, until the system is rebooted where the kernel + command line option is not specified anymore.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionFirstBoot=</varname></term> + + <listitem><para>Takes a boolean argument. This condition may be used to conditionalize units on + whether the system is booting up for the first time. This roughly means that <filename>/etc/</filename> + is unpopulated (for details, see "First Boot Semantics" in + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + This may be used to populate <filename>/etc/</filename> on the first boot after factory reset, or + when a new system instance boots up for the first time.</para> + + <para>For robustness, units with <varname>ConditionFirstBoot=yes</varname> should order themselves + before <filename>first-boot-complete.target</filename> and pull in this passive target with + <varname>Wants=</varname>. This ensures that in a case of an aborted first boot, these units will + be re-run during the next system startup.</para> + + <para>If the <varname>systemd.condition-first-boot=</varname> option is specified on the kernel + command line (taking a boolean), it will override the result of this condition check, taking + precedence over <filename>/etc/machine-id</filename> existence checks.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathExists=</varname></term> + + <listitem><para>Check for the exists of a file. If the specified absolute path name does not exist, + the condition will fail. If the absolute path name passed to + <varname>ConditionPathExists=</varname> is prefixed with an exclamation mark + (<literal>!</literal>), the test is negated, and the unit is only started if the path does not + exist.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathExistsGlob=</varname></term> + + <listitem><para><varname>ConditionPathExistsGlob=</varname> is similar to + <varname>ConditionPathExists=</varname>, but checks for the existence of at least one file or + directory matching the specified globbing pattern.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathIsDirectory=</varname></term> + + <listitem><para><varname>ConditionPathIsDirectory=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a + directory.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathIsSymbolicLink=</varname></term> + + <listitem><para><varname>ConditionPathIsSymbolicLink=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a symbolic + link.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathIsMountPoint=</varname></term> + + <listitem><para><varname>ConditionPathIsMountPoint=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a mount + point.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathIsReadWrite=</varname></term> + + <listitem><para><varname>ConditionPathIsReadWrite=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that the underlying file system is readable + and writable (i.e. not mounted read-only).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionPathIsEncrypted=</varname></term> + + <listitem><para><varname>ConditionPathIsEncrypted=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that the underlying file system's backing + block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4 + per-directory encryption, and only detects block level encryption. Moreover, if the specified path + resides on a file system on top of a loopback block device, only encryption above the loopback device is + detected. It is not detected whether the file system backing the loopback block device is encrypted.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionDirectoryNotEmpty=</varname></term> + + <listitem><para><varname>ConditionDirectoryNotEmpty=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a non-empty + directory.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionFileNotEmpty=</varname></term> + + <listitem><para><varname>ConditionFileNotEmpty=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that a certain path exists and refers to a + regular file with a non-zero size.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionFileIsExecutable=</varname></term> + + <listitem><para><varname>ConditionFileIsExecutable=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies that a certain path exists, is a regular file, + and marked executable.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionUser=</varname></term> + + <listitem><para><varname>ConditionUser=</varname> takes a numeric <literal>UID</literal>, a UNIX + user name, or the special value <literal>@system</literal>. This condition may be used to check + whether the service manager is running as the given user. The special value + <literal>@system</literal> can be used to check if the user id is within the system user + range. This option is not useful for system services, as the system manager exclusively runs as the + root user, and thus the test result is constant.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionGroup=</varname></term> + + <listitem><para><varname>ConditionGroup=</varname> is similar to <varname>ConditionUser=</varname> + but verifies that the service manager's real or effective group, or any of its auxiliary groups, + match the specified group or GID. This setting does not support the special value + <literal>@system</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionControlGroupController=</varname></term> + + <listitem><para>Verify that the given cgroup controller (eg. <literal>cpu</literal>) is available + for use on the system. For example, a particular controller may not be available if it was disabled + on the kernel command line with <varname>cgroup_disable=controller</varname>. Multiple controllers + may be passed with a space separating them; in this case the condition will only pass if all listed + controllers are available for use. Controllers unknown to systemd are ignored. Valid controllers + are <literal>cpu</literal>, <literal>cpuacct</literal>, <literal>io</literal>, + <literal>blkio</literal>, <literal>memory</literal>, <literal>devices</literal>, and + <literal>pids</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionMemory=</varname></term> + + <listitem><para>Verify that the specified amount of system memory is available to the current + system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator + <literal><</literal>, <literal><=</literal>, <literal>=</literal>, <literal>!=</literal>, + <literal>>=</literal>, <literal>></literal>. On bare-metal systems compares the amount of + physical memory in the system with the specified size, adhering to the specified comparison + operator. In containers compares the amount of memory assigned to the container instead.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ConditionCPUs=</varname></term> + + <listitem><para>Verify that the specified number of CPUs is available to the current system. Takes + a number of CPUs as argument, optionally prefixed with a comparison operator + <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 + 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></listitem> + </varlistentry> + + <varlistentry> + <term><varname>AssertArchitecture=</varname></term> + <term><varname>AssertVirtualization=</varname></term> + <term><varname>AssertHost=</varname></term> + <term><varname>AssertKernelCommandLine=</varname></term> + <term><varname>AssertKernelVersion=</varname></term> + <term><varname>AssertSecurity=</varname></term> + <term><varname>AssertCapability=</varname></term> + <term><varname>AssertACPower=</varname></term> + <term><varname>AssertNeedsUpdate=</varname></term> + <term><varname>AssertFirstBoot=</varname></term> + <term><varname>AssertPathExists=</varname></term> + <term><varname>AssertPathExistsGlob=</varname></term> + <term><varname>AssertPathIsDirectory=</varname></term> + <term><varname>AssertPathIsSymbolicLink=</varname></term> + <term><varname>AssertPathIsMountPoint=</varname></term> + <term><varname>AssertPathIsReadWrite=</varname></term> + <term><varname>AssertDirectoryNotEmpty=</varname></term> + <term><varname>AssertFileNotEmpty=</varname></term> + <term><varname>AssertFileIsExecutable=</varname></term> + <term><varname>AssertUser=</varname></term> + <term><varname>AssertGroup=</varname></term> + <term><varname>AssertControlGroupController=</varname></term> + + <listitem><para>Similar to the <varname>ConditionArchitecture=</varname>, + <varname>ConditionVirtualization=</varname>, …, condition settings described above, these settings + add assertion checks to the start-up of the unit. However, unlike the conditions settings, any + assertion setting that is not met results in failure of the start job (which means this is logged + loudly). Note that hitting a configured assertion does not cause the unit to enter the + <literal>failed</literal> state (or in fact result in any state change of the unit), it affects + only the job queued for it. Use assertion expressions for units that cannot operate when specific + requirements are not met, and when this is something the administrator or user should look + into.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Mapping of unit properties to their inverses</title> + + <para>Unit settings that create a relationship with a second unit usually show up + in properties of both units, for example in <command>systemctl show</command> + output. In some cases the name of the property is the same as the name of the + configuration setting, but not always. This table lists the properties + that are shown on two units which are connected through some dependency, and shows + which property on "source" unit corresponds to which property on the "target" unit. + </para> + + <table> + <title> + "Forward" and "reverse" unit properties + </title> + + <tgroup cols='4'> + <colspec colname='forward' /> + <colspec colname='reverse' /> + <colspec colname='fuse' /> + <colspec colname='ruse' /> + <thead> + <row> + <entry>"Forward" property</entry> + <entry>"Reverse" property</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' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry> + </row> + <row> + <entry><varname>After=</varname></entry> + <entry><varname>Before=</varname></entry> + </row> + <row> + <entry><varname>Requires=</varname></entry> + <entry><varname>RequiredBy=</varname></entry> + <entry>[Unit] section</entry> + <entry>[Install] section</entry> + </row> + <row> + <entry><varname>Wants=</varname></entry> + <entry><varname>WantedBy=</varname></entry> + <entry>[Unit] section</entry> + <entry>[Install] section</entry> + </row> + <row> + <entry><varname>PartOf=</varname></entry> + <entry><varname>ConsistsOf=</varname></entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> + </row> + <row> + <entry><varname>BindsTo=</varname></entry> + <entry><varname>BoundBy=</varname></entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> + </row> + <row> + <entry><varname>Requisite=</varname></entry> + <entry><varname>RequisiteOf=</varname></entry> + <entry>[Unit] section</entry> + <entry>an automatic property</entry> + </row> + <row> + <entry><varname>Triggers=</varname></entry> + <entry><varname>TriggeredBy=</varname></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>[Unit] section</entry> + <entry>an automatic property</entry> + </row> + <row> + <entry><varname>PropagatesReloadTo=</varname></entry> + <entry><varname>ReloadPropagatedFrom=</varname></entry> + <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry> + </row> + <row> + <entry><varname>ReloadPropagatedFrom=</varname></entry> + <entry><varname>PropagatesReloadTo=</varname></entry> + </row> + <row> + <entry><varname>Following=</varname></entry> + <entry>n/a</entry> + <entry>An automatic property</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Note: <varname>WantedBy=</varname> and <varname>RequiredBy=</varname> are + used in the [Install] section to create symlinks in <filename>.wants/</filename> + and <filename>.requires/</filename> directories. They cannot be used directly as a + unit configuration setting.</para> + + <para>Note: <varname>ConsistsOf=</varname>, <varname>BoundBy=</varname>, + <varname>RequisiteOf=</varname>, <varname>ConflictedBy=</varname> are created + implicitly along with their reverses and cannot be specified directly.</para> + + <para>Note: <varname>Triggers=</varname> is created implicitly between a socket, + path unit, or an automount unit, and the unit they activate. By default a unit + with the same name is triggered, but this can be overridden using + <varname>Sockets=</varname>, <varname>Service=</varname>, and <varname>Unit=</varname> + settings. See + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + and + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. <varname>TriggeredBy=</varname> is created implicitly on the + triggered unit.</para> + + <para>Note: <varname>Following=</varname> is used to group device aliases and points to the + "primary" device unit that systemd is using to track device state, usually corresponding to a + sysfs path. It does not show up in the "target" unit.</para> + </refsect1> + + <refsect1> + <title>[Install] Section Options</title> + + <para>Unit files may include an [Install] section, which carries installation information for + the unit. This section is not interpreted by + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> during runtime; it is + used by the <command>enable</command> and <command>disable</command> commands of the + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool during + installation of a unit.</para> + + <variablelist class='unit-directives'> + <varlistentry> + <term><varname>Alias=</varname></term> + + <listitem><para>A space-separated list of additional names this unit shall be installed under. The names listed + here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once, + in which case all listed names are used. At installation time, <command>systemctl enable</command> will create + symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this + setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support + aliasing.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WantedBy=</varname></term> + <term><varname>RequiredBy=</varname></term> + + <listitem><para>This option may be used more than once, or a + space-separated list of unit names may be given. A symbolic + link is created in the <filename>.wants/</filename> or + <filename>.requires/</filename> directory of each of the + listed units when this unit is installed by <command>systemctl + enable</command>. This has the effect that a dependency of + type <varname>Wants=</varname> or <varname>Requires=</varname> + is added from the listed unit to the current unit. The primary + result is that the current unit will be started when the + listed unit is started. See the description of + <varname>Wants=</varname> and <varname>Requires=</varname> in + the [Unit] section for details.</para> + + <para><command>WantedBy=foo.service</command> in a service + <filename>bar.service</filename> is mostly equivalent to + <command>Alias=foo.service.wants/bar.service</command> in the + same file. In case of template units, <command>systemctl + enable</command> must be called with an instance name, and + this instance will be added to the + <filename>.wants/</filename> or + <filename>.requires/</filename> list of the listed unit. E.g. + <command>WantedBy=getty.target</command> in a service + <filename>getty@.service</filename> will result in + <command>systemctl enable getty@tty2.service</command> + creating a + <filename>getty.target.wants/getty@tty2.service</filename> + link to <filename>getty@.service</filename>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Also=</varname></term> + + <listitem><para>Additional units to install/deinstall when + this unit is installed/deinstalled. If the user requests + installation/deinstallation of a unit with this option + configured, <command>systemctl enable</command> and + <command>systemctl disable</command> will automatically + install/uninstall units listed in this option as well.</para> + + <para>This option may be used more than once, or a + space-separated list of unit names may be + given.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>DefaultInstance=</varname></term> + + <listitem><para>In template unit files, this specifies for + which instance the unit shall be enabled if the template is + enabled without any explicitly set instance. This option has + no effect in non-template unit files. The specified string + must be usable as instance identifier.</para></listitem> + </varlistentry> + </variablelist> + + <para>The following specifiers are interpreted in the Install section: + %a, %b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%. + For their meaning see the next section.</para> + </refsect1> + + <refsect1> + <title>Specifiers</title> + + <para>Many settings resolve specifiers which may be used to write + generic unit files referring to runtime or unit parameters that + are replaced when the unit files are loaded. Specifiers must be known + and resolvable for the setting to be valid. The following + specifiers are understood:</para> + + <table class='specifiers'> + <title>Specifiers available in unit files</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="spec" /> + <colspec colname="mean" /> + <colspec colname="detail" /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Meaning</entry> + <entry>Details</entry> + </row> + </thead> + <tbody> + <row> + <!-- We do not use the common definition from standard-specifiers.xml here since it includes a + reference onto our own man page, which would make the rendered version self-referential. --> + <entry><literal>%a</literal></entry> + <entry>Architecture</entry> + <entry>A short string identifying the architecture of the local system. A string such as <constant>x86</constant>, <constant>x86-64</constant> or <constant>arm64</constant>. See the architectures defined for <varname>ConditionArchitecture=</varname> above for a full list.</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="b"/> + <xi:include href="standard-specifiers.xml" xpointer="B"/> + <row> + <entry><literal>%C</literal></entry> + <entry>Cache directory root</entry> + <entry>This is either <filename>/var/cache</filename> (for the system manager) or the path <literal>$XDG_CACHE_HOME</literal> resolves to (for user managers).</entry> + </row> + <row> + <entry><literal>%E</literal></entry> + <entry>Configuration directory root</entry> + <entry>This is either <filename>/etc/</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to (for user managers).</entry> + </row> + <row> + <entry><literal>%f</literal></entry> + <entry>Unescaped filename</entry> + <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the unescaped prefix name prepended with <filename>/</filename>. This implements unescaping according to the rules for escaping absolute file system paths discussed above.</entry> + </row> + <row> + <entry><literal>%g</literal></entry> + <entry>User group</entry> + <entry>This is the name of the group running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry> + </row> + <row> + <entry><literal>%G</literal></entry> + <entry>User GID</entry> + <entry>This is the numeric GID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry> + </row> + <row> + <entry><literal>%h</literal></entry> + <entry>User home directory</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> + <!-- We do not use the common definition from standard-specifiers.xml here since we want a + slightly more verbose explanation here, referring to the reload cycle. --> + <entry><literal>%H</literal></entry> + <entry>Host name</entry> + <entry>The hostname of the running system at the point in time the unit configuration is loaded.</entry> + </row> + <row> + <entry><literal>%i</literal></entry> + <entry>Instance name</entry> + <entry>For instantiated units this is the string between the first <literal>@</literal> character and the type suffix. Empty for non-instantiated units.</entry> + </row> + <row> + <entry><literal>%I</literal></entry> + <entry>Unescaped instance name</entry> + <entry>Same as <literal>%i</literal>, but with escaping undone.</entry> + </row> + <row> + <entry><literal>%j</literal></entry> + <entry>Final component of the prefix</entry> + <entry>This is the string between the last <literal>-</literal> and the end of the prefix name. If there is no <literal>-</literal>, this is the same as <literal>%p</literal>.</entry> + </row> + <row> + <entry><literal>%J</literal></entry> + <entry>Unescaped final component of the prefix</entry> + <entry>Same as <literal>%j</literal>, but with escaping undone.</entry> + </row> + <row> + <entry><literal>%l</literal></entry> + <entry>Short host name</entry> + <entry>The hostname of the running system at the point in time the unit configuration is loaded, truncated at the first dot to remove any domain component.</entry> + </row> + <row> + <entry><literal>%L</literal></entry> + <entry>Log directory root</entry> + <entry>This is either <filename>/var/log</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to with <filename index="false">/log</filename> appended (for user managers).</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="m"/> + <row> + <entry><literal>%n</literal></entry> + <entry>Full unit name</entry> + <entry></entry> + </row> + <row> + <entry><literal>%N</literal></entry> + <entry>Full unit name</entry> + <entry>Same as <literal>%n</literal>, but with the type suffix removed.</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="o"/> + <row> + <entry><literal>%p</literal></entry> + <entry>Prefix name</entry> + <entry>For instantiated units, this refers to the string before the first <literal>@</literal> character of the unit name. For non-instantiated units, same as <literal>%N</literal>.</entry> + </row> + <row> + <entry><literal>%P</literal></entry> + <entry>Unescaped prefix name</entry> + <entry>Same as <literal>%p</literal>, but with escaping undone.</entry> + </row> + <row> + <entry><literal>%s</literal></entry> + <entry>User shell</entry> + <entry>This is the shell of the user running the service manager instance. In case of the system manager this resolves to <literal>/bin/sh</literal>.</entry> + </row> + <row> + <entry><literal>%S</literal></entry> + <entry>State directory root</entry> + <entry>This is either <filename>/var/lib</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to (for user managers).</entry> + </row> + <row> + <entry><literal>%t</literal></entry> + <entry>Runtime directory root</entry> + <entry>This is either <filename>/run/</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="T"/> + <row> + <entry><literal>%u</literal></entry> + <entry>User name</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 <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> + <xi:include href="standard-specifiers.xml" xpointer="v"/> + <xi:include href="standard-specifiers.xml" xpointer="V"/> + <xi:include href="standard-specifiers.xml" xpointer="w"/> + <xi:include href="standard-specifiers.xml" xpointer="W"/> + <xi:include href="standard-specifiers.xml" xpointer="percent"/> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Examples</title> + + <example> + <title>Allowing units to be enabled</title> + + <para>The following snippet (highlighted) allows a unit (e.g. + <filename>foo.service</filename>) to be enabled via + <command>systemctl enable</command>:</para> + + <programlisting>[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +<emphasis>[Install]</emphasis> +<emphasis>WantedBy=multi-user.target</emphasis></programlisting> + + <para>After running <command>systemctl enable</command>, a + symlink + <filename index="false">/etc/systemd/system/multi-user.target.wants/foo.service</filename> + linking to the actual unit will be created. It tells systemd to + pull in the unit when starting + <filename>multi-user.target</filename>. The inverse + <command>systemctl disable</command> will remove that symlink + again.</para> + </example> + + <example> + <title>Overriding vendor settings</title> + + <para>There are two methods of overriding vendor settings in + unit files: copying the unit file from + <filename>/usr/lib/systemd/system</filename> to + <filename>/etc/systemd/system</filename> and modifying the + chosen settings. Alternatively, one can create a directory named + <filename><replaceable>unit</replaceable>.d/</filename> within + <filename>/etc/systemd/system</filename> and place a drop-in + file <filename><replaceable>name</replaceable>.conf</filename> + there that only changes the specific settings one is interested + in. Note that multiple such drop-in files are read if + present, processed in lexicographic order of their filename.</para> + + <para>The advantage of the first method is that one easily + overrides the complete unit, the vendor unit is not parsed at + all anymore. It has the disadvantage that improvements to the + unit file by the vendor are not automatically incorporated on + updates.</para> + + <para>The advantage of the second method is that one only + overrides the settings one specifically wants, where updates to + the unit by the vendor automatically apply. This has the + disadvantage that some future updates by the vendor might be + incompatible with the local changes.</para> + + <para>This also applies for user instances of systemd, but with + different locations for the unit files. See the section on unit + load paths for further details.</para> + + <para>Suppose there is a vendor-supplied unit + <filename>/usr/lib/systemd/system/httpd.service</filename> with + the following contents:</para> + + <programlisting>[Unit] +Description=Some HTTP server +After=remote-fs.target sqldb.service +Requires=sqldb.service +AssertPathExists=/srv/webserver + +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +Nice=5 + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Now one wants to change some settings as an administrator: + firstly, in the local setup, <filename>/srv/webserver</filename> + might not exist, because the HTTP server is configured to use + <filename>/srv/www</filename> instead. Secondly, the local + configuration makes the HTTP server also depend on a memory + cache service, <filename>memcached.service</filename>, that + should be pulled in (<varname>Requires=</varname>) and also be + ordered appropriately (<varname>After=</varname>). Thirdly, in + order to harden the service a bit more, the administrator would + like to set the <varname>PrivateTmp=</varname> setting (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details). And lastly, the administrator would like to reset + the niceness of the service to its default value of 0.</para> + + <para>The first possibility is to copy the unit file to + <filename>/etc/systemd/system/httpd.service</filename> and + change the chosen settings:</para> + + <programlisting>[Unit] +Description=Some HTTP server +After=remote-fs.target sqldb.service <emphasis>memcached.service</emphasis> +Requires=sqldb.service <emphasis>memcached.service</emphasis> +AssertPathExists=<emphasis>/srv/www</emphasis> + +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +<emphasis>Nice=0</emphasis> +<emphasis>PrivateTmp=yes</emphasis> + +[Install] +WantedBy=multi-user.target</programlisting> + + <para>Alternatively, the administrator could create a drop-in + file + <filename>/etc/systemd/system/httpd.service.d/local.conf</filename> + with the following contents:</para> + + <programlisting>[Unit] +After=memcached.service +Requires=memcached.service +# Reset all assertions and then re-add the condition we want +AssertPathExists= +AssertPathExists=/srv/www + +[Service] +Nice=0 +PrivateTmp=yes</programlisting> + + <para>Note that for drop-in files, if one wants to remove + entries from a setting that is parsed as a list (and is not a + dependency), such as <varname>AssertPathExists=</varname> (or + e.g. <varname>ExecStart=</varname> in service units), one needs + to first clear the list before re-adding all entries except the + one that is to be removed. Dependencies (<varname>After=</varname>, etc.) + cannot be reset to an empty list, so dependencies can only be + added in drop-ins. If you want to remove dependencies, you have + to override the entire unit.</para> + + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.xml b/man/systemd.xml new file mode 100644 index 0000000..882b5a6 --- /dev/null +++ b/man/systemd.xml @@ -0,0 +1,1269 @@ +<?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-or-later --> + +<refentry id="systemd" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>systemd</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>systemd</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>systemd</refname> + <refname>init</refname> + <refpurpose>systemd system and service manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>/usr/lib/systemd/systemd</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>init</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>systemd is a system and service manager for Linux operating systems. When run as first process on + boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate + instances are started for logged-in users to start their services.</para> + + <para><command>systemd</command> is usually not invoked directly by the user, but is installed as the + <filename>/sbin/init</filename> symlink and started during early boot. The user manager instances are + started automatically through the + <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + service.</para> + + <para>For compatibility with SysV, if the binary is called as <command>init</command> and is not the + first process on the machine (PID is not 1), it will execute <command>telinit</command> and pass all + command line arguments unmodified. That means <command>init</command> and <command>telinit</command> are + mostly equivalent when invoked from normal login sessions. See + <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more + information.</para> + + <para>When run as a system instance, systemd interprets the + configuration file <filename>system.conf</filename> and the files + in <filename>system.conf.d</filename> directories; when run as a + user instance, systemd interprets the configuration file + <filename>user.conf</filename> and the files in + <filename>user.conf.d</filename> directories. See + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information.</para> + </refsect1> + + <refsect1> + <title>Concepts</title> + + <para>systemd provides a dependency system between various + entities called "units" of 11 different types. Units encapsulate + various objects that are relevant for system boot-up and + maintenance. The majority of units are configured in unit + configuration files, whose syntax and basic set of options is + described in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + however some are created automatically from other configuration, + dynamically from system state or programmatically at runtime. + Units may be "active" (meaning started, bound, plugged in, …, + depending on the unit type, see below), or "inactive" (meaning + stopped, unbound, unplugged, …), as well as in the process of + being activated or deactivated, i.e. between the two states (these + states are called "activating", "deactivating"). A special + "failed" state is available as well, which is very similar to + "inactive" and is entered when the service failed in some way + (process returned error code on exit, or crashed, an operation + timed out, or after too many restarts). If this state is entered, + the cause will be logged, for later reference. Note that the + various unit types may have a number of additional substates, + which are mapped to the five generalized unit states described + here.</para> + + <para>The following unit types are available:</para> + + <orderedlist> + <listitem><para>Service units, which start and control daemons + and the processes they consist of. For details, see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Socket units, which encapsulate local IPC or + network sockets in the system, useful for socket-based + activation. For details about socket units, see + <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + for details on socket-based activation and other forms of + activation, see + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Target units are useful to group units, or + provide well-known synchronization points during boot-up, see + <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Device units expose kernel devices in systemd + and may be used to implement device-based activation. For + details, see + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Mount units control mount points in the file + system, for details see + <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Automount units provide automount capabilities, + for on-demand mounting of file systems as well as parallelized + boot-up. See + <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Timer units are useful for triggering activation + of other units based on timers. You may find details in + <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Swap units are very similar to mount units and + encapsulate memory swap partitions or files of the operating + system. They are described in + <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Path units may be used to activate other + services when file system objects change or are modified. See + <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Slice units may be used to group units which + manage system processes (such as service and scope units) in a + hierarchical tree for resource management purposes. See + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + <listitem><para>Scope units are similar to service units, but + manage foreign processes instead of starting them as well. See + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + + </orderedlist> + + <para>Units are named as their configuration files. Some units + have special semantics. A detailed list is available in + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>systemd knows various kinds of dependencies, including + positive and negative requirement dependencies (i.e. + <varname>Requires=</varname> and <varname>Conflicts=</varname>) as + well as ordering dependencies (<varname>After=</varname> and + <varname>Before=</varname>). NB: ordering and requirement + dependencies are orthogonal. If only a requirement dependency + exists between two units (e.g. <filename>foo.service</filename> + requires <filename>bar.service</filename>), but no ordering + dependency (e.g. <filename>foo.service</filename> after + <filename>bar.service</filename>) and both are requested to start, + they will be started in parallel. It is a common pattern that both + requirement and ordering dependencies are placed between two + units. Also note that the majority of dependencies are implicitly + created and maintained by systemd. In most cases, it should be + unnecessary to declare additional dependencies manually, however + it is possible to do this.</para> + + <para>Application programs and units (via dependencies) may + request state changes of units. In systemd, these requests are + encapsulated as 'jobs' and maintained in a job queue. Jobs may + succeed or can fail, their execution is ordered based on the + ordering dependencies of the units they have been scheduled + for.</para> + + <para>On boot systemd activates the target unit + <filename>default.target</filename> whose job is to activate + on-boot services and other on-boot units by pulling them in via + dependencies. Usually, the unit name is just an alias (symlink) for + either <filename>graphical.target</filename> (for fully-featured + boots into the UI) or <filename>multi-user.target</filename> (for + limited console-only boots for use in embedded or server + environments, or similar; a subset of graphical.target). However, + it is at the discretion of the administrator to configure it as an + alias to any other target unit. See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about these target units.</para> + + <para>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are kept + loaded into memory are those for which at least one of the following conditions is true:</para> + + <orderedlist> + <listitem><para>It is in an active, activating, deactivating or failed state (i.e. in any unit state except for <literal>inactive</literal>)</para></listitem> + <listitem><para>It has a job queued for it</para></listitem> + <listitem><para>It is a dependency of at least one other unit that is loaded into memory</para></listitem> + <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which + a process is still lingering that ignored the request to be terminated)</para></listitem> + <listitem><para>It has been pinned into memory programmatically by a D-Bus call</para></listitem> + </orderedlist> + + <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as + operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to + clients. Use <command>systemctl list-units --all</command> to comprehensively list all units currently loaded. Any + unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from + memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record + is generated declaring the consumed resources whenever a unit shuts down.</para> + + <para>Processes systemd spawns are placed in individual Linux + control groups named after the unit which they belong to in the + private systemd hierarchy. (see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink> + for more information about control groups, or short "cgroups"). + systemd uses this to effectively keep track of processes. Control + group information is maintained in the kernel, and is accessible + via the file system hierarchy (beneath + <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as + <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry> + or + <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> + (<command>ps xawf -eo pid,user,cgroup,args</command> is + particularly useful to list all processes and the systemd units + they belong to.).</para> + + <para>systemd is compatible with the SysV init system to a large + degree: SysV init scripts are supported and simply read as an + alternative (though limited) configuration file format. The SysV + <filename>/dev/initctl</filename> interface is provided, and + compatibility implementations of the various SysV client tools are + available. In addition to that, various established Unix + functionality such as <filename>/etc/fstab</filename> or the + <filename>utmp</filename> database are supported.</para> + + <para>systemd has a minimal transaction system: if a unit is + requested to start up or shut down it will add it and all its + dependencies to a temporary transaction. Then, it will verify if + the transaction is consistent (i.e. whether the ordering of all + units is cycle-free). If it is not, systemd will try to fix it up, + and removes non-essential jobs from the transaction that might + remove the loop. Also, systemd tries to suppress non-essential + jobs in the transaction that would stop a running service. Finally + it is checked whether the jobs of the transaction contradict jobs + that have already been queued, and optionally the transaction is + aborted then. If all worked out and the transaction is consistent + and minimized in its impact it is merged with all already + outstanding jobs and added to the run queue. Effectively this + means that before executing a requested operation, systemd will + verify that it makes sense, fixing it if possible, and only + failing if it really cannot work.</para> + + <para>Note that transactions are generated independently of a unit's + state at runtime, hence, for example, if a start job is requested on an + already started unit, it will still generate a transaction and wake up any + inactive dependencies (and cause propagation of other jobs as per the + defined relationships). This is because the enqueued job is at the time of + execution compared to the target unit's state and is marked successful and + complete when both satisfy. However, this job also pulls in other + dependencies due to the defined relationships and thus leads to, in our + example, start jobs for any of those inactive units getting queued as + well.</para> + + <para>systemd contains native implementations of various tasks + that need to be executed as part of the boot process. For example, + it sets the hostname or configures the loopback network device. It + also sets up and mounts various API file systems, such as + <filename>/sys/</filename> or <filename>/proc/</filename>.</para> + + <para>For more information about the concepts and + ideas behind systemd, please refer to the + <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para> + + <para>Note that some but not all interfaces provided by systemd are covered by the + <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>.</para> + + <para>Units may be generated dynamically at boot and system + manager reload time, for example based on other configuration + files or parameters passed on the kernel command line. For details, see + <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + + <para>The D-Bus API of <command>systemd</command> is described in + <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + + <para>Systems which invoke systemd in a container or initrd environment should implement the <ulink + url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> or + <ulink url="https://systemd.io/INITRD_INTERFACE/">initrd Interface</ulink> + specifications, respectively.</para> + </refsect1> + + <refsect1> + <title>Directories</title> + + <variablelist> + <varlistentry> + <term>System unit directories</term> + + <listitem><para>The systemd system manager reads unit + configuration from various directories. Packages that want to + install unit files shall place them in the directory returned + by <command>pkg-config systemd + --variable=systemdsystemunitdir</command>. Other directories + checked are <filename>/usr/local/lib/systemd/system</filename> + and <filename>/usr/lib/systemd/system</filename>. User + configuration always takes precedence. <command>pkg-config + systemd --variable=systemdsystemconfdir</command> returns the + path of the system configuration directory. Packages should + alter the content of these directories only with the + <command>enable</command> and <command>disable</command> + commands of the + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool. Full list of directories is provided in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term>User unit directories</term> + + <listitem><para>Similar rules apply for the user unit + directories. However, here the + <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG + Base Directory specification</ulink> is followed to find + units. Applications should place their unit files in the + directory returned by <command>pkg-config systemd + --variable=systemduserunitdir</command>. Global configuration + is done in the directory reported by <command>pkg-config + systemd --variable=systemduserconfdir</command>. The + <command>enable</command> and <command>disable</command> + commands of the + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool can handle both global (i.e. for all users) and private + (for one user) enabling/disabling of units. Full list of + directories is provided in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term>SysV init scripts directory</term> + + <listitem><para>The location of the SysV init script directory + varies between distributions. If systemd cannot find a native + unit file for a requested service, it will look for a SysV + init script of the same name (with the + <filename>.service</filename> suffix + removed).</para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term>SysV runlevel link farm directory</term> + + <listitem><para>The location of the SysV runlevel link farm + directory varies between distributions. systemd will take the + link farm into account when figuring out whether a service + shall be enabled. Note that a service unit with a native unit + configuration file cannot be started by activating it in the + SysV runlevel link farm.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Signals</title> + + <variablelist> + <varlistentry> + <term><constant>SIGTERM</constant></term> + + <listitem><para>Upon receiving this signal the systemd system + manager serializes its state, reexecutes itself and + deserializes the saved state again. This is mostly equivalent + to <command>systemctl daemon-reexec</command>.</para> + + <para>systemd user managers will start the + <filename>exit.target</filename> unit when this signal is + received. This is mostly equivalent to <command>systemctl + --user start exit.target + --job-mode=replace-irreversibly</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGINT</constant></term> + + <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-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 + console will trigger this signal. Hence, if a reboot is hanging, pressing + <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than + 7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para> + + <para>systemd user managers treat this signal the same way as + <constant>SIGTERM</constant>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGWINCH</constant></term> + + <listitem><para>When this signal is received the systemd + system manager will start the + <filename>kbrequest.target</filename> unit. This is mostly + equivalent to <command>systemctl start + kbrequest.target</command>.</para> + + <para>This signal is ignored by systemd user + managers.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGPWR</constant></term> + + <listitem><para>When this signal is received the systemd + manager will start the <filename>sigpwr.target</filename> + unit. This is mostly equivalent to <command>systemctl start + sigpwr.target</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGUSR1</constant></term> + + <listitem><para>When this signal is received the systemd + manager will try to reconnect to the D-Bus + bus.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGUSR2</constant></term> + + <listitem><para>When this signal is received the systemd + manager will log its complete state in human-readable form. + The data logged is the same as printed by + <command>systemd-analyze dump</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGHUP</constant></term> + + <listitem><para>Reloads the complete daemon configuration. + This is mostly equivalent to <command>systemctl + daemon-reload</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+0</constant></term> + + <listitem><para>Enters default mode, starts the + <filename>default.target</filename> unit. This is mostly + equivalent to <command>systemctl isolate + default.target</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+1</constant></term> + + <listitem><para>Enters rescue mode, starts the + <filename>rescue.target</filename> unit. This is mostly + equivalent to <command>systemctl isolate + rescue.target</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+2</constant></term> + + <listitem><para>Enters emergency mode, starts the + <filename>emergency.service</filename> unit. This is mostly + equivalent to <command>systemctl isolate + emergency.service</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+3</constant></term> + + <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-irreversibly</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+4</constant></term> + + <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-irreversibly</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+5</constant></term> + + <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-irreversibly</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+6</constant></term> + + <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-irreversibly</command>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+13</constant></term> + + <listitem><para>Immediately halts the machine.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+14</constant></term> + + <listitem><para>Immediately powers off the machine.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+15</constant></term> + + <listitem><para>Immediately reboots the machine.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+16</constant></term> + + <listitem><para>Immediately reboots the machine with kexec.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+20</constant></term> + + <listitem><para>Enables display of status messages on the + console, as controlled via + <varname>systemd.show_status=1</varname> on the kernel command + line.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+21</constant></term> + + <listitem><para>Disables display of + status messages on the console, as + controlled via + <varname>systemd.show_status=0</varname> + on the kernel command + line.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+22</constant></term> + + <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to + <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+23</constant></term> + + <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order + of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the + value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of + <literal>info</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+24</constant></term> + + <listitem><para>Immediately exits the manager (only available + for --user instances).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+26</constant></term> + + <listitem><para>Restores the log target to its configured value. The configured value is derived from – in + order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line, + or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in + default.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>SIGRTMIN+27</constant></term> + <term><constant>SIGRTMIN+28</constant></term> + + <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or + <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to + <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on + <constant>SIGRTMIN+28</constant>) on the kernel command line.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$SYSTEMD_LOG_COLOR</varname></term> + <listitem><para>Controls whether systemd highlights important log messages. This can be overridden + with <option>--log-color=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_LOG_LEVEL</varname></term> + <listitem><para>systemd reads the log level from this environment variable. This can be overridden + with <option>--log-level=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_LOG_LOCATION</varname></term> + <listitem><para>Controls whether systemd prints the code location along with log messages. This can + be overridden with <option>--log-location=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_LOG_TARGET</varname></term> + <listitem><para>systemd reads the log target from this environment variable. This can be overridden + with <option>--log-target=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_LOG_TIME</varname></term> + <listitem><para>Controls whether systemd prefixes log messages with the current time. This can be + overridden with <option>--log-time=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_LOG_TID</varname></term> + <listitem><para>Controls whether systemd prefixes log messages with the current thread ID + (TID).</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$XDG_CONFIG_HOME</varname></term> + <term><varname>$XDG_CONFIG_DIRS</varname></term> + <term><varname>$XDG_DATA_HOME</varname></term> + <term><varname>$XDG_DATA_DIRS</varname></term> + + <listitem><para>The systemd user manager uses these variables + in accordance to the <ulink + url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG + Base Directory specification</ulink> to find its + configuration.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_UNIT_PATH</varname></term> + <term><varname>$SYSTEMD_GENERATOR_PATH</varname></term> + <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH</varname></term> + + <listitem><para>Controls where systemd looks for unit files and + generators.</para> + <para>These variables may contain a list of paths, separated by colons + (<literal>:</literal>). When set, if the list ends with an empty + component (<literal>...:</literal>), this list is prepended to the + usual set of paths. Otherwise, the specified list replaces the usual + set of paths. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term> + + <listitem><para>Controls where systemd looks for SysV init + scripts.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term> + + <listitem><para>Controls where systemd looks for SysV init + script runlevel link farms.</para></listitem> + </varlistentry> + + <xi:include href="less-variables.xml" xpointer="pager"/> + <xi:include href="less-variables.xml" xpointer="less"/> + <xi:include href="less-variables.xml" xpointer="lesscharset"/> + <xi:include href="less-variables.xml" xpointer="lesssecure"/> + <xi:include href="less-variables.xml" xpointer="colors"/> + <xi:include href="less-variables.xml" xpointer="urlify"/> + + <varlistentry> + <term><varname>$LISTEN_PID</varname></term> + <term><varname>$LISTEN_FDS</varname></term> + <term><varname>$LISTEN_FDNAMES</varname></term> + + <listitem><para>Set by systemd for supervised processes during + socket-based activation. See + <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>$NOTIFY_SOCKET</varname></term> + + <listitem><para>Set by systemd for supervised processes for + status and start-up completion notification. See + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> + for more information.</para></listitem> + </varlistentry> + </variablelist> + + <para>For further environment variables understood by systemd and its various components, see <ulink + url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para>When run as the system instance systemd parses a number of options listed below. They can be + specified as kernel command line arguments<footnote><para>If run inside a Linux container these arguments + may be passed as command line arguments to systemd itself, next to any of the command line options listed + in the Options section above. If run outside of Linux containers, these arguments are parsed from + <filename>/proc/cmdline</filename> instead.</para></footnote>, or through the + <literal>SystemdOptions</literal> EFI variable (on EFI systems). The kernel command line has higher + priority. Following variables are understood:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>systemd.unit=</varname></term> + <term><varname>rd.systemd.unit=</varname></term> + + <listitem><para>Overrides the unit to activate on boot. + Defaults to <filename>default.target</filename>. This may be + used to temporarily boot into a different boot unit, for + example <filename>rescue.target</filename> or + <filename>emergency.service</filename>. See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details about these units. The option prefixed with + <literal>rd.</literal> is honored only in the initial RAM disk + (initrd), while the one that is not prefixed only in the main + system.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.dump_core</varname></term> + + <listitem><para>Takes a boolean argument or enables the option if specified + without an argument. If enabled, the systemd manager (PID 1) dumps core when + it crashes. Otherwise, no core dump is created. Defaults to enabled.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.crash_chvt</varname></term> + + <listitem><para>Takes a positive integer, or a boolean argument. Can be also specified without an + argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is + specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes. + Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual + terminal the kernel messages are written to is used instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.crash_shell</varname></term> + + <listitem><para>Takes a boolean argument or enables the option if specified + without an argument. If enabled, the system manager (PID 1) spawns a shell + when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults + to disabled, for security reasons, as the shell is not protected by password + authentication.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.crash_reboot</varname></term> + + <listitem><para>Takes a boolean argument or enables the option if specified + without an argument. If enabled, the system manager (PID 1) will reboot the + machine automatically when it crashes, after a 10s delay. Otherwise, the + system will hang indefinitely. Defaults to disabled, in order to avoid a + reboot loop. If combined with <varname>systemd.crash_shell</varname>, the + system is rebooted after the shell exits.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.confirm_spawn</varname></term> + + <listitem><para>Takes a boolean argument or a path to the virtual console + where the confirmation messages should be emitted. Can be also specified + without an argument, with the same effect as a positive boolean. If enabled, + the system manager (PID 1) asks for confirmation when spawning processes + using <option>/dev/console</option>. If a path or a console name (such as + <literal>ttyS0</literal>) is provided, the virtual console pointed to by this + path or described by the give name will be used instead. Defaults to disabled. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.service_watchdogs=</varname></term> + + <listitem><para>Takes a boolean argument. If disabled, all service runtime + watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g. + <option>OnFailure=</option> or <option>StartLimitAction=</option>) are + ignored by the system manager (PID 1); see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + Defaults to enabled, i.e. watchdogs and failure actions are processed + normally. The hardware watchdog is not affected by this + option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.show_status</varname></term> + + <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and + <constant>auto</constant>. Can be also specified without an argument, with the same effect as a + positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the + console during bootup. With <constant>error</constant>, only messages about failures are shown, but + boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until there is + a significant delay in boot. Defaults to enabled, unless <option>quiet</option> is passed as kernel + command line option, in which case it defaults to <constant>error</constant>. If specified overrides + the system manager configuration file option <option>ShowStatus=</option>, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para></listitem> + </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_color</varname></term> + <term><varname>systemd.log_level=</varname></term> + <term><varname>systemd.log_location</varname></term> + <term><varname>systemd.log_target=</varname></term> + <term><varname>systemd.log_time</varname></term> + <term><varname>systemd.log_tid</varname></term> + + <listitem><para>Controls log output, with the same effect as the + <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, + <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>, + <varname>$SYSTEMD_LOG_TIME</varname>, and <varname>$SYSTEMD_LOG_TID</varname> environment variables + described above. <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>, + <varname>systemd.log_time</varname>, and <varname>systemd.log_tid=</varname> can be specified without + an argument, with the same effect as a positive boolean.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.default_standard_output=</varname></term> + <term><varname>systemd.default_standard_error=</varname></term> + + <listitem><para>Controls default standard output and error output for services and sockets. That is, + controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>, + <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>, + <option>kmsg+console</option>. If the argument is omitted + <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and + <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.setenv=</varname></term> + + <listitem><para>Takes a string argument in the form + VARIABLE=VALUE. May be used to set default environment + variables to add to forked child processes. May be used more + than once to set multiple variables.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.machine_id=</varname></term> + + <listitem><para>Takes a 32 character hex value to be + used for setting the machine-id. Intended mostly for + network booting where the same machine-id is desired + for every boot.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.unified_cgroup_hierarchy</varname></term> + + <listitem><para>When specified without an argument or with a true argument, + enables the usage of + <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">unified cgroup hierarchy</ulink> + (a.k.a. cgroups-v2). When specified with a false argument, fall back to + hybrid or full legacy cgroup hierarchy.</para> + + <para>If this option is not specified, the default behaviour is determined + during compilation (the <option>-Ddefault-hierarchy=</option> meson + option). If the kernel does not support unified cgroup hierarchy, the legacy + hierarchy will be used even if this option is specified.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term> + + <listitem><para>Takes effect if the full unified cgroup hierarchy is not used + (see previous option). When specified without an argument or with a true + argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2 + tree used for systemd, and + <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy + cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and + forces a full "legacy" mode. When specified with a false argument, enables + the use of "hybrid" hierarchy.</para> + + <para>If this option is not specified, the default behaviour is determined + during compilation (the <option>-Ddefault-hierarchy=</option> meson + option). If the kernel does not support unified cgroup hierarchy, the legacy + hierarchy will be used even if this option is specified.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>quiet</varname></term> + + <listitem><para>Turn off status output at boot, much like + <varname>systemd.show_status=no</varname> would. Note that + this option is also read by the kernel itself and disables + kernel log output. Passing this option hence turns off the + usual output from both the system manager and the kernel. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>debug</varname></term> + + <listitem><para>Turn on debugging output. This is equivalent + to <varname>systemd.log_level=debug</varname>. Note that this + option is also read by the kernel itself and enables kernel + debug output. Passing this option hence turns on the debug + output from both the system manager and the + kernel.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>emergency</varname></term> + <term><varname>rd.emergency</varname></term> + <term><varname>-b</varname></term> + + <listitem><para>Boot into emergency mode. This is equivalent + to <varname>systemd.unit=emergency.target</varname> or + <varname>rd.systemd.unit=emergency.target</varname>, respectively, and + provided for compatibility reasons and to be easier to type.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>rescue</varname></term> + <term><varname>rd.rescue</varname></term> + <term><varname>single</varname></term> + <term><varname>s</varname></term> + <term><varname>S</varname></term> + <term><varname>1</varname></term> + + <listitem><para>Boot into rescue mode. This is equivalent to + <varname>systemd.unit=rescue.target</varname> or + <varname>rd.systemd.unit=rescue.target</varname>, respectively, and + provided for compatibility reasons and to be easier to type.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>2</varname></term> + <term><varname>3</varname></term> + <term><varname>4</varname></term> + <term><varname>5</varname></term> + + <listitem><para>Boot into the specified legacy SysV runlevel. + These are equivalent to + <varname>systemd.unit=runlevel2.target</varname>, + <varname>systemd.unit=runlevel3.target</varname>, + <varname>systemd.unit=runlevel4.target</varname>, and + <varname>systemd.unit=runlevel5.target</varname>, + respectively, and provided for compatibility reasons and to be + easier to type.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>locale.LANG=</varname></term> + <term><varname>locale.LANGUAGE=</varname></term> + <term><varname>locale.LC_CTYPE=</varname></term> + <term><varname>locale.LC_NUMERIC=</varname></term> + <term><varname>locale.LC_TIME=</varname></term> + <term><varname>locale.LC_COLLATE=</varname></term> + <term><varname>locale.LC_MONETARY=</varname></term> + <term><varname>locale.LC_MESSAGES=</varname></term> + <term><varname>locale.LC_PAPER=</varname></term> + <term><varname>locale.LC_NAME=</varname></term> + <term><varname>locale.LC_ADDRESS=</varname></term> + <term><varname>locale.LC_TELEPHONE=</varname></term> + <term><varname>locale.LC_MEASUREMENT=</varname></term> + <term><varname>locale.LC_IDENTIFICATION=</varname></term> + + <listitem><para>Set the system locale to use. This overrides + the settings in <filename>/etc/locale.conf</filename>. For + more information, see + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> + and + <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + </variablelist> + + <para>For other kernel command line parameters understood by + components of the core OS, please refer to + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is + already running by the time users may interact with it. Normally, tools like + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to + give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the + options listed below are mostly useful for debugging and special purposes.</para> + + <refsect2> + <title>Introspection and debugging options</title> + + <para>Those options are used for testing and introspection, and <command>systemd</command> may + be invoked with them at any time:</para> + + <variablelist> + <varlistentry> + <term><option>--dump-configuration-items</option></term> + + <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of + configuration items understood in unit definition files.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--dump-bus-properties</option></term> + + <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>--test</option></term> + + <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>--system</option></term> + <term><option>--user</option></term> + + <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> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect2> + + <refsect2> + <title>Options that duplicate kernel command line settings</title> + + <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms + may be used equivalently for the system manager, but it is recommended to use the forms listed above in + this context, because they are properly namespaced. When an option is specified both on the kernel + command line and as a normal command line argument, the latter has higher precedence.</para> + + <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and + only the options described below are understood. Nevertheless, <command>systemd</command> is usually + started in this mode through the + <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + service, which is shared between all users, and it may be more convenient to use configuration files to + modify settings (see + <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>), + or a drop-in that specifies one of the environment variables listed above in the Environment section + (see the discussion of <varname>Environment=</varname> and <varname>EnvironmentFile=</varname> in + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para> + + <variablelist> + <varlistentry> + <term><option>--unit=</option></term> + + <listitem><para>Set default unit to activate on startup. If not specified, defaults to + <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--dump-core</option></term> + + <listitem><para>Enable core dumping on crash. This switch has no effect when running as user + instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--crash-vt=</option><replaceable>VT</replaceable></term> + + <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when + running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the + different spelling!).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--crash-shell</option></term> + + <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See + <varname>systemd.crash_shell=</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--crash-reboot</option></term> + + <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as + user instance. See <varname>systemd.crash_reboot</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--confirm-spawn</option></term> + + <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as + user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--show-status</option></term> + + <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See + <varname>systemd.show_status</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--log-color</option></term> + + <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--log-level=</option></term> + + <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--log-location</option></term> + + <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname> + above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--log-target=</option></term> + + <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--log-time=</option></term> + + <listitem><para>Prefix messages with timestamp. See <varname>systemd.log_time</varname> above. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--machine-id=</option></term> + + <listitem><para>Override the machine-id set on the hard drive. See + <varname>systemd.machine_id=</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--service-watchdogs</option></term> + + <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See + <varname>systemd.service_watchdogs</varname> above.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--default-standard-output=</option></term> + <term><option>--default-standard-error=</option></term> + + <listitem><para>Sets the default output or error output for all services and sockets, + respectively. See <varname>systemd.default_standard_output=</varname> and + <varname>systemd.default_standard_error=</varname> above.</para></listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>Sockets and FIFOs</title> + + <variablelist> + <varlistentry> + <term><filename>/run/systemd/notify</filename></term> + + <listitem><para>Daemon status notification socket. This is an + <constant>AF_UNIX</constant> datagram socket and is used to + implement the daemon notification logic as implemented by + <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem> + + </varlistentry> + + <varlistentry> + <term><filename>/run/systemd/private</filename></term> + + <listitem><para>Used internally as communication channel + between + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + and the systemd process. This is an + <constant>AF_UNIX</constant> stream socket. This interface is + private to systemd and should not be used in external + projects.</para></listitem> + </varlistentry> + + <varlistentry> + <term><filename>/dev/initctl</filename></term> + + <listitem><para>Limited compatibility support for the SysV + client interface, as implemented by the + <filename>systemd-initctl.service</filename> unit. This is a + named pipe in the file system. This interface is obsolete and + should not be used in new applications.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>, + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/sysusers.d.xml b/man/sysusers.d.xml new file mode 100644 index 0000000..a76dda9 --- /dev/null +++ b/man/sysusers.d.xml @@ -0,0 +1,292 @@ +<?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-or-later --> +<refentry id="sysusers.d" conditional='ENABLE_SYSUSERS' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>sysusers.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>sysusers.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>sysusers.d</refname> + <refpurpose>Declarative allocation of system users and groups</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/sysusers.d/*.conf</filename></para> + <para><filename>/run/sysusers.d/*.conf</filename></para> + <para><filename>/usr/lib/sysusers.d/*.conf</filename></para> + + <programlisting> +#Type Name ID GECOS Home directory Shell +u user_name uid "User Description" /home/dir /path/to/shell +u user_name uid:gid "User Description" /home/dir /path/to/shell +u user_name /file/owned/by/user "User Description" /home/dir /path/to/shell +g group_name gid +g group_name /file/owned/by/group +m user_name group_name +r - lowest-highest</programlisting> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>systemd-sysusers</command> uses the files from + <filename>sysusers.d</filename> directory to create system users and groups and + to add users to groups, at package installation or boot time. This tool may be + used to allocate system users and groups only, it is not useful for creating + non-system (i.e. regular, "human") users and groups, as it accesses + <filename>/etc/passwd</filename> and <filename>/etc/group</filename> directly, + bypassing any more complex user databases, for example any database involving NIS + or LDAP.</para> + </refsect1> + + <refsect1> + <title>Configuration Directories and Precedence</title> + + <para>Each configuration file shall be named in the style of + <filename><replaceable>package</replaceable>.conf</filename> or + <filename><replaceable>package</replaceable>-<replaceable>part</replaceable>.conf</filename>. + The second variant should be used when it is desirable to make it + easy to override just this part of configuration.</para> + + <para>Files in <filename>/etc/sysusers.d</filename> override files + with the same name in <filename>/usr/lib/sysusers.d</filename> and + <filename>/run/sysusers.d</filename>. Files in + <filename>/run/sysusers.d</filename> override files with the same + name in <filename>/usr/lib/sysusers.d</filename>. Packages should + install their configuration files in + <filename>/usr/lib/sysusers.d</filename>. Files in + <filename>/etc/sysusers.d</filename> are reserved for the local + administrator, who may use this logic to override the + configuration files installed by vendor packages. All + configuration files are sorted by their filename in lexicographic + order, regardless of which of the directories they reside in. If + multiple files specify the same path, the entry in the file with + the lexicographically earliest name will be applied. All later + entries for the same user and group names will be logged as warnings. + </para> + + <para>If the administrator wants to disable a configuration file + supplied by the vendor, the recommended way is to place a symlink + to <filename>/dev/null</filename> in + <filename>/etc/sysusers.d/</filename> bearing the same filename. + </para> + </refsect1> + + <refsect1> + <title>Configuration File Format</title> + + <para>The file format is one line per user or group containing name, ID, GECOS + field description, home directory, and login shell:</para> + + <programlisting>#Type Name ID GECOS Home directory Shell +u httpd 404 "HTTP User" +u _authd /usr/bin/authd "Authorization user" +u postgres - "Postgresql Database" /var/lib/pgsql /usr/libexec/postgresdb +g input - - +m _authd input +u root 0 "Superuser" /root /bin/zsh +r - 500-900 +</programlisting> + + <para>Empty lines and lines beginning with the <literal>#</literal> character are ignored, and may be used for + commenting.</para> + + <refsect2> + <title>Type</title> + + <para>The type consists of a single letter. The following line + types are understood:</para> + + <variablelist> + <varlistentry> + <term><varname>u</varname></term> + <listitem><para>Create a system user and group of the specified name should + they not exist yet. The user's primary group will be set to the group + bearing the same name unless the ID field specifies it. The account will be + created disabled, so that logins are not allowed.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>g</varname></term> + <listitem><para>Create a system group of the specified name + should it not exist yet. Note that <varname>u</varname> + implicitly creates a matching group. The group will be + created with no password set.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>m</varname></term> + <listitem><para>Add a user to a group. If the user or group + do not exist yet, they will be implicitly + created.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>r</varname></term> + <listitem><para>Add a range of numeric UIDs/GIDs to the pool + to allocate new UIDs and GIDs from. If no line of this type + is specified, the range of UIDs/GIDs is set to some + compiled-in default. Note that both UIDs and GIDs are + allocated from the same pool, in order to ensure that users + and groups of the same name are likely to carry the same + numeric UID and GID.</para></listitem> + </varlistentry> + + </variablelist> + </refsect2> + + <refsect2> + <title>Name</title> + + <para>The name field specifies the user or group name. The specified name must consist only of the characters a-z, + A-Z, 0-9, <literal>_</literal> and <literal>-</literal>, except for the first character which must be one of a-z, + A-Z or <literal>_</literal> (i.e. numbers and <literal>-</literal> are not permitted as first character). The + user/group name must have at least one character, and at most 31.</para> + + <para>For further details about the syntax of user/group names, see <ulink + url="https://systemd.io/USER_NAMES">User/Group Name Syntax</ulink>.</para> + + <para>It is strongly recommended to pick user and group names that are unlikely to clash with normal users + created by the administrator. A good scheme to guarantee this is by prefixing all system and group names with the + underscore, and avoiding too generic names.</para> + + <para>For <varname>m</varname> lines, this field should contain + the user name to add to a group.</para> + + <para>For lines of type <varname>r</varname>, this field should + be set to <literal>-</literal>.</para> + </refsect2> + + <refsect2> + <title>ID</title> + + <para>For <varname>u</varname> and <varname>g</varname>, the + numeric 32-bit UID or GID of the user/group. Do not use IDs 65535 + or 4294967295, as they have special placeholder meanings. + Specify <literal>-</literal> for automatic UID/GID allocation + for the user or group (this is strongly recommended unless it is strictly + necessary to use a specific UID or GID). Alternatively, specify an absolute path + in the file system. In this case, the UID/GID is read from the + path's owner/group. This is useful to create users whose UID/GID + match the owners of pre-existing files (such as SUID or SGID + binaries). + The syntaxes <literal><replaceable>uid</replaceable>:<replaceable>gid</replaceable></literal> and + <literal><replaceable>uid</replaceable>:<replaceable>groupname</replaceable></literal> are supported to + allow creating users with specific primary groups. The given group must be created explicitly, or it + must already exist. Specifying <literal>-</literal> for the UID in these syntaxes is also supported. + </para> + + <para>For <varname>m</varname> lines, this field should contain + the group name to add to a user to.</para> + + <para>For lines of type <varname>r</varname>, this field should + be set to a UID/GID range in the format + <literal>FROM-TO</literal>, where both values are formatted as + decimal ASCII numbers. Alternatively, a single UID/GID may be + specified formatted as decimal ASCII numbers.</para> + </refsect2> + + <refsect2> + <title>GECOS</title> + + <para>A short, descriptive string for users to be created, enclosed in + quotation marks. Note that this field may not contain colons.</para> + + <para>Only applies to lines of type <varname>u</varname> and should otherwise + be left unset (or <literal>-</literal>).</para> + </refsect2> + + <refsect2> + <title>Home Directory</title> + + <para>The home directory for a new system user. If omitted, defaults to the + root directory.</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 + software strictly requires a home directory to be set.</para> + </refsect2> + + <refsect2> + <title>Shell</title> + + <para>The login shell of the user. If not specified, this will be set to + <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>/usr/sbin/nologin</filename> must be used.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Specifiers</title> + + <para>Specifiers can be used in the <literal>Name</literal>, <literal>ID</literal>, + <literal>GECOS</literal>, <literal>Home directory</literal>, and <literal>Shell</literal> fields. An + unknown or unresolvable specifier is treated as invalid configuration. The following expansions are + understood:</para> + + <table class='specifiers'> + <title>Specifiers available</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="spec" /> + <colspec colname="mean" /> + <colspec colname="detail" /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Meaning</entry> + <entry>Details</entry> + </row> + </thead> + <tbody> + <xi:include href="standard-specifiers.xml" xpointer="a"/> + <xi:include href="standard-specifiers.xml" xpointer="b"/> + <xi:include href="standard-specifiers.xml" xpointer="B"/> + <xi:include href="standard-specifiers.xml" xpointer="H"/> + <xi:include href="standard-specifiers.xml" xpointer="l"/> + <xi:include href="standard-specifiers.xml" xpointer="m"/> + <xi:include href="standard-specifiers.xml" xpointer="o"/> + <xi:include href="standard-specifiers.xml" xpointer="T"/> + <xi:include href="standard-specifiers.xml" xpointer="v"/> + <xi:include href="standard-specifiers.xml" xpointer="V"/> + <xi:include href="standard-specifiers.xml" xpointer="w"/> + <xi:include href="standard-specifiers.xml" xpointer="W"/> + <xi:include href="standard-specifiers.xml" xpointer="percent"/> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Idempotence</title> + + <para>Note that <command>systemd-sysusers</command> will do nothing if the + specified users or groups already exist or the users are members of specified + groups, so normally there is no reason to override + <filename>sysusers.d</filename> vendor configuration, except to block certain + users or groups from being created.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/tc.xml b/man/tc.xml new file mode 100644 index 0000000..e5c70d4 --- /dev/null +++ b/man/tc.xml @@ -0,0 +1,48 @@ +<?xml version="1.0"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1-or-later +--> + +<refsect1> + <variablelist class='network-directives'> + <varlistentry id='qdisc-parent'> + <term><varname>Parent=</varname></term> + <listitem> + <para>Configures the parent Queueing Discipline (qdisc). Takes one of <literal>root</literal>, + <literal>clsact</literal>, <literal>ingress</literal> or a class identifier. The class identifier is + specified as the major and minor numbers in hexadecimal in the range 0x1–Oxffff separated with a + colon (<literal>major:minor</literal>). Defaults to <literal>root</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry id='qdisc-handle'> + <term><varname>Handle=</varname></term> + <listitem> + <para>Configures the major number of unique identifier of the qdisc, known as the handle. + Takes a hexadecimal number in the range 0x1–0xffff. Defaults to unset.</para> + </listitem> + </varlistentry> + + <varlistentry id='tclass-parent'> + <term><varname>Parent=</varname></term> + <listitem> + <para>Configures the parent Queueing Discipline (qdisc). Takes one of <literal>root</literal>, or a + qdisc identifier. The qdisc identifier is specified as the major and minor numbers in hexadecimal in + the range 0x1–Oxffff separated with a colon (<literal>major:minor</literal>). Defaults to + <literal>root</literal>. + </para> + </listitem> + </varlistentry> + + <varlistentry id='tclass-classid'> + <term><varname>ClassId=</varname></term> + <listitem> + <para>Configures the unique identifier of the class. It is specified as the major and minor numbers in + hexadecimal in the range 0x1–Oxffff separated with a colon (<literal>major:minor</literal>). + Defaults to unset.</para> + </listitem> + </varlistentry> + </variablelist> +</refsect1> diff --git a/man/telinit.xml b/man/telinit.xml new file mode 100644 index 0000000..294b359 --- /dev/null +++ b/man/telinit.xml @@ -0,0 +1,151 @@ +<?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-or-later --> + +<refentry id="telinit" conditional='HAVE_SYSV_COMPAT' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>telinit</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>telinit</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>telinit</refname> + <refpurpose>Change SysV runlevel</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>telinit <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>telinit</command> may be used to change the SysV + system runlevel. Since the concept of SysV runlevels is obsolete + the runlevel requests will be transparently translated into + systemd unit activation requests.</para> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--help</option></term> + + <xi:include href="standard-options.xml" xpointer="help-text" /> + </varlistentry> + + <varlistentry> + <term><option>--no-wall</option></term> + + <listitem><para>Do not send wall message before + reboot/halt/power-off.</para></listitem> + </varlistentry> + </variablelist> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>0</command></term> + + <listitem><para>Power-off the machine. This is translated into + an activation request for <filename>poweroff.target</filename> + and is equivalent to <command>systemctl + poweroff</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>6</command></term> + + <listitem><para>Reboot the machine. This is translated into an + activation request for <filename>reboot.target</filename> and + is equivalent to <command>systemctl + reboot</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>2</command></term> + <term><command>3</command></term> + <term><command>4</command></term> + <term><command>5</command></term> + + <listitem><para>Change the SysV runlevel. This is translated + into an activation request for + <filename>runlevel2.target</filename>, + <filename>runlevel3.target</filename>, … and is equivalent + to <command>systemctl isolate runlevel2.target</command>, + <command>systemctl isolate runlevel3.target</command>, + …</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>1</command></term> + <term><command>s</command></term> + <term><command>S</command></term> + + <listitem><para>Change into system rescue mode. This is + translated into an activation request for + <filename>rescue.target</filename> and is equivalent to + <command>systemctl rescue</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>q</command></term> + <term><command>Q</command></term> + + <listitem><para>Reload daemon configuration. This is + equivalent to <command>systemctl + daemon-reload</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>u</command></term> + <term><command>U</command></term> + + <listitem><para>Serialize state, reexecute daemon and + deserialize state again. This is equivalent to + <command>systemctl daemon-reexec</command>.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure + code otherwise.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <para>This is a legacy command available for compatibility only. + It should not be used anymore, as the concept of runlevels is + obsolete.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/threads-aware.xml b/man/threads-aware.xml new file mode 100644 index 0000000..fb38d07 --- /dev/null +++ b/man/threads-aware.xml @@ -0,0 +1,15 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refsect1> + +<para id="strict">All functions listed here are thread-agnostic and only a single specific thread may operate on a +given object during its entire lifetime. It's safe to allocate multiple independent objects and use each from a +specific thread in parallel. However, it's not safe to allocate such an object in one thread, and operate or free it +from any other, even if locking is used to ensure these threads don't operate on it at the very same time.</para> + +<para id="safe">All functions listed here are thread-safe and may be called in parallel from multiple threads.</para> + +</refsect1> diff --git a/man/timedatectl.xml b/man/timedatectl.xml new file mode 100644 index 0000000..e7db487 --- /dev/null +++ b/man/timedatectl.xml @@ -0,0 +1,325 @@ +<?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-or-later --> + +<refentry id="timedatectl" conditional='ENABLE_TIMEDATECTL' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>timedatectl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>timedatectl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>timedatectl</refname> + <refpurpose>Control the system time and date</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <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, + 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 time synchronization + services, for example + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term><command>status</command></term> + + <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> + + <varlistentry> + <term><command>show</command></term> + + <listitem><para>Show the same information as <option>status</option>, but in machine readable form. + This command is intended to be used whenever computer-parsable output is required. + Use <option>status</option> if you are looking for formatted human-readable output.</para> + <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>set-time [TIME]</command></term> + + <listitem><para>Set the system clock to the specified time. + This will also update the RTC time accordingly. The time may + be specified in the format "2012-10-30 + 18:17:16".</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-timezone [TIMEZONE]</command></term> + + <listitem><para>Set the system time zone to the specified + value. Available timezones can be listed with + <command>list-timezones</command>. If the RTC is configured to + be in the local time, this will also update the RTC time. This + call will alter the <filename>/etc/localtime</filename> + symlink. See + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>list-timezones</command></term> + + <listitem><para>List available time zones, one per line. + Entries from the list can be set as the system timezone with + <command>set-timezone</command>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>set-local-rtc [BOOL]</command></term> + + <listitem><para>Takes a boolean argument. If + <literal>0</literal>, the system is configured to maintain the + RTC in universal time. If <literal>1</literal>, it will + maintain the RTC in local time instead. Note that maintaining + the RTC in the local timezone is not fully supported and will + create various problems with time zone changes and daylight + saving adjustments. If at all possible, keep the RTC in UTC + mode. Note that invoking this will also synchronize the RTC + from the system clock, unless + <option>--adjust-system-clock</option> is passed (see above). + This command will change the 3rd line of + <filename>/etc/adjtime</filename>, as documented in + <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + </varlistentry> + + <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 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> + + <refsect2> + <title>systemd-timesyncd Commands</title> + + <para>The following commands are specific to + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para> + + <variablelist> + <varlistentry> + <term><command>timesync-status</command></term> + + <listitem><para>Show current status of + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + If <option>--monitor</option> is specified, then this will monitor the status updates.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>show-timesync</command></term> + + <listitem><para>Show the same information as <option>timesync-status</option>, but in machine readable form. + This command is intended to be used whenever computer-parsable output is required. + Use <option>timesync-status</option> if you are looking for formatted human-readable output.</para> + <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> + + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--no-ask-password</option></term> + + <listitem><para>Do not query the user for authentication for + privileged operations.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--adjust-system-clock</option></term> + + <listitem><para>If <command>set-local-rtc</command> is invoked + and this option is passed, the system clock is synchronized + from the RTC again, taking the new setting into account. + Otherwise, the RTC is synchronized from the system + clock.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--monitor</option></term> + + <listitem><para>If <command>timesync-status</command> is invoked and this option is passed, then + <command>timedatectl</command> monitors the status of + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and updates the outputs. Use <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> to terminate the + monitoring.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-a</option></term> + <term><option>--all</option></term> + + <listitem><para>When showing properties of + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + show all properties regardless of whether they are set or not.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--property=</option></term> + + <listitem><para>When showing properties of + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + limit display to certain properties as specified as argument. If not specified, all set properties are shown. + The argument should be a property name, such as <literal>ServerName</literal>. If specified more than once, + all properties with the specified names are shown.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--value</option></term> + + <listitem> + <para>When printing properties with <command>show-timesync</command>, only print the value, and skip the + property name and <literal>=</literal>.</para></listitem> + </varlistentry> + + <xi:include href="user-system-options.xml" xpointer="host" /> + <xi:include href="user-system-options.xml" xpointer="machine" /> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + <xi:include href="standard-options.xml" xpointer="no-pager" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>Examples</title> + <para>Show current settings: + <programlisting>$ timedatectl + Local time: Thu 2017-09-21 16:08:56 CEST + Universal time: Thu 2017-09-21 14:08:56 UTC + RTC time: Thu 2017-09-21 14:08:56 + Time zone: Europe/Warsaw (CEST, +0200) +System clock synchronized: yes + NTP service: active + RTC in local TZ: no</programlisting> + </para> + + <para>Enable network time synchronization: + <programlisting>$ timedatectl set-ntp true +==== AUTHENTICATING FOR org.freedesktop.timedate1.set-ntp === +Authentication is required to control whether network time synchronization shall be enabled. +Authenticating as: user +Password: ******** +==== AUTHENTICATION COMPLETE ===</programlisting> + + <programlisting>$ systemctl status systemd-timesyncd.service +● systemd-timesyncd.service - Network Time Synchronization + Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled) + Active: active (running) since Mo 2015-03-30 14:20:38 CEST; 5s ago + Docs: man:systemd-timesyncd.service(8) + Main PID: 595 (systemd-timesyn) + Status: "Using Time Server 216.239.38.15:123 (time4.google.com)." + CGroup: /system.slice/systemd-timesyncd.service + └─595 /usr/lib/systemd/systemd-timesyncd +…</programlisting> + </para> + + <para>Show current status of + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>: + <programlisting>$ timedatectl timesync-status + Server: 216.239.38.15 (time4.google.com) +Poll interval: 1min 4s (min: 32s; max 34min 8s) + Leap: normal + Version: 4 + Stratum: 1 + Reference: GPS + Precision: 1us (-20) +Root distance: 335us (max: 5s) + Offset: +316us + Delay: 349us + Jitter: 0 + Packet count: 1 + Frequency: -8.802ppm</programlisting> + </para> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>date</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml new file mode 100644 index 0000000..1cbea9e --- /dev/null +++ b/man/timesyncd.conf.xml @@ -0,0 +1,106 @@ +<?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-or-later --> + +<refentry id="timesyncd.conf" conditional='ENABLE_TIMESYNCD' + xmlns:xi="http://www.w3.org/2001/XInclude"> + <refentryinfo> + <title>timesyncd.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>timesyncd.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>timesyncd.conf</refname> + <refname>timesyncd.conf.d</refname> + <refpurpose>Network Time Synchronization configuration files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/systemd/timesyncd.conf</filename></para> + <para><filename>/etc/systemd/timesyncd.conf.d/*.conf</filename></para> + <para><filename>/run/systemd/timesyncd.conf.d/*.conf</filename></para> + <para><filename>/usr/lib/systemd/timesyncd.conf.d/*.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>These configuration files control NTP network time synchronization. See + <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for a general description of the syntax.</para> + </refsect1> + + <xi:include href="standard-conf.xml" xpointer="main-conf" /> + + <refsect1> + <title>Options</title> + + <para>The following settings are configured in the [Time] section:</para> + + <variablelist class='network-directives'> + + <varlistentry> + <term><varname>NTP=</varname></term> + <listitem><para>A space-separated list of NTP server host + names or IP addresses. During runtime this list is combined + with any per-interface NTP servers acquired from + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + systemd-timesyncd will contact all configured system or + per-interface servers in turn until one is found that + responds. When the empty string is assigned, the list of + NTP servers is reset, and all assignments prior to this one + will have no effect. This setting defaults to an empty + list.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FallbackNTP=</varname></term> + <listitem><para>A space-separated list of NTP server host + names or IP addresses to be used as the fallback NTP servers. + Any per-interface NTP servers obtained from + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + take precedence over this setting, as do any servers set via + <varname>NTP=</varname> above. This setting is hence only used + if no other NTP server information is known. When the empty + string is assigned, the list of NTP servers is reset, + and all assignments prior to this one will have no effect. + If this option is not given, a compiled-in list of NTP servers + is used instead.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RootDistanceMaxSec=</varname></term> + <listitem><para>Maximum acceptable root distance. Takes a time value (in seconds). + Defaults to 5 seconds.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>PollIntervalMinSec=</varname></term> + <term><varname>PollIntervalMaxSec=</varname></term> + <listitem><para>The minimum and maximum poll intervals for NTP messages. + Each setting takes a time value (in seconds). + <varname>PollIntervalMinSec=</varname> must not be smaller than 16 seconds. + <varname>PollIntervalMaxSec=</varname> must be larger than <varname>PollIntervalMinSec=</varname>. + <varname>PollIntervalMinSec=</varname> defaults to 32 seconds, and + <varname>PollIntervalMaxSec=</varname> defaults to 2048 seconds.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml new file mode 100644 index 0000000..49ce837 --- /dev/null +++ b/man/tmpfiles.d.xml @@ -0,0 +1,795 @@ +<?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-or-later + + Copyright © 2010 Brandon Philips +--> +<refentry id="tmpfiles.d" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>tmpfiles.d</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>tmpfiles.d</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>tmpfiles.d</refname> + <refpurpose>Configuration for creation, deletion and cleaning of + volatile and temporary files</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><literallayout><filename>/etc/tmpfiles.d/*.conf</filename> +<filename>/run/tmpfiles.d/*.conf</filename> +<filename>/usr/lib/tmpfiles.d/*.conf</filename> + </literallayout></para> + + <para><literallayout><filename>~/.config/user-tmpfiles.d/*.conf</filename> +<filename>$XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf</filename> +<filename>~/.local/share/user-tmpfiles.d/*.conf</filename> +<filename index='false'>…</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 +w+ /file/to/append-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-or-directory/to/create mode user group - - +q /subvolume-or-directory/to/create mode user group - - +Q /subvolume-or-directory/to/create mode user group - - +p /fifo/to/create mode user group - - +p+ /fifo/to/[re]create mode user group - - +L /symlink/to/create - - - - symlink/target/path +L+ /symlink/to/[re]create - - - - symlink/target/path +c /dev/char-device-to-create mode user group - major:minor +c+ /dev/char-device-to-[re]create mode user group - major:minor +b /dev/block-device-to-create mode user group - major:minor +b+ /dev/block-device-to-[re]create mode user group - major:minor +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 - - +Z /path-or-glob/to/adjust/mode/recursively mode user group - - +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/append/acls - - - - POSIX ACLs +A /path-or-glob/to/set/acls/recursively - - - - POSIX ACLs +A+ /path-or-glob/to/append/acls/recursively - - - - POSIX ACLs + +</programlisting> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><filename>tmpfiles.d</filename> configuration files provide a generic mechanism to define the + <emphasis>creation</emphasis> of regular files, directories, pipes, and device nodes, adjustments to + their <emphasis>access mode, ownership, attributes, quota assignments, and contents</emphasis>, and + finally their time-based <emphasis>removal</emphasis>. It is mostly commonly used for volatile and + temporary files and directories (such as those located under <filename>/run/</filename>, + <filename>/tmp/</filename>, <filename>/var/tmp/</filename>, the API file systems such as + <filename>/sys/</filename> or <filename>/proc/</filename>, as well as some other directories below + <filename>/var/</filename>).</para> + + <para><command>systemd-tmpfiles</command> uses this configuration to create volatile files and + directories during boot and to do periodic cleanup afterwards. See + <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + the description of <filename>systemd-tmpfiles-setup.service</filename>, + <filename>systemd-tmpfiles-clean.service</filename>, and associated units.</para> + + <para>System daemons frequently require private runtime directories below <filename>/run/</filename> to + store communication sockets and similar. For these, it is better to use + <varname>RuntimeDirectory=</varname> in their unit files (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details), if the flexibility provided by <filename>tmpfiles.d</filename> is not required. The advantages + are that the configuration required by the unit is centralized in one place, and that the lifetime of the + directory is tied to the lifetime of the service itself. Similarly, <varname>StateDirectory=</varname>, + <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, and + <varname>ConfigurationDirectory=</varname> should be used to create directories under + <filename>/var/lib/</filename>, <filename>/var/cache/</filename>, <filename>/var/log/</filename>, and + <filename>/etc/</filename>. <filename>tmpfiles.d</filename> should be used for files whose lifetime is + independent of any service or requires more complicated configuration.</para> + </refsect1> + + <refsect1> + <title>Configuration Directories and Precedence</title> + + <para>Each configuration file shall be named in the style of + <filename><replaceable>package</replaceable>.conf</filename> or + <filename><replaceable>package</replaceable>-<replaceable>part</replaceable>.conf</filename>. + The second variant should be used when it is desirable to make it + easy to override just this part of configuration.</para> + + <para>Files in <filename>/etc/tmpfiles.d</filename> override files with the same name in + <filename>/usr/lib/tmpfiles.d</filename> and <filename>/run/tmpfiles.d</filename>. Files in + <filename>/run/tmpfiles.d</filename> override files with the same name in + <filename>/usr/lib/tmpfiles.d</filename>. Packages should install their configuration files in + <filename>/usr/lib/tmpfiles.d</filename>. Files in <filename>/etc/tmpfiles.d</filename> are reserved for + the local administrator, who may use this logic to override the configuration files installed by vendor + packages. All configuration files are sorted by their filename in lexicographic order, regardless of + which of the directories they reside in. If multiple files specify the same path, the entry in the file + with the lexicographically earliest name will be applied (note that lines suppressed due to the + <literal>!</literal> are filtered before application, meaning that if an early line carries the + exclamation mark and is suppressed because of that, a later line matching in path will be applied). All + other conflicting entries will be logged as errors. When two lines are prefix path and suffix path of + each other, then the prefix line is always created first, the suffix later (and if removal applies to the + line, the order is reversed: the suffix is removed first, the prefix later). Lines that take globs are + applied after those accepting no globs. If multiple operations shall be applied on the same file (such as + ACL, xattr, file attribute adjustments), these are always done in the same fixed order. Except for those + cases, the files/directories are processed in the order they are listed.</para> + + <para>If the administrator wants to disable a configuration file + supplied by the vendor, the recommended way is to place a symlink + to <filename>/dev/null</filename> in + <filename>/etc/tmpfiles.d/</filename> bearing the same filename. + </para> + </refsect1> + + <refsect1> + <title>Configuration File Format</title> + + <para>The configuration format is one line per path containing + type, path, mode, ownership, age, and argument fields:</para> + + <programlisting>#Type Path Mode User Group Age Argument +d /run/user 0755 root root 10d - +L /tmp/foobar - - - - /dev/null</programlisting> + + <para>Fields may be enclosed within quotes and contain C-style escapes.</para> + + <refsect2> + <title>Type</title> + + <para>The type consists of a single letter and optionally an exclamation mark (<literal>!</literal>) + and/or minus sign (<literal>-</literal>).</para> + + <para>The following line types are understood:</para> + + <variablelist> + <varlistentry> + <term><varname>f</varname></term> + <term><varname>f+</varname></term> + <listitem><para><varname>f</varname> will create a file if it does not exist yet. If the argument + parameter is given and the file did not exist yet, it will be written to the file. + <varname>f+</varname> will create or truncate the file. If the argument parameter is given, it will + be written to the file. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>w</varname></term> + <term><varname>w+</varname></term> + <listitem><para>Write the argument parameter to a file, if the file exists. + If suffixed with <varname>+</varname>, the line will be appended to the file. + If your configuration writes multiple lines to the same file, use <varname>w+</varname>. + Lines of this type accept shell-style globs in place of normal path names. + The argument parameter will be written without a trailing newline. + C-style backslash escapes are interpreted. Follows symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>d</varname></term> + <listitem><para>Create a directory. The mode and ownership will be adjusted if specified. Contents + of this directory are subject to time based cleanup if the age argument is specified. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>D</varname></term> + <listitem><para>Similar to <varname>d</varname>, but in addition the contents of the directory will + be removed when <option>--remove</option> is used.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>e</varname></term> + <listitem><para>Adjust the mode and ownership of existing directories and remove their contents + based on age. + Lines of this type accept shell-style globs in place of normal path names. Contents of the + directories are subject to time based cleanup if the age argument is specified. If the age argument + is <literal>0</literal>, contents will be unconditionally deleted every time + <command>systemd-tmpfiles --clean</command> is run.</para> + + <para>For this entry to be useful, at least one of the mode, user, group, or age arguments must be + specified, since otherwise this entry has no effect. As an exception, an entry with no effect may + be useful when combined with <varname>!</varname>, see the examples.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>v</varname></term> + <listitem><para>Create a subvolume if the path does not exist yet, the file system supports + subvolumes (btrfs), and the system itself is installed into a subvolume (specifically: the root + directory <filename>/</filename> is itself a subvolume). Otherwise, create a normal directory, in + the same way as <varname>d</varname>.</para> + + <para>A subvolume created with this line type is not assigned to any higher-level quota group. For + that, use <varname>q</varname> or <varname>Q</varname>, which allow creating simple quota group + hierarchies, see below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>q</varname></term> + <listitem><para>Create a subvolume or directory the same as <varname>v</varname>, but assign the + subvolume to the same higher-level quota groups as the parent. This ensures that higher-level + limits and accounting applied to the parent subvolume also include the specified subvolume. On + non-btrfs file systems, this line type is identical to <varname>d</varname>.</para> + + <para>If the subvolume already exists, no change to the quota hierarchy is made, regardless of whether the + subvolume is already attached to a quota group or not. Also see <varname>Q</varname> below. See <citerefentry + project='die-net'><refentrytitle>btrfs-qgroup</refentrytitle><manvolnum>8</manvolnum></citerefentry> for + details about the btrfs quota group concept.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Q</varname></term> + <listitem><para>Create the subvolume or directory the same as <varname>v</varname>, but assign the + new subvolume to a new leaf quota group. Instead of copying the higher-level quota group + assignments from the parent as is done with <varname>q</varname>, the lowest quota group of the + parent subvolume is determined that is not the leaf quota group. Then, an "intermediary" quota + group is inserted that is one level below this level, and shares the same ID part as the specified + subvolume. If no higher-level quota group exists for the parent subvolume, a new quota group at + level 255 sharing the same ID as the specified subvolume is inserted instead. This new intermediary + quota group is then assigned to the parent subvolume's higher-level quota groups, and the specified + subvolume's leaf quota group is assigned to it.</para> + + <para>Effectively, this has a similar effect as <varname>q</varname>, however introduces a new higher-level + quota group for the specified subvolume that may be used to enforce limits and accounting to the specified + subvolume and children subvolume created within it. Thus, by creating subvolumes only via + <varname>q</varname> and <varname>Q</varname>, a concept of "subtree quotas" is implemented. Each subvolume + for which <varname>Q</varname> is set will get a "subtree" quota group created, and all child subvolumes + created within it will be assigned to it. Each subvolume for which <varname>q</varname> is set will not get + such a "subtree" quota group, but it is ensured that they are added to the same "subtree" quota group as + their immediate parents.</para> + + <para>It is recommended to use <varname>Q</varname> for subvolumes that typically contain further subvolumes, + and where it is desirable to have accounting and quota limits on all child subvolumes together. Examples for + <varname>Q</varname> are typically <filename>/home/</filename> or <filename>/var/lib/machines/</filename>. In + contrast, <varname>q</varname> should be used for subvolumes that either usually do not include further + subvolumes or where no accounting and quota limits are needed that apply to all child subvolumes + together. Examples for <varname>q</varname> are typically <filename>/var/</filename> or + <filename>/var/tmp/</filename>. </para> + + <para>As with <varname>q</varname>, <varname>Q</varname> has no effect on the quota group hierarchy if the + subvolume already exists, regardless of whether the subvolume already belong to a quota group or not. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>p</varname></term> + <term><varname>p+</varname></term> + <listitem><para>Create a named pipe (FIFO) if it does not + exist yet. If suffixed with <varname>+</varname> and a file + already exists where the pipe is to be created, it will be + removed and be replaced by the pipe.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>L</varname></term> + <term><varname>L+</varname></term> + <listitem><para>Create a symlink if it does not exist + yet. If suffixed with <varname>+</varname> and a file or + directory already exists where the symlink is to be created, + it will be removed and be replaced by the symlink. If the + argument is omitted, symlinks to files with the same name + residing in the directory + <filename>/usr/share/factory/</filename> are created. Note + that permissions and ownership on symlinks are ignored. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>c</varname></term> + <term><varname>c+</varname></term> + <listitem><para>Create a character device node if it does + not exist yet. If suffixed with <varname>+</varname> and a + file already exists where the device node is to be created, + it will be removed and be replaced by the device node. It is + recommended to suffix this entry with an exclamation mark to + only create static device nodes at boot, as udev will not + manage static device nodes that are created at runtime. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>b</varname></term> + <term><varname>b+</varname></term> + <listitem><para>Create a block device node if it does not + exist yet. If suffixed with <varname>+</varname> and a file + already exists where the device node is to be created, it + will be removed and be replaced by the device node. It is + recommended to suffix this entry with an exclamation mark to + only create static device nodes at boot, as udev will not + manage static device nodes that are created at runtime. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>C</varname></term> + <listitem><para>Recursively copy a file or directory, if the + destination files or directories do not exist yet or the + destination directory is empty. Note that this command will not + descend into subdirectories if the destination directory already + exists and is not empty. Instead, the entire copy operation is + skipped. If the argument is omitted, files from the source directory + <filename>/usr/share/factory/</filename> with the same name + are copied. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>x</varname></term> + <listitem><para>Ignore a path during cleaning. Use this type + to exclude paths from clean-up as controlled with the Age + parameter. Note that lines of this type do not influence the + effect of <varname>r</varname> or <varname>R</varname> + lines. Lines of this type accept shell-style globs in place + of normal path names. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>X</varname></term> + <listitem><para>Ignore a path during cleaning. Use this type + to exclude paths from clean-up as controlled with the Age + parameter. Unlike <varname>x</varname>, this parameter will + not exclude the content if path is a directory, but only + directory itself. Note that lines of this type do not + influence the effect of <varname>r</varname> or + <varname>R</varname> lines. Lines of this type accept + shell-style globs in place of normal path names. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>r</varname></term> + <listitem><para>Remove a file or directory if it exists. + This may not be used to remove non-empty directories, use + <varname>R</varname> for that. Lines of this type accept + shell-style globs in place of normal path + names. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>R</varname></term> + <listitem><para>Recursively remove a path and all its + subdirectories (if it is a directory). Lines of this type + accept shell-style globs in place of normal path + names. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>z</varname></term> + <listitem><para>Adjust the access mode, user and group ownership, and restore the SELinux security + context of a file or directory, if it exists. Lines of this type accept shell-style globs in place + of normal path names. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Z</varname></term> + <listitem><para>Recursively set the access mode, user and group ownership, and restore the SELinux + security context of a file or directory if it exists, as well as of its subdirectories and the + files contained therein (if applicable). Lines of this type accept shell-style globs in place of + normal path names. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>t</varname></term> + <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>Same as <varname>t</varname>, but operates recursively.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>h</varname></term> + <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 + <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> + + <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>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), 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> + <term><varname>A</varname></term> + <term><varname>A+</varname></term> + <listitem><para>Same as <varname>a</varname> and + <varname>a+</varname>, but recursive. Does not follow + symlinks.</para></listitem> + </varlistentry> + </variablelist> + + <para>If the exclamation mark (<literal>!</literal>) is used, this line is only safe to execute during + boot, and can break a running system. Lines without the exclamation mark are presumed to be safe to + execute at any time, e.g. on package upgrades. <command>systemd-tmpfiles</command> will take lines with + an exclamation mark only into consideration, if the <option>--boot</option> option is given.</para> + + <para>For example: + <programlisting># Make sure these are created by default so that nobody else can +d /tmp/.X11-unix 1777 root root 10d + +# Unlink the X11 lock files +r! /tmp/.X[0-9]*-lock</programlisting> + The second line in contrast to the first one would break a + running system, and will only be executed with + <option>--boot</option>.</para> + + <para>If the minus sign (<literal>-</literal>) is used, this line failing to run successfully during + create (and only create) will not cause the execution of <command>systemd-tmpfiles</command> to return + an error.</para> + + <para>For example: + <programlisting># Modify sysfs but don't fail if we are in a container with a read-only /proc +w- /proc/sys/vm/swappiness - - - - 10</programlisting></para> + + <para>Note that for all line types that result in creation of any kind of file node + (i.e. <varname>f</varname>/<varname>F</varname>, + <varname>d</varname>/<varname>D</varname>/<varname>v</varname>/<varname>q</varname>/<varname>Q</varname>, + <varname>p</varname>, <varname>L</varname>, <varname>c</varname>/<varname>b</varname> and <varname>C</varname>) + leading directories are implicitly created if needed, owned by root with an access mode of 0755. In order to + create them with different modes or ownership make sure to add appropriate <varname>d</varname> lines.</para> + </refsect2> + + <refsect2> + <title>Path</title> + + <para>The file system path specification supports simple + specifier expansion, see below. The path (after expansion) must be + absolute.</para> + </refsect2> + + <refsect2> + <title>Mode</title> + + <para>The file access mode to use when creating this file or + directory. If omitted or when set to <literal>-</literal>, the + default is used: 0755 for directories, 0644 for all other file + objects. For <varname>z</varname>, <varname>Z</varname> lines, + if omitted or when set to <literal>-</literal>, the file access + mode will not be modified. This parameter is ignored for + <varname>x</varname>, <varname>r</varname>, + <varname>R</varname>, <varname>L</varname>, <varname>t</varname>, + and <varname>a</varname> lines.</para> + + <para>Optionally, if prefixed with <literal>~</literal>, the + access mode is masked based on the already set access bits for + existing file or directories: if the existing file has all + executable bits unset, all executable bits are removed from the + new access mode, too. Similarly, if all read bits are removed + from the old access mode, they will be removed from the new + access mode too, and if all write bits are removed, they will be + removed from the new access mode too. In addition, the + sticky/SUID/SGID bit is removed unless applied to a + directory. This functionality is particularly useful in + conjunction with <varname>Z</varname>.</para> + </refsect2> + + <refsect2> + <title>User, Group</title> + + <para>The user and group to use for this file or directory. This may either be a numeric ID or a + user/group name. If omitted or when set to <literal>-</literal>, the user and group of the user who + invokes <command>systemd-tmpfiles</command> is used. For <varname>z</varname> and <varname>Z</varname> + 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/#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> + <title>Age</title> + <para>The date field, when set, is used to decide what files to + delete when cleaning. If a file or directory is older than the + current time minus the age field, it is deleted. The field + format is a series of integers each followed by one of the + following suffixes for the respective time units: + <constant>s</constant>, + <constant>m</constant> or <constant>min</constant>, + <constant>h</constant>, + <constant>d</constant>, + <constant>w</constant>, + <constant>ms</constant>, and + <constant>us</constant>, + meaning seconds, minutes, hours, days, weeks, + milliseconds, and microseconds, respectively. Full names of the time units can + be used too. + </para> + + <para>If multiple integers and units are specified, the time + values are summed. If an integer is given without a unit, + <constant>s</constant> is assumed. + </para> + + <para>When the age is set to zero, the files are cleaned + unconditionally.</para> + + <para>The age field only applies to lines starting with + <varname>d</varname>, <varname>D</varname>, <varname>e</varname>, + <varname>v</varname>, <varname>q</varname>, + <varname>Q</varname>, <varname>C</varname>, <varname>x</varname> + and <varname>X</varname>. If omitted or set to + <literal>-</literal>, no automatic clean-up is done.</para> + + <para>If the age field starts with a tilde character + <literal>~</literal>, the clean-up is only applied to files and + directories one level inside the directory specified, but not + the files and directories immediately inside it.</para> + + <para>The age of a file system entry is determined from its last + modification timestamp (mtime), its last access timestamp (atime), + and (except for directories) its last status change timestamp + (ctime). Any of these three (or two) values will prevent cleanup + if it is more recent than the current time minus the age + field.</para> + + <para>Note that while the aging algorithm is run a 'shared' BSD file lock (see <citerefentry + project='man-pages'><refentrytitle>flock</refentrytitle><manvolnum>2</manvolnum></citerefentry>) is + taken on each directory the algorithm descends into (and each directory below that, and so on). If the + aging algorithm finds a lock is already taken on some directory, it (and everything below it) is + skipped. Applications may use this to temporarily exclude certain directory subtrees from the aging + algorithm: the applications can take a BSD file lock themselves, and as long as they keep it aging of + the directory and everything below it is disabled.</para> + </refsect2> + + <refsect2> + <title>Argument</title> + + <para>For <varname>L</varname> lines determines the destination path of the symlink. For <varname>c</varname> and + <varname>b</varname>, determines the major/minor of the device node, with major and minor formatted as integers, + separated by <literal>:</literal>, e.g. <literal>1:3</literal>. For <varname>f</varname>, <varname>F</varname>, + and <varname>w</varname>, the argument may be used to specify a short string that is written to the file, + suffixed by a newline. For <varname>C</varname>, specifies the source file or directory. For <varname>t</varname> + and <varname>T</varname>, determines extended attributes to be set. For <varname>a</varname> and + <varname>A</varname>, determines ACL attributes to be set. For <varname>h</varname> and <varname>H</varname>, + determines the file attributes to set. Ignored for all other lines.</para> + + <para>This field can contain specifiers, see below.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Specifiers</title> + + <para>Specifiers can be used in the "path" and "argument" fields. + An unknown or unresolvable specifier is treated as invalid configuration. + The following expansions are understood:</para> + <table class='specifiers'> + <title>Specifiers available</title> + <tgroup cols='3' align='left' colsep='1' rowsep='1'> + <colspec colname="spec" /> + <colspec colname="mean" /> + <colspec colname="detail" /> + <thead> + <row> + <entry>Specifier</entry> + <entry>Meaning</entry> + <entry>Details</entry> + </row> + </thead> + <tbody> + <xi:include href="standard-specifiers.xml" xpointer="a"/> + <xi:include href="standard-specifiers.xml" xpointer="b"/> + <xi:include href="standard-specifiers.xml" xpointer="B"/> + <row> + <entry><literal>%C</literal></entry> + <entry>System or user cache directory</entry> + <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_CACHE_HOME</varname>, and <filename>/var/cache</filename> otherwise.</entry> + </row> + <row> + <entry><literal>%g</literal></entry> + <entry>User group</entry> + <entry>This is the name of the group running the command. In case of the system instance this resolves to <literal>root</literal>.</entry> + </row> + <row> + <entry><literal>%G</literal></entry> + <entry>User GID</entry> + <entry>This is the numeric GID of the group running the command. In case of the system instance this resolves to <constant>0</constant>.</entry> + </row> + <row> + <entry><literal>%h</literal></entry> + <entry>User home directory</entry> + <entry>This is the home directory of the user running the command. In case of the system instance this resolves to <literal>/root</literal>.</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="H"/> + <xi:include href="standard-specifiers.xml" xpointer="l"/> + <row> + <entry><literal>%L</literal></entry> + <entry>System or user log directory</entry> + <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_CONFIG_HOME</varname> with <filename index="false">/log</filename> appended, and <filename>/var/log</filename> otherwise.</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="m"/> + <xi:include href="standard-specifiers.xml" xpointer="o"/> + <row> + <entry><literal>%S</literal></entry> + <entry>System or user state directory</entry> + <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_CONFIG_HOME</varname>, and <filename>/var/lib</filename> otherwise.</entry> + </row> + <row> + <entry><literal>%t</literal></entry> + <entry>System or user runtime directory</entry> + <entry>In <option>--user</option> mode, this is the same <varname>$XDG_RUNTIME_DIR</varname>, and <filename>/run/</filename> otherwise.</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="T"/> + <row> + <entry><literal>%u</literal></entry> + <entry>User name</entry> + <entry>This is the name of the user running the command. In case of the system instance this resolves to <literal>root</literal>.</entry> + </row> + <row> + <entry><literal>%U</literal></entry> + <entry>User UID</entry> + <entry>This is the numeric UID of the user running the command. In case of the system instance this resolves to <constant>0</constant>.</entry> + </row> + <xi:include href="standard-specifiers.xml" xpointer="v"/> + <xi:include href="standard-specifiers.xml" xpointer="V"/> + <xi:include href="standard-specifiers.xml" xpointer="w"/> + <xi:include href="standard-specifiers.xml" xpointer="W"/> + <xi:include href="standard-specifiers.xml" xpointer="percent"/> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>Create directories with specific mode and ownership</title> + <para> + <citerefentry project='die-net'><refentrytitle>screen</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + needs two directories created at boot with specific modes and ownership:</para> + + <programlisting># /usr/lib/tmpfiles.d/screen.conf +d /run/screens 1777 root screen 10d +d /run/uscreens 0755 root screen 10d12h +</programlisting> + + <para>Contents of <filename>/run/screens</filename> and /run/uscreens will + be cleaned up after 10 and 10½ days, respectively.</para> + </example> + + <example> + <title>Create a directory with a SMACK attribute</title> + <programlisting>D /run/cups - - - - +t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces="foo bar" + </programlisting> + + <para>The directory will be owned by root and have default mode. Its contents are + not subject to time based cleanup, but will be obliterated when + <command>systemd-tmpfiles --remove</command> runs.</para> + </example> + + <example> + <title>Create a directory and prevent its contents from cleanup</title> + <para> + <citerefentry project='die-net'><refentrytitle>abrt</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + needs a directory created at boot with specific mode and ownership and its content + should be preserved from the automatic cleanup applied to the contents of + <filename>/var/tmp</filename>:</para> + + <programlisting># /usr/lib/tmpfiles.d/tmp.conf +d /var/tmp 1777 root root 30d +</programlisting> + + <programlisting># /usr/lib/tmpfiles.d/abrt.conf +d /var/tmp/abrt 0755 abrt abrt - +</programlisting> + </example> + + <example> + <title>Apply clean up during boot and based on time</title> + + <programlisting># /usr/lib/tmpfiles.d/dnf.conf +r! /var/cache/dnf/*/*/download_lock.pid +r! /var/cache/dnf/*/*/metadata_lock.pid +r! /var/lib/dnf/rpmdb_lock.pid +e /var/cache/dnf/ - - - 30d +</programlisting> + + <para>The lock files will be removed during boot. Any files and directories in + <filename>/var/cache/dnf/</filename> will be removed after they have not been + accessed in 30 days.</para> + </example> + + <example> + <title>Empty the contents of a cache directory on boot</title> + + <programlisting># /usr/lib/tmpfiles.d/krb5rcache.conf +e! /var/cache/krb5rcache - - - 0 +</programlisting> + + <para>Any files and subdirectories in <filename>/var/cache/krb5rcache/</filename> + will be removed on boot. The directory will not be created. + </para> + </example> + </refsect1> + + <refsect1> + <title><filename>/run/</filename> and <filename>/var/run/</filename></title> + <para><filename>/var/run/</filename> is a deprecated symlink to <filename>/run/</filename>, and + applications should use the latter. <command>systemd-tmpfiles</command> will warn if + <filename>/var/run/</filename> is used.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>attr</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>getfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>setfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>getfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>chattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>btrfs-subvolume</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>btrfs-qgroup</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/udev.conf.xml b/man/udev.conf.xml new file mode 100644 index 0000000..df0a70c --- /dev/null +++ b/man/udev.conf.xml @@ -0,0 +1,127 @@ +<?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-or-later --> + +<refentry id="udev.conf" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev.conf</refname> + <refpurpose>Configuration for device event managing daemon</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/udev/udev.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para> + <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + expects its main configuration file at + <filename>/etc/udev/udev.conf</filename>. It consists of a set + of variables allowing the user to override default udev + values. All empty lines or lines beginning with '#' are + ignored. The following variables can be set: + </para> + + <variablelist class='config-directives'> + <varlistentry> + <term><varname>udev_log=</varname></term> + + <listitem> + <para>The log level. Valid values are the numerical + syslog priorities or their textual representations: + <option>err</option>, <option>info</option> and + <option>debug</option>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>children_max=</varname></term> + + <listitem> + <para>An integer. The maximum number of events executed in parallel.</para> + + <para>This is the same as the <option>--children-max=</option> option.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>exec_delay=</varname></term> + + <listitem> + <para>An integer. Delay the execution of <varname>RUN</varname> + instructions by the given number of seconds. This option + might be useful when debugging system crashes during + coldplug caused by loading non-working kernel + modules.</para> + + <para>This is the same as the <option>--exec-delay=</option> option.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>event_timeout=</varname></term> + + <listitem> + <para>An integer. The number of seconds to wait for events to finish. After + this time, the event will be terminated. The default is 180 seconds.</para> + + <para>This is the same as the <option>--event-timeout=</option> option.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>resolve_names=</varname></term> + + <listitem> + <para>Specifies when systemd-udevd should resolve names of users and groups. When set to + <option>early</option> (the default), names will be resolved when the rules are parsed. + When set to <option>late</option>, names will be resolved for every event. When set to + <option>never</option>, names will never be resolved and all devices will be owned by + root.</para> + + <para>This is the same as the <option>--resolve-names=</option> option.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>timeout_signal=</varname></term> + + <listitem> + <para>Specifies a signal that <filename>systemd-udevd</filename> will send on worker + timeouts. Note that both workers and spawned processes will be killed using this + signal. Defaults to <option>SIGKILL</option>.</para> + </listitem> + </varlistentry> + </variablelist> + + <para> + In addition, <filename>systemd-udevd</filename> can be configured + by command line options and the kernel command line (see + <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>). + </para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/udev.xml b/man/udev.xml new file mode 100644 index 0000000..14e4c21 --- /dev/null +++ b/man/udev.xml @@ -0,0 +1,832 @@ +<?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-or-later + Copyright © 2014 Jason St. John +--> + +<refentry id="udev"> + <refentryinfo> + <title>udev</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev</refentrytitle> + <manvolnum>7</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev</refname> + <refpurpose>Dynamic device management</refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + <para>udev supplies the system software with device events, manages permissions + of device nodes and may create additional symlinks in the <filename>/dev/</filename> + directory, or renames network interfaces. The kernel usually just assigns unpredictable + device names based on the order of discovery. Meaningful symlinks or network device + names provide a way to reliably identify devices based on their properties or + current configuration.</para> + + <para>The udev daemon, <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle> + <manvolnum>8</manvolnum></citerefentry>, receives device uevents directly from + the kernel whenever a device is added or removed from the system, or it changes its + state. When udev receives a device event, it matches its configured set of rules + against various device attributes to identify the device. Rules that match may + provide additional device information to be stored in the udev database or + to be used to create meaningful symlink names.</para> + + <para>All device information udev processes is stored in the udev database and + sent out to possible event subscribers. Access to all stored data and the event + sources is provided by the library libudev.</para> + </refsect1> + + <refsect1> + <title>Rules Files</title> + <para>The udev rules are read from the files located in the system rules directories + <filename>/usr/lib/udev/rules.d</filename> and <filename>/usr/local/lib/udev/rules.d</filename>, the + volatile runtime directory <filename>/run/udev/rules.d</filename> and the local administration + directory <filename>/etc/udev/rules.d</filename>. All rules files are collectively sorted and + processed in lexical order, regardless of the directories in which they live. However, files with + identical filenames replace each other. Files in <filename>/etc/</filename> have the highest priority, + files in <filename>/run/</filename> take precedence over files with the same name under + <filename>/usr/</filename>. This can be used to override a system-supplied rules file with a local + file if needed; a symlink in <filename>/etc/</filename> with the same name as a rules file in + <filename>/usr/lib/</filename>, pointing to <filename>/dev/null</filename>, disables the rules file + entirely. Rule files must have the extension <filename>.rules</filename>; other extensions are + ignored.</para> + + <para>Every line in the rules file contains at least one key-value pair. + Except for empty lines or lines beginning with <literal>#</literal>, which are ignored. + There are two kinds of keys: match and assignment. + If all match keys match against their values, the rule gets applied and the + assignment keys get the specified values assigned.</para> + + <para>A matching rule may rename a network interface, add symlinks + pointing to the device node, or run a specified program as part of + the event handling.</para> + + <para>A rule consists of a comma-separated list of one or more key-operator-value expressions. + Each expression has a distinct effect, depending on the key and operator used.</para> + + <refsect2> + <title>Operators</title> + <variablelist> + <varlistentry> + <term><literal>==</literal></term> + <listitem> + <para>Compare for equality.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>!=</literal></term> + <listitem> + <para>Compare for inequality.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>=</literal></term> + <listitem> + <para>Assign a value to a key. Keys that represent a list are reset + and only this single value is assigned.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>+=</literal></term> + <listitem> + <para>Add the value to a key that holds a list of entries.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>-=</literal></term> + <listitem> + <para>Remove the value from a key that holds a list of entries.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>:=</literal></term> + <listitem> + <para>Assign a value to a key finally; disallow any later changes.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Values</title> + <para>Values are written as double quoted strings, such as ("string"). + To include a quotation mark (") in the value, precede it by a backslash (\"). + Any other occurrences of a character followed by a backslash are not further unescaped. + That is, "\t\n" is treated as four characters: + backslash, lowercase t, backslash, lowercase n.</para> + + <para>The string can be prefixed with a lowercase e (e"string\n") to mark the string as + <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style escaped</ulink>. + For example, e"string\n" is parsed as 7 characters: 6 lowercase letters and a newline. + This can be useful for writing special characters when a kernel driver requires them.</para> + + <para>Please note that <constant>NUL</constant> is not allowed in either string variant.</para> + </refsect2> + + <refsect2> + <title>Keys</title> + <para>The following key names can be used to match against device properties. + Some of the keys also match against properties of the parent devices in sysfs, + not only the device that has generated the event. If multiple keys that match + a parent device are specified in a single rule, all these keys must match at + one and the same parent device.</para> + <variablelist class='udev-directives'> + <varlistentry> + <term><varname>ACTION</varname></term> + <listitem> + <para>Match the name of the event action.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DEVPATH</varname></term> + <listitem> + <para>Match the devpath of the event device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>KERNEL</varname></term> + <listitem> + <para>Match the name of the event device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>NAME</varname></term> + <listitem> + <para>Match the name of a network interface. It can be used once the + NAME key has been set in one of the preceding rules.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYMLINK</varname></term> + <listitem> + <para>Match the name of a symlink targeting the node. It can + be used once a SYMLINK key has been set in one of the preceding + rules. There may be multiple symlinks; only one needs to match. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SUBSYSTEM</varname></term> + <listitem> + <para>Match the subsystem of the event device.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DRIVER</varname></term> + <listitem> + <para>Match the driver name of the event device. Only set this key for devices + which are bound to a driver at the time the event is generated.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ATTR{<replaceable>filename</replaceable>}</varname></term> + <listitem> + <para>Match sysfs attribute values of the event device. Trailing + whitespace in the attribute values is ignored unless the specified match + value itself contains trailing whitespace. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>SYSCTL{<replaceable>kernel parameter</replaceable>}</varname></term> + <listitem> + <para>Match a kernel parameter value. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>KERNELS</varname></term> + <listitem> + <para>Search the devpath upwards for a matching device name.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SUBSYSTEMS</varname></term> + <listitem> + <para>Search the devpath upwards for a matching device subsystem name.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>DRIVERS</varname></term> + <listitem> + <para>Search the devpath upwards for a matching device driver name.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ATTRS{<replaceable>filename</replaceable>}</varname></term> + <listitem> + <para>Search the devpath upwards for a device with matching sysfs attribute values. + If multiple <varname>ATTRS</varname> matches are specified, all of them + must match on the same device. Trailing whitespace in the attribute values is ignored + unless the specified match value itself contains trailing whitespace.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TAGS</varname></term> + <listitem> + <para>Search the devpath upwards for a device with matching tag.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ENV{<replaceable>key</replaceable>}</varname></term> + <listitem> + <para>Match against a device property value.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>CONST{<replaceable>key</replaceable>}</varname></term> + <listitem> + <para>Match against a system-wide constant. Supported keys are:</para> + <variablelist> + <varlistentry> + <term><literal>arch</literal></term> + <listitem> + <para>System's architecture. See <option>ConditionArchitecture=</option> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for possible values.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>virt</literal></term> + <listitem> + <para>System's virtualization environment. See + <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for possible values.</para> + </listitem> + </varlistentry> + </variablelist> + <para>Unknown keys will never match.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TAG</varname></term> + <listitem> + <para>Match against a device tag.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TEST{<replaceable>octal mode mask</replaceable>}</varname></term> + <listitem> + <para>Test the existence of a file. An octal mode mask can be specified + if needed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>PROGRAM</varname></term> + <listitem> + <para>Execute a program to determine whether there is a match; the key is true if the program + returns successfully. The device properties are made available to the executed program in the + environment. The program's standard output is available in the <varname>RESULT</varname> + key.</para> + + <para>This can only be used for very short-running foreground tasks. For details, see + <varname>RUN</varname>.</para> + + <para>Note that multiple <varname>PROGRAM</varname> keys may be specified in one rule, and + <literal>=</literal>, <literal>:=</literal>, and <literal>+=</literal> have the same effect as + <literal>==</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RESULT</varname></term> + <listitem> + <para>Match the returned string of the last <varname>PROGRAM</varname> call. + This key can be used in the same or in any later rule after a + <varname>PROGRAM</varname> call.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>Most of the fields support shell glob pattern matching and + alternate patterns. The following special characters are supported:</para> + <variablelist> + <varlistentry> + <term><literal>*</literal></term> + <listitem> + <para>Matches zero or more characters.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>?</literal></term> + <listitem> + <para>Matches any single character.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>[]</literal></term> + <listitem> + <para>Matches any single character specified within the brackets. For + example, the pattern string <literal>tty[SR]</literal> + would match either <literal>ttyS</literal> or <literal>ttyR</literal>. + Ranges are also supported via the <literal>-</literal> character. + For example, to match on the range of all digits, the pattern + <literal>[0-9]</literal> could be used. If the first character + following the <literal>[</literal> is a <literal>!</literal>, + any characters not enclosed are matched.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>|</literal></term> + <listitem> + <para>Separates alternative patterns. For example, the pattern string + <literal>abc|x*</literal> would match either <literal>abc</literal> + or <literal>x*</literal>.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>The following keys can get values assigned:</para> + <variablelist class='udev-directives'> + <varlistentry> + <term><varname>NAME</varname></term> + <listitem> + <para>The name to use for a network interface. See + <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a higher-level mechanism for setting the interface name. + The name of a device node cannot be changed by udev, only additional + symlinks can be created.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYMLINK</varname></term> + <listitem> + <para>The name of a symlink targeting the node. Every matching rule adds + this value to the list of symlinks to be created.</para> + <para>The set of characters to name a symlink is limited. Allowed + characters are <literal>0-9A-Za-z#+-.:=@_/</literal>, valid UTF-8 character + sequences, and <literal>\x00</literal> hex encoding. All other + characters are replaced by a <literal>_</literal> character.</para> + <para>Multiple symlinks may be specified by separating the names by the + space character. In case multiple devices claim the same name, the link + always points to the device with the highest link_priority. If the current + device goes away, the links are re-evaluated and the device with the + next highest link_priority becomes the owner of the link. If no + link_priority is specified, the order of the devices (and which one of + them owns the link) is undefined.</para> + <para>Symlink names must never conflict with the kernel's default device + node names, as that would result in unpredictable behavior. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>OWNER</varname>, <varname>GROUP</varname>, <varname>MODE</varname></term> + <listitem> + <para>The permissions for the device node. Every specified value overrides + the compiled-in default value.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SECLABEL{<replaceable>module</replaceable>}</varname></term> + <listitem> + <para>Applies the specified Linux Security Module label to the device node.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ATTR{<replaceable>key</replaceable>}</varname></term> + <listitem> + <para>The value that should be written to a sysfs attribute of the + event device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>SYSCTL{<replaceable>kernel parameter</replaceable>}</varname></term> + <listitem> + <para>The value that should be written to kernel parameter.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ENV{<replaceable>key</replaceable>}</varname></term> + <listitem> + <para>Set a device property value. Property names with a leading <literal>.</literal> + are neither stored in the database nor exported to events or + external tools (run by, for example, the <varname>PROGRAM</varname> + match key).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>TAG</varname></term> + <listitem> + <para>Attach a tag to a device. This is used to filter events for users + of libudev's monitor functionality, or to enumerate a group of tagged + devices. The implementation can only work efficiently if only a few + tags are attached to a device. It is only meant to be used in + contexts with specific device filter requirements, and not as a + general-purpose flag. Excessive use might result in inefficient event + handling.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>RUN{<replaceable>type</replaceable>}</varname></term> + <listitem> + <para>Specify a program to be executed after processing of all the rules for the event. With + <literal>+=</literal>, this invocation is added to the list, and with <literal>=</literal> or + <literal>:=</literal>, it replaces any previous contents of the list. Please note that both + <literal>program</literal> and <literal>builtin</literal> types described below use a single + list, so clearing the list with <literal>:=</literal> and <literal>=</literal> affects both + types.</para> + + <para><replaceable>type</replaceable> may be:</para> + <variablelist> + <varlistentry> + <term><literal>program</literal></term> + <listitem> + <para>Execute an external program specified as the assigned + value. If no absolute path is given, the program is expected + to live in <filename>/usr/lib/udev</filename>; otherwise, the + absolute path must be specified.</para> + <para>This is the default if no <replaceable>type</replaceable> + is specified.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>builtin</literal></term> + <listitem> + <para>As <varname>program</varname>, but use one of the + built-in programs rather than an external one.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>The program name and following arguments are separated by spaces. Single quotes can be + used to specify arguments with spaces.</para> + + <para>This can only be used for very short-running foreground tasks. Running an event process for + a long period of time may block all further events for this or a dependent device.</para> + + <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>Starting daemons or other long-running processes is not allowed; the forked processes, + detached or not, will be unconditionally killed after the event handling has finished. In order + to activate long-running processes from udev rules, provide a service unit and pull it in from a + udev device using the <varname>SYSTEMD_WANTS</varname> device property. See + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>LABEL</varname></term> + <listitem> + <para>A named label to which a <varname>GOTO</varname> may jump.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>GOTO</varname></term> + <listitem> + <para>Jumps to the next <varname>LABEL</varname> with a matching name.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IMPORT{<replaceable>type</replaceable>}</varname></term> + <listitem> + <para>Import a set of variables as device properties, depending on + <replaceable>type</replaceable>:</para> + + <variablelist> + <varlistentry> + <term><literal>program</literal></term> + <listitem> + <para>Execute an external program specified as the assigned + value and, if it returns successfully, + import its output, which must be in environment key + format. Path specification, command/argument separation, + and quoting work like in <varname>RUN</varname>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>builtin</literal></term> + <listitem> + <para>Similar to <literal>program</literal>, but use one of the + built-in programs rather than an external one.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>file</literal></term> + <listitem> + <para>Import a text file specified as the assigned value, the content + of which must be in environment key format.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>db</literal></term> + <listitem> + <para>Import a single property specified as the assigned value from the + current device database. This works only if the database is already populated + by an earlier event.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>cmdline</literal></term> + <listitem> + <para>Import a single property from the kernel command line. For simple flags + the value of the property is set to <literal>1</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>parent</literal></term> + <listitem> + <para>Import the stored keys from the parent device by reading + the database entry of the parent device. The value assigned to + <option>IMPORT{parent}</option> is used as a filter of key names + to import (with the same shell glob pattern matching used for + comparisons).</para> + </listitem> + </varlistentry> + </variablelist> + + <para>This can only be used for very short-running foreground tasks. For details see + <option>RUN</option>.</para> + + <para>Note that multiple <varname>IMPORT{}</varname> keys may be specified in one rule, and + <literal>=</literal>, <literal>:=</literal>, and <literal>+=</literal> have the same effect as + <literal>==</literal>. The key is true if the import is successful, unless <literal>!=</literal> + is used as the operator which causes the key to be true if the import failed.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>OPTIONS</varname></term> + <listitem> + <para>Rule and device options:</para> + <variablelist class='udev-directives'> + <varlistentry> + <term><option>link_priority=<replaceable>value</replaceable></option></term> + <listitem> + <para>Specify the priority of the created symlinks. Devices with higher + priorities overwrite existing symlinks of other devices. The default is 0.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>string_escape=<replaceable>none|replace</replaceable></option></term> + <listitem> + <para>Usually, control and other possibly unsafe characters are replaced + in strings used for device naming. The mode of replacement can be specified + with this option.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>static_node=</option></term> + <listitem> + <para>Apply the permissions specified in this rule to the + static device node with the specified name. Also, for every + tag specified in this rule, create a symlink + in the directory + <filename>/run/udev/static_node-tags/<replaceable>tag</replaceable></filename> + pointing at the static device node with the specified name. + Static device node creation is performed by systemd-tmpfiles + before systemd-udevd is started. The static nodes might not + have a corresponding kernel device; they are used to trigger + automatic kernel module loading when they are accessed.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>watch</option></term> + <listitem> + <para>Watch the device node with inotify; when the node is + closed after being opened for writing, a change uevent is + synthesized.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>nowatch</option></term> + <listitem> + <para>Disable the watching of a device node with inotify.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>db_persist</option></term> + <listitem> + <para>Set the flag (sticky bit) on the udev database entry + of the event device. Device properties are then kept in the + database even when + <command>udevadm info --cleanup-db</command> is called. + This option can be useful in certain cases + (e.g. Device Mapper devices) for persisting device state + on the transition from initramfs.</para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + </variablelist> + + <para>The <varname>NAME</varname>, <varname>SYMLINK</varname>, + <varname>PROGRAM</varname>, <varname>OWNER</varname>, + <varname>GROUP</varname>, <varname>MODE</varname>, <varname>SECLABEL</varname>, + and <varname>RUN</varname> fields support simple string substitutions. + The <varname>RUN</varname> substitutions are performed after all rules + have been processed, right before the program is executed, allowing for + the use of device properties set by earlier matching rules. For all other + fields, substitutions are performed while the individual rule is being + processed. The available substitutions are:</para> + <variablelist class='udev-directives'> + <varlistentry> + <term><option>$kernel</option>, <option>%k</option></term> + <listitem> + <para>The kernel name for this device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$number</option>, <option>%n</option></term> + <listitem> + <para>The kernel number for this device. For example, <literal>sda3</literal> has kernel number + 3.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$devpath</option>, <option>%p</option></term> + <listitem> + <para>The devpath of the device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$id</option>, <option>%b</option></term> + <listitem> + <para>The name of the device matched while searching the devpath + upwards for <option>SUBSYSTEMS</option>, <option>KERNELS</option>, + <option>DRIVERS</option>, and <option>ATTRS</option>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$driver</option></term> + <listitem> + <para>The driver name of the device matched while searching the + devpath upwards for <option>SUBSYSTEMS</option>, + <option>KERNELS</option>, <option>DRIVERS</option>, and + <option>ATTRS</option>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$attr{<replaceable>file</replaceable>}</option>, <option>%s{<replaceable>file</replaceable>}</option></term> + <listitem> + <para>The value of a sysfs attribute found at the device where + all keys of the rule have matched. If the matching device does not + have such an attribute, and a previous <option>KERNELS</option>, + <option>SUBSYSTEMS</option>, <option>DRIVERS</option>, or + <option>ATTRS</option> test selected a parent device, then the + attribute from that parent device is used. + </para> + <para>If the attribute is a symlink, the last element of the + symlink target is returned as the value. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$env{<replaceable>key</replaceable>}</option>, <option>%E{<replaceable>key</replaceable>}</option></term> + <listitem> + <para>A device property value.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$major</option>, <option>%M</option></term> + <listitem> + <para>The kernel major number for the device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$minor</option>, <option>%m</option></term> + <listitem> + <para>The kernel minor number for the device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$result</option>, <option>%c</option></term> + <listitem> + <para>The string returned by the external program requested with + <varname>PROGRAM</varname>. + A single part of the string, separated by a space character, may be selected + by specifying the part number as an attribute: <literal>%c{N}</literal>. + If the number is followed by the <literal>+</literal> character, this part plus all remaining parts + of the result string are substituted: <literal>%c{N+}</literal>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$parent</option>, <option>%P</option></term> + <listitem> + <para>The node name of the parent device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$name</option></term> + <listitem> + <para>The current name of the device. If not changed by a rule, it is the + name of the kernel device.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$links</option></term> + <listitem> + <para>A space-separated list of the current symlinks. The value is + only set during a remove event or if an earlier rule assigned a value.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$root</option>, <option>%r</option></term> + <listitem> + <para>The udev_root value.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$sys</option>, <option>%S</option></term> + <listitem> + <para>The sysfs mount point.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$devnode</option>, <option>%N</option></term> + <listitem> + <para>The name of the device node.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>%%</option></term> + <listitem> + <para>The <literal>%</literal> character itself.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>$$</option></term> + <listitem> + <para>The <literal>$</literal> character itself.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry> + <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum> + </citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/udev_device_get_syspath.xml b/man/udev_device_get_syspath.xml new file mode 100644 index 0000000..f2d712f --- /dev/null +++ b/man/udev_device_get_syspath.xml @@ -0,0 +1,180 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_device_get_syspath" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_device_get_syspath</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_device_get_syspath</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_device_get_syspath</refname> + <refname>udev_device_get_sysname</refname> + <refname>udev_device_get_sysnum</refname> + <refname>udev_device_get_devpath</refname> + <refname>udev_device_get_devnode</refname> + <refname>udev_device_get_devnum</refname> + <refname>udev_device_get_devtype</refname> + <refname>udev_device_get_subsystem</refname> + <refname>udev_device_get_driver</refname> + <refname>udev_device_get_udev</refname> + <refname>udev_device_get_parent</refname> + <refname>udev_device_get_parent_with_subsystem_devtype</refname> + <refname>udev_device_get_is_initialized</refname> + <refname>udev_device_get_action</refname> + + <refpurpose>Query device properties</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_syspath</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_sysname</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_sysnum</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_devpath</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_devnode</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>dev_t <function>udev_device_get_devnum</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_devtype</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_subsystem</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_driver</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev *<function>udev_device_get_udev</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_get_parent</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_get_parent_with_subsystem_devtype</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + <paramdef>const char *<parameter>subsystem</parameter></paramdef> + <paramdef>const char *<parameter>devtype</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_device_get_is_initialized</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_action</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add documentation.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>udev_device_get_syspath()</function>, + <function>udev_device_get_sysname()</function>, + <function>udev_device_get_sysnum()</function>, + <function>udev_device_get_devpath()</function>, + <function>udev_device_get_devnode()</function>, + <function>udev_device_get_devtype()</function>, + <function>udev_device_get_subsystem()</function>, + <function>udev_device_get_driver()</function> and + <function>udev_device_get_action()</function> return a pointer + to a constant string that describes the requested property. The + lifetime of this string is bound to the device it was requested + on. On failure, each function may return + <constant>NULL</constant>.</para> + + <para>On success, <function>udev_device_get_devnum()</function> + returns the device type of the passed device. On failure, a + device type with minor and major number set to + <constant>0</constant> is returned.</para> + + <para><function>udev_device_get_udev()</function> always returns + a valid pointer to the udev context that this device belongs + to.</para> + + <para>On success, <function>udev_device_get_parent()</function> + and + <function>udev_device_get_parent_with_subsystem_devtype()</function> + return a pointer to the parent device. No additional reference + to this device is acquired, but the child device owns a reference + to such a parent device. On failure, <constant>NULL</constant> + is returned.</para> + + <para>On success, <function>udev_device_get_is_initialized()</function> returns either <constant>1</constant> or + <constant>0</constant>, depending on whether the passed device has already been initialized by udev or not. On + failure, a negative error code is returned. Note that devices for which no udev rules are defined are never + reported initialized.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_has_tag</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/udev_device_has_tag.xml b/man/udev_device_has_tag.xml new file mode 100644 index 0000000..19bad4f --- /dev/null +++ b/man/udev_device_has_tag.xml @@ -0,0 +1,170 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_device_has_tag" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_device_has_tag</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_device_has_tag</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_device_has_tag</refname> + <refname>udev_device_has_current_tag</refname> + <refname>udev_device_get_devlinks_list_entry</refname> + <refname>udev_device_get_properties_list_entry</refname> + <refname>udev_device_get_tags_list_entry</refname> + <refname>udev_device_get_current_tags_list_entry</refname> + <refname>udev_device_get_sysattr_list_entry</refname> + <refname>udev_device_get_property_value</refname> + <refname>udev_device_get_sysattr_value</refname> + <refname>udev_device_set_sysattr_value</refname> + + <refpurpose>Retrieve or set device attributes</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>udev_device_has_tag</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + <paramdef>const char *<parameter>tag</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_device_has_current_tag</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + <paramdef>const char *<parameter>tag</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_device_get_devlinks_list_entry</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_device_get_properties_list_entry</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_device_get_tags_list_entry</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_device_get_current_tags_list_entry</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_device_get_sysattr_list_entry</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_property_value</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + <paramdef>const char *<parameter>key</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_device_get_sysattr_value</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + <paramdef>const char *<parameter>sysattr</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_device_set_sysattr_value</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + <paramdef>const char *<parameter>sysattr</parameter></paramdef> + <paramdef>const char *<parameter>value</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>udev_device_has_tag()</function> returns a valuer larger than zero if the specified + device object has the indicated tag assigned to it, and zero otherwise. See + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on + the tags concept. <function>udev_device_has_current_tag()</function> executes a similar check, however + only determines whether the indicated tag was set as result of the most recent event seen for the + device. Tags are "sticky", i.e. once set for a device they remain on the device until the device is + unplugged, even if the rules run for later events of the same device do not set them anymore. Any tag for + which <function>udev_device_has_current_tag()</function> returns true will hence also return true when + passed to <function>udev_device_has_tag()</function>, but the opposite might not be true, in case a tag is + no longer configured by the rules applied to the most recent device even.</para> + + <para><function>udev_device_get_tags_list_entry()</function> returns a + <structname>udev_list_entry</structname> object, encapsulating a list of tags set for the specified + device. Similar, <function>udev_device_get_current_tags_list_entry()</function> returns a list of tags + set for the specified device as effect of the most recent device event seen (see above for details on the + difference).</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>udev_device_has_tag()</function> and + <function>udev_device_has_current_tag()</function> return positive or <constant>0</constant>, depending + on whether the device has the given tag or not. On failure, a negative error code is returned.</para> + + <para>On success, <function>udev_device_get_devlinks_list_entry()</function>, + <function>udev_device_get_properties_list_entry()</function>, + <function>udev_device_get_tags_list_entry()</function>, + <function>udev_device_get_current_tags_list_entry()</function> and + <function>udev_device_get_sysattr_list_entry()</function> return a pointer to the first entry of the + retrieved list. If that list is empty, or if an error occurred, <constant>NULL</constant> is + returned.</para> + + <para>On success, + <function>udev_device_get_property_value()</function> and + <function>udev_device_get_sysattr_value()</function> return a + pointer to a constant string of the requested value. On error, + <constant>NULL</constant> is returned. Attributes that may + contain <constant>NUL</constant> bytes should not be retrieved + with <function>udev_device_get_sysattr_value()</function>; + instead, read them directly from the files within the device's + <property>syspath</property>.</para> + + <para>On success, + <function>udev_device_set_sysattr_value()</function> returns + an integer greater than, or equal to, <constant>0</constant>. + On failure, a negative error code is returned. Values that + contain <constant>NUL</constant> bytes should not be set with + this function; instead, write them directly to the files within + the device's <property>syspath</property>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_get_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_device_new_from_syspath.xml b/man/udev_device_new_from_syspath.xml new file mode 100644 index 0000000..f5ec03d --- /dev/null +++ b/man/udev_device_new_from_syspath.xml @@ -0,0 +1,187 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_device_new_from_syspath" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_device_new_from_syspath</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_device_new_from_syspath</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_device_new_from_syspath</refname> + <refname>udev_device_new_from_devnum</refname> + <refname>udev_device_new_from_subsystem_sysname</refname> + <refname>udev_device_new_from_device_id</refname> + <refname>udev_device_new_from_environment</refname> + <refname>udev_device_ref</refname> + <refname>udev_device_unref</refname> + + <refpurpose>Create, acquire and release a udev device object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_new_from_syspath</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + <paramdef>const char *<parameter>syspath</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_new_from_devnum</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + <paramdef>char <parameter>type</parameter></paramdef> + <paramdef>dev_t <parameter>devnum</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_new_from_subsystem_sysname</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + <paramdef>const char *<parameter>subsystem</parameter></paramdef> + <paramdef>const char *<parameter>sysname</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_new_from_device_id</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + <paramdef>const char *<parameter>id</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_new_from_environment</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_ref</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_device_unref</function></funcdef> + <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>udev_device_new_from_syspath()</function>, + <function>udev_device_new_from_devnum()</function>, + <function>udev_device_new_from_subsystem_sysname()</function>, + <function>udev_device_new_from_device_id()</function>, and + <function>udev_device_new_from_environment()</function> + allocate a new udev device object and returns a pointer to it. This + object is opaque and must not be accessed by the caller via different + means than functions provided by libudev. Initially, the reference count + of the device is 1. You can acquire further references, and drop + gained references via <function>udev_device_ref()</function> and + <function>udev_device_unref()</function>. Once the reference count hits 0, + the device object is destroyed and freed.</para> + + <para><function>udev_device_new_from_syspath()</function>, + <function>udev_device_new_from_devnum()</function>, + <function>udev_device_new_from_subsystem_sysname()</function>, and + <function>udev_device_new_from_device_id()</function> + create the device object based on information found in + <filename>/sys/</filename>, annotated with properties from the udev-internal + device database. A syspath is any subdirectory of <filename>/sys/</filename>, + with the restriction that a subdirectory of <filename>/sys/devices</filename> + (or a symlink to one) represents a real device and as such must contain + a <filename>uevent</filename> file. <function>udev_device_new_from_devnum()</function> + takes a device type, which can be <constant>b</constant> for block devices or + <constant>c</constant> for character devices, as well as a devnum (see + <citerefentry project='man-pages'><refentrytitle>makedev</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + <function>udev_device_new_from_subsystem_sysname()</function> looks up devices based + on the provided subsystem and sysname + (see <citerefentry><refentrytitle>udev_device_get_subsystem</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and + <citerefentry><refentrytitle>udev_device_get_sysname</refentrytitle><manvolnum>3</manvolnum></citerefentry>) + and <function>udev_device_new_from_device_id()</function> looks up devices based on the provided + device ID, which is a special string in one of the following four forms: + <table> + <title>Device ID strings</title> + + <tgroup cols='2'> + <colspec colname='example' /> + <colspec colname='explanation' /> + <thead><row> + <entry>Example</entry> + <entry>Explanation</entry> + </row></thead> + <tbody> + <row><entry><varname>b8:2</varname></entry> + <entry>block device major:minor</entry></row> + + <row><entry><varname>c128:1</varname></entry> + <entry>char device major:minor</entry></row> + + <row><entry><varname>n3</varname></entry> + <entry>network device ifindex</entry></row> + + <row><entry><varname>+sound:card29</varname></entry> + <entry>kernel driver core subsystem:device name</entry></row> + </tbody> + </tgroup> + </table> + </para> + + <para><function>udev_device_new_from_environment()</function> + creates a device from the current environment (see + <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>). + Each key-value pair is interpreted in the same way as if it was + received in an uevent (see + <citerefentry><refentrytitle>udev_monitor_receive_device</refentrytitle><manvolnum>3</manvolnum></citerefentry>). + The keys <constant>DEVPATH</constant>, <constant>SUBSYSTEM</constant>, + <constant>ACTION</constant>, and <constant>SEQNUM</constant> are mandatory.</para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>udev_device_new_from_syspath()</function>, + <function>udev_device_new_from_devnum()</function>, + <function>udev_device_new_from_subsystem_sysname()</function>, + <function>udev_device_new_from_device_id()</function> and + <function>udev_device_new_from_environment()</function> return a + pointer to the allocated udev device. On failure, + <constant>NULL</constant> is returned, + and <varname>errno</varname> is set appropriately. + <function>udev_device_ref()</function> returns the argument + that it was passed, unmodified. + <function>udev_device_unref()</function> always returns + <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_get_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_has_tag</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_enumerate_add_match_subsystem.xml b/man/udev_enumerate_add_match_subsystem.xml new file mode 100644 index 0000000..455aabd --- /dev/null +++ b/man/udev_enumerate_add_match_subsystem.xml @@ -0,0 +1,136 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_enumerate_add_match_subsystem" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_enumerate_add_match_subsystem</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_enumerate_add_match_subsystem</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_enumerate_add_match_subsystem</refname> + <refname>udev_enumerate_add_nomatch_subsystem</refname> + <refname>udev_enumerate_add_match_sysattr</refname> + <refname>udev_enumerate_add_nomatch_sysattr</refname> + <refname>udev_enumerate_add_match_property</refname> + <refname>udev_enumerate_add_match_sysname</refname> + <refname>udev_enumerate_add_match_tag</refname> + <refname>udev_enumerate_add_match_parent</refname> + <refname>udev_enumerate_add_match_is_initialized</refname> + + <refpurpose>Modify filters</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_subsystem</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>subsystem</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_nomatch_subsystem</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>subsystem</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_sysattr</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>sysattr</parameter></paramdef> + <paramdef>const char *<parameter>value</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_nomatch_sysattr</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>sysattr</parameter></paramdef> + <paramdef>const char *<parameter>value</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_property</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>property</parameter></paramdef> + <paramdef>const char *<parameter>value</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_sysname</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>sysname</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_tag</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>tag</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_parent</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>struct udev_device *<parameter>parent</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_match_is_initialized</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>udev_enumerate_add_match_subsystem()</function>, + <function>udev_enumerate_add_nomatch_subsystem()</function>, + <function>udev_enumerate_add_match_sysattr()</function>, + <function>udev_enumerate_add_nomatch_sysattr()</function>, + <function>udev_enumerate_add_match_property()</function>, + <function>udev_enumerate_add_match_sysname()</function>, + <function>udev_enumerate_add_match_tag()</function>, + <function>udev_enumerate_add_match_parent()</function> and + <function>udev_enumerate_add_match_is_initialized()</function> + return an integer greater than, or equal to, + <constant>0</constant>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_scan_devices</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_enumerate_new.xml b/man/udev_enumerate_new.xml new file mode 100644 index 0000000..3360cf0 --- /dev/null +++ b/man/udev_enumerate_new.xml @@ -0,0 +1,84 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_enumerate_new" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_enumerate_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_enumerate_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_enumerate_new</refname> + <refname>udev_enumerate_ref</refname> + <refname>udev_enumerate_unref</refname> + + <refpurpose>Create, acquire and release a udev enumerate object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>struct udev_enumerate *<function>udev_enumerate_new</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_enumerate *<function>udev_enumerate_ref</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_enumerate *<function>udev_enumerate_unref</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>udev_enumerate_new()</function> returns a + pointer to the allocated udev monitor. On failure, + <constant>NULL</constant> is returned. + <function>udev_enumerate_ref()</function> returns the argument + that it was passed, unmodified. + <function>udev_enumerate_unref()</function> always returns + <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_add_match_subsystem</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_scan_devices</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_enumerate_scan_devices.xml b/man/udev_enumerate_scan_devices.xml new file mode 100644 index 0000000..22151a5 --- /dev/null +++ b/man/udev_enumerate_scan_devices.xml @@ -0,0 +1,106 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_enumerate_scan_devices" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_enumerate_scan_devices</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_enumerate_scan_devices</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_enumerate_scan_devices</refname> + <refname>udev_enumerate_scan_subsystems</refname> + <refname>udev_enumerate_get_list_entry</refname> + <refname>udev_enumerate_add_syspath</refname> + <refname>udev_enumerate_get_udev</refname> + + <refpurpose>Query or modify a udev enumerate object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>udev_enumerate_scan_devices</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_scan_subsystems</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_enumerate_get_list_entry</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_enumerate_add_syspath</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + <paramdef>const char *<parameter>syspath</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev *<function>udev_enumerate_get_udev</function></funcdef> + <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>udev_enumerate_scan_devices()</function>, + <function>udev_enumerate_scan_subsystems()</function> and + <function>udev_enumerate_add_syspath()</function> + return an integer greater than, or equal to, + <constant>0</constant>.</para> + + <para>On success, + <function>udev_enumerate_get_list_entry()</function> + returns a pointer to the first entry in the list of found + devices. If the list is empty, or on failure, + <constant>NULL</constant> is returned.</para> + + <para><function>udev_enumerate_get_udev()</function> always + returns a pointer to the udev context that this enumerated + object is associated with.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_add_match_subsystem</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_list_entry.xml b/man/udev_list_entry.xml new file mode 100644 index 0000000..94273ce --- /dev/null +++ b/man/udev_list_entry.xml @@ -0,0 +1,96 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_list_entry" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_list_entry</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_list_entry</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_list_entry</refname> + <refname>udev_list_entry_get_next</refname> + <refname>udev_list_entry_get_by_name</refname> + <refname>udev_list_entry_get_name</refname> + <refname>udev_list_entry_get_value</refname> + + <refpurpose>Iterate and access udev lists</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_list_entry_get_next</function></funcdef> + <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_list_entry *<function>udev_list_entry_get_by_name</function></funcdef> + <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_list_entry_get_name</function></funcdef> + <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>const char *<function>udev_list_entry_get_value</function></funcdef> + <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>udev_list_entry_get_next()</function> and + <function>udev_list_entry_get_by_name()</function> return + a pointer to the requested list entry. If no such entry can + be found, or on failure, <constant>NULL</constant> is + returned.</para> + + <para>On success, + <function>udev_list_entry_get_name()</function> and + <function>udev_list_entry_get_value()</function> return a + pointer to a constant string representing the requested value. + The string is bound to the lifetime of the list entry itself. + On failure, <constant>NULL</constant> is returned.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_monitor_filter_update.xml b/man/udev_monitor_filter_update.xml new file mode 100644 index 0000000..4e77db4 --- /dev/null +++ b/man/udev_monitor_filter_update.xml @@ -0,0 +1,95 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_monitor_filter_update" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_monitor_filter_update</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_monitor_filter_update</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_monitor_filter_update</refname> + <refname>udev_monitor_filter_remove</refname> + <refname>udev_monitor_filter_add_match_subsystem_devtype</refname> + <refname>udev_monitor_filter_add_match_tag</refname> + + <refpurpose>Modify filters</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>int <function>udev_monitor_filter_update</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_monitor_filter_remove</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_monitor_filter_add_match_subsystem_devtype</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + <paramdef>const char *<parameter>subsystem</parameter></paramdef> + <paramdef>const char *<parameter>devtype</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_monitor_filter_add_match_tag</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + <paramdef>const char *<parameter>tag</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>udev_monitor_filter_update()</function>, + <function>udev_monitor_filter_remove()</function>, + <function>udev_monitor_filter_add_match_subsystem_devtype()</function> + and + <function>udev_monitor_filter_add_match_tag()</function> + return an integer greater than, or equal to, + <constant>0</constant>. On failure, a negative error code is + returned.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_receive_device</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_monitor_new_from_netlink.xml b/man/udev_monitor_new_from_netlink.xml new file mode 100644 index 0000000..538a27e --- /dev/null +++ b/man/udev_monitor_new_from_netlink.xml @@ -0,0 +1,86 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_monitor_new_from_netlink" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_monitor_new_from_netlink</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_monitor_new_from_netlink</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_monitor_new_from_netlink</refname> + <refname>udev_monitor_ref</refname> + <refname>udev_monitor_unref</refname> + + <refpurpose>Create, acquire and release a udev monitor object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>struct udev_monitor *<function>udev_monitor_new_from_netlink</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + <paramdef>const char *<parameter>name</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_monitor *<function>udev_monitor_ref</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev_monitor *<function>udev_monitor_unref</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>udev_monitor_new_from_netlink()</function> returns a + pointer to the allocated udev monitor. On failure, + <constant>NULL</constant> is returned. + <function>udev_monitor_ref()</function> returns the argument + that it was passed, unmodified. + <function>udev_monitor_unref()</function> always returns + <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_filter_update</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_receive_device</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_monitor_receive_device.xml b/man/udev_monitor_receive_device.xml new file mode 100644 index 0000000..bbdce3c --- /dev/null +++ b/man/udev_monitor_receive_device.xml @@ -0,0 +1,110 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_monitor_receive_device" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_monitor_receive_device</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_monitor_receive_device</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_monitor_receive_device</refname> + <refname>udev_monitor_enable_receiving</refname> + <refname>udev_monitor_set_receive_buffer_size</refname> + <refname>udev_monitor_get_fd</refname> + <refname>udev_monitor_get_udev</refname> + + <refpurpose>Query and modify device monitor</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>struct udev_device *<function>udev_monitor_receive_device</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_monitor_enable_receiving</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_monitor_set_receive_buffer_size</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + <paramdef>int <parameter>size</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>udev_monitor_get_fd</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev *<function>udev_monitor_get_udev</function></funcdef> + <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <!--<refsect1> + <title>Description</title> + + <para>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <para>On success, + <function>udev_monitor_receive_device()</function> returns a + pointer to a newly referenced device that was received via the + monitor. The caller is responsible to drop this reference when + done. On failure, <constant>NULL</constant> is returned.</para> + + <para>On success, + <function>udev_monitor_enable_receiving()</function> and + <function>udev_monitor_set_receive_buffer_size()</function> + return an integer greater than, or equal to, + <constant>0</constant>. On failure, a negative error code is + returned.</para> + + <para>On success, <function>udev_monitor_get_fd()</function> + returns the file descriptor used by this monitor. On failure, + a negative error code is returned.</para> + + <para><function>udev_monitor_get_udev()</function> always returns + a pointer to the udev context that this monitor is associated + with.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_monitor_filter_update</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udev_new.xml b/man/udev_new.xml new file mode 100644 index 0000000..34e249d --- /dev/null +++ b/man/udev_new.xml @@ -0,0 +1,83 @@ +<?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" [ +<!ENTITY % entities SYSTEM "custom-entities.ent" > +%entities; +]> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<refentry id="udev_new" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udev_new</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udev_new</refentrytitle> + <manvolnum>3</manvolnum> + </refmeta> + + <refnamediv> + <refname>udev_new</refname> + <refname>udev_ref</refname> + <refname>udev_unref</refname> + + <refpurpose>Create, acquire and release a udev context object</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <libudev.h></funcsynopsisinfo> + + <funcprototype> + <funcdef>struct udev *<function>udev_new</function></funcdef> + <paramdef><parameter>void</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev *<function>udev_ref</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>struct udev *<function>udev_unref</function></funcdef> + <paramdef>struct udev *<parameter>udev</parameter></paramdef> + </funcprototype> + + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><function>udev_new()</function> allocates a new udev context + object and returns a pointer to it. This object is opaque and must + not be accessed by the caller via different means than functions + provided by libudev. Initially, the reference count of the context + is 1. You can acquire further references, and drop gained references + via <function>udev_ref()</function> and + <function>udev_unref()</function>. Once the reference count hits 0, + the context object is destroyed and freed.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>udev_new()</function> returns a pointer + to the allocated udev context. On failure, <constant>NULL</constant> + is returned. <function>udev_ref()</function> returns the argument + that it was passed, unmodified. <function>udev_unref()</function> + always returns <constant>NULL</constant>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + </para> + </refsect1> + +</refentry> diff --git a/man/udevadm.xml b/man/udevadm.xml new file mode 100644 index 0000000..ec26cc3 --- /dev/null +++ b/man/udevadm.xml @@ -0,0 +1,581 @@ +<?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-or-later --> + +<refentry id="udevadm" + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>udevadm</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>udevadm</refentrytitle> + <manvolnum>8</manvolnum> + </refmeta> + + <refnamediv> + <refname>udevadm</refname><refpurpose>udev management tool</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>udevadm</command> + <arg><option>--debug</option></arg> + <arg><option>--version</option></arg> + <arg><option>--help</option></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm info <optional>options</optional> <optional>devpath</optional></command> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm trigger <optional>options</optional> <optional>devpath</optional></command> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm settle <optional>options</optional></command> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm control <replaceable>option</replaceable></command> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm monitor <optional>options</optional></command> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm test <optional>options</optional> <replaceable>devpath</replaceable></command> + </cmdsynopsis> + <cmdsynopsis> + <command>udevadm test-builtin <optional>options</optional> <replaceable>command</replaceable> <replaceable>devpath</replaceable></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1><title>Description</title> + <para><command>udevadm</command> expects a command and command + specific options. It controls the runtime behavior of + <command>systemd-udevd</command>, requests kernel events, manages + the event queue, and provides simple debugging mechanisms.</para> + </refsect1> + + <refsect1><title>Options</title> + <variablelist> + <varlistentry> + <term><option>-d</option></term> + <term><option>--debug</option></term> + <listitem> + <para>Print debug messages to standard error. This option is implied in <command>udevadm test</command> and + <command>udevadm test-builtin</command> commands.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + + <refsect2><title>udevadm info + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt" rep="repeat"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg> + </title> + + <para>Query the udev database for device information.</para> + + <para>Positional arguments should be used to specify one or more devices. Each one may be a device name + (in which case it must start with <filename>/dev/</filename>), a sys path (in which case it must start + with <filename>/sys/</filename>), or a systemd device unit name (in which case it must end with + <literal>.device</literal>, see + <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + </para> + + <variablelist> + <varlistentry> + <term><option>-q</option></term> + <term><option>--query=<replaceable>TYPE</replaceable></option></term> + <listitem> + <para>Query the database for the specified type of device data. + Valid <replaceable>TYPE</replaceable>s are: + <constant>name</constant>, <constant>symlink</constant>, + <constant>path</constant>, <constant>property</constant>, + <constant>all</constant>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--path=<replaceable>DEVPATH</replaceable></option></term> + <listitem> + <para>The <filename>/sys/</filename> path of the device to query, e.g. + <filename><optional>/sys/</optional>/class/block/sda</filename>. This option is an alternative to + the positional argument with a <filename>/sys/</filename> prefix. <command>udevadm info + --path=/class/block/sda</command> is equivalent to <command>udevadm info + /sys/class/block/sda</command>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-n</option></term> + <term><option>--name=<replaceable>FILE</replaceable></option></term> + <listitem> + <para>The name of the device node or a symlink to query, + e.g. <filename><optional>/dev/</optional>/sda</filename>. This option is an alternative to the + positional argument with a <filename>/dev/</filename> prefix. <command>udevadm info + --name=sda</command> is equivalent to <command>udevadm info /dev/sda</command>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-r</option></term> + <term><option>--root</option></term> + <listitem> + <para>Print absolute paths in <command>name</command> or <command>symlink</command> + query.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-a</option></term> + <term><option>--attribute-walk</option></term> + <listitem> + <para>Print all sysfs properties of the specified device that can be used + in udev rules to match the specified device. It prints all devices + along the chain, up to the root of sysfs that can be used in udev rules.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-x</option></term> + <term><option>--export</option></term> + <listitem> + <para>Print output as key/value pairs. Values are enclosed in single quotes. + This takes effects only when <option>--query=property</option> or + <option>--device-id-of-file=<replaceable>FILE</replaceable></option> is specified.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-P</option></term> + <term><option>--export-prefix=<replaceable>NAME</replaceable></option></term> + <listitem> + <para>Add a prefix to the key name of exported values. + This implies <option>--export</option>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-d</option></term> + <term><option>--device-id-of-file=<replaceable>FILE</replaceable></option></term> + <listitem> + <para>Print major/minor numbers of the underlying device, where the file lives on. + If this is specified, all positional arguments are ignored.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-e</option></term> + <term><option>--export-db</option></term> + <listitem> + <para>Export the content of the udev database.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-c</option></term> + <term><option>--cleanup-db</option></term> + <listitem> + <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> + </refsect2> + + <refsect2><title>udevadm trigger + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg> + </title> + <para>Request device events from the kernel. Primarily used to replay events at system coldplug time.</para> + + <para>Takes device specifications as positional arguments. See the description of <command>info</command> + above.</para> + + <variablelist> + <varlistentry> + <term><option>-v</option></term> + <term><option>--verbose</option></term> + <listitem> + <para>Print the list of devices which will be triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-n</option></term> + <term><option>--dry-run</option></term> + <listitem> + <para>Do not actually trigger the event.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-t</option></term> + <term><option>--type=<replaceable>TYPE</replaceable></option></term> + <listitem> + <para>Trigger a specific type of devices. Valid types are: + <command>devices</command>, <command>subsystems</command>. + The default value is <command>devices</command>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-c</option></term> + <term><option>--action=<replaceable>ACTION</replaceable></option></term> + <listitem> + <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>. 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> + <term><option>-s</option></term> + <term><option>--subsystem-match=<replaceable>SUBSYSTEM</replaceable></option></term> + <listitem> + <para>Trigger events for devices which belong to a + matching subsystem. This option supports shell style pattern matching. + When this option is specified more than once, then each matching result is ORed, that is, + all the devices in each subsystem are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-S</option></term> + <term><option>--subsystem-nomatch=<replaceable>SUBSYSTEM</replaceable></option></term> + <listitem> + <para>Do not trigger events for devices which belong to a matching subsystem. This option + supports shell style pattern matching. When this option is specified more than once, + then each matching result is ANDed, that is, devices which do not match all specified + subsystems are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-a</option></term> + <term><option>--attr-match=<replaceable>ATTRIBUTE</replaceable>=<replaceable>VALUE</replaceable></option></term> + <listitem> + <para>Trigger events for devices with a matching sysfs attribute. If a value is specified along + with the attribute name, the content of the attribute is matched against the given value using + shell style pattern matching. If no value is specified, the existence of the sysfs attribute is + checked. When this option is specified multiple times, then each matching result is ANDed, + that is, only devices which have all specified attributes are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-A</option></term> + <term><option>--attr-nomatch=<replaceable>ATTRIBUTE</replaceable>=<replaceable>VALUE</replaceable></option></term> + <listitem> + <para>Do not trigger events for devices with a matching sysfs attribute. If a value is specified + along with the attribute name, the content of the attribute is matched against the given value + using shell style pattern matching. If no value is specified, the existence of the sysfs attribute + is checked. When this option is specified multiple times, then each matching result is ANDed, + that is, only devices which have none of the specified attributes are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-p</option></term> + <term><option>--property-match=<replaceable>PROPERTY</replaceable>=<replaceable>VALUE</replaceable></option></term> + <listitem> + <para>Trigger events for devices with a matching property value. This option supports shell style + pattern matching. When this option is specified more than once, then each matching result is ORed, + that is, devices which have one of the specified properties are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-g</option></term> + <term><option>--tag-match=<replaceable>PROPERTY</replaceable></option></term> + <listitem> + <para>Trigger events for devices with a matching tag. When this option is specified multiple times, + then each matching result is ANDed, that is, devices which have all specified tags are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-y</option></term> + <term><option>--sysname-match=<replaceable>NAME</replaceable></option></term> + <listitem> + <para>Trigger events for devices for which the last component (i.e. the filename) of the + <filename>/sys/</filename> path matches the specified <replaceable>PATH</replaceable>. This option + supports shell style pattern matching. When this option is specified more than once, then each + matching result is ORed, that is, all devices which have any of the specified + <replaceable>NAME</replaceable> are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--name-match=<replaceable>NAME</replaceable></option></term> + <listitem> + <para>Trigger events for devices with a matching device path. When this option is specified more than once, + then each matching result is ORed, that is, all specified devices are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-b</option></term> + <term><option>--parent-match=<replaceable>SYSPATH</replaceable></option></term> + <listitem> + <para>Trigger events for all children of a given device. When this option is specified more than once, + then each matching result is ORed, that is, all children of each specified device are triggered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-w</option></term> + <term><option>--settle</option></term> + <listitem> + <para>Apart from triggering events, also waits for those events to + finish. Note that this is different from calling <command>udevadm + settle</command>. <command>udevadm settle</command> waits for all + events to finish. This option only waits for events triggered by + the same command to finish.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--wait-daemon[=<replaceable>SECONDS</replaceable>]</option></term> + <listitem> + <para>Before triggering uevents, wait for systemd-udevd daemon to be initialized. + Optionally takes timeout value. Default timeout is 5 seconds. This is equivalent to invoke + invoking <command>udevadm control --ping</command> before <command>udevadm trigger</command>.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + + <para>In addition, optional positional arguments can be used + to specify device names or sys paths. They must start with + <filename>/dev/</filename> or <filename>/sys/</filename> + respectively.</para> + </refsect2> + + <refsect2><title>udevadm settle + <arg choice="opt"><replaceable>options</replaceable></arg> + </title> + <para>Watches the udev event queue, and exits if all current events are handled.</para> + <variablelist> + <varlistentry> + <term><option>-t</option></term> + <term><option>--timeout=<replaceable>SECONDS</replaceable></option></term> + <listitem> + <para>Maximum number of seconds to wait for the event + queue to become empty. The default value is 120 seconds. A + value of 0 will check if the queue is empty and always + return immediately. A non-zero value will return an exit + code of 0 if queue became empty before timeout was reached, + non-zero otherwise.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-E</option></term> + <term><option>--exit-if-exists=<replaceable>FILE</replaceable></option></term> + <listitem> + <para>Stop waiting if file exists.</para> + </listitem> + </varlistentry> + + <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> + <para>Modify the internal state of the running udev daemon.</para> + <variablelist> + <varlistentry> + <term><option>-e</option></term> + <term><option>--exit</option></term> + <listitem> + <para>Signal and wait for systemd-udevd to exit. No option except for + <option>--timeout</option> can be specified after this option. + Note that <filename>systemd-udevd.service</filename> contains + <option>Restart=always</option> and so as a result, this option restarts systemd-udevd. + If you want to stop <filename>systemd-udevd.service</filename>, please use the following: + <programlisting>systemctl stop systemd-udevd-control.socket systemd-udevd-kernel.socket systemd-udevd.service</programlisting> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-l</option></term> + <term><option>--log-level=<replaceable>value</replaceable></option></term> + <listitem> + <para>Set the internal log level of + <filename>systemd-udevd</filename>. Valid values are the + numerical syslog priorities or their textual + representations: <option>emerg</option>, + <option>alert</option>, <option>crit</option>, + <option>err</option>, <option>warning</option>, + <option>notice</option>, <option>info</option>, and + <option>debug</option>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-s</option></term> + <term><option>--stop-exec-queue</option></term> + <listitem> + <para>Signal systemd-udevd to stop executing new events. Incoming events + will be queued.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-S</option></term> + <term><option>--start-exec-queue</option></term> + <listitem> + <para>Signal systemd-udevd to enable the execution of events.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-R</option></term> + <term><option>--reload</option></term> + <listitem> + <para>Signal systemd-udevd to reload the rules files and other databases like the kernel + module index. Reloading rules and databases does not apply any changes to already + existing devices; the new configuration will only be applied to new events.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-p</option></term> + <term><option>--property=<replaceable>KEY</replaceable>=<replaceable>value</replaceable></option></term> + <listitem> + <para>Set a global property for all events.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-m</option></term> + <term><option>--children-max=</option><replaceable>value</replaceable></term> + <listitem> + <para>Set the maximum number of events, systemd-udevd will handle at the + same time.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--ping</option></term> + <listitem> + <para>Send a ping message to systemd-udevd and wait for the reply. This may be useful to check that + systemd-udevd daemon is running.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-t</option></term> + <term><option>--timeout=</option><replaceable>seconds</replaceable></term> + <listitem> + <para>The maximum number of seconds to wait for a reply from systemd-udevd.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + </refsect2> + + <refsect2><title>udevadm monitor + <arg choice="opt"><replaceable>options</replaceable></arg> + </title> + <para>Listens to the kernel uevents and events sent out by a udev rule + and prints the devpath of the event to the console. It can be used to analyze the + event timing, by comparing the timestamps of the kernel uevent and the udev event. + </para> + <variablelist> + <varlistentry> + <term><option>-k</option></term> + <term><option>--kernel</option></term> + <listitem> + <para>Print the kernel uevents.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-u</option></term> + <term><option>--udev</option></term> + <listitem> + <para>Print the udev event after the rule processing.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-p</option></term> + <term><option>--property</option></term> + <listitem> + <para>Also print the properties of the event.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-s</option></term> + <term><option>--subsystem-match=<replaceable>string[/string]</replaceable></option></term> + <listitem> + <para>Filter kernel uevents and udev events by subsystem[/devtype]. Only events with a matching subsystem value will pass. + When this option is specified more than once, then each matching result is ORed, that is, all devices in the specified + subsystems are monitored.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>-t</option></term> + <term><option>--tag-match=<replaceable>string</replaceable></option></term> + <listitem> + <para>Filter udev events by tag. Only udev events with a given tag attached will pass. + When this option is specified more than once, then each matching result is ORed, that is, devices which have one of the + specified tags are monitored.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + </refsect2> + + <refsect2><title>udevadm test + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg><replaceable>devpath</replaceable></arg> + </title> + <para>Simulate a udev event run for the given device, and print debug output.</para> + <variablelist> + <varlistentry> + <term><option>-a</option></term> + <term><option>--action=<replaceable>ACTION</replaceable></option></term> + <listitem> + <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> + <term><option>-N</option></term> + <term><option>--resolve-names=<constant>early</constant>|<constant>late</constant>|<constant>never</constant></option></term> + <listitem> + <para>Specify when udevadm should resolve names of users + and groups. When set to <constant>early</constant> (the + default), names will be resolved when the rules are + parsed. When set to <constant>late</constant>, names will + be resolved for every event. When set to + <constant>never</constant>, names will never be resolved + and all devices will be owned by root.</para> + </listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + </refsect2> + + <refsect2><title>udevadm test-builtin + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg><replaceable>command</replaceable></arg> + <arg><replaceable>devpath</replaceable></arg> + </title> + <para>Run a built-in command <replaceable>COMMAND</replaceable> + for device <replaceable>DEVPATH</replaceable>, and print debug + output.</para> + <variablelist> + <xi:include href="standard-options.xml" xpointer="help" /> + </variablelist> + </refsect2> + </refsect1> + + <refsect1> + <title>See Also</title> + <para><citerefentry> + <refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum> + </citerefentry>, + <citerefentry> + <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum> + </citerefentry></para> + </refsect1> +</refentry> diff --git a/man/user-system-options.xml b/man/user-system-options.xml new file mode 100644 index 0000000..728118e --- /dev/null +++ b/man/user-system-options.xml @@ -0,0 +1,52 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1-or-later --> + +<variablelist> + <varlistentry id='user'> + <term><option>--user</option></term> + + <listitem id='user-text'> + <para>Talk to the service manager of the calling user, + rather than the service manager of the system.</para> + </listitem> + </varlistentry> + + <varlistentry id='system'> + <term><option>--system</option></term> + + <listitem id='system-text'> + <para>Talk to the service manager of the system. This is the + implied default.</para> + </listitem> + </varlistentry> + + <varlistentry id='host'> + <term><option>-H</option></term> + <term><option>--host=</option></term> + + <listitem id='host-text'> + <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, 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 + instance. Container names may be enumerated with + <command>machinectl -H + <replaceable>HOST</replaceable></command>. Put IPv6 addresses in brackets.</para> + </listitem> + </varlistentry> + + <varlistentry id='machine'> + <term><option>-M</option></term> + <term><option>--machine=</option></term> + + <listitem id='machine-text'> + <para>Execute operation on a local container. Specify a + container name to connect to.</para> + </listitem> + </varlistentry> +</variablelist> diff --git a/man/user@.service.xml b/man/user@.service.xml new file mode 100644 index 0000000..0cf7f02 --- /dev/null +++ b/man/user@.service.xml @@ -0,0 +1,194 @@ +<?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-or-later --> + +<refentry id="user@.service"> + <refentryinfo> + <title>user@.service</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>user@.service</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>user@.service</refname> + <refname>user-runtime-dir@.service</refname> + <refname>systemd-user-runtime-dir</refname> + <refpurpose>System units to start the user manager</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>user@<replaceable>UID</replaceable>.service</filename></para> + <para><filename>user-runtime-dir@<replaceable>UID</replaceable>.service</filename></para> + <para><filename>/usr/lib/systemd/systemd-user-runtime-dir</filename></para> + <para><filename>user-<replaceable>UID</replaceable>.slice</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + system manager (PID 1) starts user manager instances as + <filename>user@<replaceable>UID</replaceable>.service</filename>, with the user's numerical UID used as + the instance identifier. These instances use the same executable as the system manager, but running in a + mode where it starts a different set of units. Each <command>systemd --user</command> instance manages a + hierarchy of units specific to that user. See + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for a + discussion of units and + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a + list of units that form the basis of the unit hierarchies of system and user units.</para> + + <para><filename>user@<replaceable>UID</replaceable>.service</filename> is accompanied by the + system unit <filename>user-runtime-dir@<replaceable>UID</replaceable>.service</filename>, which + creates the user's runtime directory + <filename>/run/user/<replaceable>UID</replaceable></filename>, and then removes it when this + unit is stopped. <filename>user-runtime-dir@<replaceable>UID</replaceable>.service</filename> + executes the <filename>systemd-user-runtime-dir</filename> binary to do the actual work.</para> + + <para>User processes may be started by the <filename>user@.service</filename> instance, in which + case they will be part of that unit in the system hierarchy. They may also be started elsewhere, + for example by + <citerefentry project='die-net'><refentrytitle>sshd</refentrytitle><manvolnum>8</manvolnum></citerefentry> or a + display manager like <command>gdm</command>, in which case they form a .scope unit (see + <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>). + Both <filename>user@<replaceable>UID</replaceable>.service</filename> and the scope units are + collected under the <filename>user-<replaceable>UID</replaceable>.slice</filename>.</para> + + <para>Individual <filename>user-<replaceable>UID</replaceable>.slice</filename> slices are + collected under <filename>user.slice</filename>, see + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + </para> + </refsect1> + + <refsect1> + <title>Controlling resources for logged-in users</title> + + <para>Options that control resources available to logged-in users can be configured at a few + different levels. As described in the previous section, <filename>user.slice</filename> contains + processes of all users, so any resource limits on that slice apply to all users together. The + usual way to configure them would be through drop-ins, e.g. <filename + index="false">/etc/systemd/system/user.slice.d/resources.conf</filename>. + </para> + + <para>The processes of a single user are collected under + <filename>user-<replaceable>UID</replaceable>.slice</filename>. Resource limits for that user + can be configured through drop-ins for that unit, e.g. <filename + index="false">/etc/systemd/system/user-1000.slice.d/resources.conf</filename>. If the limits + should apply to all users instead, they may be configured through drop-ins for the truncated + unit name, <filename>user-.slice</filename>. For example, configuration in <filename + index="false">/etc/systemd/system/user-.slice.d/resources.conf</filename> is included in all + <filename>user-<replaceable>UID</replaceable>.slice</filename> units, see + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for a discussion of the drop-in mechanism.</para> + + <para>When a user logs in and a .scope unit is created for the session (see previous section), + the creation of the scope may be managed through + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + This PAM module communicates with + <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry> + to create the session scope and provide access to hardware resources. Resource limits for the + scope may be configured through the PAM module configuration, see + <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + Configuring them through the normal unit configuration is also possible, but since + the name of the slice unit is generally unpredictable, this is less useful.</para> + + <para>In general any resources that apply to units may be set for + <filename>user@<replaceable>UID</replaceable>.service</filename> and the slice + units discussed above, see + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for an overview.</para> + </refsect1> + + <refsect1> + <title>Examples</title> + <example> + <title>Hierarchy of control groups with two logged in users</title> + + <programlisting>$ systemd-cgls +Control group /: +-.slice +├─user.slice +│ ├─user-1000.slice +│ │ ├─user@1000.service +│ │ │ ├─pulseaudio.service +│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no +│ │ │ └─gnome-terminal-server.service +│ │ │ └─init.scope +│ │ │ ├─ 4127 /usr/libexec/gnome-terminal-server +│ │ │ └─ 4198 zsh +│ │ … +│ │ └─session-4.scope +│ │ ├─ 1264 gdm-session-worker [pam/gdm-password] +│ │ ├─ 2339 /usr/bin/gnome-shell +│ │ … +│ │ ├─session-19.scope +│ │ ├─6497 sshd: zbyszek [priv] +│ │ ├─6502 sshd: zbyszek@pts/6 +│ │ ├─6509 -zsh +│ │ └─6602 systemd-cgls --no-pager +│ … +│ └─user-1001.slice +│ ├─session-20.scope +│ │ ├─6675 sshd: guest [priv] +│ │ ├─6708 sshd: guest@pts/6 +│ │ └─6717 -bash +│ └─user@1001.service +│ ├─init.scope +│ │ ├─6680 /usr/lib/systemd/systemd --user +│ │ └─6688 (sd-pam) +│ └─sleep.service +│ └─6706 /usr/bin/sleep 30 +…</programlisting> + <para>User with UID 1000 is logged in using <command>gdm</command> (<filename + index="false">session-4.scope</filename>) and + <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry> + (<filename index="false">session-19.scope</filename>), and also has a user manager instance + running (<filename index="false">user@1000.service</filename>). User with UID 1001 is logged + in using <command>ssh</command> (<filename index="false">session-20.scope</filename>) and + also has a user manager instance running (<filename + index="false">user@1001.service</filename>). Those are all (leaf) system units, and form + part of the slice hierarchy, with <filename index="false">user-1000.slice</filename> and + <filename index="false">user-1001.slice</filename> below <filename + index="false">user.slice</filename>. User units are visible below the + <filename>user@.service</filename> instances (<filename + index="false">pulseaudio.service</filename>, <filename + index="false">gnome-terminal-server.service</filename>, <filename + index="false">init.scope</filename>, <filename index="false">sleep.service</filename>). + </para> + </example> + + <example> + <title>Default user resource limits</title> + + <programlisting>$ systemctl cat user-1000.slice +# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf +# … +[Unit] +Description=User Slice of UID %j +After=systemd-user-sessions.service + +[Slice] +TasksMax=33%</programlisting> + <para>The <filename>user-<replaceable>UID</replaceable>.slice</filename> units by default don't + have a unit file. The resource limits are set through a drop-in, which can be easily replaced + or extended following standard drop-in mechanisms discussed in the first section.</para> + </example> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> +</refentry> diff --git a/man/userdbctl.xml b/man/userdbctl.xml new file mode 100644 index 0000000..0c2dd73 --- /dev/null +++ b/man/userdbctl.xml @@ -0,0 +1,272 @@ +<?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-or-later --> + +<refentry id="userdbctl" conditional='ENABLE_USERDB' + xmlns:xi="http://www.w3.org/2001/XInclude"> + + <refentryinfo> + <title>userdbctl</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>userdbctl</refentrytitle> + <manvolnum>1</manvolnum> + </refmeta> + + <refnamediv> + <refname>userdbctl</refname> + <refpurpose>Inspect users, groups and group memberships</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <cmdsynopsis> + <command>userdbctl</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="req">COMMAND</arg> + <arg choice="opt" rep="repeat">NAME</arg> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>userdbctl</command> may be used to inspect user and groups (as well as group memberships) + of the system. This client utility inquires user/group information provided by various system services, + both operating on JSON user/group records (as defined by the <ulink + url="https://systemd.io/USER_RECORD">JSON User Record</ulink> and <ulink + url="https://systemd.io/GROUP_RECORD">JSON Group Record</ulink> definitions), and classic UNIX NSS/glibc + user and group records. This tool is primarily a client to the <ulink + url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + + <varlistentry> + <term><option>--output=</option><replaceable>MODE</replaceable></term> + + <listitem><para>Choose the output mode, takes one of <literal>classic</literal>, + <literal>friendly</literal>, <literal>table</literal>, <literal>json</literal>. If + <literal>classic</literal>, an output very close to the format of <filename>/etc/passwd</filename> or + <filename>/etc/group</filename> is generated. If <literal>friendly</literal> a more comprehensive and + user friendly, human readable output is generated; if <literal>table</literal> a minimal, tabular + output is generated; if <literal>json</literal> a JSON formatted output is generated. Defaults to + <literal>friendly</literal> if a user/group is specified on the command line, + <literal>table</literal> otherwise.</para> + + <para>Note that most output formats do not show all available information. In particular, + <literal>classic</literal> and <literal>table</literal> show only the most important fields. Various + modes also do not show password hashes. Use <literal>json</literal> to view all fields, including + any authentication fields.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>--service=</option><replaceable>SERVICE</replaceable><optional>:<replaceable>SERVICE…</replaceable></optional></term> + <term><option>-s</option> <replaceable>SERVICE</replaceable>:<replaceable>SERVICE…</replaceable></term> + + <listitem><para>Controls which services to query for users/groups. Takes a list of one or more + service names, separated by <literal>:</literal>. See below for a list of well-known service + names. If not specified all available services are queried at once.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--with-nss=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Controls whether to include classic glibc/NSS user/group lookups in the output. If + <option>--with-nss=no</option> is used any attempts to resolve or enumerate users/groups provided + only via glibc NSS is suppressed. If <option>--with-nss=yes</option> is specified such users/groups + are included in the output (which is the default).</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--synthesize=</option><replaceable>BOOL</replaceable></term> + + <listitem><para>Controls whether to synthesize records for the root and nobody users/groups if they + aren't defined otherwise. By default (or <literal>yes</literal>) such records are implicitly + synthesized if otherwise missing since they have special significance to the OS. When + <literal>no</literal> this synthesizing is turned off.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-N</option></term> + + <listitem><para>This option is short for <option>--with-nss=no</option> + <option>--synthesize=no</option>. Use this option to show only records that are natively defined as + JSON user or group records, with all NSS/glibc compatibility and all implicit synthesis turned + off.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="no-pager" /> + <xi:include href="standard-options.xml" xpointer="no-legend" /> + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </refsect1> + + <refsect1> + <title>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + + <varlistentry> + <term><command>user</command> <optional><replaceable>USER</replaceable>…</optional></term> + + <listitem><para>List all known users records or show details of one or more specified user + records. Use <option>--output=</option> to tweak output mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>group</command> <optional><replaceable>GROUP</replaceable>…</optional></term> + + <listitem><para>List all known group records or show details of one or more specified group + records. Use <option>--output=</option> to tweak output mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>users-in-group</command> <optional><replaceable>GROUP</replaceable>…</optional></term> + + <listitem><para>List users that are members of the specified groups. If no groups are specified list + all user/group memberships defined. Use <option>--output=</option> to tweak output + mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>groups-of-user</command> <optional><replaceable>USER</replaceable>…</optional></term> + + <listitem><para>List groups that the specified users are members of. If no users are specified list + all user/group memberships defined (in this case <command>groups-of-user</command> and + <command>users-in-group</command> are equivalent). Use <option>--output=</option> to tweak output + mode.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>services</command></term> + + <listitem><para>List all services currently providing user/group definitions to the system. See below + for a list of well-known services providing user information.</para></listitem> + </varlistentry> + + <varlistentry> + <term><command>ssh-authorized-keys</command></term> + + <listitem><para>This operation is not a public, user-facing interface. It is used to allow the SSH daemon to pick + up authorized keys from user records, see below.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Well-Known Services</title> + + <para>The <command>userdbctl services</command> command will list all currently running services that + provide user or group definitions to the system. The following well-known services are shown among + this list:</para> + + <variablelist> + <varlistentry> + <term><constant>io.systemd.DynamicUser</constant></term> + + <listitem><para>This service is provided by the system service manager itself (i.e. PID 1) and + makes all users (and their groups) synthesized through the <varname>DynamicUser=</varname> setting in + service unit files available to the system (see + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details about this setting).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>io.systemd.Home</constant></term> + + <listitem><para>This service is provided by + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and makes all users (and their groups) belonging to home directories managed by that service + available to the system.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>io.systemd.Machine</constant></term> + + <listitem><para>This service is provided by + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and synthesizes records for all users/groups used by a container that employs user + namespacing.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>io.systemd.Multiplexer</constant></term> + + <listitem><para>This service is provided by + <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and multiplexes user/group look-ups to all other running lookup services. This is the primary entry point + for user/group record clients, as it simplifies client side implementation substantially since they + can ask a single service for lookups instead of asking all running services in parallel. + <command>userdbctl</command> uses this service preferably, too, unless <option>--with-nss=</option> + or <option>--service=</option> are used, in which case finer control over the services to talk to is + required.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>io.systemd.NameSeviceSwitch</constant></term> + + <listitem><para>This service is (also) provided by + <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + and converts classic NSS/glibc user and group records to JSON user/group records, providing full + backwards compatibility. Use <option>--with-nss=no</option> to disable this compatibility, see + above. Note that compatibility is actually provided in both directions: + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> will + automatically synthesize classic NSS/glibc user/group records from all JSON user/group records + provided to the system, thus using both APIs is mostly equivalent and provides access to the same + data, however the NSS/glibc APIs necessarily expose a more reduced set of fields + only.</para></listitem> + </varlistentry> + </variablelist> + + <para>Note that <command>userdbctl</command> has internal support for NSS-based lookups too. This means + that if neither <constant>io.systemd.Multiplexer</constant> nor + <constant>io.systemd.NameSeviceSwitch</constant> are running look-ups into the basic user/group + databases will still work.</para> + </refsect1> + + <refsect1> + <title>Integration with SSH</title> + + <para>The <command>userdbctl</command> tool may be used to make the list of SSH authorized keys possibly + contained in a user record available to the SSH daemon for authentication. For that configure the + following in <citerefentry + project='die-net'><refentrytitle>sshd_config</refentrytitle><manvolnum>5</manvolnum></citerefentry>:</para> + + <programlisting>… +AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u +AuthorizedKeysCommandUser root +…</programlisting> + </refsect1> + + <refsect1> + <title>Exit status</title> + + <para>On success, 0 is returned, a non-zero failure code otherwise.</para> + </refsect1> + + <xi:include href="less-variables.xml" /> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/vconsole.conf.xml b/man/vconsole.conf.xml new file mode 100644 index 0000000..378812b --- /dev/null +++ b/man/vconsole.conf.xml @@ -0,0 +1,144 @@ +<?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-or-later --> + +<refentry id="vconsole.conf" conditional='ENABLE_VCONSOLE'> + <refentryinfo> + <title>vconsole.conf</title> + <productname>systemd</productname> + </refentryinfo> + + <refmeta> + <refentrytitle>vconsole.conf</refentrytitle> + <manvolnum>5</manvolnum> + </refmeta> + + <refnamediv> + <refname>vconsole.conf</refname> + <refpurpose>Configuration file for the virtual console</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <para><filename>/etc/vconsole.conf</filename></para> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>The <filename>/etc/vconsole.conf</filename> file configures + the virtual console, i.e. keyboard mapping and console font. It is + applied at boot by udev using <filename>90-vconsole.rules</filename> file. + You can safely mask this file if you want to avoid this kind of initialization. + </para> + + <para>The basic file format of the + <filename>vconsole.conf</filename> is a newline-separated list of + environment-like shell-compatible variable assignments. It is + possible to source the configuration from shell scripts, however, + beyond mere variable assignments no shell features are supported, + allowing applications to read the file without implementing a + shell compatible execution engine.</para> + + <para>Note that the kernel command line options + <varname>vconsole.keymap=</varname>, + <varname>vconsole.keymap_toggle=</varname>, + <varname>vconsole.font=</varname>, + <varname>vconsole.font_map=</varname>, + <varname>vconsole.font_unimap=</varname> may be used + to override the console settings at boot.</para> + + <para>Depending on the operating system other configuration files + might be checked for configuration of the virtual console as well, + however only as fallback.</para> + + <para><filename>/etc/vconsole.conf</filename> is usually created and updated + using + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + <citerefentry><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be used to instruct <command>systemd-localed.service</command> to + query or update configuration.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist class='environment-variables'> + + <varlistentry> + <term><varname>KEYMAP=</varname></term> + <term><varname>KEYMAP_TOGGLE=</varname></term> + + <listitem><para>Configures the key mapping table for the keyboard. + <varname>KEYMAP=</varname> defaults to <literal>us</literal> if not set. The + <varname>KEYMAP_TOGGLE=</varname> can be used to configure a second toggle keymap and is by + default unset.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>FONT=</varname></term> + <term><varname>FONT_MAP=</varname></term> + <term><varname>FONT_UNIMAP=</varname></term> + + <listitem><para>Configures the console font, the console map + and the unicode font map.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Kernel Command Line</title> + + <para>A few configuration parameters from <filename>vconsole.conf</filename> may be overridden + on the kernel command line:</para> + + <variablelist class='kernel-commandline-options'> + <varlistentry> + <term><varname>vconsole.keymap=</varname></term> + <term><varname>vconsole.keymap_toggle=</varname></term> + + <listitem><para>Overrides <varname>KEYMAP=</varname> and <varname>KEYMAP_TOGGLE=</varname>. + </para></listitem> + </varlistentry> + <varlistentry> + + <term><varname>vconsole.font=</varname></term> + <term><varname>vconsole.font_map=</varname></term> + <term><varname>vconsole.font_unimap=</varname></term> + + <listitem><para>Overrides <varname>FONT=</varname>, <varname>FONT_MAP=</varname>, and + <varname>FONT_UNIMAP=</varname>.</para></listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Example</title> + + <example> + <title>German keyboard and console</title> + + <para><filename>/etc/vconsole.conf</filename>:</para> + + <programlisting>KEYMAP=de-latin1 +FONT=eurlatgr</programlisting> + </example> + + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry project='die-net'><refentrytitle>setfont</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/vtable-example.c b/man/vtable-example.c new file mode 100644 index 0000000..dede12b --- /dev/null +++ b/man/vtable-example.c @@ -0,0 +1,94 @@ +#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_METHOD_WITH_ARGS_OFFSET( + "Method3", + SD_BUS_ARGS("s", string, "o", path), + SD_BUS_RESULT("s", returnstring), + method, offsetof(object, number), + SD_BUS_VTABLE_UNPRIVILEGED), + SD_BUS_METHOD_WITH_ARGS( + "Method4", + SD_BUS_NO_ARGS, + SD_BUS_NO_RESULT, + method, + SD_BUS_VTABLE_UNPRIVILEGED), + SD_BUS_SIGNAL( + "Signal1", + "so", + 0), + SD_BUS_SIGNAL_WITH_NAMES( + "Signal2", + "so", SD_BUS_PARAM(string) SD_BUS_PARAM(path), + 0), + SD_BUS_SIGNAL_WITH_ARGS( + "Signal3", + SD_BUS_ARGS("s", string, "o", path), + 0), + 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 0000000..a3cdeae --- /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> + diff --git a/man/yubikey-crypttab.sh b/man/yubikey-crypttab.sh new file mode 100644 index 0000000..651246d --- /dev/null +++ b/man/yubikey-crypttab.sh @@ -0,0 +1,50 @@ +# Make sure no one can read the files we generate but us +umask 077 + +# Destroy any old key on the Yubikey (careful!) +ykman piv reset + +# Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'. +ykman piv generate-key -a RSA2048 9d pubkey.pem + +# Create a self-signed certificate from this public key, and store it on the +# device. The "subject" should be an arbitrary string to identify the token in +# the p11tool output below. +ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem + +# Check if the newly create key on the Yubikey shows up as token in PKCS#11. Have a look at the output, and +# copy the resulting token URI to the clipboard. +p11tool --list-tokens + +# Generate a (secret) random key to use as LUKS decryption key. +dd if=/dev/urandom of=plaintext.bin bs=128 count=1 + +# Encode the secret key also as base64 text (with all whitespace removed) +base64 < plaintext.bin | tr -d '\n\r\t ' > plaintext.base64 + +# Encrypt this newly generated (binary) LUKS decryption key using the public key whose private key is on the +# Yubikey, store the result in /etc/cryptsetup-keys.d/mytest.key, where we'll look for it during boot. +mkdir -p /etc/cryptsetup-keys.d +sudo openssl rsautl -encrypt -pubin -inkey pubkey.pem -in plaintext.bin -out /etc/cryptsetup-keys.d/mytest.key + +# Configure the LUKS decryption key on the LUKS device. We use very low pbkdf settings since the key already +# has quite a high quality (it comes directly from /dev/urandom after all), and thus we don't need to do much +# key derivation. Replace /dev/sdXn by the partition to use (e.g. sda1) +sudo cryptsetup luksAddKey /dev/sdXn plaintext.base64 --pbkdf=pbkdf2 --pbkdf-force-iterations=1000 + +# Now securely delete the plain text LUKS key, we don't need it anymore, and since it contains secret key +# material it should be removed from disk thoroughly. +shred -u plaintext.bin plaintext.base64 + +# We don't need the public key anymore either, let's remove it too. Since this one is not security +# sensitive we just do a regular "rm" here. +rm pubkey.pem + +# Test: Let's run systemd-cryptsetup to test if this all worked. The option string should contain the full +# PKCS#11 URI we have in the clipboard; it tells the tool how to decipher the encrypted LUKS key. Note that +# systemd-cryptsetup automatically searches for the encrypted key in /etc/cryptsetup-keys.d/, hence we do +# not need to specify the key file path explicitly here. +sudo systemd-cryptsetup attach mytest /dev/sdXn - 'pkcs11-uri=pkcs11:…' + +# If that worked, let's now add the same line persistently to /etc/crypttab, for the future. +sudo bash -c 'echo "mytest /dev/sdXn - \'pkcs11-uri=pkcs11:…\'" >> /etc/crypttab' |